Practical framework / 5 MIN READ
Explain which journeys identity stitching can actually connect
Separate known links, device records and modeled gaps before reporting people.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
A cross-device report can look complete while combining several kinds of identity evidence. Decisions about reach, repeat behavior and journey length need an explanation of which links are directly supported, which are modeled and which remain unknown.
What you will leave with: Build an identity coverage note with permitted identifiers, failure cases and reporting limitations.
Use this when
- User totals change when a reporting identity option changes.
- A dashboard presents connected journeys as a complete customer census.
This lesson does not authorize fingerprinting, sensitive identifier collection or bypassing consent to improve match rates.
List the identity mechanisms in use
Record the permitted identifiers available at each journey stage and the rules used to connect records. Distinguish signed-in account identifiers, browser or app identifiers and modeled behavior. An account can be shared, a device can be shared and one person can use several devices; these units need explicit labels.
Ask who owns identifier generation, expiry and deletion. Confirm that the intended collection and sharing are authorized. Do not put email addresses, credentials, authentication tokens or sensitive customer details into analytics identifiers or diagnostic exports. A useful identity graph must still respect the person’s choices and platform restrictions.
Read the reporting configuration precisely
Google Analytics documents User-ID, device ID and modeling as distinct identity spaces, with blended, observed and device-based reporting options. These options explain why a reported user count can change without an equivalent change in actual customer behavior.
Record the exact configuration and reporting date when comparing extracts. Do not call all stitched records verified individuals or assume modeling reveals a particular unobserved person. Keep the distinction between collected evidence and reporting treatment visible, and inspect any applicable threshold or coverage notices before interpreting small groups.
Measure coverage without forcing extra collection
Describe coverage with available, permitted aggregate counts: journeys with an authorized account link, journeys represented only by device evidence and records with unresolved identity. State denominators and avoid summing overlapping categories. The signed-in subset may differ substantially from visitors who never sign in.
Use synthetic fixtures to test logout, account switching, shared-device behavior and identifier resets. Confirm that events do not remain incorrectly attached to the previous account. Report unmatched records honestly rather than adding invasive identifiers or relaxing consent to make the dashboard appear more complete. Missing linkage is a limitation to manage, not permission to reconstruct identity.
Constrain the business claim
Explain which decisions the current evidence can support. A device-level repeat-visit metric can describe observed device behavior without claiming exact person-level loyalty. A signed-in cross-device journey can inform that covered population while leaving anonymous journeys unresolved.
When identity settings or implementation change, annotate the break and rerun key comparisons consistently where feasible. Do not interpret the resulting drop in reported users as lost demand. Preserve a coverage note beside reach and journey claims, and revisit it when account behavior, privacy choices or collection technology changes.
Make the reasoning concrete.
A hypothetical report contains 120 device identifiers. Among them, 30 device records are linked to 15 authorized signed-in accounts; the other 90 remain device-only. The resulting 105 reporting units are not proven to be 105 distinct people because unresolved devices and shared accounts remain.
Call the lower count exact people
Opening: Report 105 unique customers after stitching.
Hypothesis: Known cross-device links reduced duplication.
Risk: Unknown duplication and shared-account behavior are concealed.
Explain the mixed evidence
Opening: Report the configured user measure with coverage and unresolved-link caveats.
Hypothesis: Readers understand what was joined and what remains uncertain.
Risk: The data cannot supply a complete person-level census.
Use the platform’s defined reporting unit and disclose the coverage limits. Do not claim exact unique people or collect additional identifiers without a justified, authorized basis.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Mechanisms
Which authorized identifiers and modeled elements are used?
Unit
Does each measure represent accounts, devices or reporting users?
Coverage
What portion can be linked and what remains unresolved?
Tests
Do logout and shared-device fixtures behave correctly?
Claims
Which reach or journey statements exceed the evidence?
Watch for the wrong conclusion.
- Treating an account as necessarily one person.
- Calling modeled journeys directly observed.
- Using extra personal identifiers to hide coverage gaps.
- Interpreting an identity-setting change as a real audience movement.
Your next action
Add an identity coverage note to one reach or journey report and test account-switching behavior with synthetic data.
Sources & scope
Frameworks, worksheets and hypothetical examples are original editorial synthesis. Linked primary sources support only the stated concepts. Source checking is not an independent audit of effectiveness. No named human author or reviewer is claimed.
- Google Analytics Help: Reporting identity →Primary technical documentation · Supports: Documents User-ID, device ID and modeling, and the different reporting identity options. These are reporting mechanisms, not proof of complete person-level observation or permission to collect prohibited identifiers.