Configuración del esquema de socio
Experience Platform utiliza esquemas para describir la estructura de los datos de una manera uniforme y reutilizable. Cuando se incorporan datos en Platform, se estructuran según un esquema XDM. Para obtener más información sobre el modelo de composición de esquema, incluidos los principios de diseño y las prácticas recomendadas, vea los conceptos básicos de la composición de esquema.
Al crear un destino con Destination SDK, puede definir su propio esquema de socio para que lo utilice su plataforma de destino. Esto permite a los usuarios asignar atributos de perfil de Platform a campos específicos que la plataforma de destino reconoce, todo ello dentro de la interfaz de usuario de Platform.
Al configurar el esquema de socio para el destino, puede ajustar la asignación de campos admitida por la plataforma de destino, como:
- Permitir que los usuarios asignen un atributo XDM
phoneNumber
a un atributophone
compatible con la plataforma de destino. - Cree esquemas de socios dinámicos a los que el Experience Platform pueda llamar dinámicamente para recuperar una lista de todos los atributos admitidos dentro del destino.
- Defina las asignaciones de campos obligatorias que requiere la plataforma de destino.
Para saber dónde encaja este componente en una integración creada con Destination SDK, consulte el diagrama en la documentación de opciones de configuración o consulte la guía sobre cómo usar Destination SDK para configurar un destino basado en archivos.
Puede configurar las opciones del esquema a través del extremo /authoring/destinations
. Consulte las siguientes páginas de referencia de la API para ver ejemplos detallados de llamadas de la API donde puede configurar los componentes que se muestran en esta página.
Este artículo describe todas las opciones de configuración de esquema admitidas que puede utilizar para su destino y muestra lo que los clientes verán en la interfaz de usuario de Platform.
Tipos de integración admitidos supported-integration-types
Consulte la tabla siguiente para obtener detalles sobre qué tipos de integraciones admiten la funcionalidad descrita en esta página.
Configuración de esquema admitida supported-schema-types
El Destination SDK admite varias configuraciones de esquema:
- Los esquemas estáticos se definen mediante la matriz
profileFields
en la secciónschemaConfig
. En un esquema estático, define todos los atributos de destino que deben mostrarse en la interfaz de usuario del Experience Platform en la matrizprofileFields
. Si necesita actualizar su esquema, debe actualizar la configuración de destino. - Los esquemas dinámicos utilizan un tipo de servidor de destino adicional, denominado servidor de esquema dinámico, para recuperar dinámicamente los atributos de destino admitidos y generar esquemas basados en su propia API. Los esquemas dinámicos no utilizan la matriz
profileFields
. Si necesita actualizar su esquema, no es necesario actualizar la configuración de destino. En su lugar, el servidor de esquema dinámico recupera el esquema actualizado de la API. - En la configuración del esquema, tiene la opción de añadir las asignaciones necesarias (o predefinidas). Son asignaciones que los usuarios pueden ver en la interfaz de usuario de Platform, pero no pueden modificarlas al configurar una conexión con el destino. Por ejemplo, puede hacer que el campo de dirección de correo electrónico se envíe siempre al destino.
La sección schemaConfig
utiliza varios parámetros de configuración, según el tipo de esquema que necesite, como se muestra en las secciones siguientes.
Creación de un esquema estático attributes-schema
Para crear un esquema estático con atributos de perfil, defina los atributos de destino en la matriz profileFields
como se muestra a continuación.
"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
, puede omitir completamente el parámetro useCustomerSchemaForAttributeMapping
.useCustomerSchemaForAttributeMapping
Habilita o deshabilita la asignación de atributos del esquema cliente a los atributos definidos en la matriz profileFields
.
- Si se establece en
true
, los usuarios solo verán la columna de origen en el campo de asignación.profileFields
no son aplicables en este caso. - Si se establece en
false
, los usuarios pueden asignar atributos de origen de su esquema a los atributos definidos en la matrizprofileFields
.
El valor predeterminado es false
.
profileRequired
true
si los usuarios deben poder asignar atributos de perfil del Experience Platform a atributos personalizados en la plataforma de destino.segmentRequired
true
.identityRequired
true
si los usuarios deben poder asignar tipos de identidad del Experience Platform a los atributos definidos en la matriz profileFields
segmentNamespaceAllowList
segmentNamespaceDenyList
.Ejemplo:
"segmentNamespaceAllowList": ["AudienceManager"]
permitirá a los usuarios asignar solamente audiencias del área de nombres AudienceManager
a este destino.Para permitir que los usuarios exporten cualquier audiencia a su destino, puede ignorar este parámetro.
Si faltan
segmentNamespaceAllowList
y segmentNamespaceDenyList
en la configuración, los usuarios solo podrán exportar audiencias que se originen del servicio de segmentación.segmentNamespaceDenyList
segmentNamespaceAllowed
.Ejemplo:
"segmentNamespaceDenyList": ["AudienceManager"]
impedirá que los usuarios asignen audiencias del área de nombres AudienceManager
a este destino.Para permitir que los usuarios exporten cualquier audiencia a su destino, puede ignorar este parámetro.
Si faltan
segmentNamespaceAllowed
y segmentNamespaceDenyList
en la configuración, los usuarios solo podrán exportar audiencias que se originen del servicio de segmentación.Para permitir la exportación de todas las audiencias, independientemente del origen, establezca
"segmentNamespaceDenyList":[]
.La experiencia de IU resultante se muestra en las imágenes siguientes.
Cuando los usuarios seleccionan la asignación de destino, pueden ver los campos definidos en la matriz profileFields
.
Después de seleccionar los atributos, pueden verlos en la columna del campo de destinatario.
Creación de un esquema dinámico dynamic-schema-configuration
Destination SDK permite crear esquemas de socios dinámicos. A diferencia de un esquema estático, un esquema dinámico no utiliza una matriz profileFields
. En su lugar, los esquemas dinámicos utilizan un servidor de esquema dinámico que se conecta a su propia API desde donde recupera la configuración de esquema.
En una configuración de esquema dinámico, la matriz profileFields
se reemplaza por la sección dynamicSchemaConfig
, como se muestra a continuación.
"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 cómo se conectan los clientes de Platform a su destino. Los valores aceptados son CUSTOMER_AUTHENTICATION
, PLATFORM_AUTHENTICATION
, NONE
.
- Use
CUSTOMER_AUTHENTICATION
si los clientes de Platform inician sesión en el sistema mediante cualquiera de los métodos de autenticación descritos aquí. - Use
PLATFORM_AUTHENTICATION
si existe un sistema de autenticación global entre el Adobe y el destino y el cliente Platform no necesita proporcionar credenciales de autenticación para conectarse al destino. En este caso, debe crear un objeto de credenciales mediante la API de credenciales. - Use
NONE
si no se requiere autenticación para enviar datos a la plataforma de destino.
dynamicEnum.destinationServerId
instanceId
de su servidor de esquema dinámico. Este servidor de destino incluye el extremo de API al que el Experience Platform llamará para recuperar el esquema dinámico.dynamicEnum.value
dynamicEnum.responseFormat
SCHEMA
al definir un esquema dinámico.profileRequired
true
si los usuarios deben poder asignar atributos de perfil del Experience Platform a atributos personalizados en la plataforma de destino.segmentRequired
true
.identityRequired
true
si los usuarios deben poder asignar tipos de identidad del Experience Platform a los atributos definidos en la matriz profileFields
Asignaciones requeridas required-mappings
En la configuración del esquema, además del esquema estático o dinámico, tiene la opción de añadir las asignaciones necesarias (o predefinidas). Son asignaciones que los usuarios pueden ver en la interfaz de usuario de Platform, pero no pueden modificarlas al configurar una conexión con el destino.
Por ejemplo, puede hacer que el campo de dirección de correo electrónico se envíe siempre al destino.
- Puede configurar un campo de origen y un campo de destino obligatorios. En este caso, los usuarios no pueden editar ni seleccionar ninguno de los dos campos y solo pueden ver la selección.
- Solo puede configurar un campo de destino requerido. En este caso, los usuarios podrán seleccionar un campo de origen para asignarlo al destino.
Vea a continuación dos ejemplos de una configuración de esquema con asignaciones requeridas y cómo se ven en el paso de asignación de activar datos en el flujo de trabajo de destinos por lotes.
El ejemplo siguiente muestra las asignaciones de origen y destino requeridas. Cuando los campos de origen y de destino se especifican como asignaciones requeridas, los usuarios no pueden seleccionar ni editar ninguno de los dos campos y solo pueden ver la selección 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 | Obligatorio/Opcional | Descripción |
requiredMappingsOnly |
Booleano | Opcional | Cuando se establece en true , los usuarios no pueden asignar otros atributos e identidades en el flujo de activación, aparte de las asignaciones necesarias que defina en la matriz requiredMappings . |
requiredMappings.sourceType |
Cadena | Requerido |
Indica el tipo del campo
|
requiredMappings.source |
Cadena | Requerido |
Indica el valor del campo de origen. Tipos de valores admitidos:
|
requiredMappings.destination |
Cadena | Requerido | Indica el valor del campo de destino. Cuando los campos de origen y de destino se especifican como asignaciones requeridas, los usuarios no pueden seleccionar ni editar ninguno de los dos campos y solo pueden ver la selección. |
Como resultado, las secciones Campo de Source y Campo de destino de la IU de Platform están atenuadas.
El ejemplo siguiente muestra una asignación de destino requerida. Si solo se especifica el campo de destino como obligatorio, los usuarios pueden seleccionar qué campo de origen se asignará a él.
code language-json |
---|
|
table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 layout-auto | |||
---|---|---|---|
Parámetro | Tipo | Obligatorio/Opcional | Descripción |
requiredMappingsOnly |
Booleano | Opcional | Cuando se establece en true , los usuarios no pueden asignar otros atributos e identidades en el flujo de activación, aparte de las asignaciones necesarias que defina en la matriz requiredMappings . |
requiredMappings.destination |
Cadena | Requerido | Indica el valor del campo de destino. Cuando solo se especifica el campo de destino, los usuarios pueden seleccionar un campo de origen para asignarlo al destino. |
mandatoryRequired |
Booleano | Opcional | Indica si la asignación debe marcarse como atributo obligatorio. |
primaryKeyRequired |
Booleano | Opcional | Indica si la asignación debe marcarse como clave de anulación de duplicación. |
Como resultado, la sección Campo de destino de la IU de Platform está atenuada, mientras que la sección Campo de Source está activa y los usuarios pueden interactuar con ella. Las opciones Clave obligatoria y Clave de anulación de duplicación están activas y los usuarios no pueden cambiarlas.
Configuración de la compatibilidad con audiencias externas external-audiences
Para configurar el destino de modo que admita la activación de audiencias generadas externamente, incluya el fragmento de código siguiente en la sección schemaConfig
.
"schemaConfig": {
"segmentNamespaceDenyList": [],
...
}
Consulte las descripciones de las propiedades en la tabla más arriba en esta página para obtener más información acerca de la funcionalidad segmentNamespaceDenyList
.
Pasos siguientes next-steps
Después de leer este artículo, debería comprender mejor qué tipos de esquema admite Destination SDK y cómo puede configurar el esquema.
Para obtener más información acerca de los demás componentes de destino, consulte los siguientes artículos:
- Autenticación del cliente
- Autorización de OAuth2
- Atributos de IU
- Campos de datos del cliente
- Configuración del área de nombres de identidad
- Configuraciones de asignación compatibles
- Envío de destino
- Configuración de metadatos de audiencia
- Política de agregación
- Configuración por lotes
- Cualificaciones históricas del perfil