This article describes various visitor stitching scenarios.
In this article:
When the same user is identified by two email addresses, the result is determined based on the device and browser used for each.
For example, a user visits a website for the first time and provides an email address when submitting a form. The email address is hashed, it enriches the
Email Address Hash visitor ID attribute, and a new visitor profile is created in AudienceStream.
The resulting visitor profile might look like this:
|Email Address Hash||16c18d336f0b250f0e2d907452ceb9658a74ecdae8bc94864c23122a72cc27a5|
A week later, the user visits the website using the same device and browser and submits a form with a different email address. The anonymous ID is the same, so the incoming event will match the profile that was created on the user's first visit. However, because a visitor ID attribute cannot be changed, the new email address hash value will not be used.
Result: One visitor profile with a visitor ID attribute set to the email address hash.
A week later, the same user visits the website using a different device or browser and submits a form with a different email address. The anonymous ID will be different, so the incoming event will not match the profile that was created on the user's first visit. A new profile is created and there are two profiles for this user after the second visit. No visitor stitching occurs, because the visitor ID attribute does not match (the email addresses are different). These two profiles could be stitched together later, if they matched on a second visitor ID attribute.
Result: Two visitor profiles, with each visitor ID attribute set to the corresponding email address hash.
In this example, a user visits a web site from two different devices and is assigned a customer ID for each visit. The anonymous IDs do not match, and two separate profiles are created. The customer ID is configured to enrich visitor ID attribute #1, and the visitor ID attribute is enriched in each profile, as shown below.
This scenario could only happen if the anonymous ID (
tealium_visitor_id) is not known, or are different in the two profiles. No user IDs or visitor ID attributes would be evaluated if the anonymous IDs match, and the second profile would not be created.
The user visits the website again from the first device and provides an email address when submitting a form. The customer_email address attribute is configured to enrich visitor ID attribute #2. Visitor ID attribute #2 in Profile A is enriched with the email address, as shown below.
When the user visits the website from the second device and provides the same email address when submitting a form, the email address matches visitor ID attribute #2 in Profile A, and the two profiles are stitched together to create Profile C, as shown below.
Profile C contains a new
replaces array, which holds values that are no longer stored in visitor ID attributes, but can still be used for visitor stitching in the future. Profile A and Profile B had different values for the anonymous ID and Visitor ID Attribute #1 (Customer ID). Because only one value can be set per visitor ID attribute, two values had to move to the
replaces array. Profile B was the newer profile and had fewer events than Profile A, so the Profile B identifiers were moved to the
For web or HTTP API data sources, this scenario would happen only if the attribute ID value of Visitor ID Attribute #1 (Customer ID) is lower than Visitor ID Attribute #2 (Hashed Email).
With file import, because visitor ID mappings can be customized and user identifier enrichment occurs in the ordered mapped, this scenario could be achieved in a few different ways depending on the setup.
HTTP API and file import both send stateless events because the
tealium_visitor_id value is not automatically assigned. For HTTP API requests, each event generates a new visitor profile unless
tealium_visitor_id is set. In these cases, we recommend generating your own anonymous value for
File import data sources typically include a user identifier which maps to a visitor ID attribute.
tealium_visitor_id value is not included in an HTTP API request or in a file import mapping, AudienceStream assigns a random value to the anonymous ID and creates a new visitor profile prior to visitor stitching.