Consentimiento e identidad en la recopilación de datos

El consentimiento y la identidad están estrechamente relacionados en las implementaciones de Web SDK. La forma y el momento en que se recopila el consentimiento afectan directamente al momento y al momento en que Web SDK genera un ECID, establece cookies de identidad y envía datos a Edge Network. Cuando el consentimiento no se gestiona con cuidado, el resultado es a menudo una inflación de visitantes inesperada, brechas en la continuidad de la identidad o ambas cosas.

Esta página explica cómo las opciones de consentimiento interactúan con el comportamiento de identidad y proporciona instrucciones para configurar la implementación a fin de evitar escollos comunes. Para obtener información general sobre cómo administra Web SDK los ECID, FPID y otras señales de identidad, consulte Identidad en la recopilación de datos.

Cómo afecta el consentimiento a la identidad how-consent-affects-identity

Web SDK utiliza la variable de configuración defaultConsent y el comando setConsent para controlar si envía datos a Edge Network. El estado de consentimiento determina directamente cuándo se genera un ECID y cuándo se configuran las cookies de identidad.

En la tabla siguiente se muestra el efecto combinado de defaultConsent y setConsent en la recopilación de datos, la configuración de cookies y el comportamiento de identidad.

Cuando un visitante vuelve a conceder el consentimiento después de revocarlo anteriormente (llamando a setConsent con "general": "in" después de "general": "out"), Web SDK reanuda el envío de eventos y utiliza el ECID existente de la cookie si no ha caducado. Se conserva la identidad del visitante.

Una vez que un visitante concede o deniega el consentimiento, Web SDK mantiene su preferencia en una cookie de consentimiento de kndctr_. En cargas de página subsiguientes, SDK lee esta cookie y aplica la preferencia almacenada automáticamente; no es necesario que vuelva a llamar a setConsent a menos que cambie la preferencia del visitante. Tenga en cuenta que el valor de configuración defaultConsent no persiste entre cargas de página, pero el consentimiento resuelto del visitante (establecido mediante setConsent) sí.

Patrones de implementación implementation-patterns

Modelo de inclusión (se requiere consentimiento antes de la recopilación) opt-in

Utilice este patrón cuando las regulaciones (como el RGPD) requieran un consentimiento explícito antes de recopilar datos.

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" }
  }]
});

Con este patrón:

Modelo de exclusión (colección de forma predeterminada, detener en caso de denegación) opt-out

Utilice este patrón cuando las regulaciones permitan la recopilación de datos de forma predeterminada con una opción de exclusión.

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" }
  }]
});

Con este patrón:

Consentimiento con ID de dispositivo de origen consent-with-fpids

Si su implementación utiliza ID de dispositivos de origen (FPID), el servidor establece la cookie FPID independientemente del estado de consentimiento de Web SDK. La cookie FPID es un identificador que administra en su propia infraestructura. Sin embargo, el FPID solo se envía a Edge Network cuando Web SDK realiza una solicitud (que se cierra mediante consentimiento):

Si la implementación del consentimiento requiere que no se establezca ningún identificador antes del consentimiento, retrase la configuración de la cookie FPID hasta que se comunique el consentimiento. La única función de acceso de consentimiento de Web SDK no impide que se establezca la cookie FPID, ya que la administra el servidor.

Peligros comunes common-pitfalls