Autocapture

The moment the VeritaMetrics script is installed, it records what people do on your site: clicks, form submissions, outbound links, downloads, scroll depth, and the two frustration signals. There is nothing to tag and no extra code to write.

What autocapture records

These events are captured automatically from the first pageview. This is the product-analytics layer (how visitors use your site), on top of the traffic counts.

How events appear in your dashboard

Top Events groups your events by name, so form_submit and Signup each appear as their own row with its own total. Open a row to drill in: the panel breaks that event down by the page it fired on, an element label, and the link destination.

A captured click looks like this on the wire, with the visible label attached as a property:

{ "n": "cta_click", "p": { "text": "Add to cart" } }

Name an element, and the click becomes a key

Autocapture already records the click. What it cannot know is which control you meant: every card on a page has an expander, they all say "Show more", and a label read off the page is a guess that changes the day somebody rewrites the copy. Putting data-verita-event-name on an element names the event yourself. The name survives a copy edit, a translation and a redesign, and it is what you turn into a goal. There is still no JavaScript to write.

It works on anything clickable. A button and a link are tagged the same way:

<button data-verita-event-name="signup" data-verita-prop-plan="pro">
  Sign up
</button>

<a href="/signup" data-verita-event-name="trial_start" data-verita-prop-plan="pro">
  Start a trial
</a>

Each data-verita-prop-* attribute becomes a property on the event. The part after the prefix is the property name, lowercased with hyphens turned into underscores, so data-verita-prop-cart-total arrives as cart_total. A tagged link reports under its own name rather than as an outbound or internal link, so tagging replaces the automatic event instead of adding a second one. See Custom events and definitions for how to name and shape events, and Goals and data export to turn a named event into a tracked conversion.

{ "n": "signup", "p": { "plan": "pro", "page_location": "/pricing", "label_source": "key" } }

Untagged elements still report, as a guess

Nothing has to be tagged. An untagged click is still captured, labelled from whatever the tracker could read off the page, and marked "label_source": "derived" so a report can tell the two apart. A derived click also carries context, the nearest heading above it, which is what separates two expanders that read the same:

<section><h3>Top Pages</h3><button>Show more</button></section>

{
  "n": "button_click",
  "p": { "text": "Show more", "context": "Top Pages", "label_source": "derived" }
}

The difference is worth knowing when you read a report. A key is a fact you chose: two elements with different keys stay two rows forever. A derived label is what the page said at the moment of the click, so it splits when the wording changes and merges when two controls happen to share it. context is absent rather than empty when no heading sits within six ancestors, because a context on every row would teach you to trust one.

Switching capture off for part of a page

Put data-verita-no-capture on any element and nothing inside it is captured: no clicks, and no rage or dead clicks either. Use it on an admin screen, a support console, or anywhere the labels on screen belong to your users rather than to you. It is checked before everything else, so it also suppresses elements you have tagged.

<section data-verita-no-capture>
  <button data-verita-event-name="delete_user">Delete</button>
</section>

Was it seen, or only shipped?

A click count cannot tell you whether the other visitors rejected a feature or never saw it, and those two need opposite fixes: one says redesign it, the other says move it up the page. Put data-verita-expose on an element and every page load reports whether it was rendered, whether it reached the screen, and whether anybody touched it. Seen means half the element on screen or half the screen filled by it, measured on the same clock as engaged time, so a tab left open in the background adds nothing.

<section data-verita-expose="pricing-table">
  ...
</section>

The value is a key you choose, not the element's text, so a report keyed on it does not split the day somebody edits the copy. One element_exposure event per tagged element arrives once you leave the page, carrying visible and interacted, and visible_ms only for an element that was actually seen:

{ "n": "element_exposure", "p": { "element": "pricing-table", "visible": true, "interacted": false, "visible_ms": 4200 } }

Track custom events in code (optional)

For actions that are not a click, call the tracking API directly. Events appear in your dashboard within seconds.

window.verita('trackEvent', 'video_complete', { title: 'Demo' });

See the Tracking API and the API reference for the full method list, including revenue tracking. To carry your own signed-in user's id on these events instead of the daily-salted default, see Identity Modes.

Names we already recognise

Any name works. These few are worth using verbatim, because they mean the same thing on every site and let a report compare one of yours against another. An action is opened and closed, so an attempt the visitor walked away from is counted as abandoned without you instrumenting the leaving; a moment is a single event.

Register the events you expect

In Tracking settings, list the custom event names you plan to send and, for any of them, the properties every occurrence must carry. The registry is what you expect, not a filter: an event that arrives under a name you have not registered, or missing a property you marked required, is stored exactly as sent. It is never dropped for failing the plan, so a typo in your own registry costs a wrong count, not a lost event.

A required property is a key and a type (string, number, or boolean) you declare for a registered event. An occurrence missing it, or sending the wrong type for it, is still recorded; the drift is listed instead of the write being refused.

Drift shows up on the Data quality list next to the registry, one row per event name and reason, with a count and when it was last seen. The reasons:

• unregistered_name — Event name is not in the tracking plan.
• invalid_outcome — Action outcome is not one of the allowed values.
• missing_property — Missing required property "plan".
• wrong_type — Property "plan" has the wrong type.
• overflow — More distinct violations than we track individually for this site.

Privacy

Every autocaptured event is anonymous by default. It is tied to the daily-salted visit identifier that resets every 24 hours, sets no cookies, and stores no IP address, so you get behavioural insight without tracking a person across days. A site switched to pseudonymous mode carries its own supplied id on these events instead, stable across days by design; the cookie and IP handling stay the same. See how a pageview works for the anonymous-mode mechanism.