The anonymous-to-known gap: why you can't connect the click to the customer

Every company has two databases that never talk to each other.

Database one — your analytics — is full of anonymous visitors. Sessions, page paths, referrers, campaigns. It knows a great deal about behaviour and nothing at all about people.

Database two — your application — is full of customers. Emails, orders, subscriptions, support tickets. It knows a great deal about people and nothing at all about how they arrived.

The join between them does not exist. That missing join is the single largest cause of bad acquisition attribution, and it is not a browser problem, a cookie problem or a privacy problem. It is a row nobody wrote.

What it costs

Here is a customer, in one business, spread across two systems that never met:

Ask “which campaign acquired this $129 customer?” and neither system can answer. Analytics saw the Facebook click but has no idea it became a customer. The application has the customer and the order but no idea a Facebook click ever happened.

The honest answer available to most companies is: we don’t know. So the sale gets credited to email, the Facebook campaign shows a CPA that gets it paused, and the machine that was generating customers gets switched off for underperforming.

The bridge

The fix is one call, at the moment an email legitimately arrives:

flowsk.identify("hello@example.com", { via: "newsletter" })

or, better, from your server where you know what actually caused it:

{
  "source": "server",
  "category": "identification",
  "name": "lead_captured",     // ← the cause, which the browser cannot know
  "email": "hello@example.com",
  "dedup_key": "subscriber_9182"
}

What that does is retroactive, and that is the important word. Every anonymous session that visitor ever had now belongs to a named person. Day 0’s Facebook click is no longer an orphan; it is the first touch of a customer who bought on day 11.

And it works forwards too: every future purchase by that person inherits the campaign that acquired them. Month twelve’s renewal is still credited to the ad that started it.

Why “what caused it” matters

identify(email) says we learned an email. It does not say why, and the browser has no reliable way to know.

Your server does. It knows whether this was a newsletter subscription, a gated download, an account creation, a demo request or a checkout. Those are wildly different intent signals, and having the cause on the person record is the difference between “we have 4,000 emails” and “we have 340 people who requested a demo, and here is where each of them came from.”

Where the cookie still matters

The bridge only works if the anonymous history is still there when the email arrives.

If the visitor’s id expired after seven days — which it does, in Safari, for any JavaScript-set cookie — then the day-0 Facebook click is already gone by the time they subscribe on day 4 as a “new” visitor. The join happens, but there is nothing on the other side of it.

So the two fixes are complements, not alternatives:

• A durable server-set id keeps the anonymous history alive long enough to be claimed.
• An early identification claims it, and takes over from the cookie permanently.

Get both and the seven-day cap stops being your ceiling. Get neither and every considered purchase in your business is attributed to whatever happened to be last.

The practical sequence

1. Find every place an email enters your system. There are more than you think — forms, checkout, support, imports.
2. Call identify from the server at each one, with the cause recorded.
3. Make sure the anonymous id is durable, so there is a history to claim. See proxy setup.
4. Then look at first-touch by campaign. It will not resemble your last-touch report, and the difference is what your acquisition channels were always worth.

The mechanics of merging identities — two devices, out-of-order events, one person — are covered in identity resolution.