Saltar al contenido principal
Consulte la guía del usuario para obtener instrucciones sobre cómo configurar la política de gestión del consentimiento al utilizar Kameleoon en su aplicación web.
Kameleoon proporciona integraciones nativas integradas con plataformas de gestión del consentimiento.

Políticas de consentimiento

Para un visitante determinado, el consentimiento legal para usar Kameleoon se considera concedido, denegado o desconocido (un estado especial que se utiliza cuando el consentimiento no está definido, ya que el visitante aún no lo ha concedido ni denegado). Para empezar, debe elegir cómo trata Kameleoon el consentimiento legal:
  • Consentimiento no requerido: Con esta política, no se exige explícitamente el consentimiento para este sitio web y módulo. Kameleoon asume que se concede automáticamente y se inicia de inmediato en modo con todas las funciones.
  • Consentimiento requerido: Con esta política, el consentimiento debe obtenerse explícitamente del visitante. Hasta que se otorgue, el consentimiento legal se considerará “desconocido” y Kameleoon no funcionará con normalidad.
Para informar a Kameleoon de que se ha obtenido el consentimiento legal, debe utilizar el método de la Activation API de Kameleoon, que requiere implementar código JS personalizado, o uno de los SDKs si ejecuta feature flags. Para más información sobre este tema, consulte la guía del usuario.
Para cubrir todos los casos de uso posibles, el comportamiento de Kameleoon Web Experimentation puede personalizarse aún más cuando el consentimiento se considera desconocido o cuando el usuario lo deniega. Para conocer las opciones disponibles, lea el artículo sobre el comportamiento cuando el consentimiento es desconocido.

Lectura del estado actual del consentimiento de un visitante

Esta sección se aplica únicamente a la solución Kameleoon Web Experimentation.
Para obtener (leer) el estado actual del consentimiento legal de un visitante, utilice el objeto Kameleoon.API.Visitor:
  • Kameleoon.API.Visitor.experimentLegalConsent: devuelve true, false o null si el estado es desconocido (se requiere consentimiento pero aún no se ha concedido ni denegado).
  • Kameleoon.API.Visitor.personalizationLegalConsent: devuelve true, false o null si el estado es desconocido (se requiere consentimiento pero aún no se ha concedido ni denegado).
Mientras que los métodos Kameleoon.API.Core.enableLegalConsent() y Kameleoon.API.Core.disableLegalConsent() permiten cambiar (escribir) el estado del consentimiento legal de este visitante, obtener (leer) el estado actual se realiza mediante Kameleoon.API.Visitor.
Si ha elegido la política “Consentimiento no requerido”, el consentimiento legal nunca puede estar en estado desconocido. Kameleoon.API.Visitor.experimentLegalConsent o Kameleoon.API.Visitor.personalizationLegalConsent siempre devolverá true de forma predeterminada y se establecerá en false únicamente si se invoca el método Kameleoon.API.Core.disableLegalConsent().

Modos de funcionamiento del motor de Kameleoon Web Experimentation

Esta sección se aplica únicamente a la solución Kameleoon Web Experimentation.
El motor de Kameleoon funciona de forma distinta según su modo de funcionamiento. Para determinar el modo operativo, Kameleoon tiene en cuenta el valor actual del consentimiento en Kameleoon.API.Visitor.experimentLegalConsent y Kameleoon.API.Visitor.personalizationLegalConsent. Si el valor es null (estado desconocido) o false, Kameleoon considera el valor de configuración correspondiente en los ajustes del proyecto para el comportamiento cuando el consentimiento es desconocido o el comportamiento en caso de opt-out. La siguiente sección describe todos los modos posibles del motor:

Modo activo

Es el modo normal de funcionamiento. Kameleoon envía datos a los servidores de seguimiento y escribe datos en el dispositivo cuando es necesario. Se asume que el visitante ha concedido el consentimiento para el uso de Kameleoon. Este modo está operativo cuando Kameleoon.API.Visitor.experimentLegalConsent o Kameleoon.API.Visitor.personalizationLegalConsent es true.

Modo deshabilitado

En este modo, Kameleoon no hace absolutamente nada: ni se envían datos a servidores remotos ni se escriben en el dispositivo local. Los experimentos y personalizaciones no se muestran nunca. A todos los efectos, es como si Kameleoon no existiera para este visitante en particular. Este modo está operativo cuando:
  • Kameleoon.API.Visitor.experimentLegalConsent o Kameleoon.API.Visitor.personalizationLegalConsent es null y ha seleccionado la opción “Bloquear Kameleoon por completo” cuando el consentimiento es desconocido.
  • Kameleoon.API.Visitor.experimentLegalConsent o Kameleoon.API.Visitor.personalizationLegalConsent es false y el cliente seleccionó “Bloquear Kameleoon por completo” para el comportamiento de opt-out.

Modo diferido

En este modo, Kameleoon no envía datos a los servidores de seguimiento ni escribe datos en el dispositivo. Sin embargo, seguirá mostrando experimentos (o personalizaciones) con normalidad si el visitante activa el segmento asociado. Además, todos los datos que deberían escribirse o enviarse a un servidor remoto se mantienen en memoria. Si más tarde Kameleoon cambia al modo activo (normalmente porque se concede el consentimiento en algún momento), todos los datos recopilados hasta ese momento (en el contexto de esta página) se escriben y envían de una sola vez. De ahí el nombre “diferido”: si en algún momento se obtiene el consentimiento completo, el resultado final será que Kameleoon se ha comportado casi como en modo activo. Este modo está operativo cuando Kameleoon.API.Visitor.experimentLegalConsent / Kameleoon.API.Visitor.personalizationLegalConsent es null y ha seleccionado la opción “No bloquear Kameleoon” cuando el consentimiento es desconocido.

Modo restringido

En este modo, Kameleoon no envía datos a los servidores de seguimiento ni escribe datos en el dispositivo. Sin embargo, seguirá mostrando experimentos (o personalizaciones) que hayan sido marcados con la etiqueta “Technical” en Kameleoon. El resto de experimentos / personalizaciones no se muestran. Este es un modo muy útil que permite deshabilitar la mayoría de las operaciones de Kameleoon si un visitante no desea conceder el consentimiento, pero que aun así permite ejecutar experimentos y personalizaciones críticas para este visitante. A menudo, Kameleoon se utiliza como una solución rápida para desplegar correcciones de errores y pequeñas mejoras en producción. En este contexto concreto, las regulaciones de privacidad de datos como el RGPD explícitamente no se aplican, y Kameleoon puede utilizarse sin consentimiento para tales casos de uso. El modo restringido equivale al modo diferido, pero es más restrictivo. Dado que puede elegirse como resultado de una elección final del consentimiento legal (una denegación), se espera que probablemente los datos nunca se escriban ni se envíen en este caso (mientras que el modo diferido normalmente es solo un modo “transitorio”). Este modo está operativo cuando:
  • Kameleoon.API.Visitor.experimentLegalConsent o Kameleoon.API.Visitor.personalizationLegalConsent es null y ha seleccionado la opción “Bloquear Kameleoon parcialmente” cuando el consentimiento es desconocido.
  • Kameleoon.API.Visitor.experimentLegalConsent o Kameleoon.API.Visitor.personalizationLegalConsent es false y ha seleccionado la opción “Bloquear Kameleoon parcialmente” para el comportamiento de opt-out.
Es muy posible que Kameleoon tenga modos operativos diferentes para los experimentos AB y para las personalizaciones. En ese caso, todo funciona como se espera. Por ejemplo, los experimentos se muestran y se hace seguimiento de los datos, pero no ocurre nada para las personalizaciones.

Consideraciones avanzadas

Optar por implementar una política de consentimiento explícito en el contexto de las pruebas A/B suele conllevar problemas complejos, y no existe una solución ideal. A continuación se describen los dos principales problemas. Lo primero a tener en cuenta es que, si elige un comportamiento estricto (modo deshabilitado) mientras el consentimiento es desconocido, los experimentos / personalizaciones se activarán “tarde” en el contexto de la primera vista de página de un visitante totalmente nuevo. Con esta configuración, solo podrán mostrarse después de haber obtenido el consentimiento legal, lo que suele ser después de unos segundos. Esto puede generar, lamentablemente, problemas serios de UX según los experimentos y personalizaciones subyacentes, y debe tenerse en cuenta. El modo diferido puede mitigar este problema, ya que la visualización es inmediata y solo se retrasa la escritura. Sin embargo, surge un segundo problema cuando un visitante “permanece” con el estado del consentimiento legal desconocido durante varias páginas. Dado que Kameleoon no escribe datos en el dispositivo, ni siquiera el identificador visitorCode de Kameleoon, este sigue (re)generándose de forma aleatoria en cada página mientras no se determine el consentimiento final. Esto implica que, para los experimentos, la asignación de variaciones se producirá en cada nueva vista de página, y no se garantiza la coherencia en esas asignaciones. Por tanto, es importante tomar medidas para evitar que se produzca esta situación. Existen varias opciones (banner de consentimiento bloqueante, denegación automática del consentimiento tras X segundos…), pero un visitante no debería permanecer en el estado de consentimiento legal desconocido para siempre. O bien se concede el consentimiento o bien se deniega.
Por la misma razón técnica (reasignación permanente de variaciones), si se elige el modo restringido para el comportamiento de opt-out, se espera que solo se marquen con la etiqueta “Technical” aquellas personalizaciones o experimentos con un desvío de tráfico del 100 % hacia una variación. Hacer lo contrario puede deteriorar seriamente la experiencia de navegación de los usuarios que han rechazado el consentimiento, ya que podrían quedar expuestos a varias variaciones diferentes en la misma sesión.