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.

Depending on the type of destination that you create (streaming or file-based), keep in mind the following identity namespace requirements:

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:

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.

"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: