Consentimento e identidade na coleção de dados

O consentimento e a identidade estão intimamente conectados em implementações do Web SDK. Como e quando você coleta o consentimento afeta diretamente quando e se o Web SDK gera uma ECID, define cookies de identidade e envia dados para a Edge Network. Quando o consentimento não é tratado com cuidado, o resultado geralmente é uma inflação inesperada de visitantes, lacunas na continuidade da identidade ou ambos.

Esta página explica como as opções de consentimento interagem com o comportamento da identidade e fornece orientação para configurar sua implementação a fim de evitar armadilhas comuns. Para obter informações sobre como o Web SDK lida com ECIDs, FPIDs e outros sinais de identidade, consulte Identidade na Coleção de Dados.

Como o consentimento afeta a identidade how-consent-affects-identity

O Web SDK usa a variável de configuração defaultConsent e o comando setConsent para controlar se envia dados para o Edge Network. O status de consentimento determina diretamente quando uma ECID é gerada e quando os cookies de identidade são definidos.

A tabela a seguir mostra o efeito combinado de defaultConsent e setConsent na coleta de dados, configuração de cookie e comportamento de identidade.

Quando um visitante consente novamente depois de revogá-lo anteriormente (chamando setConsent com "general": "in" após "general": "out"), o Web SDK retoma o envio de eventos e usa a ECID existente do cookie, se ela não tiver expirado. A identidade do visitante é preservada.

Depois que um visitante concede ou nega o consentimento, o Web SDK persiste sua preferência em um cookie de consentimento kndctr_. Em carregamentos de páginas subsequentes, o SDK lê esse cookie e aplica a preferência armazenada automaticamente. Você não precisa chamar setConsent novamente, a menos que a preferência do visitante seja alterada. Observe que o valor de configuração defaultConsent não persiste entre os carregamentos de página, mas o consentimento resolvido do visitante (definido por meio de setConsent) persiste.

Padrões de implementação implementation-patterns

Modelo de Opt-in (consentimento necessário antes da coleta) opt-in

Use esse padrão quando as regulamentações (como o GDPR) exigirem consentimento explícito antes de coletar quaisquer dados.

alloy("configure", {
  orgId: "YOUR_ORG_ID@AdobeOrg",
  edgeDomain: "data.example.com",
  defaultConsent: "pending"
});

// When the visitor grants consent:
alloy("setConsent", {
  consent: [{
    standard: "Adobe",
    version: "1.0",
    value: { general: "in" }
  }]
});

Com este padrão:

Modelo de recusa (coleção por padrão, parada na negação) opt-out

Use esse padrão quando os regulamentos permitirem a coleta de dados por padrão com uma opção de recusa.

alloy("configure", {
  orgId: "YOUR_ORG_ID@AdobeOrg",
  edgeDomain: "data.example.com",
  defaultConsent: "in"
});

// If the visitor opts out:
alloy("setConsent", {
  consent: [{
    standard: "Adobe",
    version: "1.0",
    value: { general: "out" }
  }]
});

Com este padrão:

Consentimento com IDs de dispositivo primário consent-with-fpids

Se sua implementação usa IDs de dispositivo próprio (FPIDs), o cookie FPID é definido pelo seu servidor independentemente do estado de consentimento do Web SDK. O cookie FPID é um identificador que você gerencia em sua própria infraestrutura. No entanto, o FPID só é enviado para o Edge Network quando o Web SDK faz uma solicitação (que é fechada por consentimento):

Se sua implementação de consentimento exigir que nenhum identificador seja definido antes do consentimento, atrase a definição do cookie FPID até que o consentimento seja comunicado. A marcação de consentimento do Web SDK sozinha não impede que o cookie FPID seja definido, pois ele é gerenciado pelo seu servidor.

Armadilhas comuns common-pitfalls