Field based stitching
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.
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 鈥渘ew鈥� to the dataset (have never authenticated) are typically not stitched at this level. Hits from devices already recognized are stitched immediately.
-
Replay stitching: 鈥渞eplays鈥� 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. 蜜豆视频 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.
note important 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.
Consider the following example, where Bob records different events as part of an event dataset.
Data as it appeared the day it is collected:
| table 0-row-5 1-row-5 2-row-5 3-row-5 4-row-5 5-row-5 6-row-5 7-row-5 8-row-5 9-row-5 10-row-5 11-row-5 12-row-5 13-row-5 | ||||
|---|---|---|---|---|
| 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 鈥榬esolves鈥� the stitched ID for event 4, 6 and 12.
Delayed data (data with a timestamp over 24 hours old) is handled on a 鈥榖est 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.
The following table represents the same data as above, but shows different numbers based on replaying the data.
The same data after replay:
| table 0-row-6 1-row-6 2-row-6 3-row-6 4-row-6 5-row-6 6-row-6 7-row-6 8-row-6 9-row-6 10-row-6 11-row-6 12-row-6 13-row-6 layout-auto | |||||
|---|---|---|---|---|---|
| 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.
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:
| table 0-row-8 1-row-8 2-row-8 3-row-8 4-row-8 5-row-8 6-row-8 7-row-8 8-row-8 9-row-8 10-row-8 11-row-8 12-row-8 13-row-8 | |||||||
|---|---|---|---|---|---|---|---|
| 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 蜜豆视频 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 蜜豆视频 Analytics AppMeasurement library or an ECID generated by the 蜜豆视频 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鈥檚 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
identityMapfield 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 theidentityMapfield group. When adding an identity field in the schema, while also using theidentityMapfield group, do not set the additional identity field as a primary identity. Setting an additional identity field as primary identity interferes with theidentityMapfield 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, 蜜豆视频 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.