Skip to main content
Las condiciones de targeting de Kameleoon activan los feature flags en función de criterios específicos. Para utilizar estas condiciones de forma eficaz, establezca sus valores con el método addData(). En algunos escenarios, llame a getRemoteVisitorData() para recuperar el historial del visitante. Esta combinación permite crear experiencias altamente segmentadas y personalizadas.

​
Gestionar los datos en los SDKs de Kameleoon

Unos datos precisos garantizan una segmentación y experimentación consistentes. Las secciones siguientes explican cómo gestionan los SDKs del lado del cliente y del lado del servidor las condiciones de targeting y especifican cuándo usar getRemoteVisitorData() para obtener datos del servidor.

​
Terminología clave

  • Condición de targeting: el atributo concreto del usuario o sesión utilizado para el targeting, como conversión, navegador o datos personalizados.
  • Lado del cliente: gestión de datos para SDKs estándar que se ejecutan en un navegador web o aplicación móvil.
  • Lado del cliente (cross-device): gestión de datos para implementaciones del lado del cliente que mantienen un perfil de visitante consistente entre varios dispositivos.
  • Lado del servidor: gestión de datos cuando el SDK se ejecuta en un servidor backend. A diferencia de los SDKs del lado del cliente, los SDKs del lado del servidor normalmente eliminan la información del visitante al finalizar la sesión.
  • Solo web: una condición de targeting basada en datos que solo genera un navegador, como la URL de la página o el título de la página. Los SDKs web recopilan estos datos automáticamente. Los SDKs de Android, iOS y Flutter no admiten estas condiciones porque ningún navegador genera los datos. El SDK de React Native ofrece compatibilidad experimental con estas condiciones. Los SDKs del lado del servidor sí admiten estas condiciones: reciben los datos mediante addData() o los recuperan de una sesión web anterior con getRemoteVisitorData().

​
Definiciones de gestión de datos

​
SDKs del lado del cliente

  • No (automático): el SDK recopila estos datos automáticamente. No requiere solicitudes remotas ni llamadas explícitas a addData().
  • No: el SDK no recopila estos datos automáticamente. Debe usar addData(), trackConversion() o métodos de evaluación como getVariation() para añadirlos. No requiere una solicitud remota.
  • Sí: debe llamar a getRemoteVisitorData(). Este requisito aplica a los datos generados en el servidor (como “Likelihood to convert”) o cuando se unifican las sesiones entre varios dispositivos para recuperar las acciones de un dispositivo anterior.

​
SDKs del lado del servidor

  • No compatible: el SDK del lado del servidor no admite esta condición.
  • No (automático): solo aplica a “SDK Type”. El SDK los recopila automáticamente.
  • No: utilice addData() o trackConversion() para proporcionar estos datos. No requiere una solicitud remota.
  • No/Sí: puede proporcionar los datos directamente en el servidor u obtenerlos mediante una solicitud remota. Este caso ocurre si un SDK del lado del cliente ya ha recopilado información durante la visita actual.
  • Sí: debe llamar a getRemoteVisitorData(). Como los SDKs del lado del servidor tienen almacenamiento de datos limitado, necesitan una llamada remota para identificar acciones históricas, como visitas anteriores o exclusividad para un experimento.

​
Requisitos de recopilación de datos

El SDK requiere datos específicos del visitante para evaluar las condiciones de targeting. La tabla siguiente indica qué criterios gestiona el SDK automáticamente y cuáles requieren una llamada de método explícita.
“Solo web” indica el origen de los datos, no qué SDKs pueden usarlos. Las condiciones “solo web” proceden de datos del navegador, por lo que la mayoría de los SDKs móviles no las admiten, pero los SDKs del lado del servidor sí, mediante addData() o getRemoteVisitorData(). El SDK de React Native es la excepción entre los SDKs móviles: ofrece compatibilidad experimental con estas condiciones.
* No compatible con los SDKs de Android, iOS o Flutter. El SDK de React Native ofrece compatibilidad experimental mediante addData().

​
Usar getRemoteVisitorData() para datos históricos

La siguiente tabla indica cuándo se requiere una llamada remota a getRemoteVisitorData() para recuperar datos históricos para las decisiones de targeting.

​
Ventajas de la recuperación remota de datos

Llamar a getRemoteVisitorData() ofrece las siguientes ventajas:
  • Información actualizada: las decisiones utilizan datos en tiempo real de la Data API.
  • Coherencia cross-device: accede a datos recopilados desde otros dispositivos o sesiones.
  • Acceso histórico: recupera el comportamiento previo del usuario, como visitas a URLs anteriores, incluso si el estado local del SDK se ha vaciado.
Utilice el parámetro VisitorDataFiltersType para especificar el número de visitas anteriores a recuperar o para aplicar filtros de criterios específicos.

​
Modo de experimentación híbrida

La experimentación híbrida combina el SDK con el snippet JavaScript de Kameleoon para habilitar un targeting avanzado. Para más detalles, consulte la guía Experimentación híbrida. Ventajas:
  • Agiliza el proceso de implementación.
  • Accede a los datos del lado del cliente recopilados por el engine, como las variables de datalayer y los objetivos del front-end, directamente en el SDK.
Requisito:
  • Implementar tanto el SDK como el tag JavaScript de Kameleoon.
Llamar a getRemoteVisitorData() en este modo proporciona acceso a todos los puntos de datos recopilados automáticamente por el engine de Kameleoon en la página web.