Adobe Experience Platform Privacy Service procesa las solicitudes de los clientes para acceder, excluirse de la venta o eliminar sus datos personales según lo establecido en las normas legales y de privacidad de la organización.
Este documento cubre conceptos esenciales relacionados con el procesamiento de solicitudes de privacidad para los datos de clientes almacenados en la variable Data Lake.
Esta guía solo explica cómo realizar solicitudes de privacidad para el lago de datos en Experience Platform. Si también planea realizar solicitudes de privacidad para el almacén de datos del perfil del cliente en tiempo real, consulte la guía de procesamiento de solicitudes de privacidad para Perfil además de este tutorial.
Para ver los pasos sobre cómo realizar solicitudes de privacidad para otras aplicaciones de Adobe Experience Cloud, consulte la documentación del Privacy Service.
Se recomienda que tenga una comprensión práctica de lo siguiente Experience Platform antes de leer esta guía:
Adobe Experience Platform Identity Service vincula los datos de identidad de los clientes entre sistemas y dispositivos. Identity Service utiliza áreas de nombres de identidad para proporcionar contexto a los valores de identidad relacionándolos con su sistema de origen. Un área de nombres puede representar un concepto genérico, como una dirección de correo electrónico ("correo electrónico") o asociar la identidad a una aplicación específica, como un Adobe Advertising Cloud ID ("AdCloud") o un Adobe Target ID ("TNTID").
Identity Service mantiene un almacén de áreas de nombres de identidad definidas globalmente (estándar) y definidas por el usuario (personalizadas). Las áreas de nombres estándar están disponibles para todas las organizaciones (por ejemplo, "correo electrónico" y "ECID"), mientras que la organización también puede crear áreas de nombres personalizadas para adaptarlas a sus necesidades específicas.
Para obtener más información sobre áreas de nombres de identidad en Experience Platform, consulte la información general del área de nombres de identidad.
Al crear solicitudes de privacidad para la variable Data Lake, se deben proporcionar valores de identidad válidos (y sus áreas de nombres asociadas) para cada cliente individual a fin de localizar sus datos y procesarlos en consecuencia. Por lo tanto, todos los conjuntos de datos sujetos a solicitudes de privacidad deben contener un descriptor de identidad en su esquema XDM asociado.
Actualmente, los conjuntos de datos basados en esquemas que no admiten metadatos del descriptor de identidad (como conjuntos de datos ad-hoc) no se pueden procesar en solicitudes de privacidad.
Esta sección explica los pasos para agregar un descriptor de identidad al esquema XDM de un conjunto de datos existente. Si ya tiene un conjunto de datos con un descriptor de identidad, puede pasar al sección siguiente.
Cuando decida qué campos de esquema desea establecer como identidades, tenga en cuenta la variable limitaciones de uso de campos anidados de tipo mapa.
Existen dos métodos para añadir un descriptor de identidad a un esquema de conjunto de datos:
En el Experience Platform interfaz de usuario, la variable Esquemas workspace le permite editar los esquemas XDM existentes. Para añadir un descriptor de identidad a un esquema, seleccione el esquema en la lista y siga los pasos para definición de un campo de esquema como campo de identidad en el Schema Editor tutorial.
Una vez configurados los campos adecuados dentro del esquema como campos de identidad, puede continuar con la siguiente sección en envío de solicitudes de privacidad.
Esta sección supone que conoce el valor de ID de URI único del esquema XDM de su conjunto de datos. Si no conoce este valor, puede recuperarlo utilizando la variable Catalog Service API. Después de leer el introducción de la guía para desarrolladores, siga los pasos descritos en para lista o buscar Catalog para encontrar el conjunto de datos. El ID de esquema se puede encontrar en schemaRef.id
En esta sección también se da por hecho que sabe cómo realizar llamadas a la API del Registro de esquemas. Para obtener información importante relacionada con el uso de la API, incluido el hecho de conocer su {TENANT_ID}
y el concepto de contenedores, consulte la introducción de la guía de API.
Puede añadir un descriptor de identidad al esquema XDM de un conjunto de datos realizando una solicitud de POST al /descriptors
en la variable Schema Registry API.
Formato de API
POST /descriptors
Solicitud
La siguiente solicitud define un descriptor de identidad en un campo "dirección de correo electrónico" de un esquema de ejemplo.
curl -X POST \
https://platform.adobe.io/data/foundation/schemaregistry/tenant/descriptors \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'x-sandbox-name: {SANDBOX_NAME}' \
-H 'Content-Type: application/json' \
-d '
{
"@type": "xdm:descriptorIdentity",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/personalEmail/address",
"xdm:namespace": "Email",
"xdm:property": "xdm:code",
"xdm:isPrimary": false
}'
Propiedad | Descripción |
---|---|
@type |
Tipo de descriptor que se está creando. Para los descriptores de identidad, el valor debe ser "xdm:descriptorIdentity". |
xdm:sourceSchema |
ID de URI único del esquema XDM de su conjunto de datos. |
xdm:sourceVersion |
La versión del esquema XDM especificado en xdm:sourceSchema . |
xdm:sourceProperty |
Ruta al campo de esquema al que se está aplicando el descriptor. |
xdm:namespace |
Uno de los áreas de nombres de identidad estándar reconocido por Privacy Serviceo un espacio de nombres personalizado definido por su organización. |
xdm:property |
"xdm:id" o "xdm:code", según el espacio de nombres que se utilice en xdm:namespace . |
xdm:isPrimary |
Un valor booleano opcional. Cuando es true, esto indica que el campo es una identidad principal. Los esquemas solo pueden contener una identidad principal. Si no se incluye, el valor predeterminado es false . |
Respuesta
Una respuesta correcta devuelve el estado HTTP 201 (Creado) y los detalles del descriptor recién creado.
{
"@type": "xdm:descriptorIdentity",
"xdm:sourceSchema": "https://ns.adobe.com/{TENANT_ID}/schemas/fbc52b243d04b5d4f41eaa72a8ba58be",
"xdm:sourceVersion": 1,
"xdm:sourceProperty": "/personalEmail/address",
"xdm:namespace": "Email",
"xdm:property": "xdm:code",
"xdm:isPrimary": false,
"meta:containerId": "tenant",
"@id": "f3a1dfa38a4871cf4442a33074c1f9406a593407"
}
Esta sección explica cómo dar formato a las solicitudes de privacidad para la variable Data Lake. Se recomienda que revise la Privacy Service IU o Privacy Service API documentación para ver los pasos completos sobre cómo enviar un trabajo de privacidad, incluido cómo dar formato correcto a los datos de identidad de usuario enviados en las cargas de solicitud.
La siguiente sección describe cómo realizar solicitudes de privacidad para la variable Data Lake usando la variable Privacy Service IU o API.
No se puede garantizar la cantidad de tiempo que una solicitud de privacidad puede tardar en completarse. Si se producen cambios dentro del lago de datos mientras se procesa una solicitud, no se puede garantizar si esos registros se procesan o no.
Al crear solicitudes de trabajo en la interfaz de usuario, asegúrese de seleccionar Lago de datos AEP y/o Perfil under Productos para procesar los trabajos de los datos almacenados en la variable Data Lake o Real-time Customer Profile, respectivamente.
Al crear solicitudes de trabajo en la API, cualquier userIDs
que se proporcionan deben utilizar un namespace
y type
según el almacén de datos al que se apliquen. ID para Data Lake debe usarse unregistered
para su type
y un namespace
que coincida con uno de los valores etiquetas de privacidad que se han agregado a conjuntos de datos aplicables.
Además, la variable include
matriz de la carga útil de solicitud debe incluir los valores de producto para los diferentes almacenes de datos a los que se realiza la solicitud. Al realizar solicitudes para Data Lake, la matriz debe incluir el valor aepDataLake
.
La siguiente solicitud crea un nuevo trabajo de privacidad para el Data Lake, utilizando el email_label
espacio de nombres. También incluye el valor del producto para la variable Data Lake en el include
matriz:
curl -X POST \
https://platform.adobe.io/data/core/privacy/jobs \
-H 'Authorization: Bearer {ACCESS_TOKEN}' \
-H 'x-api-key: {API_KEY}' \
-H 'x-gw-ims-org-id: {ORG_ID}' \
-H 'Content-Type: application/json' \
-d '{
"companyContexts": [
{
"namespace": "imsOrgID",
"value": "{ORG_ID}"
}
],
"users": [
{
"key": "user12345",
"action": ["access","delete"],
"userIDs": [
{
"namespace": "email_label",
"value": "ajones@acme.com",
"type": "unregistered"
},
{
"namespace": "email_label",
"value": "jdoe@example.com",
"type": "unregistered"
}
]
}
],
"include": ["aepDataLake"],
"expandIds": false,
"priority": "normal",
"regulation": "ccpa"
}'
Platform procesa las solicitudes de privacidad en todas las entornos limitados pertenecer a su organización. Como resultado, cualquier x-sandbox-name
el sistema ignora el encabezado incluido en la solicitud.
When Experience Platform recibe una solicitud de eliminación de Privacy Service, Platform envía confirmación a Privacy Service que la solicitud se ha recibido y los datos afectados se han marcado para su eliminación. A continuación, los registros se eliminan del Data Lake en un plazo de siete días. Durante esa ventana de siete días, los datos se eliminan de forma suave y, por lo tanto, ningún usuario puede acceder a ellos. Platform servicio.
En futuras versiones, Platform enviará confirmación a Privacy Service después de eliminar físicamente los datos.
Al leer este documento, se le han introducido los conceptos importantes relacionados con el procesamiento de solicitudes de privacidad para la variable Data Lake. Se recomienda seguir leyendo la documentación proporcionada en esta guía para comprender mejor cómo administrar los datos de identidad y crear trabajos de privacidad.
Consulte el documento en procesamiento de solicitudes de privacidad para Perfil del cliente en tiempo real para ver los pasos sobre el procesamiento de solicitudes de privacidad para la variable Profile tienda.
La siguiente sección contiene información adicional para procesar solicitudes de privacidad en la variable Data Lake.
Es importante tener en cuenta que hay dos tipos de campos anidados de tipo mapa que no admiten el etiquetado de privacidad:
El procesamiento del trabajo de privacidad de cualquiera de los dos ejemplos anteriores fallará finalmente. Por este motivo, se recomienda evitar el uso de campos anidados de tipo mapa para almacenar datos privados de clientes. Los ID de consumidor relevantes deben almacenarse como un tipo de datos que no sea de asignación dentro del identityMap
campo (campo de tipo map) para conjuntos de datos basados en registros o endUserID
para conjuntos de datos basados en series temporales.