Back

This article describes various visitor stitching scenarios.

In this article:

Examples of a Visitor Using Two Different Email Addresses

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:

Attribute Value
Anonymous ID 01754649ad73005a6d584d2732c401078005b0700093c
Device Laptop
Browser Chrome 89
Email Address Hash 16c18d336f0b250f0e2d907452ceb9658a74ecdae8bc94864c23122a72cc27a5

Scenario 1: A Different Email Address from the Same Device and Browser

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.

two-emails-first.png

Scenario 2: A Different Email from a Different Device or Browser

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.

two-emails-both.png

Example of Two Visitor Profiles Matching on a Second Visitor ID Attribute

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.

match-2nd-visID-first.png

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.

match-2nd-visID-second.png

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.

match-2nd-visID-third.png

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 replaces array.

HTTP API and File Import Data Sources

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.

About Stateless Events

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 tealium_visitor_id.

File import data sources typically include a user identifier which maps to a visitor ID attribute.

If a 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.

Related Articles

Public