Configuração de esquema de parceiro
O Experience Platform usa esquemas para descrever a estrutura dos dados de forma consistente e reutilizável. Quando os dados são assimilados na Platform, eles são estruturados de acordo com um esquema XDM. Para obter mais informações sobre o modelo de composição de esquema, incluindo princípios de design e práticas recomendadas, consulte as noções básicas da composição de esquema.
Ao criar um destino com o Destination SDK, você pode definir seu próprio esquema de parceiro a ser usado pela plataforma de destino. Isso oferece aos usuários a capacidade de mapear atributos de perfil da Platform para campos específicos reconhecidos pela plataforma de destino, tudo na interface do usuário da Platform.
Ao configurar o esquema de parceiro para o seu destino, você pode ajustar o mapeamento de campos compatível com sua plataforma de destino, como:
- Permite que os usuários mapeiem um atributo XDM do
phoneNumber
para um atributo dophone
compatível com sua plataforma de destino. - Crie esquemas de parceiros dinâmicos que o Experience Platform possa chamar dinamicamente para recuperar uma lista de todos os atributos compatíveis no seu destino.
- Defina os mapeamentos de campo obrigatórios exigidos pela plataforma de destino.
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 definir suas configurações de esquema 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 esquema 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.
Configuração de esquema compatível supported-schema-types
O Destination SDK suporta várias configurações de esquema:
- Os esquemas estáticos são definidos por meio da matriz
profileFields
na seçãoschemaConfig
. Em um esquema estático, você define cada atributo de destino que deve ser mostrado na interface do usuário do Experience Platform na matrizprofileFields
. Se precisar atualizar seu esquema, você deve atualizar a configuração de destino. - Os esquemas dinâmicos usam um tipo de servidor de destino adicional, chamado de servidor de esquema dinâmico, para recuperar dinamicamente os atributos de destino compatíveis e gerar esquemas com base em sua própria API. Esquemas dinâmicos não usam a matriz
profileFields
. Se você precisar atualizar seu esquema, não há necessidade de atualizar a configuração de destino. Em vez disso, o servidor de esquema dinâmico recupera o esquema atualizado da API. - Na configuração do esquema, você tem a opção de adicionar mapeamentos necessários (ou predefinidos). Esses são mapeamentos que os usuários podem visualizar na interface do usuário da Platform, mas não podem modificá-los ao configurar uma conexão com o seu destino. Por exemplo, é possível impor que o campo de endereço de email sempre seja enviado ao destino.
A seção schemaConfig
usa vários parâmetros de configuração, dependendo do tipo de esquema necessário, conforme mostrado nas seções abaixo.
Criar um esquema estático attributes-schema
Para criar um esquema estático com atributos de perfil, defina os atributos de destino na matriz profileFields
conforme mostrado abaixo.
"schemaConfig":{
"profileFields":[
{
"name":"phoneNo",
"title":"phoneNo",
"description":"This is a fixed attribute on your destination side that customers can map profile attributes to. For example, the mobilePhone.number value in Experience Platform could be phoneNo on your side.",
"type":"string",
"isRequired":false,
"readOnly":false,
"hidden":false
},
{
"name":"firstName",
"title":"firstName",
"description":"This is a fixed attribute on your destination side that customers can map profile attributes to. For example, the person.name.firstName value in Experience Platform could be firstName on your side.",
"type":"string",
"isRequired":false,
"readOnly":false,
"hidden":false
},
{
"name":"lastName",
"title":"lastName",
"description":"This is a fixed attribute on your destination side that customers can map profile attributes to. For example, the person.name.lastName value in Experience Platform could be phoneNo on your side.",
"type":"string",
"isRequired":false,
"readOnly":false,
"hidden":false
}
],
"useCustomerSchemaForAttributeMapping":false,
"profileRequired":true,
"segmentRequired":true,
"identityRequired":true,
"segmentNamespaceAllowList": ["someNamespace"],
"segmentNamespaceDenyList": ["someOtherNamespace"]
}
profileFields
profileFields
, você pode omitir totalmente o parâmetro useCustomerSchemaForAttributeMapping
.useCustomerSchemaForAttributeMapping
Habilita ou desabilita o mapeamento de atributos do esquema do cliente para os atributos definidos na matriz profileFields
.
- Se definido como
true
, os usuários verão somente a coluna de origem no campo de mapeamento.profileFields
não são aplicáveis neste caso. - Se definido como
false
, os usuários podem mapear atributos de origem de seus esquemas para os atributos definidos na matrizprofileFields
.
O valor padrão é false
.
profileRequired
true
se os usuários precisarem mapear atributos de perfil do Experience Platform para atributos personalizados na plataforma de destino.segmentRequired
true
.identityRequired
true
se os usuários puderem mapear tipos de identidade do Experience Platform para os atributos definidos na matriz profileFields
.segmentNamespaceAllowList
segmentNamespaceDenyList
.Exemplo:
"segmentNamespaceAllowList": ["AudienceManager"]
permitirá que os usuários mapeiem apenas públicos-alvo do namespace AudienceManager
para esse destino.Para permitir que os usuários exportem qualquer público para o seu destino, você pode ignorar este parâmetro.
Se
segmentNamespaceAllowList
e segmentNamespaceDenyList
estiverem ausentes em sua configuração, os usuários só poderão exportar públicos-alvo originados do Serviço de Segmentação.segmentNamespaceDenyList
segmentNamespaceAllowed
.Exemplo:
"segmentNamespaceDenyList": ["AudienceManager"]
impedirá que os usuários mapeiem públicos do namespace AudienceManager
para esse destino.Para permitir que os usuários exportem qualquer público para o seu destino, você pode ignorar este parâmetro.
Se
segmentNamespaceAllowed
e segmentNamespaceDenyList
estiverem ausentes na sua configuração, os usuários só poderão exportar públicos originados do Serviço de Segmentação.Para permitir a exportação de todos os públicos, independentemente da origem, defina
"segmentNamespaceDenyList":[]
.A experiência de interface do usuário resultante é mostrada nas imagens abaixo.
Ao selecionar o target mapping, os usuários podem ver os campos definidos na matriz profileFields
.
Após selecionar os atributos, eles podem vê-los na coluna do campo de destino.
Criar um esquema dinâmico dynamic-schema-configuration
O Destination SDK oferece suporte à criação de esquemas de parceiros dinâmicos. Ao contrário de um esquema estático, um esquema dinâmico não usa uma matriz profileFields
. Em vez disso, os esquemas dinâmicos usam um servidor de esquema dinâmico que se conecta à sua própria API de onde recupera a configuração do esquema.
Em uma configuração de esquema dinâmico, a matriz profileFields
é substituída pela seção dynamicSchemaConfig
, conforme mostrado abaixo.
"schemaConfig":{
"dynamicSchemaConfig":{
"dynamicEnum": {
"authenticationRule":"CUSTOMER_AUTHENTICATION",
"destinationServerId":"DYNAMIC_SCHEMA_SERVER_ID",
"value": "Schema Name",
"responseFormat": "SCHEMA"
}
},
"profileRequired":true,
"segmentRequired":true,
"identityRequired":true
}
dynamicEnum.authenticationRule
Indica como Platform clientes se conectam ao seu destino. Os valores aceitos são CUSTOMER_AUTHENTICATION
, PLATFORM_AUTHENTICATION
, NONE
.
- Use
CUSTOMER_AUTHENTICATION
se os clientes da Platform fizerem logon no sistema por meio de qualquer um dos métodos de autenticação descritos aqui. - Use o
PLATFORM_AUTHENTICATION
se houver um sistema de autenticação global entre o Adobe e o seu destino e o cliente do Platform não precisar fornecer credenciais de autenticação para se conectar ao seu destino. Nesse caso, você deve criar um objeto de credenciais usando a API de Credenciais. - Use
NONE
se nenhuma autenticação for necessária para enviar dados para a plataforma de destino.
dynamicEnum.destinationServerId
instanceId
do seu servidor de esquema dinâmico. Esse servidor de destino inclui o endpoint da API que o Experience Platform chamará para recuperar o esquema dinâmico.dynamicEnum.value
dynamicEnum.responseFormat
SCHEMA
ao definir um esquema dinâmico.profileRequired
true
se os usuários precisarem mapear atributos de perfil do Experience Platform para atributos personalizados na plataforma de destino.segmentRequired
true
.identityRequired
true
se os usuários puderem mapear tipos de identidade do Experience Platform para os atributos definidos na matriz profileFields
.Mapeamentos necessários required-mappings
Na configuração do esquema, além do esquema estático ou dinâmico, você tem a opção de adicionar mapeamentos necessários (ou predefinidos). Esses são mapeamentos que os usuários podem visualizar na interface do usuário da Platform, mas não podem modificá-los ao configurar uma conexão com o seu destino.
Por exemplo, é possível impor que o campo de endereço de email sempre seja enviado ao destino.
- Você pode configurar um campo de origem e um campo de destino obrigatórios. Nesse caso, os usuários não podem editar ou selecionar nenhum dos dois campos e só podem visualizar a seleção.
- Você pode configurar apenas um campo de destino obrigatório. Nesse caso, os usuários poderão selecionar um campo de origem para mapear para o destino.
Veja abaixo dois exemplos de uma configuração de esquema com os mapeamentos necessários e como eles se parecem na etapa de mapeamento do fluxo de trabalho ativar dados para destinos em lote.
O exemplo abaixo mostra os mapeamentos de origem e de destino necessários. Quando os campos de origem e de destino são especificados como mapeamentos obrigatórios, os usuários não podem selecionar ou editar nenhum dos dois campos e só podem exibir a seleção predefinida.
code language-json |
---|
|
table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 layout-auto | |||
---|---|---|---|
Parâmetro | Tipo | Obrigatório/Opcional | Descrição |
requiredMappingsOnly |
Booleano | Opcional | Quando definido como true, os usuários não poderão mapear outros atributos e identidades no fluxo de ativação, exceto os mapeamentos necessários definidos na matriz requiredMappings . |
requiredMappings.sourceType |
String | Obrigatório |
Indica o tipo do campo
|
requiredMappings.source |
String | Obrigatório |
Indica o valor do campo de origem. Tipos de valores suportados:
|
requiredMappings.destination |
String | Obrigatório | Indica o valor do campo de destino. Quando os campos de origem e de destino são especificados como mapeamentos obrigatórios, os usuários não podem selecionar ou editar nenhum dos dois campos e só podem exibir a seleção. |
Como resultado, as seções do campo do Source e do campo do Target na interface do usuário da Platform estão esmaecidas.
O exemplo abaixo mostra um mapeamento de destino necessário. Se apenas o campo de destino for especificado conforme necessário, os usuários poderão selecionar qual campo de origem mapear para ele.
code language-json |
---|
|
table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 layout-auto | |||
---|---|---|---|
Parâmetro | Tipo | Obrigatório/Opcional | Descrição |
requiredMappingsOnly |
Booleano | Opcional | Quando definido como true, os usuários não poderão mapear outros atributos e identidades no fluxo de ativação, exceto os mapeamentos necessários definidos na matriz requiredMappings . |
requiredMappings.destination |
String | Obrigatório | Indica o valor do campo de destino. Quando apenas o campo de destino é especificado, os usuários podem selecionar um campo de origem para mapear para o destino. |
mandatoryRequired |
Booleano | Opcional | Indica se o mapeamento deve ser marcado como um atributo obrigatório. |
primaryKeyRequired |
Booleano | Opcional | Indica se o mapeamento deve ser marcado como uma chave de desduplicação. |
Como resultado, a seção Campo de destino da interface do usuário da plataforma está esmaecida, enquanto a seção Campo do Source está ativa e os usuários podem interagir com ela. As opções Chave obrigatória e Chave de desduplicação estão ativas e os usuários não podem alterá-las.
Configuração do suporte para públicos externos external-audiences
Para configurar o destino para oferecer suporte à ativação de públicos gerados externamente, inclua o trecho abaixo na seção schemaConfig
.
"schemaConfig": {
"segmentNamespaceDenyList": [],
...
}
Consulte as descrições de propriedade na tabela mais acima nesta página para saber mais sobre a funcionalidade segmentNamespaceDenyList
.
Próximas etapas next-steps
Depois de ler este artigo, você deve entender melhor quais tipos de esquema são compatíveis com o Destination SDK e como você pode configurar seu esquema.
Para saber mais sobre os outros componentes de destino, consulte os seguintes artigos:
- Autenticação do cliente
- Autorização OAuth2
- Atributos da interface
- Campos de dados do cliente
- 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