What is identity stitching?
Identity stitching connects the activity a customer generated under one identifier, like an anonymous cookie or a second device, to the rest of their profile once the link is known. It keeps their whole history attached to one person.
The anonymous to known gap
Most customers browse before they identify themselves. They arrive, look around, and only later log in or sign up. Until that moment their activity is tied to an anonymous id, such as a cookie or a device id. Identity stitching is the step that attaches that earlier activity to the known profile once the link is made.
Stitching is one part of identity resolution. Resolution decides which identifiers belong to the same customer, and an identity graph records those links. Stitching then joins the history recorded under each identifier into one profile.
Why it matters
The behavior before a login is often the most telling: what someone searched, compared, and nearly bought as a stranger. Lose it at the moment they identify themselves and the profile starts from scratch, blind to everything that led up to the signup.
The same loss happens every time a customer switches device or a browser forgets them. Each fragment looks like a separate, lighter customer. A system reading one fragment sees only part of the person, and a model trained on fragments learns from customers who do not exist.
Where stitching is useful
The scenarios below are illustrations, but each one is common on any site where customers do not log in on every visit.
Example: anonymous to known
A visitor reads reviews of two cameras, compares them, and leaves a lens in the basket, all while logged out. A week later they create an account to check out. Without stitching, the new account starts empty. The recommender sees a first-time customer, and the research behind the basket sits on a cookie nothing reads again. With stitching, the account takes on that history when it is created, so what the customer sees next reflects what they were looking at.
Example: cross-device
A reader follows a story on their phone during the commute and finishes it on a laptop at work. They are signed in on both, but each device has its own cookie. Stitching on the shared login joins the two, so the laptop knows which stories were read and where the reader stopped. Without it, each device builds its own partial profile, and a model trained on them sees two occasional readers instead of one loyal one.
Example: a returning customer with a new cookie
Browsers expire and clear cookies, and some cap how long a cookie set by a script can last. A long-standing customer who stays away for a while can come back with a fresh anonymous id and look brand new. When they log in again, stitching reconnects the new id to their profile, and their order history and preferences come back with them.
Example: logged-out visits on a known device
Many customers sign in once on a device and then browse logged out. If that first login linked the device’s id to their account, later anonymous visits on the same device belong to the same person. The app can recognize them without asking them to log in again, and their research on that device counts toward the profile.
Example: reading the profile from wherever the customer is
A customer pays on their laptop, then opens a support chat from a work computer where they are not signed in. The support agent, human or AI, looks the customer up with the id the current device has. If that id is stitched to the rest of the profile, the agent sees the order. If it is not, the agent sees a stranger and answers like one.
When not to stitch
Stitching on the wrong evidence merges different people. Shared devices are the usual cause: two members of a household on one tablet, or a kiosk in a store. Joining profiles because they share a device produces a customer with a history that belongs to neither person.
Links made on exact shared data, like the same login on two devices, avoid this. Links inferred from patterns reach further and are sometimes wrong. The trade-off is covered in deterministic vs probabilistic identity matching.
Some questions need no stitching at all. An attribute keyed on a session or a basket answers its question without knowing who the person is.
When the stitch happens
The stitch happens when an anonymous id and a known id are connected, usually at login or signup. Done in batch, it attaches the history by the next day. Done as it happens, the profile carries the full session forward immediately, while the customer is still there to act on.
A link can also arrive late, after both ids have built up history of their own. The profile then has to combine the two, including counts over a window, such as orders in the last seven days, so the combined value is what it would have been had the link been known all along.
Timing matters for models too. If training data is stitched in the warehouse but the app reads features keyed on a single cookie at request time, the model scores fragments of the profiles it learned from. That is one source of training-serving skew.
Stitching with Signals
Signals computes attributes on whatever key you choose: a user, a session, a device, a basket. Snowplow Identities resolves identifiers deterministically, and the Signals integration with Identities, which is coming soon, computes attributes on the whole person and reads them with any identifier linked to that person.
See it on your own traffic
Add the SDK, define one attribute, and see an attribute updating against your own traffic in the first session. The free tier runs on the real engine: no card, no sales call.