Enhanced measurements

The extra facts your site can hand the tracker with no event code: 404s, site searches, authors and categories, logged-in status, ecommerce revenue, chosen query parameters and affiliate links.

Some of the most useful facts about a page load are things only your server knows: that the response was a 404, what someone typed into your search box, who wrote the post, whether the reader was signed in. Numative collects these as properties on the pageview the tracker was going to send anyway.

That choice matters to your bill. A 404 page load is already a pageview, so tagging it costs nothing extra against your event quota and every existing report can be narrowed to it. Sending a second event for the same page load, as some tools do, bills you twice for one fact and leaves two rows to reconcile.

The quickest route: WordPress

The Numative Analytics plugin has a checkbox for each of these under Numative > Settings. Nothing else to write.

MeasurementWhat you getDefault
404 error pagesBroken URLs and the links pointing at them, under Pages > Not found.On
Search queriesWhat people typed into your site's search box, and how many results came back. Under Pages > Site search.On
Authors and categoriesEach post tagged with its author and its taxonomy terms, so you can compare writers and topics. Every public taxonomy is included, not just categories.Off
Logged-in user statusWhether the reader was signed in, so members and visitors can be compared. Never who they are.Off
Ecommerce revenueA Purchase event with the order total when a WooCommerce or Easy Digital Downloads order completes, attributed to the visit that earned it.Off
Hash-based routingCounts #fragment changes as pageviews, for themes that navigate with the hash.Off

Ecommerce is the one exception to the rule above: a completed purchase genuinely is a new event, not a page load, and it carries money. Each order is marked as reported the first time its receipt renders, so a refresh or a second visit to the receipt URL sends nothing.

Any other stack

Print a data-props attribute on the snippet with whatever your server knew about this request. The values ride every pageview from that page as properties. Use JSON, with string, number or boolean values:

A 404 page's snippethtml
<script
  defer
  src="https://app.numative.com/numative.js"
  data-site="YOUR_SITE_ID"
  data-props='{"http_status":"404"}'
></script>
A search results page, and a posthtml
data-props='{"search_query":"pricing","search_results":"0"}'

data-props='{"author":"Jane Doe","category":"Guides","logged_in":"false"}'

Malformed JSON never costs you the pageview: the attribute is ignored and the visit is still counted. Nested objects and arrays are dropped; the same property limits apply as to any event.

Numative's Pages section looks for two specific names. Use http_status with the value 404 for the Not found lens, and search_query plus search_results for Site search. Everything else is a property like any other, breakable down under Properties and usable as a filter across the whole dashboard.

Form completions

The tracker records every form that actually submits, with no code at all. A form appears under Interactions > Forms on the Overview, named by its own name, id or aria-label.

Submissions are reported beside attempts, which is the pairing that makes the number useful. A click on a submit button happens whether or not the form validated, so clicks without submissions is what client-side validation failure looks like from the outside, and neither half shows it alone. A form with 400 attempts and 120 completions has a problem no conversion rate would have named.

  • Field values are never read. What is recorded is the form's structural selector, its authored name, its action stripped to origin and path, and how many fields it has.
  • Capture happens even when your own validation code stops the event from bubbling, and is capped per page load so a form submitted in a loop cannot become its own firehose.
  • Form events are stored as reserved events, so they are unbilled and never appear in your custom-event lists.
  • Turn it off with data-forms="false" on the snippet.

Query parameters worth keeping

By default Numative groups URLs by path, so /pricing?ref=x and /pricing?ref=y are one page. Keeping the whole query string instead turns one page into a thousand paths. Naming individual parameters is the finer instrument between the two.

Under Settings > Capture query parameters, list one parameter name per line. Each is stored as a property on the pageview, so the page stays a single row while the value becomes something you can break any report down by, or filter the dashboard on.

  • It is an allowlist on purpose. Query strings routinely carry email addresses and password-reset tokens, and nothing you have not named is ever stored.
  • Up to 12 parameters per site, values kept to 200 characters.
  • UTM parameters already have their own reports and are ignored if listed, as are names Numative uses itself.

A cloaked affiliate link is an internal link: /go/thing on your own domain, redirecting somewhere else. The browser has no way to know that, so those clicks land among your ordinary internal links.

Under Settings > Affiliate link paths, list the paths you use for them, one per line. Clicks on matching links are then reported separately under Interactions > Affiliate rather than counted as visits to a page on your own site.

PatternMatches
/goThat exact path and everything under it, so /go/hosting counts without a wildcard.
/recommends/*Anything under /recommends/. Use * only where a pattern needs to end in one.

Nothing extra is captured for these: autocapture already recorded the click. All the setting supplies is the knowledge that the destination is somebody else's site.

Everything on this page needs the Numative tracker. A site reading Google Analytics only has no pageview of its own to attach these to.