In 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.
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:
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.
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.
Live stitching attempts to stitch each event upon collection to known devices and channels.
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.
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.
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.
When you receive a privacy request, the stitched id is deleted in all records for the user subject of the privacy request.
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 |
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:
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.
The following limitations apply specifically to field-based stitching:
Undefined
. See the FAQ for more information.