Identity namespace configuration
Experience Platform uses identity namespaces to describe the type of specific identities. For example, an identity namespace called Email
identifies a value like name@email.com
as an email address.
When creating a destination through Destination SDK, in addition to configuring a partner schema that users can map profile attributes and identities to, you can also define identity namespaces supported by your destination platform.
When you do this, users have the added choice of selecting target identities, in addition to target profile attributes.
To learn more about identity namespaces in Experience Platform, see the identity namespaces documentation.
When configuring identity namespaces for your destination, you can fine tune the target identity mapping supported by your destination, such as:
- Allowing users to map XDM attributes to identity namespaces.
- Allowing users to map standard identity namespaces to your own identity namespaces.
- Allowing users to map custom identity namespaces to your own identity namespaces.
To understand where this component fits into an integration created with Destination SDK, see the diagram in the configuration options documentation or see the guide on how to use Destination SDK to configure a file-based destination.
You can configure your supported identity namespaces via the /authoring/destinations
endpoint. See the following API reference pages for detailed API call examples where you can configure the components shown in this page.
This article describes all the supported identity namespaces configuration options that you can use for your destination, and shows what customers will see in the Platform UI.
Supported integration types supported-integration-types
Refer to the table below for details on which types of integrations support the functionality described on this page.
Supported parameters supported-parameters
When defining the target identities that your destination supports, you can use the parameters described in the table below to configure their behavior.
acceptsAttributes
acceptsCustomNamespaces
acceptedGlobalNamespaces
transformation
sha256(lower($))
.requiredTransformation
sha256(lower($))
."identityNamespaces":{
"external_id":{
"acceptsAttributes":true,
"acceptsCustomNamespaces":true,
"acceptedGlobalNamespaces":{
"Email":{
}
}
},
"another_id":{
"acceptsAttributes":true,
"acceptsCustomNamespaces":true
}
}
You must indicate which Platform identities customers are able to export to your destination. Some examples are Experience Cloud ID, hashed email, device ID (IDFA, GAID). These values are Platform identity namespaces that customers can map to identity namespaces from your destination.
Identity namespaces do not require a 1-to-1 correspondence between Platform and your destination.
For instance, customers could map a Platform IDFA namespace to an IDFA namespace from your destination, or they can map the same Platform IDFA namespace to a Customer ID namespace in your destination.
Read more about identities in the identity namespace overview.
Mapping considerations
If customers select a source identity namespace and do not select a target mapping, Platform automatically populates the target mapping with an attribute with the same name.
Configure optional source field hashing
Experience Platform customers can choose to ingest data into Platform in hashed format or in plain text. If your destination platform accepts both hashed and unhashed data, you can give customers the option to choose whether Platform should hash the source field values when they get exported to your destination.
The configuration below enables the optional Apply transformation option in the Platform UI, in the Mapping step.
"identityNamespaces":{
"Customer_contact":{
"acceptsAttributes":true,
"acceptsCustomNamespaces":true,
"transformation": "sha256(lower($))",
"acceptedGlobalNamespaces":{
"Email":{
},
"Phone":{
}
}
}
}
Check this option when using unhashed source fields, to have Adobe Experience Platform automatically hash them on activation.
When you are mapping unhashed source attributes to target attributes that the destination expects to be hashed (for example: email_lc_sha256
or phone_sha256
), check the Apply transformation option to have Adobe Experience Platform automatically hash the source attributes on activation.
Configure mandatory source field hashing
If your destination only accepts hashed data, you can configure the exported attributes to be automatically hashed by Platform. The configuration below automatically checks the Apply transformation option when the Email
and Phone
identities are mapped.
"identityNamespaces":{
"Customer_contact":{
"acceptsAttributes":true,
"acceptsCustomNamespaces":true,
"transformation": "sha256(lower($))",
"acceptedGlobalNamespaces":{
"Email":{
"requiredTransformation": "sha256(lower($))"
},
"Phone":{
"requiredTransformation": "sha256(lower($))"
}
}
}
}
Next steps next-steps
After reading this article, you should have a better understanding of how to configure your identity namespaces for destinations built with Destination SDK.
To learn more about the other destination components, see the following articles: