Graph-based stitching

Use of the primary identity in identityMap namespaces to define the persistentID:

• If multiple primary identities are found in different namespaces, the identities in the namespaces are sorted lexicographically, and the first identity is selected.
• If multiple primary identities are found in a single namespace, the first lexicographical available primary identity is selected.

In the example below, the namespaces and identities result in a sorted primary identities list, and finally the selected identity.

[
  {"id": "ecid-3"},
  {"id": "ecid-2", "primary": true},
  {"id": "ecid-1", "primary": true}
 ]

[
  {"id": "ccid-1"},
  {"id": "ccid-2", "primary": true}
]

PrimaryIdentities [
  {"id": "ccid-2", "namespace": "CCID"},
  {"id": "ecid-1", "namespace": "ECID"},
  {"id": "ecid-2", "namespace": "ECID"}
]
NonPrimaryIdentities [
  {"id": "ccid-1", "namespace": "CCID"},
  {"id": "ecid-3", "namespace": "ECID"}
]

"id": "ccid-2",
"namespace": "CCID"

Use of identityMap namespace to define the persistentID:

• If multiple values for persistentID are found in an identityMap namespace, the first lexicographical available identity is used.

In the example below, you have selected ECID as the namespace to use. That selection results in a sorted identities list, and finally the selected identity.

[
  {"id": "ecid-3"},
  {"id": "ecid-2", "primary": true},
  {"id": "ecid-1", "primary": true}
]

[
  {"id": "ccid-1"},
  {"id": "ccid-2", "primary": true}
]

[
  "id": "ecid-1",
  "id": "ecid-2",
  "id": "ecid-3"
]

"id": "ecid-1",
"namespace": "ECID"

Live stitching: attempts to stitch each hit (event) as it comes in, using the persistent ID to look up the person ID for the selected namespace by querying the identity graph. If the person ID is available from the lookup, this person 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. Two parameters determine the replay: 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 profiles 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.

The event dataset in Adobe Experience Platform, to which you want to apply stitching, must have one column that identifies a profile on every row, the persistent ID. For example, a visitor ID generated by an Adobe Analytics AppMeasurement library or an ECID generated by the Experience Platform Identity Service.

The identity graph from Experience Platform Identity Service must be set up at sandbox level, prior to enabling Graph-based stitching.

• The identity graph must have a namespace (for example Email, or Phone) that you want to use during stitching to resolve the person ID.
• The identity graph must be populated with identities info from any relevant datasets (of type event or profile and that contain at least two useful namespaces with ID values).
• All datasets that hold such relevant identities must be enabled for identity graph data ingestion. This enablement assures that incoming identities are added to the graph over time from all needed sources.
• If already using Real-Time Customer Data Profile or Adobe Journey Optimizer for a while, the graph should be already set up to a certain extent.
  If historical stitching backfill is also required for the dataset enabled with graph-based stitching, the graph should already contain historical identities for the entire period, to obtain desired stitching results.

If you want to use graph-based stitching and you anticipate the event dataset to contribute to the identity graph, you should enable the dataset for the Identity service.

The persistent ID and person ID can be used with identityMap. Or the persistent ID and person ID can be fields from the XDM schema, in which case the fields must be defined as an identity in the schema.

Timestamps are not taken into account when querying for the person ID using the specified namespace. So, it is possible that a persistent ID is stitched with a person ID from a record that has an earlier timestamp.

In shared device scenarios, where the namespace in the graph contains multiple identities, the first lexicographic identity is used. If namespace limits and priorities are configured as part of the release of graph-linking rules, the last authenticated user’s identity is used. See Shared devices for more information.

There is a hard limit of three months of backfilling identities into the identity graph. You would use backfilling identities in case you are not using an Experience Platform application, like Real-time Customer Data Platform, to populate the identity graph.

The Identity Service guardrails apply. See, for example, the following static limits:

• Maximum number of identities in a graph: 50.
• Maximum number of links to an identity for a single batch ingestion: 50.
• Maximum number of identities in an XDM record for graph ingestion: 20.
• Minimum number of identities in an XDM record for graph ingestion: 2.