Processamento de solicitação de privacidade no data lake

O Adobe Experience Platform Privacy Service processa solicitações do cliente para acessar, cancelar a venda ou excluir seus dados pessoais, conforme definido pelas regulamentações legais e organizacionais de privacidade.

Este documento aborda conceitos essenciais relacionados ao processamento de solicitações de privacidade para dados do cliente armazenados no data lake.

Introdução

É recomendável que você tenha uma compreensão funcional dos seguintes serviços do Experience Platform antes de ler este guia:

Compreensão dos namespaces de identidade namespaces

O Adobe Experience Platform Identity Service une dados de identidade do cliente entre sistemas e dispositivos. Identity Service usa namespaces de identidade para fornecer contexto aos valores de identidade, relacionando-os ao seu sistema de origem. Um namespace pode representar um conceito genérico, como um endereço de email ("Email") ou associar a identidade a um aplicativo específico, como uma Adobe Advertising Cloud ID ("AdCloud") ou Adobe Target ID ("TNTID").

Identity Service mantém um armazenamento de namespaces de identidade definidos globalmente (padrão) e definidos pelo usuário (personalizado). Os namespaces padrão estão disponíveis para todas as organizações (por exemplo, "Email" e "ECID"), enquanto sua organização também pode criar namespaces personalizados para atender às suas necessidades específicas.

Para obter mais informações sobre namespaces de identidade em Experience Platform, consulte a visão geral sobre namespaces de identidade.

Adição de dados de identidade a conjuntos de dados

Ao criar solicitações de privacidade para o data lake, valores de identidade válidos (e seus namespaces associados) devem ser fornecidos para cada cliente individual para localizar seus dados e processá-los adequadamente. Portanto, todos os conjuntos de dados sujeitos a solicitações de privacidade devem conter um descritor de identidade em seu esquema XDM associado.

Esta seção aborda as etapas de adição de um descritor de identidade a um esquema XDM do conjunto de dados existente. Se você já tiver um conjunto de dados com um descritor de identidade, poderá pular para a próxima seção.

Há dois métodos de adicionar um descritor de identidade a um esquema de conjunto de dados:

Uso da interface identity-ui

Na Experience Platforminterface de usuário, o espaço de trabalho Esquemas permite editar seus esquemas XDM existentes. Para adicionar um descritor de identidade a um esquema, selecione o esquema na lista e siga as etapas para definir um campo de esquema como um campo de identidade no tutorial Schema Editor.

Depois de definir os campos apropriados no esquema como campos de identidade, você pode prosseguir para a próxima seção em enviando solicitações de privacidade.

Uso da API identity-api

Você pode adicionar um descritor de identidade ao esquema XDM de um conjunto de dados fazendo uma solicitação POST para o ponto de extremidade /descriptors na API Schema Registry.

Formato da API

POST /descriptors

Solicitação

A solicitação a seguir define um descritor de identidade em um campo "endereço de email" em um esquema de amostra.

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
      }'

Resposta

Uma resposta bem-sucedida retorna o status HTTP 201 (Criado) e os detalhes do descritor recém-criado.

{
  "@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"
}

Envio de solicitações submit

A seção a seguir descreve como fazer solicitações de privacidade para o data lake usando a interface ou a API Privacy Service.

Uso da interface

Ao criar solicitações de trabalho na interface do usuário, selecione Data Lake da AEP em Produtos para processar trabalhos para dados armazenados no data lake.

Uso da API

Ao criar solicitações de trabalho na API, qualquer userIDs fornecido deve usar um namespace e type específicos, dependendo do armazenamento de dados ao qual se aplicam. As IDs do data lake devem usar unregistered para seu valor type e um valor namespace que corresponda a um dos rótulos de privacidade que foram adicionados aos conjuntos de dados aplicáveis.

Além disso, a matriz include da carga da solicitação deve incluir os valores de produto para os diferentes armazenamentos de dados para os quais a solicitação está sendo feita. Ao fazer solicitações ao data lake, a matriz deve incluir o valor aepDataLake.

A solicitação a seguir cria um novo trabalho de privacidade para o data lake, usando o namespace email_label não registrado. Também inclui o valor do produto para o data lake na matriz include:

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"
}'

Processamento de solicitação de exclusão

Quando Experience Platform recebe uma solicitação de exclusão de Privacy Service, Platform envia uma confirmação para Privacy Service de que a solicitação foi recebida e de que os dados afetados foram marcados para exclusão. Os registros são removidos do data lake em sete dias. Durante esse período de sete dias, os dados são excluídos por software e, portanto, não estão acessíveis por nenhum serviço do Platform.

Se você também incluiu ProfileService ou identity na solicitação de privacidade, os dados associados a eles serão tratados separadamente. Consulte a seção sobre processamento de solicitação de exclusão do Perfil para obter mais informações.

Próximas etapas

Ao ler este documento, você foi apresentado aos conceitos importantes envolvidos no processamento de solicitações de privacidade do data lake. É recomendável continuar lendo a documentação fornecida neste guia para aprofundar sua compreensão de como gerenciar dados de identidade e criar processos de privacidade.

Consulte o documento sobre processamento de solicitação de privacidade para o Perfil de Cliente em Tempo Real para obter as etapas sobre o processamento de solicitações de privacidade para a loja Profile.

Apêndice

A seção a seguir contém informações adicionais para o processamento de solicitações de privacidade no data lake.

Rotulagem de campos aninhados do tipo mapa nested-maps

É importante observar que há dois tipos de campos aninhados do tipo mapa que não oferecem suporte à rotulagem de privacidade:

O processamento do trabalho de privacidade para qualquer um dos dois exemplos acima acabará falhando. Por esse motivo, é recomendável evitar o uso de campos aninhados do tipo mapa para armazenar dados privados do cliente. As IDs de consumidores relevantes devem ser armazenadas como um tipo de dados não mapeado no campo identityMap (ele próprio um campo do tipo mapa) para conjuntos de dados baseados em registro, ou no campo endUserID para conjuntos de dados baseados em série temporal.