Configuração do namespace de identidade
O Experience Platform usa namespaces de identidade para descrever o tipo de identidades específicas. Por exemplo, um namespace de identidade chamado Email
identifica um valor como name@email.com
como um endereço de email.
Dependendo do tipo de destino que você criar (streaming ou baseado em arquivo), lembre-se dos seguintes requisitos de namespace de identidade:
-
Ao criar destinos em tempo real (transmissão) por meio do Destination SDK, além de configurar um esquema de parceiro para o qual os usuários podem mapear atributos de perfil e identidades, você também deve definir pelo menos um namespace de identidade com suporte na plataforma de destino. Por exemplo, se sua plataforma de destino aceitar emails com hash e IDFA, você deverá definir essas duas identidades como descritas mais adiante neste documento.
note important IMPORTANT Ao ativar públicos para destinos de streaming, os usuários também devem mapear pelo menos uma identidade de destino, além dos atributos de perfil de destino. Caso contrário, os públicos-alvo não serão ativados para a plataforma de destino. -
Ao criar destinos baseados em arquivo por meio do Destination SDK, a configuração dos namespaces de identidade é opcional.
Para saber mais sobre namespaces de identidade no Experience Platform, consulte a documentação de namespaces de identidade.
Ao configurar namespaces de identidade para seu destino, você pode ajustar o mapeamento de identidade de destino compatível com seu destino, como:
- Permitir que os usuários mapeiem atributos XDM para namespaces de identidade.
- Permitindo que os usuários mapeiem namespaces de identidade padrão para seus próprios namespaces de identidade.
- Permitindo que os usuários mapeiem namespaces de identidade personalizados para seus próprios namespaces de identidade.
Para entender onde esse componente se encaixa em uma integração criada com o Destination SDK, consulte o diagrama na documentação de opções de configuração ou consulte o guia sobre como usar o Destination SDK para configurar um destino baseado em arquivo.
Você pode configurar seus namespaces de identidade compatíveis por meio do ponto de extremidade /authoring/destinations
. Consulte as seguintes páginas de referência de API para obter exemplos detalhados de chamadas de API, onde é possível configurar os componentes mostrados nesta página.
Este artigo descreve todas as opções de configuração de namespaces de identidade compatíveis que você pode usar para o seu destino e mostra o que os clientes verão na interface do usuário da Platform.
Tipos de integração compatíveis supported-integration-types
Consulte a tabela abaixo para obter detalhes sobre quais tipos de integrações suportam a funcionalidade descrita nesta página.
Parâmetros compatíveis supported-parameters
Ao definir as identidades de público-alvo compatíveis com seu destino, você pode usar os parâmetros descritos na tabela abaixo para configurar seu comportamento.
acceptsAttributes
acceptsCustomNamespaces
acceptedGlobalNamespaces
transformation
sha256(lower($))
.requiredTransformation
sha256(lower($))
."identityNamespaces":{
"external_id":{
"acceptsAttributes":true,
"acceptsCustomNamespaces":true,
"acceptedGlobalNamespaces":{
"Email":{
}
}
},
"another_id":{
"acceptsAttributes":true,
"acceptsCustomNamespaces":true
}
}
Você deve indicar quais Platform identidades os clientes podem exportar para o seu destino. Alguns exemplos são Experience Cloud ID, email com hash, ID de dispositivo (IDFA, GAID). Esses valores são Platform namespaces de identidade que os clientes podem mapear para namespaces de identidade do seu destino.
Os namespaces de identidade não exigem uma correspondência de 1 para 1 entre Platform e seu destino.
Por exemplo, os clientes podem mapear um namespace Platform IDFA para um namespace IDFA de seu destino, ou podem mapear o mesmo namespace Platform IDFA para um namespace Customer ID de seu destino.
Leia mais sobre identidades na visão geral do namespace de identidade.
Considerações de mapeamento
Se os clientes selecionarem um namespace de identidade de origem e não selecionarem um target mapping, o Platform preencherá automaticamente o target mapping com um atributo com o mesmo nome.
Configurar hash de campo de origem opcional
Os clientes do Experience Platform podem optar por assimilar dados na Platform em formato com hash ou em texto simples. Se sua plataforma de destino aceitar dados com hash e sem hash, você poderá dar aos clientes a opção de escolher se a Platform deverá fazer o hash dos valores do campo de origem quando eles forem exportados para seu destino.
A configuração abaixo habilita a opção Aplicar transformação opcional na interface do usuário da plataforma, na etapa Mapeamento.
"identityNamespaces":{
"Customer_contact":{
"acceptsAttributes":true,
"acceptsCustomNamespaces":true,
"transformation": "sha256(lower($))",
"acceptedGlobalNamespaces":{
"Email":{
},
"Phone":{
}
}
}
}
Marque essa opção ao usar campos de origem sem hash, para que a Adobe Experience Platform faça o hash automaticamente na ativação.
Ao mapear atributos de origem com hash não atribuídos para atributos de destino que o destino espera que tenham hash (por exemplo: email_lc_sha256
ou phone_sha256
), marque a opção Aplicar transformação para que o Adobe Experience Platform coloque os atributos de origem em hash automaticamente na ativação.
Configurar hash de campo de origem obrigatório
Se o destino aceitar apenas dados com hash, você poderá configurar os atributos exportados para serem automaticamente transformados em hash pela Platform. A configuração abaixo verifica automaticamente a opção Aplicar transformação quando as identidades Email
e Phone
são mapeadas.
"identityNamespaces":{
"Customer_contact":{
"acceptsAttributes":true,
"acceptsCustomNamespaces":true,
"transformation": "sha256(lower($))",
"acceptedGlobalNamespaces":{
"Email":{
"requiredTransformation": "sha256(lower($))"
},
"Phone":{
"requiredTransformation": "sha256(lower($))"
}
}
}
}
Próximas etapas next-steps
Depois de ler este artigo, você deve entender melhor como configurar seus namespaces de identidade para destinos criados com o Destination SDK.
Para saber mais sobre os outros componentes de destino, consulte os seguintes artigos:
- Autenticação do cliente
- Autorização OAuth2
- Campos de dados do cliente
- Atributos da interface
- Configuração do esquema
- Configuração do namespace de identidade
- Configurações de mapeamento compatíveis
- Entrega de destino
- Configuração de metadados de público
- Política de agregação
- Configuração em lote
- Qualificações do perfil histórico