Skip to main content
Con el SDK de React de Kameleoon, puede ejecutar experimentos de funcionalidad y activar feature flags en su aplicación web y móvil de front-end. Integrar nuestro SDK en su aplicación web y móvil es sencillo y su huella (memoria y uso de red) es baja. Primeros pasos: Para obtener ayuda para comenzar, consulte la guía del desarrollador Changelog: Encontrará información sobre la última versión del SDK de React en el changelog. Métodos del SDK: Para la documentación de referencia completa del SDK de React, consulte la sección referencia. Requisitos: El SDK de React requiere React 16.8.0+

Guía del desarrollador

Siga esta sección para integrar el SDK en su aplicación y obtener más información sobre cómo usar el SDK.

Primeros pasos

Esta sección le guía a través de la instalación y configuración del SDK por primera vez.

Instalación

La herramienta de instalación del SDK de Kameleoon es la forma preferida de instalar el SDK. Este SDK Installer le ayuda a instalar el SDK de su elección, generar un ejemplo de código básico y configurar dependencias externas si es necesario. Para iniciar la herramienta de instalación del SDK, instálela y ejecútela globalmente:
O ejecútela directamente con npx:

Crear el cliente Kameleoon

Para comenzar, debe crear un punto de entrada para el SDK de React creando un cliente de Kameleoon en el nivel superior de su aplicación. Cree una instancia de KameleoonClient usando la función createClient(), importada del paquete kameleoon.

Envolver la aplicación en el Kameleoon Provider

El segundo paso es conectar el Cliente de Kameleoon creado anteriormente a KameleoonProvider pasando el cliente configurado a KameleoonProvider:
KameleoonProvider
Utilice este proveedor en el nivel raíz envolviendo su aplicación para obtener acceso a KameleoonClient. Esto garantiza que su aplicación no parpadee debido a cambios de flags al iniciar.
Props
KameleoonProviderSSR
Utilice este proveedor en el nivel raíz envolviendo su aplicación para obtener acceso a KameleoonClient. KameleoonProviderSSR difiere de KameleoonProvider en que crea una instancia de KameleoonClient dentro del contexto en la primera solicitud del cliente. Esto evita el riesgo de crear el cliente en el lado del servidor. Se recomienda su uso en sistemas basados en SSR, como Next.js con SSR.
Props

Esperar a la inicialización del cliente

La inicialización de KameleoonClient se realiza de forma asincrónica para garantizar que la llamada a la API de Kameleoon fue exitosa para lo cual se utiliza el hook useInitialize. Puede usar async/await, Promise.then() u otro método para gestionar la inicialización asincrónica del cliente.

Activar un feature flag

Asignar un identificador único a un usuario
Para asignar un ID único a un usuario, puede usar el método getVisitorCode(). Si un código de visitante no existe (en la cookie del encabezado de solicitud), el método genera un ID único aleatorio o utiliza un defaultVisitorCode que habría generado. El ID se establece entonces en una cookie del encabezado de respuesta. Si está utilizando Kameleoon en Modo híbrido, llamar al método getVisitorCode() garantiza que el ID único (código de visitante) se comparta entre el archivo de aplicación engine.js (anteriormente llamado kameleoon.js) y el SDK.
Recuperando una configuración de flag
Para implementar un feature flag en su código, primero debe crear el feature flag en su cuenta de Kameleoon. Para determinar el estado o variación de un feature flag para un usuario específico, debe usar el método getVariation() o isFeatureFlagActive() para recuperar la configuración según la featureKey. El método getVariation() maneja tanto feature flags simples con estados ON/OFF como flags más complejos con múltiples variaciones. El método recupera la variación apropiada para el usuario verificando las reglas de funcionalidad, asignando la variación y devolviéndola según la featureKey y visitorCode. El método isFeatureFlagActive() puede ser usado si desea recuperar la configuración de un feature flag simple que tiene solo un estado ON u OFF, en contraposición a feature flags más complejos con múltiples variaciones u opciones de dirigimiento. Si su feature flag tiene variables asociadas (como comportamientos específicos vinculados a cada variación), getVariation() también le permite acceder al objeto Variation, que proporciona detalles sobre la variación asignada y su experimento asociado. Este método comprueba si el usuario está dirigido, encuentra la variación asignada del visitante y la guarda en el almacenamiento. Cuando track=true, el SDK enviará el evento de exposición al experimento especificado en la próxima solicitud de seguimiento, que se activa automáticamente según la tracking_interval_millisecond del SDK. Por defecto, este intervalo está establecido en 1000 milisegundos (1 segundo). El método getVariation() le permite controlar si se realiza el seguimiento. Si track=false, el SDK no enviará eventos de exposición. Esto es útil si prefiere no rastrear datos a través del SDK y en su lugar confía en el seguimiento del lado del cliente administrado por el motor de Kameleoon, por ejemplo. Además, configurar track=false es útil cuando se usa el método getVariations(), donde puede que solo necesite las variaciones para todos los flags sin activar eventos de seguimiento. Si desea saber más sobre cómo funciona el seguimiento, vea este artículo
Agregar puntos de datos para dirigirse a un usuario o filtrar/desglosar visitas en informes
Para dirigirse a un usuario, asegúrese de haber agregado puntos de datos relevantes a su perfil antes de recuperar la variación de funcionalidad o verificar si el flag está activo. Use el método addData() para agregar estos puntos de datos al perfil del usuario. Para recuperar puntos de datos recopilados en otros dispositivos o para acceder a datos de usuario pasados (recopilados en el lado del cliente cuando se utiliza Kameleoon en modo híbrido), use el método getRemoteVisitorData(). Este método obtiene datos de los servidores de forma asincrónica. Es importante llamar a getRemoteVisitorData() antes de recuperar la variación o verificar si el feature flag está activo, ya que estos datos pueden ser necesarios para asignar un usuario a una variación determinada. Para obtener más información sobre las condiciones de dirigimiento disponibles, consulte el artículo detallado sobre el tema. Además, los puntos de datos que agregue al perfil del visitante estarán disponibles al analizar sus experimentos, lo que le permitirá filtrar y desglosar sus resultados por factores como dispositivo y navegador. El modo híbrido de Kameleoon recopila automáticamente una variedad de puntos de datos en el lado del cliente, facilitando el desglose de sus resultados basándose en estos puntos de datos recopilados previamente. Vea la lista completa aquí. Si necesita rastrear puntos de datos adicionales más allá de lo que se recoge automáticamente, puede utilizar la funcionalidad Custom Data de Kameleoon. Custom Data le permite capturar y analizar información específica relevante para sus experimentos. No olvide llamar al método flush() para enviar los datos recogidos a los servidores de Kameleoon para su análisis.
Para asegurar que sus resultados sean precisos, se recomienda filtrar bots utilizando el tipo de dato UserAgent.
Seguimiento de conversiones de objetivos
Cuando un usuario completa una acción deseada (como hacer una compra), se registra como una conversión. Para rastrear conversiones, use el método trackConversion() y proporcione los parámetros requeridos visitorCode y goalId. La solicitud de seguimiento de conversión se enviará junto con la siguiente solicitud de seguimiento programada, que el SDK envía a intervalos regulares (definidos por tracking_interval_millisecond). Si prefiere enviar la solicitud inmediatamente, use el método flush() con el parámetro instant=true.
Envío de eventos a soluciones de análisis
Para rastrear conversiones y enviar eventos de exposición a su solución de análisis de clientes, primero debe implementar Kameleoon en Modo híbrido. Luego, use el método getEngineTrackingCode(). El método getEngineTrackingCode() recupera el código de seguimiento único necesario para enviar eventos de exposición a su solución de análisis. El uso de este método le permite registrar eventos y enviarlos a su plataforma de análisis deseada.

Consideraciones para React Native

React Native en la plataforma android no admite la funcionalidad Real Time Update.
Aunque React SDK funciona de la misma manera en contextos tanto de React Native como de React, es importante notar que los pasos de configuración difieren. Debido a la falta de API del navegador en React Native, React SDK debe tener diferentes implementaciones de dependencia externa para funcionar correctamente. Para eso, Kameleoon proporciona varios paquetes npm dedicados que puede instalar y configurar manualmente o instalar usando la Herramienta de instalación del SDK de Kameleoon (recomendado). Los paquetes incluyen:
  • @kameleoon/react-native-storage - construido usando la biblioteca react-native-mmkv
  • @kameleoon/react-native-event-source - construido usando la biblioteca react-native-event-source-ts
  • @kameleoon/react-native-visitor-code-manager - construido sobre la biblioteca react-native-mmkv
  • @kameleoon/react-native-platform-analyzer - construido usando la biblioteca react-native
  • opcional @kameleoon/react-native-secure-prng - construido usando la biblioteca react-native-get-random-values
Si no desea usar los paquetes listados, puede proporcionar su propia implementación siguiendo la guía de dependencias externas. Ejemplo de configuración de React SDK para aplicación React Native:

Uso de una clave de bucketing personalizada

Por defecto, Kameleoon utiliza un ID único y anónimo de visitante (visitorCode) para asignar usuarios a variaciones de feature flags. Este ID típicamente se genera y se almacena en el dispositivo del usuario (en una cookie del navegador para SDKs de lado del cliente y servidor—en almacenamiento persistente para SDKs móviles). Sin embargo, en ciertos escenarios puede necesitar asegurar que todos los usuarios de la misma organización vean la misma variante de un feature flag. La opción Custom Bucketing Key le permite anular este comportamiento predeterminado proporcionando su propio identificador personalizado para bucketing. Esta anulación asegura que la lógica de asignación de Kameleoon use su clave especificada en lugar del visitorCode predeterminado.

Casos de uso

Usar una clave de bucketing personalizada es esencial para mantener la consistencia y precisión en sus asignaciones de feature flags, particularmente en estas situaciones:
  • Experimentos a nivel de cuenta u organización: Para productos B2B o escenarios en los que desea asignar a todos los usuarios de la misma organización a la misma variación, puede utilizar un identificador como un accountId. Las claves de bucketing personalizadas son fundamentales para realizar pruebas A/B de funcionalidades que afectan a todo un equipo o empresa.
Al implementar una clave de bucketing personalizada, garantiza una mayor consistencia y precisión en sus experimentos, lo que se traduce en resultados más fiables y una mejor experiencia de usuario.

Detalles técnicos

Cuando configura una clave de bucketing personalizada para un feature flag, proporciona a Kameleoon un identificador específico procedente de los datos de su aplicación:
  • Proporcionar la clave personalizada: Proporcione su identificador personalizado al SDK de Kameleoon usando el método addData(). En este método, pasará su clave de bucketing personalizada elegida como un objeto CustomData. Aquí, newVisitorCode se refiere al identificador que desea usar para su bucketing (por ejemplo, el nuevo userId o accountId).
Para que la clave de bucketing personalizada funcione correctamente, también debe estar definida y configurada para el feature flag durante el proceso de creación o edición del flag. Sin esta configuración correspondiente, el bucketing del SDK no aplicará su clave personalizada. Para instrucciones detalladas sobre cómo configurar esto en Kameleoon, consulte este artículo.
  • Lógica de bucketing: Una vez que se proporciona una clave de bucketing personalizada a través del método addData(), todos los cálculos de hash para asignar usuarios a variaciones usarán este newVisitorCode (su clave personalizada) en lugar del visitorCode predeterminado. Usar el newVisitorCode significa que la decisión de bucketing está vinculada a su identificador personalizado, asegurando asignaciones consistentes en varios contextos donde ese identificador está presente.
  • Seguimiento de datos y análisis: Es crucial notar que mientras el newVisitorCode (su clave personalizada) se utiliza para decisiones de bucketing, todos los datos posteriores (eventos de seguimiento y conversiones, por ejemplo) se envían y se asocian con el visitorCode original. Esta separación garantiza que su análisis refleje con precisión los recorridos de usuarios individuales e interacciones dentro del contexto más amplio de su experimento, incluso cuando el bucketing se realiza en un nivel superior (como una cuenta) o en múltiples dispositivos/sesiones. Sus datos originales del visitante permanecen intactos para informes completos.

Requisitos técnicos

Para usar efectivamente una clave de bucketing personalizada:
  • La clave debe ser una string.
  • Debe ser única para la entidad que desea segmentar (por ejemplo, si utiliza un userId, el ID de cada usuario debe ser único).
  • La clave debe estar disponible para el SDK en el momento exacto en el que se evalúa la decisión del feature flag para ese usuario o solicitud.

Condiciones de segmentación

Los SDKs de Kameleoon admiten una variedad de condiciones de segmentación predefinidas que puede utilizar para segmentar usuarios en sus campañas. Para ver la lista de condiciones admitidas por este SDK, consulte usar el historial de visitas para segmentar usuarios. También puede utilizar sus propios datos externos para segmentar usuarios.

Registro de logs

El SDK genera registros para reflejar varios procesos internos y problemas.

Niveles de log

El SDK admite la configuración de limitación del registro por nivel de log.

Gestión personalizada de los logs

El SDK escribe sus logs en la salida de consola de forma predeterminada. Este comportamiento puede modificarse.
La limitación de los logs por nivel de log se realiza de forma independiente a la lógica de gestión de los logs.

Información del dominio

Proporciona un dominio como el domain en la [configuración] de KameleoonClient, que se utiliza para almacenar el código de visitante de Kameleoon en cookies. Esto es importante al trabajar con los métodos getVisitorCode y setLegalConsent. El dominio que proporciona se almacena en la cookie como la clave Domain=.

Configurar el dominio

El dominio que proporciona indica la dirección URL que puede usar la cookie. Por ejemplo, si su dominio es www.example.com, la cookie solo está disponible desde una URL www.example.com. Esto significa que las páginas con el dominio app.example.com no pueden usar la cookie. Para ser más flexible con los subdominios, puede prefijar un dominio con .. Por ejemplo, el dominio .example.com permite que la cookie funcione tanto en app.example.com como en login.example.com.
No puede utilizar expresiones regulares, símbolos especiales, protocolo ni números de puerto en domain. Además, una lista específica de subdominios no se pueden usar con el prefijo ..
A continuación se ofrece una pequeña hoja de referencia para dominios:

Desarrollo en localhost

localhost siempre se considera un dominio incorrecto, lo que dificulta probar el dominio al desarrollar en localhost. Hay dos formas de evitar este problema:
  • No especifique el campo domain en el cliente del SDK mientras realiza pruebas. Esto previene problemas de localhost (la cookie se establecerá en cualquier dominio).
  • Cree un dominio local para localhost. Por ejemplo:
    • Vaya a /etc/hosts en Linux o a c:\Windows\System32\Drivers\etc\hosts en Windows
    • Abra hosts con permisos de superusuario o administrador
    • Agregue un dominio al puerto localhost, por ejemplo: 127.0.0.1 app.com
    • Ahora puede ejecutar su aplicación localmente en app.com:{my_port} y especificar .app.com como su dominio

Dependencias externas

Las dependencias externas del SDK utilizan el patrón dependency injection para darle la posibilidad de proporcionar sus propias implementaciones para ciertas partes de un SDK.
En el SDK de React, todas las dependencias externas tienen implementaciones predeterminadas, que utilizan una API de navegador nativa, por lo que no es necesario proporcionarlas a menos que se requiera otra API para casos de uso específicos.
Esta es la lista de dependencias externas disponibles: El siguiente ejemplo implementa dependencias externas. Para importar una interfaz de un SDK, cree una clase que la implemente y pase la clase instanciada al SDK.

Almacenamiento

EventSource

VisitorCodeManager

Requester

Generador de números pseudoaleatorios

Pseudo Random Number Generator (PRNG) es una dependencia que genera un número de punto flotante aleatorio entre 0 y 1 (similar a Math.random). La implementación predeterminada de Kameleoon se basa en la función crypto o Math.random del navegador si crypto no está disponible. Esas API son muy seguras y confiables, sin embargo en algunos casos extremos (especialmente en algunos motores de React Native) es posible que desee proporcionar su propia implementación o usar un paquete dedicado de Kameleoon para React Native: @kameleoon/react-native-secure-prng

Gestión de errores

Casi todos los callbacks del SDK de React que son devueltos por hooks pueden lanzar un error en algún momento. Estos errores no son solo advertencias, sino KameleoonErrors predefinidos deliberadamente que extienden la clase nativa de JavaScript Error proporcionando mensajes útiles y un campo type especial con un tipo KameleoonException. KameleoonException es una enumeración que contiene todos los tipos de error posibles. Para saber exactamente qué tipo de KameleoonException pueden lanzar los callbacks, puede consultar la sección Throws de la descripción de los hooks en esta página o simplemente pasar el cursor sobre el callback en su IDE para ver la descripción de jsdocs. En general, el manejo de errores se considera una buena práctica para hacer que su aplicación sea más estable y evitar problemas técnicos.

Experimentación entre dispositivos

Para admitir a los visitantes que acceden a una aplicación desde múltiples dispositivos, Kameleoon permite la sincronización de los datos del visitante recopilados anteriormente en cada uno de los dispositivos del visitante y la reconciliación del historial de visitas entre dispositivos a través de la experimentación entre dispositivos. Los estudios de casos e información detallada sobre cómo Kameleoon maneja los datos entre dispositivos están disponibles en el artículo sobre experimentación entre dispositivos.

Sincronización de datos personalizados entre dispositivos

Aunque se utiliza la sincronización con mapeo personalizado para alinear los datos del visitante entre dispositivos, no siempre es necesaria. A continuación se presentan dos escenarios en los que no se requiere la sincronización con mapeo personalizado: Mismo ID de usuario en todos los dispositivos Si se usa consistentemente el mismo ID de usuario en todos los dispositivos, la sincronización se maneja automáticamente sin una sincronización de mapeo personalizado. Es suficiente llamar al método getRemoteVisitorData() cuando desee sincronizar los datos recopilados entre múltiples dispositivos. Instancias de múltiples servidores con ID consistentes En configuraciones complejas que involucran múltiples servidores (por ejemplo, instancias de servidor distribuidas), donde el mismo ID de usuario está disponible en servidores, la sincronización entre servidores (con getRemoteVisitorData()) es suficiente sin sincronización de mapeo personalizado adicional. Los clientes que necesiten datos adicionales pueden consultar la descripción del método getRemoteVisitorData() para obtener más orientación. En el código siguiente, se asume que se usa consistentemente el mismo identificador único (en este caso, el visitorCode, que también se puede denominar userId) entre los dos dispositivos para recuperación precisa de datos.
Si desea sincronizar los datos recogidos en tiempo real, debe elegir el ámbito Visitor para sus datos personalizados.
Device One
Device Two

Uso de datos personalizados para la fusión de sesiones

Experimentación entre dispositivos permite combinar el historial de un visitante en cada uno de sus dispositivos (reconciliación del historial). Una de las características poderosas que proporciona la reconciliación del historial es la capacidad de fusionar diferentes sesiones de visitantes en una. Para reconciliar el historial de visitas, puede usar CustomData para proporcionar un identificador único para el visitante.Siga la guía de activación de la reconciliación del historial entre dispositivos para configurar sus datos personalizados en la plataforma KameleoonCuando sus datos personalizados estén configurados, puede usarlos en su código para fusionar una sesión de visitante. Las sesiones con el mismo identificador siempre verán la misma variación del experimento y se mostrarán como un único visitante en la vista Visitor de las páginas de resultados de su experimento.La configuración del SDK garantiza que las sesiones asociadas siempre vean la misma variación del experimento.Antes de usar otros métodos, asegúrese de dejar que el SDK sepa que el visitante es un identificador único agregando datos UniqueIdentifier a un visitante
Como los datos personalizados que usa como identificador deben configurarse en el ámbito Visitor, debe usar sincronización de datos personalizados entre dispositivos para recuperar el identificador con el método getRemoteVisitorData en cada dispositivo.
Este es un ejemplo de cómo usar datos personalizados para la fusión de sesiones. Este ejemplo usa una aplicación con una página de inicio de sesión. Dado que no se conoce el ID de usuario en el momento del inicio de sesión, el código usa un identificador de visitante anónimo generado por el método getVisitorCode. Después de que el usuario inicia sesión, puede asociar el visitante anónimo con el ID de usuario y usarlo como un identificador único para el visitante.
Login Page
Application Page

Utilidades

El SDK tiene un conjunto de métodos utilitarios que se pueden usar para simplificar el proceso de desarrollo. Todos los métodos se representan como miembros estáticos de la clase KameleoonUtils.

simulateSuccessRequest

El método simulateSuccessRequest se usa para simular una solicitud exitosa al servidor de Kameleoon. Puede ser útil para implementaciones personalizadas de Requester cuando el desarrollador necesita simular una solicitud exitosa, por ejemplo para desactivar el seguimiento.
Parámetros
El tipo de datos SimulateRequestDataType se define de la siguiente manera:
  • RequestType.Tracking - null
  • RequestType.ClientConfiguration - ClientConfigurationDataType
  • RequestType.RemoteData - JSONType
Valor de retorno

getCookieValue

El método getCookieValue se usa para analizar una cadena de cookie común (key_1=value_1; key_2=value_2; ...) y obtener el valor de una clave de cookie específica. Es útil cuando se trabaja con una implementación personalizada de VisitorCodeManager.
Parámetros
Valor de retorno

Referencia

Esta es la documentación de referencia completa para el SDK de React.

Inicialización

Esta sección proporciona los métodos que utiliza para crear e inicializar el Cliente de Kameleoon en su aplicación.

initialize()

Una función initialize asincrónica, recopilada con el hook useInitialize, que se usa para la inicialización de KameleoonClient mediante la obtención de datos relacionados con el SDK de Kameleoon del servidor o la recuperación de datos de una fuente local si los datos están actualizados o no se ha alcanzado el intervalo de actualización.
  • Si la configuración del SDK no se pudo recuperar, pero hay una configuración más antigua disponible en el almacenamiento del SDK, el SDK usa la configuración más antigua como respaldo y initialize no lanza un error.
  • El SDK admite un modo sin conexión.
En modo sin conexión, si las solicitudes de seguimiento de cualquiera de los siguientes métodos fallan debido a problemas de conectividad a internet, el SDK reenvía automáticamente la solicitud tan pronto como detecta que la conexión a internet se ha restablecido:
Valor de retorno
Excepciones lanzadas

isReady()

isReady() comprueba si el SDK está listo para usarse, es decir, si su configuración se ha cargado correctamente. A diferencia de initialize(), este método devuelve el resultado inmediatamente, sin bloquear ni lanzar excepciones. Recopile la función isReady con el hook useInitialize. Es especialmente útil en un árbol de componentes profundamente anidado, porque le permite comprobar la preparación del SDK sin gestionar un estado global ni pasar el resultado de inicialización a través de las propiedades del componente.
Una vez que el SDK está listo, permanece listo. Incluso si falla una actualización posterior de la configuración, el SDK sigue utilizando la configuración descargada previamente y no vuelve a un estado no listo.
Valor de retorno

createClient()

Para empezar, debe crear un punto de entrada para el SDK de React creando un Cliente de Kameleoon en el nivel superior de su aplicación usando la función createClient() importada del paquete kameleoon. Se crea una instancia de KameleoonClient usando la función createClient().
Parámetros
Un objeto de tipo SDKParameters que contiene:
Parámetros de configuración
Opción 1 (Recomendado): Use JSON.stringify()
Opción 2: Cadena JSON sin procesar (escape de caracteres especiales)
Reducir dataFileRefreshInterval aumenta la frecuencia con la que el SDK comprueba si hay una configuración más reciente en segundo plano, pero el archivo de datos en caché de un visitante sigue siendo utilizable hasta que supera dataFileCacheTtl (90 minutos de forma predeterminada). Reduzca dataFileCacheTtl en su lugar para acortar cuánto tiempo puede un visitante seguir evaluándose con una configuración en caché obsoleta. De lo contrario, el tráfico hacia un experimento o feature flag recién lanzado aumenta gradualmente en lugar de alcanzar el volumen completo de inmediato. Consulte Impacto en experimentos y feature flags recién lanzados para más información.
Valor de retorno
Asegúrese de no utilizar varias instancias de cliente en una aplicación, ya que aún no es totalmente compatible y puede sobrescribir la configuración del almacenamiento local y causar comportamiento no deseado (errores).

Feature flags y variaciones

Esta sección proporciona los métodos que utiliza para recuperar y administrar los feature flags y variaciones asignados al visitante.

getVariation()

  • 📨 Envía datos de seguimiento a Kameleoon (dependiendo del parámetro track)
Recupera la Variation asignada a un visitante dado para un feature flag específico. Este método toma featureKey como argumento obligatorio y track como argumento opcional. El argumento track es opcional y predeterminado a true. Devuelve la Variation asignada para el visitante. Si el visitante no está asociado con ninguna regla de feature flag, el método devuelve la Variation predeterminada para el feature flag dado. Asegúrese de que se implemente el manejo adecuado de errores en su código para gestionar posibles excepciones.
La variación predeterminada se refiere a la variación asignada a un visitante cuando no coinciden con ninguna regla de entrega predefinida para un feature flag. En otras palabras, es la variación alternativa aplicada a todos los usuarios que no están dirigidos por reglas específicas. Se representa como la variación en la sección “Entonces, para todos los demás…” en una interfaz de administración.
Parámetros
Un objeto de tipo GetVariationParamsType con las siguientes propiedades:
Valor de retorno
Excepciones lanzadas

getVariations()

  • 📨 Envía datos de seguimiento a Kameleoon (dependiendo del parámetro track)
  • 🎯 Eventos: EventType.Evaluation
El método se obtiene utilizando el hook useFeatureFlag.
Recupera un mapa de objetos Variation asignados a un visitante dado en todos los feature flags. Este método itera sobre todos los feature flags disponibles y devuelve la Variation asignada para cada flag asociado con el visitante especificado. Toma visitorCode como argumento obligatorio, mientras que onlyActive y track son opcionales.
  • Si onlyActive se establece en true, el método getVariations() devolverá variaciones de feature flags siempre que el usuario no esté asignado con la variación off.
  • El parámetro track controla si el método rastreará o no las asignaciones de variación. De forma predeterminada, se establece en true. Si se establece en false, el seguimiento se deshabilitará.
El mapa devuelto consiste en claves de feature flag como claves y sus Variation correspondientes como valores. Si no hay una variación asignada para un feature flag, el método devuelve la Variation predeterminada para ese flag. Debe implementarse el manejo adecuado de errores para gestionar posibles excepciones.
La variación predeterminada se refiere a la variación asignada a un visitante cuando no coinciden con ninguna regla de entrega predefinida para un feature flag. En otras palabras, es la variación alternativa aplicada a todos los usuarios que no están dirigidos por reglas específicas. Se representa como la variación en la sección “Entonces, para todos los demás…” en una interfaz de administración.
Parámetros
Un objeto de tipo GetVariationsParamsType con las siguientes propiedades:
Valor de retorno
Excepciones lanzadas

isFeatureFlagActive()

  • 📨 Envía datos de seguimiento a Kameleoon (dependiendo del parámetro track)
  • 🎯 Eventos: EventType.Evaluation
El método isFeatureFlagActive(), utilizado con el hook useFeatureFlag, determina si un visitante identificado por visitorCode tiene el featureKey especificado activo. Este método verifica las condiciones de segmentación, identifica la variación para el visitante y guarda esta información en el almacenamiento. Adicionalmente, el hook envía una solicitud de seguimiento. También hay una sobrecarga para este método que incluye un parámetro track, lo que le permite desactivar el seguimiento de la evaluación de características.
El visitante debe ser dirigido para tener el feature flag activo
Kameleoon utiliza el seguimiento para contar sesiones y visitantes cuando llama a ciertos métodos, como isFeatureFlagActive(), getVariation() o getVariations().Utilice el valor predeterminado true para el parámetro track cuando exponga visitantes a una variación y necesite contarlos. Establezca el parámetro track en false solo si llama a estos métodos antes de exponer visitantes.Por ejemplo, si llama a getVariations() para recuperar todas las variaciones antes de exponer visitantes, establezca el parámetro track en false. Esta configuración evita que Kameleoon cuente una sesión prematuramente. Luego puede activar el seguimiento más tarde cuando expone explícitamente al visitante.Kameleoon envía datos de seguimiento cada segundo de forma predeterminada. Puede configurar este intervalo hasta cinco segundos utilizando la opción de configuración del intervalo de seguimiento. Kameleoon agrupa los eventos de seguimiento en una sola sesión siempre que el intervalo entre eventos sea menor a 30 minutos. Si transcurren más de 30 minutos entre eventos de seguimiento, Kameleoon cuenta los eventos como sesiones separadas. Una visita aparece en sus informes 30 minutos después del último evento registrado en la sesión.
El método isFeatureFlagActive() evalúa la variante servida, no el estado del flag maestro. Si excluye reglas, el método utiliza el estado predeterminado Entonces, para todos los demás sirva. Si selecciona Off para este estado predeterminado, el método siempre devuelve false incluso cuando el feature flag maestro es On.
Parámetros
Hay dos sobrecargas disponibles para este método:
  1. Sobrecarga de dos parámetros:
Esta sobrecarga está obsoleta y se eliminará en la próxima versión principal. Utilice la nueva sobrecarga con un parámetro de objeto.
  1. Sobrecarga de parámetro de objeto de tipo IsFeatureFlagActiveParamsType:
Valor de retorno
Excepciones lanzadas

setForcedVariation()

El método le permite asignar programáticamente una Variation específica a un usuario, omitiendo el proceso de evaluación estándar. Esto es especialmente valioso para experimentos controlados donde la lógica de evaluación habitual no es requerida o debe ser omitida. También puede ser útil en escenarios como depuración o pruebas personalizadas. Cuando se establece una variación forzada, anula la lógica de evaluación en tiempo real de Kameleoon. Los procesos como segmentación, condiciones de segmentación y cálculos algorítmicos se omiten. Para preservar la segmentación y las condiciones de segmentación durante un experimento, establezca forceTargeting=false en su lugar.
Las variaciones simuladas siempre tienen prioridad en el orden de ejecución. Si se activa un cálculo de variación simulada, se procesará y completará completamente primero.
Una variación forzada se trata igual que una variación evaluada. Se rastrea en análisis y se almacena en el contexto del usuario como cualquier variación evaluada estándar, asegurando consistencia en la generación de informes. El método puede lanzar excepciones bajo ciertas condiciones (por ejemplo, parámetros inválidos, contexto de usuario o problemas internos). El manejo adecuado de excepciones es esencial para asegurar que su aplicación sea estable y resiliente.
Es importante distinguir las variaciones forzadas de las variaciones simuladas:
  • Forced variations: Son específicas para un experimento individual.
  • Simulated variations: Afectan el resultado general del feature flag.
Parámetros
Un objeto de tipo SetForcedVariationParametersType con las siguientes propiedades:
Excepciones lanzadas
En la mayoría de los casos, solo el error básico, KameleoonException, necesita ser manejado, como se demuestra en el ejemplo. Sin embargo, si diferentes tipos de errores requieren una respuesta, maneje cada uno por separado según los requisitos específicos. Además, para mayor confiabilidad, los errores del lenguaje general pueden ser manejados incluyendo Error.

evaluateAudiences()

  • 📨 Envía datos de tracking a Kameleoon
Este método evalúa a los visitantes con respecto a todos los segmentos de Audiences Explorer disponibles y rastrea los que coinciden. evaluateAudiences() debe llamarse después de que todos los datos del visitante relevantes hayan sido configurados o actualizados, y justo antes de obtener una variación de feature o verificar un feature flag. Este enfoque garantiza que el visitante sea evaluado con respecto a los datos más actuales disponibles, permitiendo una asignación precisa de audiencia basada en todos los criterios. Después de llamar a este método, puede realizar un análisis detallado del rendimiento de segmentos en Audiences Explorer.
Parámetros
Excepciones lanzadas
En la mayoría de los casos, solo el error básico, KameleoonException, necesita ser manejado, como se demuestra en el ejemplo. Sin embargo, si diferentes tipos de errores requieren una respuesta, maneje cada uno por separado según los requisitos específicos. Además, para mayor confiabilidad, los errores del lenguaje general pueden ser manejados incluyendo Error.

getDataFile()

Para evaluar todos los feature flags, use getVariations(). Este método es más eficiente que llamar a DataFile e iterar a través de flags con getVariation().
Devuelve la configuración actual del SDK como un objeto DataFile.
Valor de retorno

Datos del visitante

Esta sección proporciona los métodos que utiliza para administrar los datos del visitante.

getVisitorCode()

getVisitorCode método recopilado del hook useVisitorCode obtiene un código de visitante del cookie del navegador. Si el código de visitante aún no existe, la función genera un código de visitante único aleatorio (o utiliza el valor defaultVisitorCode si proporcionó uno) y configura el nuevo código de visitante en un cookie.
El método getVisitorCode() le permite establecer variaciones simuladas para un visitante. Cuando las cookies (de una solicitud o documento) contienen la clave kameleoonSimulationFFData, el proceso de evaluación estándar se omite. En su lugar, el método devuelve directamente una Variation basada en los datos proporcionados.Puede aplicar simulaciones de dos formas:
  • Automáticamente (recomendado): Si utiliza Kameleoon Web Experimentation o el SDK en Modo híbrido, la cookie se crea automáticamente al simular la visualización de una variante usando el Panel de Simulación.
  • Manualmente: Establezca la cookie kameleoonSimulationFFData manualmente.
Es importante distinguir las variaciones simuladas de las variaciones forzadas:
  • Variaciones simuladas: Afectan el resultado general del feature flag.
  • Variaciones forzadas: Son específicas de un experimento individual.
⚙️ Manual setupAsegúrese de que la cookie kameleoonSimulationFFData siga este formato:
  • kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: Simula la variación con varId del experimento expId para el featureKey dado.
  • kameleoonSimulationFFData={"featureKey":{"expId":0}}: Simula la variación predeterminada (definida en la sección Entonces, para todos los demás en Producción, sirva) para el featureKey dado.
⚠️ Para garantizar el correcto funcionamiento, codifique el valor de la cookie como un componente URI usando un método como encodeURIComponent.
Parámetros
Si no proporciona un defaultVisitorCode y no hay un código de visitante almacenado en una cookie, el código de visitante será generado aleatoriamente.
Valor de retorno
Excepciones lanzadas

addData()

La función addData, utilizada con el hook useData, recopila datos de targeting para almacenarlos para que otros hooks determinen si el visitante actual es dirigido.
  • La función addData() no devuelve ningún valor y no interactúa con los servidores back-end de Kameleoon por sí sola. En su lugar, todos los datos declarados se guardan para su transmisión futura mediante el método flush. Este enfoque ayuda a reducir la cantidad de llamadas al servidor realizadas, ya que los datos generalmente se agrupan en una única llamada al servidor activada por la ejecución de flush.
El método trackConversion también envía cualquier dato previamente asociado, al igual que flush. Lo mismo se aplica a los métodos getFeatureFlagVariationKey y getFeatureVariable si se activa una regla de experimentación.
  • Los datos userAgent no se almacenarán en el almacenamiento como otros datos, y se enviarán con cada solicitud de seguimiento para el filtrado de bots.
  • Consulte la lista de condiciones admitidas para saber qué tipos de datos se pueden usar para el targeting
Cada visitante solo puede tener una instancia de datos asociados para la mayoría de los tipos de datos. Sin embargo, CustomData es una excepción. Los visitantes pueden tener una instancia de CustomData asociado por customDataIndex.
Parámetros
  • kameleoonData es un argumento variádico, puede pasarse como uno o varios argumentos (vea el ejemplo)
  • El índice o ID de los datos personalizados se puede encontrar en su cuenta de Kameleoon. Es importante notar que este índice comienza en 0, lo que significa que el primer dato personalizado que cree para un sitio dado se le asignará 0 como su ID, no 1.
Excepciones lanzadas
Consulte la referencia de Tipos de datos para obtener más detalles sobre cómo administrar diferentes tipos de datos.

flush()

flush() toma los datos de Kameleoon asociados con el visitante y programa que los datos se envíen con la siguiente solicitud de seguimiento. El momento de la siguiente solicitud de seguimiento se define por el parámetro trackingInterval de la configuración del SDK. Los datos del visitante se pueden agregar usando los métodos addData y getRemoteVisitorData.Si no especifica un visitorCode, el SDK descarga todos sus datos almacenados a los servidores remotos de Kameleoon. Si hay solicitudes de seguimiento que fallaron previamente y se almacenaron localmente durante el modo sin conexión, el SDK intenta enviar las solicitudes almacenadas antes de ejecutar la solicitud más reciente.
Si necesita enviar solicitudes de seguimiento inmediatamente, use flushInstant() (la versión asincrónica de flush que devuelve Promise<void>). Puede await cuando necesite garantías de entrega (por ejemplo, antes de la navegación/descarga de página), o llámelo sin await como una solicitud de “disparar y olvidar”:
  • await flushInstant(visitorCode) envía solicitudes de seguimiento inmediatamente para un visitante específico y espera la finalización
  • await flushInstant() envía solicitudes de seguimiento inmediatamente para todos los visitantes y espera la finalización
Parámetros
O un objeto con el tipo FlushParamsType, que contiene:
Excepciones lanzadas

getRemoteData()

El método asincrónico getRemoteData, recopilado con el hook useData, devuelve datos almacenados para el código de sitio especificado en un servidor remoto de Kameleoon. Por ejemplo, puede usar esta función para recuperar preferencias del usuario, datos históricos o cualquier otro dato relevante para la lógica de su aplicación. Al almacenar estos datos en los servidores altamente escalables de Kameleoon usando la [API de datos], puede administrar eficientemente enormes cantidades de datos y recuperarlos para cada uno de sus visitantes o usuarios.
Parámetros
Valor de retorno
Excepciones lanzadas

getRemoteVisitorData()

getRemoteVisitorData() es un método asincrónico para recuperar Datos de Visitas de Kameleoon para el visitorCode de la API de Datos de Kameleoon. El método agrega los datos al almacenamiento para que otros métodos los usen al tomar decisiones de segmentación.Los datos obtenidos mediante este método juegan un papel importante cuando desea:
  • utilizar datos recopilados de otros dispositivos.
  • acceder al historial del usuario, tales como páginas visitadas previamente durante visitas anteriores.
  • utilizar datos que solo son accesibles en el lado del cliente, como variables de capa de datos y objetivos que solo se convierten en el front-end.
Lee este artículo para una mejor comprensión de los posibles casos de uso.
Por defecto, getRemoteVisitorData() recupera automáticamente los últimos datos personalizados almacenados con scope=Visitor y los adjunta al visitante sin la necesidad de llamar al método addData(). Es particularmente útil para sincronizar datos personalizados entre múltiples dispositivos.
Parámetros
Un objeto con el tipo RemoteVisitorDataParamsType que contiene:
Valor de retorno
Excepciones lanzadas
Uso de parámetros en getRemoteVisitorData()
El método getRemoteVisitorData() ofrece flexibilidad al permitirle definir varios parámetros al recuperar datos sobre visitantes. Ya sea que se dirija según objetivos, experimentos o variaciones, el mismo enfoque se aplica en todos los tipos de datos.Por ejemplo, supongamos que desea recuperar datos sobre visitantes que completaron un objetivo “Transacción de pedido”. Puede especificar parámetros dentro del método getRemoteVisitorData() para refinar su segmentación. Por ejemplo, si desea dirigirse solo a usuarios que se convirtieron en el objetivo en sus últimas cinco visitas, puede establecer el parámetro previousVisitAmount en 5 y conversions en verdadero.La flexibilidad mostrada en este ejemplo no se limita a datos de objetivos. Puede usar parámetros dentro del método getRemoteVisitorData() para recuperar datos sobre una variedad de comportamientos de visitantes.
Aquí está la lista de filtros disponibles VisitorDataFiltersType:

getVisitorWarehouseAudience()

El método asincrónico getVisitorWarehouseAudience recopilado con el gancho useData recupera todos los datos de audiencia asociados con el visitante en su almacén de datos usando el visitorCode y warehouseKey especificados. El warehouseKey es típicamente su ID de usuario interno. El parámetro customDataIndex corresponde a los datos personalizados de Kameleoon que Kameleoon utiliza para dirigirse a sus visitantes. Consulte la documentación de segmentación del almacén para obtener más detalles.
Parámetros
Objeto de parámetros que consta de:
Valor de retorno
Excepciones lanzadas

setLegalConsent()

El método setLegalConsent, recopilado con el gancho useVisitorCode, especifica si el visitante ha dado su consentimiento legal para usar datos personales. Establecer el parámetro legalConsent en false limita los tipos de datos que puede incluir en solicitudes de seguimiento. Esto le ayuda a cumplir con requisitos legales y normativos mientras gestiona responsablemente los datos del visitante. Puede encontrar más información sobre datos personales en la política de gestión de consentimiento.
  • La información de consentimiento está sincronizada entre el Motor de Kameleoon (archivo de aplicación engine.js) y el SDK de React. Esta sincronización significa que una vez que el consentimiento se establece en el Motor o el SDK, se establece automáticamente para ambos. Esta característica elimina la necesidad de manejo manual del consentimiento y garantiza que los SDK funcionen de conformidad con las preferencias del usuario.
Si utiliza Kameleoon en modo híbrido, lea la sección de consentimiento en el artículo sobre experimentación híbrida
  • Al manejar el consentimiento legal, es importante utilizar el método getVisitorCode. Además, getVisitorCode no acepta domain como argumento. En su lugar, páselo a la función createClient.
Parámetros
Excepciones lanzadas
Comportamiento de revocación de consentimiento
Cuando llama a setLegalConsent() con consent=false, el SDK no elimina la cookie kameleoonVisitorCode. En su lugar, deja de extender la fecha de vencimiento de la cookie, permitiendo que la cookie persista hasta que expire naturalmente. Si sus requisitos de cumplimiento demandan la eliminación inmediata del archivo de cookie al optar por no participar, debe eliminarlo manualmente utilizando los métodos nativos de gestión de cookies de su framework. El SDK no eliminará el archivo automáticamente.

Objetivos y analítica de terceros

Esta sección proporciona los métodos que utiliza para rastrear cuándo una acción del visitante logra uno de sus objetivos (una conversión).

trackConversion()

  • 📨 Envía datos de seguimiento a Kameleoon
La función trackConversion(), utilizada con el hook useData crea y añade datos de Conversion al visitante con los parámetros especificados y ejecuta flush().Utilice este método para realizar un seguimiento de una conversión para un objetivo específico y usuario. Este método requiere visitorCode e goalId. Además, este método también acepta argumentos opcionales revenue, negative y metadata. El visitorCode es generalmente idéntico al que se utilizó cuando se activó el experimento.El método trackConversion() no devuelve ningún valor. Este método es no bloqueante ya que la llamada al servidor se realiza de manera asincrónica.
Parámetros
Objeto de parámetros que consta de:
Los valores de metadatos son accesibles a través de exportaciones de datos sin procesar y la página de resultados.Si se proporciona el parámetro metadata, Kameleoon utilizará estos valores especificados para la conversión actual en lugar de lo recopilado anteriormente utilizando el método addData(). Si se omite el parámetro, Kameleoon utilizará los últimos valores rastreados para CustomData anteriores a la conversión y dentro de la misma visita.Kameleoon solo considerará los valores de metadatos que se pasen explícitamente como parámetros al método trackConversion().En el ejemplo a continuación, Kameleoon asociará la conversión solo con el valor de datos personalizados proporcionado explícitamente como parámetro (aquí: índice 5 con el valor ‘Amex Credit Card’).
Excepciones lanzadas

getEngineTrackingCode()

Kameleoon se integra con varias soluciones de análisis, incluidas Mixpanel, Google Analytics 4 y Segment. Para rastrear correctamente los experimentos del lado del servidor, llame al método getEngineTrackingCode() después de que el visitante desencadene un experimento. El SDK devuelve comandos de cola JavaScript para los experimentos que el visitante desencadenó durante los últimos cinco segundos. Cuando inserta este código en la página, Engine.js procesa los comandos y envía los eventos de exposición a través de la integración de análisis activa. Consulte experimentación híbrida para obtener más información sobre la implementación de este método.
  • Para utilizar esta función, implemente tanto el SDK de React como el Engine.js de Kameleoon. Dado que Engine.js se utiliza solo para rastreo en este flujo, puede instalar la etiqueta asincrónica antes de la etiqueta de cierre </body>.
  • Puede insertar el código de rastreo devuelto directamente en una etiqueta HTML <script>.
En este ejemplo, 123456 y 234567 son ID de experimentos, y 7890 y 8901 son ID de variación. En su implementación, el SDK genera estos valores en el código de rastreo devuelto.
Parámetros
Valor de retorno
Excepciones lanzadas

Eventos

Esta sección proporciona los métodos que utiliza para manejar eventos.

setEventHandler()

Utilice este método para registrar un handler para los eventos del SDK. El SDK llama al handler cuando ocurre el evento seleccionado. Registrar un nuevo handler para el mismo tipo de evento reemplaza al handler anterior.Pasar null como handler elimina el handler actual para el tipo de evento seleccionado.
Recopile el método setEventHandler con el hook useInitialize.
Para borrar el handler actual para un tipo de evento, pase null como handler:
DataFileUpdateEventDataType contiene información sobre una actualización del archivo de datos del SDK.
Parámetros

Envío de eventos de exposición a herramientas externas
Kameleoon ofrece integraciones integradas con varias soluciones de analítica y CDP, como Mixpanel, Google Analytics 4, Segment…. Para asegurar que pueda rastrear y analizar sus experimentos del lado del servidor, Kameleoon proporciona un método getEngineTrackingCode() que devuelve el código JavaScript que debe insertar en su página para enviar automáticamente los eventos de exposición a la solución de analítica que está utilizando. El SDK construye un código de seguimiento para su solución de analítica activa basándose en los experimentos que el visitante activó en los últimos 5 segundos. Para más información sobre la experimentación híbrida, consulte esta documentación.
Para beneficiarse de esta característica, deberá implementar tanto el SDK React como la etiqueta JavaScript de Kameleoon. Implemente la [etiqueta JavaScript asincrónica de Kameleoon], que puede instalar antes de su etiqueta de cierre <body> en su página HTML, ya que se utilizará solo con fines de seguimiento.

Tipos de datos

Los tipos de datos de Kameleoon son clases auxiliares utilizadas para almacenar datos en el almacenamiento en formas predefinidas. Durante la ejecución de flush, el SDK recopila todos los datos y los envía junto con la solicitud de seguimiento. Los datos disponibles en el SDK no están disponibles para orientación e informes en la aplicación Kameleoon hasta que agregue los datos. Por ejemplo, utilizando el método addData(). Consulte usar historial de visitas para orientar usuarios para obtener más información.
Si está utilizando modo híbrido, puede llamar a getRemoteVisitorData() para rellenar automáticamente todos los datos que Kameleoon ha recopilado previamente.

Browser

Desde React SDK 10.11.0, Browser se detecta automáticamente según la cadena User-Agent. Sin embargo, puede anularlo manualmente si es necesario.
Browser contiene información del navegador.
Cada visitante solo puede tener un Browser. Agregar un segundo Browser sobrescribe el primero.

UniqueIdentifier

UniqueIdentifier se utiliza como marcador para identificación única de visitantes. Si agrega UniqueIdentifier para un visitante, visitorCode se utiliza como el identificador único del visitante, que es útil para experimentación entre dispositivos. La asociación de un UniqueIdentifier con un visitante notifica al SDK que el visitante está vinculado a otro visitante. El UniqueIdentifier también puede ser útil en otros escenarios especiales, como cuando no puede acceder al visitorCode anónimo que se asignó originalmente al visitante, pero tiene acceso a un ID interno que está conectado al visitante anónimo utilizando capacidades de fusión de sesiones.
Cada visitante solo puede tener un UniqueIdentifier. Agregar otro UniqueIdentifier sobrescribe el primero.

Conversion

El conjunto de datos Conversion almacenado aquí se puede utilizar para filtrar informes de experimentos y personalización por cualquier objetivo asociado con él.
  • Cada visitante puede tener múltiples objetos Conversion.
  • Puede encontrar goalId en la aplicación Kameleoon.
ConversionParametersType conversionParameters - un objeto con parámetros de conversión descritos a continuación
Cookie contiene información sobre la cookie almacenada en el dispositivo del visitante.
  • En general, el SDK de React intentará utilizar una cookie de localStorage para las condiciones. Si no es posible, el SDK puede utilizar datos de Cookie como alternativa.
  • Cada visitante solo puede tener una Cookie. Agregar una segunda Cookie sobrescribe la primera.
Métodos
Cookie data tiene un método de utilidad estática fromString que se puede utilizar para crear una cookie instantáneamente analizando una cadena que contiene datos de cookie válidos. El método acepta string como parámetro y devuelve una instancia inicializada de Cookie.

GeolocationData

GeolocationData contiene los detalles de geolocalización del visitante
Cada visitante solo puede tener un GeolocationData. Agregar un segundo GeolocationData sobrescribe el primero.
Un parámetro de objeto con el tipo GeolocationInfoType que contiene los siguientes campos:

CustomData

Para retener datos personalizados para futuras visitas, el SDK transmite CustomData con un alcance Visitor durante la siguiente solicitud de seguimiento. Puede configurar el alcance en la configuración de datos en el panel de datos personalizados. CustomData permite asociar fácilmente cualquier tipo de datos con cada visitante. Estos datos pueden usarse como condición de orientación en segmentos o como filtro o desglose en informes de experimentos. Para obtener más información sobre datos personalizados, consulte este artículo.
  • Cada visitante solo puede tener un CustomData para cada index único. Agregar otro CustomData con el mismo index reemplazará el existente.
  • El ‘index’ de los datos personalizados se puede encontrar en el panel de Datos Personalizados bajo la columna “INDEX”.
  • Para evitar que el SDK envíe datos con el índice seleccionado a los servidores de Kameleoon por razones de privacidad, habilite la opción: Use this data only locally for targeting purposes al crear datos personalizados.
  • Agregar una instancia CustomData creada con un nombre cuando la instancia del SDK no está inicializada o el nombre no está registrado hará que los datos se ignoren.

Device

Desde React SDK 10.11.0, Device se detecta automáticamente basándose en la cadena User-Agent. Sin embargo, aún puede anularla manualmente si es necesario.React Native: La compatibilidad con esta función es actualmente experimental y puede requerir ajustes para funcionar correctamente. En React Native, Device se detecta automáticamente basándose en el DPI de react-native.Dimensions.
Device contiene información sobre su dispositivo.
Cada visitante solo puede tener un Device. Agregar un segundo Device sobrescribe el primero.

OperatingSystem

Desde React SDK 10.11.0, OperatingSystem se detecta automáticamente basándose en la cadena User-Agent. Sin embargo, aún puede anularla manualmente si es necesario.React Native: La compatibilidad con esta función es actualmente experimental y puede requerir ajustes para funcionar correctamente. En React Native, OperatingSystem se detecta automáticamente basándose en react-native.Platform.
OperatingSystem contiene la información del sistema operativo del visitante.
Cada visitante solo puede tener un OperatingSystem. Agregar un segundo OperatingSystem sobrescribe el anterior.

PageView

Desde React SDK 10.11.0, PageView se detecta automáticamente basándose en window.location?.href y document.title. Sin embargo, aún puede anularla manualmente si es necesario.React Native: La compatibilidad con esta función es actualmente experimental y puede requerir ajustes para funcionar correctamente.
PageView contiene información sobre su página web.
Cada visitante puede tener un PageView por cada URL única. Agregar un PageView con la misma URL que uno existente notificará al SDK que el visitante revisitó la página
PageViewParametersType pageViewParameters - un objeto con los parámetros de vista de página descritos a continuación

UserAgent

Almacena información sobre el agente de usuario del visitante. Los experimentos del lado del servidor son más vulnerables al tráfico de bots que los experimentos del lado del cliente. Para abordar esto, Kameleoon utiliza la Lista Internacional de Arañas y Bots de IAB/ABC para identificar bots y arañas conocidos. Kameleoon también usa el campo UserAgent para filtrar bots y otro tráfico no deseado que de otro modo podría sesgar sus métricas de conversión. Para más detalles, consulte el artículo de ayuda sobre filtrado de bots. Si utiliza bots internos, pase el valor curl/8.0 del userAgent para excluirlos de su análisis.
Un visitante solo puede tener un UserAgent. Agregar un segundo UserAgent sobrescribe el primero.
Los experimentos del lado del servidor son más vulnerables al tráfico de bots que los experimentos del lado del cliente. Para abordar esto, Kameleoon utiliza la Lista Internacional de Arañas y Bots de IAB/ABC para identificar bots y arañas conocidos. Le recomendamos que pase el agente de usuario a filtrar por Kameleoon cuando ejecute experimentos del lado del servidor para cada visitante que navega por su sitio web, para evitar contar bots en su análisis.Si utiliza bots internos, pase el valor curl/8.0 del userAgent para excluirlos de su análisis.

ApplicationVersion

ApplicationVersion representa el número de versión semántica de su aplicación.
Un visitante solo puede tener un ApplicationVersion. Agregar una segunda instancia sobrescribe la primera.

Tipos devueltos

DataFile

DataFile contiene los detalles de configuración del SDK. Puede extenderse con información adicional si es requerido por los clientes. Si necesita más detalles, contacte con su Gestor de Éxito del Cliente.

FeatureFlag

FeatureFlag representa un conjunto de propiedades que definen una bandera de característica en sí misma (por ejemplo, sus Variations, Rules, estado del entorno y otros detalles relacionados). Puede extenderse con información adicional si es requerido por los clientes. Si necesita más detalles, contacte con su Gestor de Éxito del Cliente.

Rule

Rule representa un conjunto de propiedades que definen una regla en sí misma (por ejemplo, sus Variations). Puede extenderse con información adicional si es requerido por los clientes. Si necesita más detalles, contacte con su Gestor de Éxito del Cliente.

Variation

Variation contiene información sobre la variación asignada al visitante (o la variación predeterminada, si no existe una asignación específica).
  • Asegúrese de que su código maneje el caso donde id o experimentId puede ser null, indicando una variación predeterminada.
  • El mapa variables puede estar vacío si no hay variables asociadas con la variación.

Variable

Variable contiene información sobre una variable asociada con la variación asignada.

Métodos obsoletos

Estos métodos están obsoletos y se eliminarán en la próxima actualización principal.

isInitialized()

Utilice el método isReady.
La función isInitialized, recopilada con el hook useInitialize, es un pequeño método de utilidad que comprueba si la inicialización del SDK ha completado. Por ejemplo, esto puede ser útil al tratar con un árbol de componentes profundamente anidado, porque le permite comprobar rápidamente la preparación del SDK sin tener que gestionar un estado global ni pasar el resultado de inicialización utilizando propiedades del componente.
Valor de retorno
Un valor boolean. Devuelve true si el SDK se inicializó correctamente, de lo contrario devuelve false.

getFeatureFlagVariationKey()

  • 📨 Envía datos de seguimiento a Kameleoon
  • 🎯 Eventos: EventType.Evaluation
Use el método getVariation.
El método getFeatureFlagVariationKey(), que se utiliza con el hook useFeatureFlag, recupera la clave de variación para un visitante identificado por su visitorCode. Este proceso incluye verificar los criterios de orientación, identificar la variación apropiada asignada al visitante, almacenar esta información y enviar una solicitud de seguimiento.
Si un usuario nunca ha sido asociado con una bandera de característica, el SDK devolverá aleatoriamente una clave de variación de acuerdo con las reglas de esa bandera de característica. Si el usuario ya está vinculado a la bandera de característica, el SDK identificará la clave de variación previamente asignada. Si el usuario no cumple con ninguna de las reglas especificadas, el SDK devolverá el valor predeterminado definido en las reglas de entrega de banderas de característica de Kameleoon. Es importante notar que el valor predeterminado puede no ser siempre una clave de variación; también podría ser un valor booleano u otro tipo de datos, dependiendo de cómo se configure la bandera de característica.
Parámetros
Valor de retorno
Excepciones lanzadas

getVisitorFeatureFlags()

  • 🚫 No envía Tracking Data a Kameleoon
  • 🎯 Eventos: EventType.Evaluation (para cada feature flag)
Utilice el método getVariations.
El método getVisitorFeatureFlags, utilizado con el hook useFeatureFlag, devuelve una lista de feature flags activos que dirigen al visitante asociado con visitorCode (el visitante debe tener una de las variaciones asignadas).
Este método solo recopila los feature flags que están activos para el visitante. Como resultado, no incluye ningún feature flag para el cual el visitante esté asignado a la variación “apagado” (predeterminada o control). Si necesita recuperar todos los feature flags del visitante, utilice getFeatureFlags en su lugar.Por ejemplo:
Para casos en los que necesite todos los feature flags del visitante, utilice getFeatureFlags en su lugar:
Parámetros
Valor de retorno
Excepciones lanzadas

getActiveFeatureFlags()

  • 🚫 No envía Tracking Data a Kameleoon
  • 🎯 Eventos: EventType.Evaluation (para cada feature flag)
Utilice el método getVariations.
El método getActiveFeatureFlags, recopilado con el hook useFeatureFlag, devuelve un Map, donde la clave es la clave de feature y el valor es información detallada sobre la variación del visitante y sus variables
Este método solo recopila los feature flags activos del visitante. Esto significa que el resultado excluye todos los feature flags para los que el visitante está asignado a la variación off (por defecto o control). Cuando necesita todos los feature flags del visitante para iterar, use getFeatureFlags en su lugar.Consulte la sección de PRECAUCIÓN del método getVisitorFeatureFlags para obtener más detalles.
Parámetros
Valor de retorno
Excepciones lanzadas

getFeatureFlagVariable()

  • 📨 Envía Tracking Data a Kameleoon
  • 🎯 Eventos: EventType.Evaluation
Utilice el método getVariation.
El método getFeatureFlagVariable, recopilado con el hook useFeatureFlag, devuelve una variable para el visitante bajo visitorCode en el feature flag encontrado, esto incluye la verificación de orientación, encontrar la variación correspondiente expuesta al visitante y guardarla en almacenamiento junto con el envío de una solicitud de seguimiento.
Parámetros
Objeto de parámetros de tipo GetFeatureFlagVariableParamsType que contiene los siguientes campos:
Valor de retorno
Excepciones lanzadas

getFeatureFlagVariables()

  • 📨 Envía Tracking Data a Kameleoon
  • 🎯 Eventos: EventType.Evaluation (para cada feature flag)
Utilice el método getVariations.
El método getFeatureFlagVariables, recopilado con el hook useFeatureFlag, devuelve una lista de variables para el visitante bajo visitorCode en el feature flag encontrado, esto incluye la verificación de orientación, encontrar la variación correspondiente expuesta al visitante y guardarla en almacenamiento junto con el envío de una solicitud de seguimiento.
Parámetros
Valor de retorno
Excepciones lanzadas

onConfigurationUpdate()

Utilice el método onEvent con EventType.ConfigurationUpdate en su lugar.
El método onConfigurationUpdate recopilado con el hook useInitialize ejecuta una devolución de llamada en la actualización de configuración del cliente.
Este hook solo funciona para eventos enviados por el servidor de actualización en tiempo real
Parámetros
Excepciones lanzadas

getFeatureFlags()

🚫 No envía Tracking Data a Kameleoon El método getFeatureFlags recopilado con el hook useFeatureFlag devuelve una lista de feature flags almacenados en la configuración del cliente.
Valor de retorno
Excepciones lanzadas

onEvent()

Utilice setEventHandler() en su lugar.
El método onEvent, recopilado con el hook useInitialize, dispara una devolución de llamada cuando se dispara un evento específico. La función de devolución de llamada tiene acceso a los datos asociados con el evento. Los métodos del SDK en esta documentación notan qué tipos de eventos pueden disparar, si es que hay alguno.
Solo puede asignar una devolución de llamada a cada EventType.
Eventos
Los eventos se definen en la enumeración EventType. Dependiendo del tipo de evento, el parámetro eventData tendrá un tipo diferente.
Parámetros
Excepciones lanzadas