Customer journey & attribution

Verimetriq’s data layer answers a question most dashboards can’t: which spend produced which sale, across devices and over time. This page explains the model. To install it, see the Integration guide.

---

Why not just use GA?

Google Analytics keys a visitor on client_id, stored in the _ga cookie. That cookie rotates, and Safari’s ITP or a cleared browser wipe it — so a journey longer than a few weeks falls apart, and ad spend never lines up with the sale that followed. Facebook’s _fbp/fbclid behave the same way.

Your own key

Verimetriq keeps its own visitor_id — a first‑party UUID it sets and controls — as the primary key of the journey. The Google and Facebook identifiers are still captured, but as attributes of each event, not as the key. Reset _ga all you like: the journey holds.

Identity stitching

A person uses several browsers and devices, each with its own visitor_id. When they log in or leave a lead, your site calls vmq('identify', …). That links the current visitor_id to a person handle — a one‑way hash of the email or phone (keyed per organisation, so the same address hashes differently for different tenants, and raw values are never stored).

From then on, every device that shares a handle is one person. An ad click on a laptop and a purchase on a phone become a single, continuous journey.

Customer journey

Settings → Data layer → Customer journey takes an email or phone and shows the whole timeline across all of that person’s stitched devices — first ad touch, page views, identify, purchase — ordered by time, each device a distinct colour.

Campaign attribution & ROAS

Campaigns (SMS mailings) issue a unique link per recipient (…?vmq=<token>). A click is captured by the collector like any event, so “who clicked” needs no redirect service. Because the click is stitched to a person, a later purchase — on any device — is credited to that campaign:

• CAC per click = campaign cost ÷ clicks
• ROAS = attributed revenue ÷ campaign cost

Phone numbers are never stored — a mailing links to people by the same hash used for identity stitching.

---

What is collected

• visitor_id (first‑party UUID) and event timestamps, names, URLs, referrers
• UTM parameters, and _ga/_fbp/_fbc/gclid/fbclid as attributes
• Person handles as hashes only — never raw email or phone
• Any props your site chooses to send with an event

Collection is gated by consent (see the Integration guide).