LDS tiene tres estados posibles. El valor que envías (o la ausencia de uno) determina cómo trata Singular al usuario al compartir datos con los socios.

LDS debe utilizarse para escenarios en los que la implementación del SDK (o API S2S) de Singular mide la actividad de la aplicación, pero es posible que desee que la plataforma de Singular personalice o restrinja las formas en que los datos de los usuarios se transmiten a los socios para los que ha configurado las integraciones de Singular.

• Cuándo y cómo configurar LDS debe adherirse a los requisitos de privacidad del usuario de su negocio y aplicaciones en lo que respecta a los datos a nivel de usuario transmitidos a los socios a través de las integraciones de Singular que usted configure. Consulte al asesor jurídico de su empresa sobre cómo su empresa y su aplicación deben cumplir las políticas de privacidad internas y reglamentarias.
• Las implementaciones varían según la orientación de su asesor legal sobre cómo manejar el consentimiento del usuario, pero en general se recomienda que:
  • LDS se establezca (true/false) solo cuando el usuario haya optado explícitamente por aceptar o rechazar. Se recomienda dejar LDS sin configurar si el usuario no ha hecho una elección. La ausencia de una señal del usuario puede ser importante para los socios.
  • Para funciones como "Postbacks de privacidad del usuario" que requieren un valor LDS para funcionar, se puede configurar el valor LDS por defecto en ausencia de uno.
  • Las señales de usuario para LDS se recogen normalmente a través de avisos del anunciante a través de las páginas "Configuración de privacidad" o "Opciones de privacidad" de una aplicación.
  • Cuando sea posible (y dependiendo del diseño y la estrategia del aviso de consentimiento de su aplicación) configure LDS antes de inicializar el SDK de Singular para asegurarse de que Singular tenga la señal más precisa en el momento de la instalación. Dependiendo de cómo estén configurados los "Postbacks de Privacidad del Usuario", tener la señal en el momento de la instalación puede afectar a la atribución (por ejemplo, si LDS=true se restringe el envío de postbacks de instalación a un socio autoatribuible).

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: el registro de instalación nunca se reescribe y los postbacks ya enviados no se recuperan.

• Para que la propia instalación refleje el consentimiento del usuario, establece limitDataSharing en la configuración antes de inicializar el SDK.
• No establezcas true de forma predeterminada para usuarios indecisos: un usuario que luego dé su consentimiento conservaría una instalación restringida de forma permanente. Resuelve el consentimiento antes de inicializar, o deja LDS sin establecer (unset) hasta que el usuario responda.

Por sí solo, no. LDS establece un estado; la aplicación se define por socio y por app mediante la opción Restriction Type en la configuración del socio. Las opciones son:

• None: los postbacks se envían con normalidad
• Do not send postbacks
• Send postbacks without users' data

Deben configurarse tanto el flag como la aplicación (enforcement): establecer solo el flag no cambia el comportamiento del socio.

Sí. LDS puede pasarse como argumento a nivel de evento en eventos individuales para anular el estado a nivel de dispositivo, por ejemplo, ante un cambio de consentimiento a mitad de sesión o para tipos de evento sujetos a normas jurisdiccionales más estrictas.

Algunos socios pueden recibir señales de consentimiento del usuario, normalmente en forma de "limitar el uso de datos". Si LDS está implementado, las integraciones de Singular con estos socios les pasan el valor de LDS automáticamente. Los siguientes socios usan el LDS de Singular en los postbacks según la integración predeterminada, y la misma configuración de LDS se aplica a cualquier socio de red con integración de postbacks de Singular para limitar el uso compartido de datos en los postbacks.