Stitching

Last update: 2024-11-13

Topics:
Stitching
View more on this topic
Cross-Channel Analysis
View more on this topic

Created for:
Admin

NOTE

You must have the Select package or higher (for field-based stitching) or Prime package or higher (for graph-based stitching) to use the functionality described in this section. Contact your administrator if you’re unsure which Customer Journey Analytics package you have.

Identity stitching (or simply, stitching) is a powerful feature that elevates an event dataset’s suitability for cross-channel analysis. Cross-channel analysis is a main use case that Customer Journey Analytics can handle, allowing you to combine and run reports seamlessly on multiple datasets from different channels, based on a common identifier (person ID).

When you combine datasets with similar person IDs, attribution is carried over across devices and channels. For example, a user first visits your site through an advertisement on their desktop computer. That user encounters an issue with their order, then gives your customer service team a call to help resolve it. With cross-channel analysis, you can attribute call center events to the ad that they originally clicked.

Unfortunately, not all event-based datasets that are part of your connection in Customer Journey Analytics are sufficiently populated with data to support this attribution out of the box. Especially, web-based or mobile-based experience datasets often don’t have an actual person ID information available on all events.

Stitching allows rekeying identities within one dataset’s rows, making sure the person ID (stitched ID) is available on each event. Stitching looks at user data from both authenticated and unauthenticated sessions to determine the common transient ID (person ID) value that can be used as stitched ID. This rekeying allows for resolving disparate records to a single stitched ID for analysis at the person level, rather than at the device or cookie level.

Customer Journey Analytics supports two types of stitching: field-based stitching and graph-based stitching.

Prerequisites

IMPORTANT

Failure to meet all prerequisites can result in the inability to conduct cross-channel analysis properly.

Before using stitching, make sure that your organization is prepared with the following:

Stitching includes merging authenticated and unauthenticated user data. Ensure that you comply with applicable laws and regulations, including obtaining necessary end-user permissions, before activating stitching on an event dataset. See Define identity fields in the UI for more information.
Import the desired data into Adobe Experience Platform:
- For Adobe Analytics data, see Utilizing Adobe Analytics report suite data in Customer Journey Analytics.
- For other types of data, see Create a schema and Ingest data in the Adobe Experience Platform documentation.

You benefit from cross-channel analysis if you combine one or more of your stitched datasets with other datasets, such as call center data, as part of defining your Customer Journey Analytics connection. This connection configuration assumes that those other datasets already contain a person ID on every row, similar to the stitched ID.

Limitations

IMPORTANT

No support for using identityMap as the persistent ID. You have to define a specific identifier in the dataset (for example, ECID) as the persistent ID.
Apply any change that you make to the source event dataset schema also to the new stitched dataset schema, otherwise it breaks the stitched dataset.
If you remove the source dataset, the stitched dataset stops processing and gets removed by the system.
Data usage labels are not automatically propagated to the stitched dataset schema. If you have data usage labels applied to the source dataset schema, you need to apply these data usage labels manually to the stitched dataset schema. See Managing data usage labels in Experience Platform for more information.

Stitching is a groundbreaking and robust feature, but has limitations on how it can be used.

Only event datasets are supported. Other datasets, such as lookup datasets, are not supported.
Stitching does not transform the field used for stitching in any manner. Stitching uses the value in the specified field as it exists in the unstitched dataset within the data lake.
The stitching process is case-sensitive. For example, if sometimes the word ‘Bob’ appears in the field, and sometimes the word ‘BOB’ appears, these ids are treated as two separate people.

Ensure you do not confuse stitching with:

The merge of two or more datasets. Stitching applies to one dataset only. Merging of datasets occurs as a result of setting up a Customer Journey Analytics connection and selecting the same person ID across the selected datasets in the connection.
The join of two datasets. In Customer Journey Analytics, a join is often used for lookups or classifications in Analysis Workspace. Although stitching uses join functionality, the process itself involves more than joins.

Field-based stitching

You specify an event dataset as well as the persistent ID (cookie) and transient ID (person ID) for that dataset. Field-based stitching creates a new stitched ID column in the new stitched dataset and updates this stitched ID column based on rows that have a transient ID for that specific persistent ID.
You can use field-based stitching when using Customer Journey Analytics as a standalone solution (not having access to the Experience Platform Identity Service and associated identity graph). Or, when you do not want to use the available identity graph.

Field-based stitching

How field-based stitching works

Stitching makes a minimum of two passes on data in a given dataset.

Live stitching: attempts to stitch each hit (event) as it comes in. Hits from devices that are “new” to the dataset (have never authenticated) are typically not stitched at this level. Hits from devices already recognized are stitched immediately.
Replay stitching: “replays” data based on unique identifiers (transient IDs) it has learned. This stage is where hits from previously unknown devices (persistent IDs) become stitched (to transient IDs). The replay is determined by two parameters: frequency and lookback window. Adobe offers the following combinations of these parameters:
- Daily lookback on a daily frequency: Data replays every day with a 24-hour lookback window. This option holds an advantage that replays are much more frequent, but unauthenticated visitors must authenticate the same day that they visit your site.
- Weekly lookback on a weekly frequency: Data replays once a week with a weekly lookback window (see options). This option holds an advantage that allows unauthenticated sessions a much more lenient time to authenticate. However, unstitched data less than a week old is not reprocessed until the next weekly replay.
- Biweekly lookback on a weekly frequency: Data replays once every week with a biweekly lookback window (see options). This option holds an advantage that allows unauthenticated sessions a much more lenient time to authenticate. However, unstitched data less than two weeks old is not reprocessed until the next weekly replay.
- Monthly lookback on a weekly frequency: Data replays every week with a monthly lookback window (see options). This option holds an advantage that allows unauthenticated sessions a much more lenient time to authenticate. However, unstitched data less than a month old is not reprocessed until the next weekly replay.
Privacy: When privacy-related requests are received, in addition to removing the requested identity, any stitching of that identity across unauthenticated events must be undone.

IMPORTANT

The unstitching process, as part of privacy requests, changes at the start of 2025. The current unstitching process restitches events using the latest version of known identities. This reassignment of events to another identity might have undesirable legal consequences. To remedy these concerns, from 2025 on, the new unstitching process updates events that are subject of the privacy request with the persistent ID.

Data beyond the lookback window is not replayed. A visitor must authenticate within a given lookback window for an unauthenticated visit and an authenticated visit to be identified together. Once a device is recognized, it is live stitched from that point forward.

Step 1: Live stitching

Live stitching attempts to stitch each event upon collection to known devices and channels.

Details

Consider the following example, where Bob records different events as part of an event dataset.

Data as it appeared the day it is collected:

Event	Timestamp	Persistent ID (Cookie ID)	Transient ID (Login ID)	Stitched ID (after live stitch)
1	2023-05-12 12:01	`246`	-	`246`
2	2023-05-12 12:02	`246`	`Bob`	`Bob`
3	2023-05-12 12:03	`246`	`Bob`	`Bob`
4	2023-05-12 12:04	`246`	-	`Bob`
5	2023-05-12 12:05	`246`	`Bob`	`Bob`
6	2023-05-12 12:06	`246`	-	`Bob`
7	2023-05-12 12:07	`246`	`Bob`	`Bob`
8	2023-05-12 12:03	`3579`	-	`3579`
9	2023-05-12 12:09	`3579`	-	`3579`
10	2023-05-12 12:02	`81911`	-	`81911`
11	2023-05-12 12:05	`81911`	`Bob`	`Bob`
12	2023-05-12 12:12	`81911`	-	`Bob`
		3 devices		4 people: `246`, `Bob`, `3579`, `81911`

Both unauthenticated and authenticated events on new devices are counted as separate people (temporarily). Unauthenticated events on recognized devices are live stitched.

Attribution works when the identifying custom variable is tied to a device. In the example above, all events except events 1, 8, 9 and 10 are live stitched (they all use the Bob identifier). Live stitching ‘resolves’ the stitched ID for event 4, 6 and 12.

Delayed data (data with a timestamp over 24 hours old) is handled on a ‘best effort’ basis, while prioritizing the stitching of current data for the highest quality.

Step 2: Replay stitching

At regular intervals (once a week or once a day, depending on the chosen lookback window), replay stitching recalculates historical data based on devices it now recognizes. If a device initially sends data while not authenticated and then logs in, replay stitching ties those unauthenticated events to the correct person.

Details

The following table represents the same data as above, but shows different numbers based on replaying the data.

The same data after replay:

Event	Timestamp	Persistent ID (Cookie ID)	Transient ID (Login ID)	Stitched ID (after live stitch)	Stitched ID (after replay)
1	2023-05-12 12:01	`246`	-	`246`	`Bob`
2	2023-05-12 12:02	`246`	`Bob`	`Bob`	`Bob`
3	2023-05-12 12:03	`246`	`Bob`	`Bob`	`Bob`
4	2023-05-12 12:04	`246`	-	`Bob`	`Bob`
5	2023-05-12 12:05	`246`	`Bob`	`Bob`	`Bob`
6	2023-05-12 12:06	`246`	-	`Bob`	`Bob`
7	2023-05-12 12:07	`246`	`Bob`	`Bob`	`Bob`
8	2023-05-12 12:03	`3579`	-	`3579`	`3579`
9	2023-05-12 12:09	`3579`	-	`3579`	`3579`
10	2023-05-12 12:02	`81911`	-	`81911`	`Bob`
11	2023-05-12 12:05	`81911`	`Bob`	`Bob`	`Bob`
12	2023-05-12 12:12	`81911`	-	`Bob`	`Bob`
		3 devices		4 people: `246`, `Bob`, `3579`, `81911`	2 people: `Bob`, `3579`

Attribution works when the identifying custom variable is tied to a device. In the example above, event 1 and 10 are stitched as a result from the replay, leaving only event 8, and 9 unstitched. And reducing the people metric (cumulative) to 2.

Step 3: Privacy Request

When you receive a privacy request, the stitched id is deleted in all records for the user subject of the privacy request.

Details

The following table represents the same data as above, but shows the effect that a privacy request for Bob has on the data after processing it. The rows where Bob is authenticated are removed (2, 3, 5, 7, and 11) along with removing Bob as a transient ID for other rows.

The same data after a privacy request for Bob:

Event	Timestamp	Persistent ID (Cookie ID)	Transient ID (Login ID)	Stitched ID (after live stitch)	Stitched ID (after replay)	Transient ID (Login ID)	Stitched ID (after privacy request)
1	2023-05-12 12:01	`246`	-	`246`	`Bob`	-	`246`
2	2023-05-12 12:02	`246`	Bob	`Bob`	`Bob`		`246`
3	2023-05-12 12:03	`246`	Bob	`Bob`	`Bob`		`246`
4	2023-05-12 12:04	`246`	-	`Bob`	`Bob`	-	`246`
5	2023-05-12 12:05	`246`	Bob	`Bob`	`Bob`		`246`
6	2023-05-12 12:06	`246`	-	`Bob`	`Bob`	-	`246`
7	2023-05-12 12:07	`246`	`Bob`	`Bob`	`Bob`		`246`
8	2023-05-12 12:03	`3579`	-	`3579`	`3579`	-	`3579`
9	2023-05-12 12:09	`3579`	-	`3579`	`3579`	-	`3579`
10	2023-05-12 12:02	`81911`	-	`81911`	`Bob`	-	`81911`
11	2023-05-12 12:05	`81911`	`Bob`	`Bob`	`Bob`		`81911`
12	2023-05-12 12:12	`81911`	-	`Bob`	`Bob`	-	`81911`
		3 devices		4 people: 246, `Bob`, `3579`, `81911`	2 people: Bob, `3579`		3 people: `246`, `3579`, `81911`

Prerequisites

The following prerequisites apply specifically to field-based stitching:

The event dataset in Adobe Experience Platform, to which you want to apply stitching, must have two columns that help identify visitors:
- A persistent ID, an identifier available on every row. For example, a visitor ID generated by an Adobe Analytics AppMeasurement library or an ECID generated by the Adobe Experience Platform Identity Service.
- A transient ID, an identifier available on only some rows. For example, a hashed username or email address once a visitor authenticates. You can use virtually any identifier that you like. Stitching considers this field to hold the actual person ID info. For best stitching results, a transient ID should be sent within the dataset’s events at least once for each persistent ID. If you plan to include this dataset within a Customer Journey Analytics connection, it is preferable that the other datasets also have a similar common identifier.
Both columns (persistent ID and transient ID) must be defined as an identity field with an identity namespace in the schema for the dataset you want to stitch. When using identity stitching in Real-time Customer Data Platform, using the identityMap field group, you still need to add identity fields with an identity namespace. This identification of identity fields is required as Customer Journey Analytics stitching does not support the identityMap field group. When adding an identity field in the schema, while also using the identityMap field group, do not set the additional identity field as a primary identity. Setting an additional identity field as primary identity interferes with the identityMap field group used for Real-time Customer Data Platform.

Limitations

The following limitations apply specifically to field-based stitching:

Current rekeying capabilities are limited to one step (persistent ID to transient ID). Multiple-step rekeying (for example, persistent ID to a transient ID, then to another transient ID) is not supported.
If a device is shared by multiple people and the total number of transitions between users exceeds 50,000, Customer Journey Analytics stops stitching data for that device.
Custom ID maps used in your organization are not supported.
Stitching is case-sensitive. For datasets generated through the Analytics source connector, Adobe recommends reviewing any VISTA rules or processing rules that apply to the transient ID field. This review ensures that none of these rules are introducing new forms of the same ID. For example, you should ensure that no VISTA or processing rules are introducing lowercasing to the transient ID field on only a portion of the events.
Stitching does not combine or concatenate fields.
The transient ID field should contain a single type of ID (IDs from a single namespace). For instance, the transient ID field should not contain a combination of login IDs and email IDs.
If multiple events occur with the same timestamp for the same persistent ID, but with different values in the transient ID field, stitching selects the ID based on alphabetical order. So, if persistent ID A has two events with the same timestamp and one of the events specifies Bob and the other specifies Ann, stitching selects Ann.
Be cautious of scenarios where the transient IDs contain placeholder values, for example Undefined. See the FAQ for more information.

Graph-based stitching

You specify an event dataset as well as the persistent ID (cookie) and the namespace of the transient ID (person ID) for that dataset. Graph-based stitching creates a new column for the stitched ID in the new stitched dataset. And then uses the persistent ID to query the identity graph from the Experience Platform Identity Service, using the namespace specified, to update the stitched ID.

Graph-based-stitching

How graph-based stitching works

Stitching makes a minimum of two passes on data in a given dataset.

Live stitching: attempts to stitch each hit (event) as it comes in, using the persistent ID to look up the transient id for the selected namespace by querying the identity graph. If the transient id is available from the lookup, this transient id is immediately stitched.
Replay stitching: replays data based on updated identities from the identity graph. This stage is where hits from previously unknown devices (persistent IDs) become stitched as the identity graph has resolved the identity for a namespace. The replay is determined by two parameters: frequency and lookback window. Adobe offers the following combinations of these parameters:
- Daily lookback on a daily frequency: Data replays every day with a 24-hour lookback window. This option holds an advantage that replays are much more frequent, but unauthenticated visitors must authenticate the same day that they visit your site.
- Weekly lookback on a weekly frequency: Data replays once a week with a weekly lookback window (see options). This option holds an advantage that allows unauthenticated sessions a much more lenient time to authenticate. However, unstitched data less than a week old is not reprocessed until the next weekly replay.
- Biweekly lookback on a weekly frequency: Data replays once every week with a biweekly lookback window (see options). This option holds an advantage that allows unauthenticated sessions a much more lenient time to authenticate. However, unstitched data less than two weeks old is not reprocessed until the next weekly replay.
- Monthly lookback on a weekly frequency: Data replays every week with a monthly lookback window (see options). This option holds an advantage that allows unauthenticated sessions a much more lenient time to authenticate. However, unstitched data less than a month old is not reprocessed until the next weekly replay.
Privacy: When privacy-related requests are received, in addition to removing the requested identity from the source dataset, any stitching of that identity across unauthenticated events must be undone. Also, the identity must be removed from the identity graph to prevent future graph-based stitching for that specific identity.

IMPORTANT

The unstitching process, as part of privacy requests, changes at the start of 2025. The current unstitching process restitches events using the latest version of known identities. This reassignment of events to another identity might have undesirable legal consequences. To remedy these concerns, from 2025 on, the new unstitching process updates events that are subject of the privacy request with the persistent ID.

Consider the following two identity graphs for persistent id 246 and 3579, how these identity graphs are updated over time, and how these updates impact the steps in graph-based stitching.

Identity Graph 246
Identity Graph 3579

You can view an identity graph over time for a specific profile using the Identity Graph Viewer. See also Identity Service linking logic to get a better understanding of the logic used when linking identities.