Profile merging across devices: how identity resolution actually works

A person finds you on a phone during a commute, looks again on a work laptop at lunch, and buys on a tablet that evening. That is one customer and three trails, and whether your marketing treats them as one determines whether any of your behavioural targeting is real.

The mechanism is unglamorous and it matters more than any segmentation rule you will write on top of it.

Create the profile on the first page view

The instinct is to create a customer record when somebody buys or subscribes. That is too late, because everything that led to the purchase happened before it and is thrown away.

1. A profile appears on the first page view, keyed to a first-party cookie, with nothing on it but that identifier.
2. Events attach to it from that moment — pages seen, products viewed, cart activity.
3. It gains a name and an email later, when they order or subscribe.

That ordering is the whole point. A profile created early has a history at the moment it identifies; one created at checkout is born with none, and no amount of later cleverness recovers it.

The identifiers that connect trails

• The first-party browser identifier. Strong within one browser, useless across devices, and it disappears when cookies are cleared.
• A hashed email address. The strongest cross-device signal, available the moment somebody identifies anywhere.
• The shop's own customer id, for anybody with an account. Authoritative when present.
• A cart token, which links an abandoned cart to the order it eventually became.

Match on the strong ones and treat the weak ones as supporting evidence. Never merge on a name, and never on an IP address — a household or an office shares both.

What has to happen at the moment of a merge

When two profiles turn out to be one person, the merge has to be complete or it creates a worse mess than it solved.

1. Oldest profile wins as the surviving record, so the earliest history is preserved.
2. Identities move across — every cookie id, every email hash, every customer id now points at the survivor.
3. Events move, keeping their original timestamps rather than the merge time.
4. Counts recompute rather than add naively, so an order counted on both sides does not become two.
5. Consent is unioned carefully. If one record consented and the other did not, take the most recent explicit decision, not the most permissive one.

Identity must not come from a context with no shopper in it

This is the trap that silently ruins the whole model. An order created in wp-admin by a staff member, or by WP-CLI during an import, runs in a request with the staff member's browser cookie attached.

If that cookie is treated as the shopper's identity, every order typed in by the same person collapses into one profile. A shop discovers this when one customer appears to have four hundred orders.

• Return no browser identifier outside a real shopper request. Admin context, CLI context and REST calls all qualify.
• Fall back to the email hash when there is no browser trail, which is the correct identity for an order typed in by hand.
• Pin it with a test, because it is invisible until it is very visible.

What to expect from the numbers

Merging changes counts, and it is worth knowing which way before somebody asks.

• Your visitor count falls as trails combine. This is correction, not loss.
• Repeat purchase rate rises, because orders previously split across two records now sit on one.
• The merge rate itself is a useful metric. A sudden change means something upstream altered how identity is collected — a checkout change, a consent banner change, a plugin update.