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 (por ejemplo, Conversion, Browser, Custom Data).
- 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.
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(). Esto 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. Esto 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.
| Condición de targeting | Acciones (Web) | Acciones (Mobile) | Acciones (Servidor) |
|---|
| Exclusive feature flag | isFeatureActive() / getVariation(s) / getRemoteVisitorData() | isFeatureActive() / getVariation(s) / getRemoteVisitorData() | isFeatureActive() / getVariation(s) / getRemoteVisitorData() |
| Target feature flag | isFeatureActive() / getVariation(s) / getRemoteVisitorData() | isFeatureActive() / getVariation(s) / getRemoteVisitorData() | isFeatureActive() / getVariation(s) / getRemoteVisitorData() |
| Browser (solo web) | Añadido automáticamente / addData() | No compatible | addData() / getRemoteVisitorData() |
| Device | Añadido automáticamente / addData() | Añadido automáticamente / addData() | addData() / getRemoteVisitorData() |
| Conversion | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() |
| Custom data | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() |
| Page title (solo web) | Añadido automáticamente / addData() | No compatible | addData() / getRemoteVisitorData() |
| Operating system | Añadido automáticamente / addData() | Añadido automáticamente | addData() / getRemoteVisitorData() |
| IP geolocation | addData() | addData() | addData() / getRemoteVisitorData() |
| SDK type | Añadido automáticamente | Añadido automáticamente | Añadido automáticamente |
| Visitor code | isFeatureActive() / getVariation(s) / getRemoteVisitorData() | KameleoonClientFactory.create() | isFeatureActive() / getVariation(s) / getRemoteVisitorData() |
| Segment | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() | addData() / getRemoteVisitorData() |
| Likelihood to convert | getRemoteVisitorData() | getRemoteVisitorData() | getRemoteVisitorData() |
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.
| Condición de targeting | Lado del cliente | Lado del cliente (cross-device) | Lado del servidor |
|---|
| Exclusive feature flag | No | Sí | Sí |
| Custom data | No | Sí | Sí |
| Page URL (solo web) | No (automático) | No (automático) | No/Sí |
| IP geolocation | No | No | No/Sí |
| SDK type | No (automático) | No (automático) | No (automático) |
| Time since first visit | No (automático) | Sí | Sí |
| Total number of visits | No (automático) | Sí | Sí |
| Likelihood to convert | Sí | Sí | Sí |
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 (por ejemplo, variables de datalayer, 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.
