Appearance
First-party tracker
The first-party tracker is the one integration in this catalogue that is not a connection to somebody else's product. It is your own measurement, served from your own domain, landing in your own warehouse.
What the first-party tracker records
| Event type | What lands |
|---|---|
| Pageview | URL, path, referrer, title, timestamp, device class, session id |
| Custom events | Any event you define, with your own properties |
| Identify | A pseudonymous person id and the hashed identifiers that link sessions together |
| Consent state | Which categories the visitor granted, recorded with the event rather than assumed |
| Campaign parameters | UTM source, medium, campaign, content, term and the ad click ids |
The tracker is served from your own domain. Visitor IP addresses are used for coarse geography and then discarded, never landed. There is no third-party cookie and no cross-site identifier.
What the first-party tracker can be used for
A first-party tracker can be used for traffic measurement that survives consent and blockers. Third-party analytics scripts are blocked or consent-gated for a large share of visitors, and a first-party tracker records the visits they miss. How large the gap is on your site is something to measure rather than to assume, and measuring it is exactly what running both side by side gives you.
A first-party tracker can be used for deterministic purchase attribution. The session id is written onto the order at checkout, so the path from first visit to paid order is a join rather than a model.
A first-party tracker can be used for consent-aware reporting, because consent state is recorded per event and can be honoured in every query rather than applied as an afterthought.
A first-party tracker can be used for content performance measurement at the level of the individual article, scroll depth and outbound click.
A first-party tracker can be used for funnel analysis across sessions and devices, resolved on the identity graph without holding a name or an email address.
A first-party tracker can be used to feed the company brain, so an assistant knows which pages a visitor read before they opened chat.
The tracker combined with other integrations
| Combination | What it gives you |
|---|---|
| Tracker + Shopify | The full path from anonymous first visit to paid order, deterministically |
| Tracker + GA4 | The measurement gap. How much of your traffic your third-party analytics never sees |
| Tracker + Search Console | What the searcher did after they landed |
| Tracker + Klaviyo | On-site behaviour of email recipients, including the visits that did not convert |
| Tracker + Google Ads | Click id on the visit and on the order, so paid attribution needs no modelling |
| Tracker + chat widget | A conversation that starts already knowing which article the visitor was reading |
What you need to enable the tracker
- A subdomain of your own domain pointed at the collection endpoint
- The tag on your pages, or the built-in tag if the site is built in Studio
- A consent banner wired to the tracker's consent API, if you operate under the GDPR
Frequently asked
Is this GDPR compliant? It is built for it: EU hosted, first party, consent recorded per event, IP addresses discarded rather than stored, and pseudonymous identifiers rather than names. Compliance also depends on how you configure and disclose it, so read data governance alongside your own privacy statement.
Does it replace GA4? It can, and many sites run both deliberately so the gap between them stays visible.
Will ad blockers block it? It is served from your own domain as first-party, which removes the most common reason a tracker is blocked. No tracker is unblockable and we do not claim otherwise.
Where is the data stored? In your own cloud project, in the EU.