Identity handling in the destinations activation workflow

This page describes the particularities of how identities are exported to different destination types and teaches you how to find which identities are available for export depending on destination.

Each destination in the catalog is slightly different, so there is no one-size-fits-all setup across all destinations. However, there are a few patterns that guide the setup of destinations and their identity requirements, as described in the sections below.

File-based destinations file-based

For file-based destinations (for example Amazon S3, SFTP, most email marketing destinations such as Adobe Campaign, Oracle Eloqua, Salesforce Marketing Cloud), the identity setup in most of these destinations is open, meaning that you are not required to select any identity in the Select attributes step of the batch activation workflow.

If you choose to add identities to your file exports, note that only a single identity from the identity namespace can be selected in an export. When you select an identity for export, it is automatically selected as a mandatory attribute and deduplication key.

As a workaround, you can add more identities to the export if these have been ingested into Experience Platform as attributes. See below an example where the XDM attribute email address was selected for export, in addition to the identity namespace Phone_E.164.

Exporting an identity from an identity map versus exporting an identity as an XDM attribute - the differences identity-map-or-attribute

The number of exported records can differ, based on whether you select for export identities from the identity map or identities which have been ingested as attributes into Experience Platform. Merge policies also play an important role in the number of records that get exported when you select identities from the identity map.

For example, consider that from two different datasets, you have the following profile fragments which will be merged into a single customer profile:

Profile fragment one

Profile fragment two

The merged profile would look like below:

The export behavior differs based on whether you select IdentityMap: Email or xdm: personalEmail.address for export.

If a customer activates IdentityMap: Email, there will be two records in the exported file, one for email1, and another for email2.

However, if a customer activates xdm: personalEmail.address, only email2 will be present in the record, since the email attribute field only includes email2. These situations can address different use cases where you might want to activate to all email addresses that you have on file for a customer, or just to the most recent email address that you have on file for the customer.

The takeaway is that the number of records you export depends on your chosen merge policies and whether you select identities or attributes in the export.

API-based streaming destinations streaming-destinations

API-based streaming destinations built with Destination SDK (for example Facebook, Google Customer Match, Pinterest, Braze, and others) only support specific IDs for export. For detailed information about the specific identities that can be exported to each destination, read the supported identities section in each destination documentation page (for example, see the supported identities section in the Pinterest destination page).

Note, however, that you have the flexibility to use data from either private graphs or from attributes as identities. This means that you can map XDM attributes to the identity field required by the destination. See below an example for the Pinterest destination, where the XDM attribute personalEmail.address is mapped to the required Pinterest identity pinterest_audience.

Advertising destinations relying on third-party cookie integrations third-party-cookie-destinations

Advertising destinations relying on third party cookies (for example: Google Ads, Google Ad Manager, Google DV360, Bing, The Trade Desk) do not require customers to select IDs in the activation workflow. For these destinations, when setting up an activation workflow, Experience Platform automatically looks up the identity match table constructed by the Experience Cloud ID service and exports all identities that are available for a profile and supported by the destination.

These destinations require an ID sync to happen through either the Experience Cloud ID service or through Experience Platform Web SDK.

If you are using Experience Platform Web SDK and the legacy Experience Cloud ID service is not implemented on the page, then you need to ensure that the datastream for the website in question is enabled to allow for Third Party ID syncing, as outlined in the configure datastream documentation.

When configuring a datastream as described in the documentation linked above, you need to ensure that the Third Party ID Sync slider is enabled. Most customers would leave the container_id field blank (it will default to 0). You only need to change this value if your legacy Audience Manager implementation used a specific container ID (note, however, that this would be the vast minority of customers).

Enterprise destinations enterprise-destinations

Enterprise destinations (Amazon Kinesis, Azure Event Hubs, HTTP API) do not require specific IDs in the data export, as these are designed for enterprise integration use cases. However, you can export identities as XDM attributes or from the identity map, if you wish. View an example of exported data to the HTTP destination, which includes both the personalEmail.address XDM attribute, and the identities ECID and email_lc_sha256 (hashed email address) from the identity map.

Personalization destinations personalization-destinations

Personalization (or edge) destinations (for example: Adobe Target, Custom Personalization) do not require any identity selection in the activation workflow, as the integration is a profile lookup. The client (Target, Web SDK, or others) queries the Edge and pulls the profile information that it needs for on-site personalization.

Next steps next-steps

After reading this document, you now know how to find out which identities are supported or required for individual destinations. You now also know how identity selection works for each destination type.

Next, you can read about which export settings for destinations are common across destination types, which can be configured on an individual destination level by developers, and which settings can be edited by users in the activation workflow.

You can also check out all the available destinations in the catalog.