How Tracking Works

This page explains what happens between a visitor clicking your campaign link and a lead appearing in your dashboard.

The capture flow

1. A visitor loads any front-end page. UTM Manager enqueues a small, deferred JavaScript file (tracker.js) that runs after the page has finished loading. It never blocks rendering.
2. The script identifies the visitor. It reads — or creates — a random visitor ID (a UUID) stored in a first-party cookie named utmm_vid and in localStorage. Keeping it in both places means the ID survives if either one is cleared. The cookie lives for one year.
3. The script reads the URL. It collects whichever tracked parameters are present in the page’s query string (the standard UTM keys, plus any custom keys registered by Pro or via the utmm_custom_param_keys filter).
4. The data is beaconed home. The script POSTs the visitor ID, page URL, title, referrer, and captured parameters to POST /wp-json/utmm/v1/track using navigator.sendBeacon (with a fetch fallback for older browsers). Fire-and-forget: the visitor never waits on it.
5. The server records the hit. The REST endpoint validates the request, keeps only the parameters you’ve enabled in Settings, and writes:
   • a lead row (created on first visit, updated on return visits), and
   • a visit row (one per page view — this builds the journey timeline).

First touch vs. last touch

Each lead stores two sets of attribution:

• First touch — the UTM values, landing page URL, and referrer from the visitor’s first ever recorded visit. Written once, never changed.
• Last touch — the UTM values from their most recent visit that carried UTM parameters. Refreshed on each UTM-tagged return visit.

A visit without UTM parameters never wipes attribution — it just increments the visit count and adds to the journey.

Visitor identity

Leads are deduplicated on the visitor ID — never on IP address. This matters because office networks, mobile carriers, and VPNs put many different people behind one IP.

Identity is enriched over time and never downgraded:

• If the visitor is logged in, their WordPress user ID and email are attached to the lead.
• Once an email or user ID is set, it is never overwritten by later anonymous visits.
• Display priority in the admin is: email → user display name → visitor ID.

Why it works behind page caching

Traditional tracking plugins capture data in PHP while the page is being generated. Behind a full-page cache (WP Rocket, Cloudflare, Varnish…), PHP never runs for cached hits — so those plugins silently record nothing.

UTM Manager’s capture happens in the browser, on every page view, cached or not. The beacon endpoint is the only server-side component, and REST API calls are never served from page caches.

The beacon includes an anti-abuse token generated when the page was rendered. If a page was cached for longer than the token’s lifetime, the endpoint falls back to verifying that the request genuinely originates from your own site, so tracking keeps working even behind very long-lived caches.

What is stored

Per lead: visitor ID, user ID + email (when known), first-touch UTM set + landing URL + referrer, last-touch UTM set, visit count, first/last-seen timestamps, and a salted hash of the IP (never the raw IP — see Privacy & GDPR).

Per visit: URL, page title, post ID, referrer, the UTM values on that specific view, timestamp, and the hashed IP.