(Updated 7/2024)

A common scenario plays out on your website: a user shows up for the first time, casually browses around, then mid-session logs in and becomes a known user. Not a big deal, right? In traditional Adobe Analytics, this is easy. There are multiple hits spanning across one unique visitor, one visit, maybe with a dimension to break down the changes in authentication state. Piece of cake. This is Digital Analytics 101.

It gets a little stickier measuring at a person level in Adobe Customer Journey Analytics (CJA). When you set up CJA and create your first Connection, you will have to select one field per dataset to be the Person ID. This Person ID is used to tie your events together into a journey. In the scenario above, as the user moves from an anonymous to identified state, the events will have different sets of IDs on them. You have a few different options to choose as your Person ID, each with its own implications in the above scenario:

• Visitor ID (device or cookie-based): This could be Adobe ECID or a first-party visitor cookie. Regardless, it would effectively recreate the top-level Visitor container in traditional Adobe Analytics without any of the cross-device journey capabilities. Due to cookie deletion, new devices, etc., cookie-based IDs can limit the value of using CJA for journey analysis and would be advised against in most cases.
• Customer ID: This is where the magic of linking together a customer journey across devices and systems starts to take shape. A Customer ID that connects across online and offline systems is the most ideal ID to use here. If your organization already has some kind of universal or global ID, you have a head start. You can also use a hashed email address or other unique identifier. There's a catch, though; all of the events that you bring into CJA must populate the selected field with a Customer ID and if events do not contain that ID, they will be dropped. For some organizations that have high identification rates, this can be an acceptable trade-off, but for others, that mid-session log-in scenario is a bigger problem. Those anonymous events before the user logged in will be completely dropped if you choose a Customer ID as your Person ID. Not only that, but events from prospects who never log in or create an account will also be entirely dropped.
• Identity Map: Within a dataset's schema in Adobe Experience Platform (AEP), the identityMap is a special field that allows you to set a list of IDs that exist when an event occurs. Each ID gets its own namespace within the identityMap, and you’ll need to declare which ID is the “primary” ID. Whichever namespace has the “primary” designation will be treated as the Person ID within CJA for that event. 

Great, so we can use identityMap to handle the changing levels of identification! Not so fast. Keen observers will spot a new problem. Since the unique Person ID will change namespaces through the user’s session, those events will not represent a continuous journey. In fact, the groups of events with varied ID namespaces will count as two people and two sessions in CJA.

So where does that leave us? Within the CJA user interface, there is no obvious way to actually reconstruct the full customer journey without either dropping anonymous events or breaking the journey in half when someone becomes identified. Unfortunately, this is the case, but you have options before loading the data into Adobe CJA.

Stitching it Back Together

Adobe offers two flavors of Identity Stitching to address this issue and create a more continuous journey. 

Field-based Stitching

The first option available to CJA Select SKU users and above is field-based stitching (see Adobe CJA product description for up-to-date SKU definitions).

Field-based stitching goes back and fills in prior anonymous events with a Customer ID

To simplify, the stitching process finds those log-in events where someone becomes known, then looks back within a defined window to find anonymous events with the same Visitor ID (or persistent ID) and replaces it with the Customer ID (or transient ID) from the log in. This allows you to address the basic problem of one dataset with two IDs, but what if you have more than two IDs and/or you want to start incorporating external data with other IDs into CJA?

Graph-based Stitching

The second option is the more sophisticated graph-based stitching, which is available for Prime and higher SKUs. This option taps into the powerful identity graph within the Adobe Experience Platform. Like field-based stitching, it still uses the concept of a persistent ID on your datasets, but instead of a transient ID, it allows you to select any identity namespace to query and retrieve from the graph. Let’s walk through a different example to illustrate this:

Graph-based stitching allows external datasets to create links to IDs that didn’t exist when the data was captured

Your website creates a temporary ID when someone creates an account, but for the CJA Person ID, you want to use the Customer ID that is created as part of a nightly deduplication and matching process in your data warehouse.

Like field-based stitching, the persistent ID will be the Visitor ID, but instead of using the temporary ID as the transient ID, you can import a cross-reference of the temporary ID and deduplicated Customer ID into the Adobe Experience Platform identity graph. By setting your transient namespace to the imported Customer ID, graph-based stitching will not only replace all instances of the temporary ID, but it will also walk the graph to the Visitor ID and replace those with the Customer ID, as well.

As you can see these powerful options can be used even beyond the examples laid out here. Options like bringing in leads data with hashed email addresses or point-of-sale data with loyalty IDs can be stitched together with the power of the identity graph, but there are some limitations to be aware of:

• Both stitching options require the creation of a new stitched schema and dataset, creating a duplicate of the original, but with an additional stitched ID field.
• Any changes to the source schema need to be manually applied to the stitched schema.
• As new ID relationships are detected, metrics in CJA can shift within the lookback window.
• Latency will be added from when the data is collected to when it’s stitched and available in CJA
• For graph-based stitching, shared devices with multiple users may be collapsed into a single person.
• You can only set one transient namespace in graph-based stitching, so you can’t step back through multiple IDs if it happens to be empty for a user.
• It requires a support ticket and Adobe engineering to set it up. 

Do-It-Yourself Stitching

• Multi-step stitching: If there are multiple Customer IDs that you want to utilize to stitch on, you can create your own waterfall process that descends down the available IDs (e.g., Customer ID, then hashed email, then Visitor ID).
• identityMap: Make the output of your custom stitching cleaner and easier to troubleshoot with the output as an identityMap data type.
• Flexible lookback window: Modify the lookback to either maximize the amount of history being stitched or minimize the time that metrics will shift in reports.
• Control your own destiny: Identity within CJA will continue to evolve, and controlling your own stitching process can allow you to pick and choose where to leverage those future features as Adobe makes them available.

Final Thoughts