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 datos históricos del visitante. Esta combinación crea 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().

​
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.
  • * La recopilación automática de datos no funciona en aplicaciones de una sola página (SPA). En una SPA, debe llamar al método addData() manualmente.
  • ** No compatible con los SDKs móviles (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.

​
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 (Automático): aplica solo 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 escenario 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.

​
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.

​
Restricciones de targeting en el edge

Los feature flags y los experimentos evaluados en el edge solo tienen acceso a los datos del visitante que su integración pone a disposición del edge worker. Una solicitud en el edge se comporta como una evaluación de SDK del lado del servidor para una sesión de visitante completamente nueva: el edge worker no tiene ninguna memoria garantizada de una solicitud anterior de ese visitante, por lo que la mayoría de las condiciones de targeting no tienen datos que evaluar a menos que usted los proporcione explícitamente. A continuación se describe cómo llevar los datos del visitante al edge worker para que pueda evaluar las condiciones de targeting. Enviar de vuelta a su servidor de origen las decisiones de flag y variación resultantes es una cuestión distinta, que no gestiona el mecanismo de addData() y cookies descrito aquí. Los frameworks edge exponen mecanismos diferentes para devolver esas decisiones; consulte la documentación de su propio framework.

​
De dónde proceden los datos del visitante en el edge

Según su framework edge, algunos datos de navegador y dispositivo, como el user agent y la geolocalización, están disponibles directamente desde la solicitud entrante a través de las API de contexto de solicitud propias de la plataforma. Consulte la documentación de su framework para saber qué expone. Cualquier otra condición de targeting, incluidos los datos personalizados y el historial del visitante, no tiene ninguna vía de acceso al worker a menos que su integración la proporcione explícitamente. Sea cual sea la fuente de los datos, su integración es responsable de leerlos y de llamar a addData() con ellos antes de evaluar un feature flag o un experimento. Kameleoon no recopila ninguno de estos datos en su nombre en el edge, incluidos los datos que un framework expone en la propia solicitud.

​
getRemoteVisitorData() en el edge

getRemoteVisitorData() funciona en el edge de la misma manera que en cualquier evaluación del lado del servidor, pero no resulta práctico para la mayoría de los casos de uso en el edge:
  • Latencia: una llamada a getRemoteVisitorData() suele tardar entre 100 y 200 ms en obtener los datos históricos del visitante desde la Data API. La evaluación de flags y variaciones en sí normalmente se completa en milisegundos, por lo que añadir una obtención de datos remota a cada solicitud empuja la latencia muy por encima de lo que persiguen la mayoría de los casos de uso en el edge.
  • Sin memoria compartida duradera: una plataforma edge puede destruir y recrear una instancia de worker en cualquier momento, por lo que almacenar en caché un resultado de getRemoteVisitorData() entre solicitudes no es fiable a menos que su framework ofrezca memoria duradera y compartida entre solicitudes donde guardarlo.
Consulte Usar getRemoteVisitorData() para datos históricos para saber cómo funciona este método fuera del edge. Para la mayoría de los casos de uso en el edge, proporcione en su lugar los datos del visitante que necesitan sus condiciones de targeting mediante addData(), siguiendo el enfoque que se describe a continuación.

​
Pasar datos del visitante al edge worker

Como el SDK edge no puede obtener ni conservar datos del visitante por sí mismo, su integración es responsable de poner esos datos a disposición en el momento de la solicitud:
  1. Recopile los atributos del visitante previamente, por ejemplo durante una carga de página anterior o una llamada al SDK del lado del cliente.
  2. Pase los atributos a la solicitud edge, normalmente como cookies, ya que un edge worker puede leer las cookies de la solicitud entrante sin realizar una llamada externa.
  3. En el edge worker, lea los atributos y llame a addData() con ellos antes de evaluar cualquier feature flag o experimento.
Las cookies tienen un límite de tamaño práctico de aproximadamente 4 KB. Reserve ese presupuesto para los atributos del visitante que realmente necesitan sus condiciones de targeting.

​
Las restricciones varían según el framework edge y el plan

Las capacidades de los frameworks edge cambian con el tiempo y pueden depender de su plan específico con un proveedor, no solo del proveedor que utilice. La compatibilidad con solicitudes externas, la memoria compartida entre solicitudes y la facturación del cómputo varían todas entre frameworks, y pueden cambiar entre niveles de plan o a medida que un proveedor actualiza su oferta. Consulte la documentación actual de su framework y los detalles del plan de su cuenta antes de depender de una capacidad concreta, como una llamada externa o el almacenamiento en caché entre solicitudes. Consulte Starter kits para edge computing serverless para conocer los frameworks que admite Kameleoon actualmente.

​
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.

​
FAQ

Sí, los datos están disponibles de inmediato para el targeting. Los datos están disponibles durante la sesión del visitante en los SDK del lado del servidor y durante el tiempo de vida configurado en los SDK del lado del cliente (móviles y web).
Si utiliza un SDK del lado del servidor, los datos se almacenan durante la sesión del visitante. No necesita cargar los datos en cada solicitud si la sesión del usuario no ha caducado. En los SDK móviles, los datos persisten indefinidamente (o según su configuración).Si la sesión del usuario ya no está activa, o si el visitante cambia de dispositivo en el SDK del lado del cliente, llame al método getRemoteVisitorData con los parámetros adecuados para obtener los datos enviados a la Data API. Tras la carga, el SDK incluye los datos en el targeting del visitante.
Un edge worker no tiene una memoria garantizada de las solicitudes anteriores de un visitante, por lo que se comporta como un SDK del lado del servidor que evalúa una sesión de visitante completamente nueva cada vez. La mayoría de las condiciones de targeting no tienen datos que evaluar, a menos que su integración los proporcione de forma explícita, normalmente leyéndolos de una cookie y llamando a addData() antes de evaluar el feature flag.getRemoteVisitorData() funciona en el edge, pero su latencia (normalmente de 100-200 ms) y la falta de memoria duradera entre solicitudes en la mayoría de las plataformas edge hacen que resulte poco práctico para la mayoría de los casos de uso en el edge.Consulte Restricciones de targeting en el edge para ver la explicación completa y un ejemplo de código, y Starter kits para edge computing serverless para conocer los frameworks que Kameleoon admite.