Four ways a first-party install still loses data

First-party collection solves a specific problem: requests to a known third-party analytics domain get blocked, at scale, by browser tracking prevention and by extension blocklists. Move collection under the domain being measured and that particular loss goes away, because there is no third-party request left to match against a list.

It is a real improvement and it is routinely oversold. Several other failure modes survive the move untouched, and if you switch to first-party expecting your numbers to become complete, you will be disappointed in ways that are harder to diagnose than the thing you fixed.

The most common loss has nothing to do with blocking. A visitor converts, the page navigates away, and the event never leaves the browser because a normal fetch was cancelled on unload.

This bites hardest exactly where it matters most — conversion events fire immediately before a redirect to a thank-you page or a payment provider. The fix is well known: send terminal events with the beacon API, or with a keepalive request, so the browser completes them after the document is gone. It is also frequently missing from implementations that are otherwise careful, because it only shows up as a small, consistent undercount on the single most important event.

First-party collection does not give you a durable visitor identity. The identifier still lives in browser storage, and it still disappears with private browsing, storage clearing, device switching, and — on some platforms — after a period of inactivity.

Practically, this means multi-session paths get truncated. A visitor who researches on mobile over two weeks and converts on desktop is at least two visitors, and the conversion is attributed to whatever the last session's source was. No collection architecture fixes this on its own. What you can do is know the size of the effect for your business rather than assuming it away: if a meaningful share of your conversions come from long consideration cycles, your source attribution is noisier than the dashboard implies.

Where consent is required and not given, you do not collect. That is a legal constraint, not a technical one, and it does not care whose domain the request goes to. Any vendor implying that first-party collection routes around consent requirements is describing something you should not want.

The measurable consequence is that in consent-heavy markets your data is a sample, with a bias — the people who decline are not a random subset. Reporting that presents it as a census is wrong in a way that compounds over time.

The largest category of missing data in most implementations is not blocked or dropped. It was never sent, because nobody instrumented it.

A checkout that spans a third-party payment page, a form that submits through an embedded widget, a booking that completes inside an iframe from a scheduling vendor — these produce conversions the site never sees unless someone deliberately wired them up. Moving to first-party collection does nothing here. Finding these is manual work: walk every path to the conversion event and check what actually fires at the end of each one.

It removes domain-level blocking, it takes the measurement layer off an ad-tech vendor's infrastructure, and it stops your visitor data being one input into someone else's cross-site graph. Those are good reasons and they are sufficient on their own.

It is not a completeness guarantee, and treating it as one means the remaining gaps go uninvestigated — which is worse than knowing you had them.