Cross-Device Analytics

Somebody sees a jacket on their phone during a lunch break. That evening they look at it properly on a laptop and read the returns policy. Two days later they buy it on a tablet.

One person, one decision, one purchase. Adobe Analytics reports three visitors, three visits and three separate first touches. The paid social click that started it is on the phone. The purchase is on the tablet. So the attribution report credits the purchase to whatever brought the tablet in, which is usually direct traffic or nothing at all.

Every number there is correct, and the picture is wrong.

A visitor is a browser, not a person

The unit Adobe Analytics counts is a browser holding a cookie. That is what a visitor has always meant, and it is set out in Key Terminology and again in Experience Cloud ID (ECID).

Nobody is confused about this in principle. The confusion arrives in practice. A Unique Visitors figure gets quoted in a meeting as a number of people, somebody compares it to the CRM, and it is two or three times too large. The analytics is doing what it says. It counts devices, and it is being read as though it counted people.

The error runs one way only. Devices always overstate people, never the reverse. How much depends on your customers rather than your implementation. A banking app where everyone signs in on one phone is close to accurate. A retailer whose customers browse at work and buy at home is not.

One sign-in resolves the whole device

The mechanism is the same idea in both products, and it is worth holding as one sentence before any configuration makes sense.

Every event carries a persistent ID, which is the device or cookie identifier. Some events also carry a transient ID, which identifies a person, usually written when they sign in. When a transient ID appears on an event, the system looks at every other event sharing that persistent ID and rekeys them to the same person. That includes events from before the sign-in.

So one login on a device resolves that device's history backward. That is the whole trick, and it explains both what stitching can do and what it cannot.

That last box is the part to carry into a stakeholder conversation. Stitching resolves devices that have seen an authenticated event. A device that never signs in has nothing to attach it to, so it stays what it was. Your reported people count comes down, the picture improves, and it is still an approximation whose quality is set by how many customers sign in.

Two products, two implementations

The idea is shared. Almost everything practical about it differs.

Read the last row on the Adobe Analytics side before promising anything. It is longer than people expect and it removes tools teams use daily. A stitched virtual report suite that cannot be reached from Report Builder is a real constraint for a finance team who live in spreadsheets.

The identifier is an implementation decision

Neither product can stitch anything without a reliable identifier on authenticated events, and that identifier has to be created by the website or the app.

Three things have to be true of it. It has to be stable, so the same person produces the same value in March and in November. It has to be present on every authenticated event rather than only at sign-in, because a value that appears once gives the system a single event to work with. And it must never be a raw email address or anything else that identifies a person directly.

That third point is not theoretical. When the Kestrel and Co. implementation was tested on 22 May, the customer ID arrived as a raw email address. Testing stopped and it was raised the same day, and by the next cycle it was hashed on the server with no raw address anywhere in the data layer. Hashing it made stitching possible and kept the identifier out of Adobe. The obligations behind that are covered in Privacy and Data Retention.

So cross-device work is a data layer conversation before it is an analytics one. If the hashed customer identifier is not being written today, no configuration in either product will produce person level reporting. The honest answer to a stakeholder is a development ticket rather than a setting.

Getting identity right is also the part of a Web SDK migration that most often decides whether it succeeds. The migration section of this site covers it as a step of its own, Migrate identity (ECID), with a longer reference article on identity and the ECID behind it. If you are heading toward CJA, that work is not optional preparation. It is the thing that makes person level reporting possible at all.

Your visitor count will go down

Turning stitching on makes Unique Visitors fall, often sharply. That is the feature working. To anybody who was not in the room, it is a report that lost a third of its audience overnight.

Handle it in advance, because the conversation is easy before and hard after. Say which report is changing, roughly by how much, and on which date. Keep the unstitched view available for a period so the two can be compared. And be explicit that the new number is not the old number corrected. It answers a different question: how many people, rather than how many browsers.

The same applies to every metric built on visitors. Conversion rate per visitor rises, because the denominator shrank. Visits per visitor rises. Any target or bonus written against those numbers needs restating, and hearing about that from a finance team in January is worse than raising it in October.

Whether you can stitch at all

Three checks decide this, and all three happen outside both products. They regularly end the conversation on their own, which is a good outcome reached cheaply.

First, what share of your events carry an authenticated identifier today. That number sets the ceiling on everything stitching can deliver. Below about a fifth, the honest recommendation is to improve sign-in before buying anything.

Second, whether that identifier is stable across sessions and consistent in case and format everywhere it is written. Count the distinct values and compare against your registered customer base. A number well above it means one person is arriving under several spellings.

Third, whether your privacy position allows it, confirmed in writing. Merging anonymous history into an identified person is the processing consent rules govern, and that answer is needed before a dataset exists rather than after.

Only when those three are settled does the product configuration matter, and by then it is the small part of the job.

What stitching gives you

A mechanism, its ceiling and its cost. One authenticated event resolves a device's history backward. Devices that never authenticate stay separate. The quality of the whole thing is set by your sign-in rate rather than by which product you bought.

It is also the clearest example of a pattern that runs through all cross-device work. The feature is not the hard part. The hard part is a clean identifier on every event, agreed with a privacy team, written consistently by every system, and documented well enough that somebody can find out which field it is. That work belongs to an implementation, and it is worth as much in Adobe Analytics as in CJA.

Which raises the practical question. If the platforms differ this much, what does moving between them actually involve? Migrating to CJA covers what does not come across, the five discrepancies that appear during a parallel run, and why there is less urgency than the market suggests.