Gestión del consentimiento con el SDK de Singular: un marco de decisión

Seguir
Avatar
Jared Ornstead
Updated

Gestión del consentimiento con el SDK de Singular: un marco de decisión

Este artículo describe los controles de privacidad que ofrece Singular y los patrones de implementación que observamos en nuestra base de clientes, y ofrece un marco para combinarlos en una arquitectura de consentimiento. Cada control se documenta en su propio artículo; esta página explica cómo funcionan en conjunto.

Antes de empezar: Tus equipos legales y de privacidad controlan tu flujo de consentimiento y son responsables de decidir qué postura aplica a tu app en cada jurisdicción. Este artículo describe únicamente el comportamiento del producto y no constituye asesoramiento legal.

Las dos decisiones a las que se reduce todo flujo de consentimiento

Los controles de privacidad de Singular se organizan en torno a dos decisiones independientes. Mantenerlas separadas permite que un solo aviso de consentimiento impulse una implementación conforme.

Decisión 1: Seguimiento. ¿Singular ve a este usuario? Esto se controla según si inicializas el SDK y cuándo lo haces. La inicialización envía la primera sesión, crea el registro de instalación y activa el procesamiento de atribución. Si el SDK nunca se inicializa, Singular no recibe nada del dispositivo. Este es el control más estricto disponible.

Decisión 2: Uso compartido. Dado que Singular ve al usuario, ¿pueden compartirse sus datos con los socios publicitarios? Esto se controla con el flag Limit Data Sharing (LDS). LDS te permite conservar la analítica propia (sesiones, retención, eventos, tus informes) a la vez que restringes lo que fluye a los socios en los postbacks. Consulta la Limit Data Sharing FAQ para conocer la semántica y el comportamiento de los socios.

Si tu marco de consentimiento distingue el consentimiento de medición del consentimiento de publicidad o retargeting (común en la EEA), la asignación es directa: el consentimiento de medición condiciona la inicialización y el consentimiento de publicidad establece LDS. Un solo aviso, resuelto una vez, impulsa ambas palancas.

Inventario de controles, del menos al más restrictivo

Control Qué hace Qué no hace
limitDataSharing (config o en tiempo de ejecución) Marca la preferencia de uso compartido del usuario; el comportamiento de los postbacks de los socios sigue tu configuración por socio. No impide que Singular rastree; no cambia los postbacks a menos que se configuren restricciones a nivel de socio.
Modo de identificadores limitados El SDK no recopila IDFA ni GAID; usa IDFV o ASID en su lugar. No detiene el seguimiento ni el uso compartido de identificadores no publicitarios.
stopAllTracking() Detiene toda transmisión de forma inmediata y persistente hasta que se llame a resumeAllTracking(). No deshace la instalación ni los eventos ya enviados; la inicialización ya activó la atribución.
No inicializar nunca Singular no recibe ni procesa nada del dispositivo. Los deferred deep links y la atribución no están disponibles para estos usuarios.
trackingOptIn() Heredado: solo registra un evento de notificación de consentimiento. No tiene ningún efecto funcional sobre el seguimiento ni el manejo de datos; no construyas la lógica de consentimiento sobre él.

Tres modelos de flujo de consentimiento

  • Rechazo por defecto (inicializar primero): El SDK se inicializa al abrir la app; el consentimiento se presenta durante el onboarding; un rechazo activa stopAllTracking() o establece LDS en true. Esto da fidelidad de atribución completa y postbacks rápidos a las SAN. El momento de la instalación se captura antes de que el usuario responda, por lo que este modelo requiere una postura legal que permita la recopilación antes de una elección afirmativa. Común para audiencias de EE. UU.
  • Aceptación por defecto (consentimiento primero): El SDK no se inicializa hasta que el usuario da su consentimiento afirmativo. No se transmite nada para los usuarios que no consienten. Estándar para audiencias de GDPR. Conserva la decisión e inicializa de inmediato en los inicios posteriores en todos los puntos de entrada de la app.
  • Híbrido (inicializar de inmediato, resolver LDS en la inicialización): Resuelve la superficie de consentimiento al abrir la app y luego inicializa con limitDataSharing ya establecido en el objeto de configuración. Cada registro, desde la instalación en adelante, lleva el estado declarado por el usuario, sin ninguna ventana en la que exista la intención pero no se haya aplicado. Este es el patrón que recomendamos a los clientes sensibles a la privacidad que pueden mostrar el consentimiento al abrir.

La mayoría de las apps multirregión ejecutan más de un modelo, seleccionado en tiempo de ejecución según la jurisdicción o su CMP.

Consecuencias de tiempo que debes planificar

  • La inicialización diferida no cuesta la instalación si ocurre dentro de la misma sesión de la app: el install referrer de Android persiste en el dispositivo y la solicitud de atribución se completa con normalidad.
  • Las tasas de coincidencia de las SAN se degradan cuando la inicialización se retrasa mucho (flujos de consentimiento de varios pasos, intervalos de varios días). Mantén las pantallas del primer inicio en una sola pantalla rápida.
  • Los postbacks de SKAdNetwork los genera el sistema operativo en el momento de la instalación y no se ven afectados por el momento de la inicialización del SDK.
  • Los deferred deep links requieren que se resuelvan la inicialización y la atribución. Con un modelo estricto de aceptación, el deferred deep linking solo está disponible para usuarios que consintieron.
  • No hay callback de inicialización completada. Si creas una secuenciación de eventos personalizada, captura el estado de consentimiento en el momento de la inicialización.
  • El registro de instalación fija el valor de LDS vigente en la inicialización. Las actualizaciones posteriores se aplican solo a los eventos siguientes y los postbacks ya enviados no se recuperan. No establezcas LDS en true de forma predeterminada para usuarios indecisos a menos que tu postura legal lo exija; resuelve el consentimiento primero o deja LDS sin establecer (unset) hasta que el usuario responda.

Errores comunes

  • Un LDS sin establecer se trata como no limitado. Una integración que pretende restringir a un usuario pero aún no ha establecido el flag es, desde la perspectiva de Singular, un usuario sin restricciones.
  • LDS en true no cambia nada por sí solo. El comportamiento de los postbacks para usuarios con LDS se define por socio y por app en tu configuración de socios (no enviar / enviar sin PII / enviar como de costumbre). Establece el flag y configura la aplicación.
  • ATT no es un marco de consentimiento. ATT solo rige la divulgación del IDFA. Si un rechazo de ATT también debe implicar LDS en true es una decisión de política de tu equipo de privacidad.
  • El borrado del GDPR no es una exclusión. La API de OpenDSR elimina los datos recopilados; no impide que el SDK envíe eventos futuros. Combina el borrado con stopAllTracking() en el mismo flujo de usuario.

Artículos relacionados