Overview
The scenarios below are the patterns customers most often need identity resolution to solve, with the ID Strategy setting that supports each and the pitfall to watch for. For what identity resolution is and how the identity graph works, see Identity Resolution.Anonymous to Known
Most visits to your website or app happen before anyone signs in. Those visits carry only low-fidelity identifiers such as a web cookie, and under a Custom strategy they are deliberately kept apart from your known customer profiles — so the browsing history of a customer who later logs in sits on a separate, anonymous profile. To join anonymous behaviour to the known customer, the low-fidelity web identifier has to be allowed to take part in resolution. Classify it as a Primary identifier at the lowest priority: it then resolves a record only when no higher-fidelity identifier is present, so an anonymous visit attaches to the known profile while a signed-in record is still resolved on the customer ID. Setting that supports it: classification (low-fidelity ID moved to Primary) plus prioritisation (ranked last). See How to Stitch Unknown to Known Profile for the worked configuration.
Classification and priority are set on the Prioritise your IDs screen of your ID Strategy.
Cross-device stitching
One customer uses your app on a phone, your site on a laptop, and maybe a tablet in between. Each device generates its own identifiers, so without stitching you see three customers instead of one, and campaign frequency, attribution, and personalisation all suffer. Zeotap links devices through the records that carry both a person-level identifier and a device identifier. When a customer signs in on a device, that record carries the customer ID together with the device’s ID, and a linkage is created between them; subsequent records from that device resolve to the same profile even when the person-level ID is absent. Repeat this on a second device and both device identifiers hang off the same profile. Setting that supports it: a person-level identifier (customer ID, email) as Primary; device identifiers kept Secondary or as a lower-priority Primary; No. of ID to store per profile set above one for device identifiers, so a profile can retain several devices.Stitching is not retroactive in the way people expect: activity that happened on a device before any signed-in record arrived was resolved to the anonymous profile at the time; that profile is merged into the known profile when a later record links the two identifiers, rather than being re-resolved retrospectively. It is the linkage from that first signed-in record onward that keeps the device with the known profile. A customer who clears cookies gets a new device identifier and starts the cycle again.
Profile merging (UCID-to-UCID)
Two profiles can exist for one person quite legitimately — they signed up on the website and separately in the app, or the record that would have linked their identifiers arrived late. You need those to become one profile once the evidence arrives. When an incoming record matches more than one existing profile, reconciliation merges them. The profile whose UCID was created first is retained as the master, and the other matched profiles are merged into it — their identifiers, attributes, events, and consent all move to the surviving profile. From that point on, records matching any of those identifiers resolve to the master. Setting that supports it: classification and prioritisation decide which identifiers are allowed to trigger a match, and therefore which profiles can merge. See How does Custom Strategy Work for the full match table.Cross-app / cross-brand
Groups often run several apps, or several brands, inside one Zeotap account. The same person shops two of your brands and installs two of your apps, and you want one profile with all of it — while still being able to report per brand. A record resolves to one profile whenever it carries an identifier already linked to that profile, regardless of which app or brand sent it. The practical requirement is that a shared, persistent identifier — the customer ID from your loyalty programme, for example — is present in the data from every one of those sources. Brand or app can then be carried as an attribute or event property, so one profile still supports per-brand analysis and targeting. Setting that supports it: choose a Primary identifier that is present across sources, and make sure every source maps at least one Primary identifier during catalogue mapping.A source that maps no Primary identifier creates its own Secondary-only profiles, which never merge into your known customers. If one app or brand contributes no Primary identifier, its data effectively lives in a parallel set of profiles. Identity resolution also operates within one Zeotap account — profiles are not resolved across organisations.