Back to blog
Attribution3 min read

A higher match rate doesn't mean a more accurate one

Any vendor that guesses at identity shows you higher coverage. The extra is exactly the part that might be wrong. Here's the difference between the two error types, and how to raise coverage without guessing.
Any vendor that guesses at identity shows you higher coverage. The extra is exactly the part that might be wrong. Here's the difference between the two error types, and how to raise coverage without guessing.

A household with one iPad, shared by a teenager and a parent. The teenager browses sportswear at night, and a week later the parent buys a pair as a gift from their own phone.

Any system that merges records on behavioural similarity will say those are one person. They're two, and the journey that comes out of the merge is one neither of them took.

One iPad, two people in the house

This repeats every day in real stores: same network, same device, similar browsing patterns. A vendor running probabilistic matching reads that similarity and merges.

The result looks clean in the report. One customer, with a journey combining a teenager's browsing and a parent's purchase. Every downstream figure about that customer is fiction, and nothing on the screen tells you it is.

That's why the coverage number from a vendor that guesses can't be compared directly with the number from a vendor doing deterministic matching only. The two figures don't mean the same thing.

A missed merge and a wrong merge

A missed merge leaves one customer looking like two. Your repeat rate reads low, your customer count reads high, and a channel is under-credited. Each of those errors runs in a direction you know, and each shows up as a number that looks worse than reality.

A wrong merge invents a journey. An order gets credited to a channel that never touched the buyer, and you raise that channel's budget on the strength of it.

Both are errors, and only one of them is safe to have. An under-count is conservative: you'll under-credit some channels and be slower to scale, which is a bounded cost you can reason about because you know which way it runs. An over-merge isn't bounded. It produces confident, specific, wrong attributions, and nothing in any report separates them from the correct ones.

The test to put to any vendor: if a matching decision were wrong, could I find out? With deterministic matching the answer is usually yes, because the identifiers are recorded and you can open them. With similarity matching, no, because the evidence of the mistake is the merged record itself.

What counts as identity evidence

Same email, same phone, or same store customer ID. An order ID that ties a session to a sale. A click identifier that the ad platform and your store both recognise.

What doesn't count, however tempting:

  • two devices on the same network at the same time of day
  • similar browsing patterns
  • the same city and device model
  • a household IP address

The difference between the two lists is that the first is identifiers handed to you by the customer or the platform, and the second is inferences you produce yourself. An inference is fine in a rough report. It isn't a foundation for a customer record you'll build budgets, audiences and lifetime value on.

How to raise your match rate without guessing

What deterministic matching needs isn't more cleverness, it's more identifiers. Sending more of them raises real coverage:

Add this identifierWhat it recovers
Phone at checkoutCustomers using relay email addresses
Store customer IDRepeat buyers across devices
Click identifiersThe link between an order and ad spend
Order IDThe session-to-sale connection

Every row above raises the match rate on evidence, and that's the coverage worth paying for. Start with the first row because it's the easiest: a phone field at checkout that travels with the order.

One more difference worth noting. These identifiers reach you from the order record rather than the page. The order record arrives even when the browser blocked the script or the cookie expired, so coverage from that route isn't affected by the same causes that lose you browser events.

In Flowfy, deterministic matching across fourteen identifier types is live today, with history backfill on identification, and known relay-email patterns aren't used as identity keys. No merge is made on behavioural similarity.

Common questions

Is my match rate lower than it would be elsewhere? Probably, and that's the design. The right comparison isn't rate against rate, it's rate against how much of it you can stand behind.

How do I raise it honestly? Send more real identifiers, meaning phone, customer ID and order ID, from the order record rather than from the page.

What about customers who never identify themselves? They keep their anonymous profile and their history. If they ever buy, that history reattaches to the resolved identity.

Does this weaken lookalike audiences? The opposite. A seed built from confidently resolved repeat buyers beats a larger seed containing invented customers.

Open the record and see what caused the merge

And if your rate today is lower than you want, send phone and customer ID with the order and look again after a month. That's an increase you can explain.