Skip to main content
Puede ejecutar experimentos y activar feature flags con el SDK de NodeJS. Integrar nuestro SDK en su servidor es sencillo y su huella (memoria y uso de red) es baja. Nuestro SDK de Node admite la versión 16+ de Node, con la opción de degradarlo a la versión 14 y 12 mediante el modo de compatibilidad. Primeros pasos: Para obtener ayuda para comenzar, consulte la guía del desarrollador. Métodos del SDK: Para la documentación de referencia completa del SDK de NodeJS, consulte la sección referencia. Changelog: Última versión del SDK de NodeJS: Changelog. Ejemplo de Next.js: Para ver ejemplos de la integración del SDK de NodeJS con Next.js, incluyendo App Router, Pages Router, middleware y server actions, consulte el repositorio de starter kits de Next.js.
Antes de comenzar la instalación de nuestro SDK de NodeJS, le recomendamos leer nuestro artículo de consideraciones técnicas para comprender los conceptos tecnológicos que hay detrás de nuestros SDKs. Este artículo le ayudará a garantizar una integración exitosa.

Guía del desarrollador

Siga esta sección para instalar y configurar el SDK y conocer las funcionalidades avanzadas.

Primeros pasos

Instalación

Utilice la herramienta de instalación de SDK de Kameleoon para instalar el SDK. El instalador de SDK le ayuda a instalar el SDK de su elección, generar una muestra de código básica y configurar las dependencias externas si es necesario. Para usar la herramienta de instalación del SDK, instálela y ejecútela globalmente:
O ejecútela directamente con npx:
Al usar Deno, proporcione las dependencias manualmente en deno.json:
deno.json

Inicializar el cliente Kameleoon

Los desarrolladores deben crear un punto de entrada para el SDK de NodeJS instanciando un nuevo KameleoonClient. Se recomienda tratar KameleoonClient como un singleton, creando una única instancia compartida y reutilizándola en toda la instancia del servidor para garantizar la consistencia y evitar la reinicialización innecesaria. Use KameleoonClient para ejecutar experimentos de funcionalidades y obtener el estado de los feature flags y sus variaciones. KameleoonClient se inicializa de forma asincrónica para garantizar que la comunicación con la API de Kameleoon sea exitosa, utilizando el método initialize(). Puede usar async/await, Promise.then() u otro patrón asincrónico para manejar la inicialización del cliente.
Para agregar el SDK de NodeJS a un entorno Edge, consulte esta sección.
Parámetros
Excepciones lanzadas
Parámetros de configuración
Opción 1 (Recomendado): Use JSON.stringify()
Opción 2: Cadena JSON sin procesar (escape de caracteres especiales)
Modo de compatibilidad
Use el parámetro compatibility del SDK para desactivar algunas de las características del SDK para mejorar la compatibilidad con versiones anteriores de NodeJS. Compatibility es una enumeración que representa todos los modos de compatibilidad posibles:
  • Compatibility.Node16 - modo predeterminado, todas las características están habilitadas. Este modo se utilizará si no se proporciona ningún modo de compatibilidad. Compatible con Node versión 16 y superior.
  • Compatibility.Node14 - la compatibilidad con esta versión hará que el parámetro requestTimeout en SDKConfigurationType no esté disponible e impedirá que el SDK use AbortController para la cancelación de solicitudes, incluso dentro del tiempo de espera predeterminado de 10_000 ms. Compatible con Node versión 14 y superior.
  • Compatibility.Node12 - la compatibilidad con esta versión implica las mismas limitaciones que el modo de compatibilidad Node14. Además, no puede proporcionar “@kameleoon/nodejs-requester” como implementación de solicitante en este modo de compatibilidad, ya que utiliza la biblioteca “node-fetch”, que no admite la versión Node.js 12.x.x. Un desarrollador debe proporcionar una implementación de solicitante personalizada de su elección, como una versión anterior de “node-fetch” u otra implementación basada en HTTP.

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.

Gestión de errores

Casi todos los métodos de KameleoonClient pueden lanzar un error en algún momento. Estos errores son deliberadamente KameleoonErrors predefinidos que extienden la clase nativa Error de JavaScript, proporcionando mensajes útiles y un campo especial type con un tipo KameleoonException. KameleoonException es una enumeración que contiene todos los tipos de error posibles. Para saber exactamente qué tipo de KameleoonException puede lanzar el método, consulte la sección Throws de la descripción del método, o pase el cursor sobre el método en su IDE para ver la descripción del jsdocs. Se considera una buena práctica manejar errores para hacer su aplicación más estable y evitar problemas técnicos.

Integración con proveedores Edge

Kameleoon proporciona los siguientes starter packs para automatizar su integración con proveedores edge específicos:Para otros proveedores edge, use Dependencias externas para mayor control sobre el SDK.

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

La experimentación entre dispositivos le permite combinar el historial de un visitante en cada uno de sus dispositivos (reconciliación del historial). Puede fusionar varias sesiones de visitante en una con reconciliación del historial. Use CustomData y proporcione un identificador único para el visitante para reconciliar el historial de visitas.Siga la guía activación de la reconciliación del historial entre dispositivos para configurar sus datos personalizados en Kameleoon.Puede usar datos personalizados en su código para fusionar la sesión de un 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 la página 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, informe al SDK que el visitante es un identificador único agregando datos UniqueIdentifier a un visitante.
Dado que los datos personalizados que usa como identificador deben establecerse en el alcance Visitor, debe usar sincronización de datos personalizados entre dispositivos para recuperar el identificador con el método getRemoteVisitorData en cada dispositivo.
El siguiente ejemplo muestra una aplicación con una página de inicio de sesión. Dado que el ID de usuario no se conoce 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 inicie sesión, puede asociar el visitante anónimo con el ID de usuario y usarlo como identificador único para el visitante.
Login Page
Application Page

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. Proporcionar un dominio es importante cuando se trabaja 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 permite que la dirección URL use la cookie. Por ejemplo, si su dominio es www.example.com, la cookie solo está disponible desde una URL www.example.com. Las páginas con el dominio app.example.com no pueden usar la cookie. Para mayor flexibilidad con subdominios, puede especificar un dominio que comience con un .. Por ejemplo, el dominio .example.com permite que la cookie funcione tanto en app.example.com como en login.example.com.
No puede usar expresiones regulares, símbolos especiales, protocolo ni números de puerto en domain. Además, una lista específica de subdominios no puede usarse 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 hace que sea difícil 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:
    • Navegue a /etc/hosts en Linux o a c:\Windows\System32\Drivers\etc\hosts en Windows
    • Abra hosts con permisos de superusuario o administrador
    • Añadir 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 inyección de dependencias, lo que le permite proporcionar sus propias implementaciones para ciertas partes de un SDK.
En el SDK de NodeJS, algunas dependencias externas tienen implementaciones predeterminadas, mientras que otras deben ser proporcionadas por el usuario, ya sea utilizando implementaciones dedicadas de Kameleoon o implementaciones personalizadas.
Esta es la lista de dependencias externas disponibles:
También puede implementar visitorCodeManager utilizando las interfaces IExternalNextJSVisitorCodeManager, IExternalDenoVisitorCodeManager o IExternalCustomVisitorCodeManager para implementaciones de NextJS, Deno o gestor de código de visitante personalizado, respectivamente.
Las dependencias externas proporcionan a los desarrolladores flexibilidad para adaptar y usar el SDK de NodeJS en cualquier entorno. Hay una serie de paquetes npm que Kameleoon proporciona para entornos de uso frecuente. Puede instalar los paquetes manualmente o usando la herramienta de instalación del SDK (recomendado). Estas son las dependencias externas proporcionadas por Kameleoon para el SDK de NodeJS:
  • @kameleoon/nodejs-event-source - basado en la biblioteca eventsource (se puede usar para NodeJS/Deno/NextJS SSR)
  • @kameleoon/nodejs-requester - basado en la biblioteca node-fetch (se puede usar para NodeJS/Deno/NextJS SSR)
  • @kameleoon/nodejs-visitor-code-manager - implementado con almacenamiento de memoria del servidor
  • @kameleoon/deno-visitor-code-manager - implementado usando cookies de solicitud/respuesta de Deno
  • @kameleoon/nextjs-visitor-code-manager - implementado usando la cookie NextJS SSR headers o solicitud/respuesta NextJS SSR
Puede implementar opcionalmente las dependencias externas por su cuenta. 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

Implementación de visitorCodeManager para NodeJS/NextJS SSR:
Implementación de visitorCodeManager para Deno:
visitorCodeManager implementación para NextJS Server Actions:
Implementación personalizada de visitorCodeManager con parámetros arbitrarios:

Requester

Utilidades

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

simulateSuccessRequest

Use el método simulateSuccessRequest para simular una solicitud exitosa al servidor de Kameleoon. Este método puede ser útil para implementaciones personalizadas de Requester cuando un desarrollador necesita simular una solicitud exitosa.
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

Use el método getCookieValue 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. Este método 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 del SDK de JavaScript de Kameleoon.

Inicialización

initialize()

Un método asincrónico para inicializar KameleoonClient que recupera datos del SDK de Kameleoon ya sea desde el servidor o de una fuente local si los datos aún están actualizados o el intervalo de actualización aún no ha transcurrido.
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.
Una vez que el SDK está listo, permanece listo. 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

Feature flags y variaciones

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
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() devuelve un booleano que indica si el visitante con visitorCode tiene un featureKey activo. Este método verifica el direccionamiento, encuentra la variación para el visitante y la guarda en el almacenamiento. El método también envía una solicitud de seguimiento. Este método tiene una sobrecarga adicional que le permite pasar un parámetro track, que desactiva el rastreo de la evaluación de características.
Un visitante debe ser dirigido para que los feature flags se activen.
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:
  • Variaciones forzadas: Son específicas de un experimento individual.
  • Variaciones simuladas: 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 seguimiento 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

getVisitorCode()

El método getVisitorCode recupera un código de visitante de la cookie de la solicitud en los encabezados. Si el código de visitante no existe, el método genera un nuevo código de visitante aleatorio o usa un valor defaultVisitorCode proporcionado. Luego establece el nuevo código de visitante en una cookie en los encabezados de respuesta. Este método utiliza los tipos nativos de Node.js para request y response, específicamente IncomingMessage y ServerResponse, importados del módulo http. Sin embargo, si está usando el framework Express, Deno o métodos de super renderizado de servidor de Next.js, como getServerProps, los tipos para request y response serán diferentes. Puede resolver este problema usando casting de tipos, que producirá resultados idénticos.
Al usar getVisitorCode() con Deno, Next.js SSR, Node o Express, asegúrese de haber implementado las dependencias externas correctas.
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
El objeto de parámetros está sobrecargado con dos tipos:
  • Tipo GetVisitorCodeParametersType (para NodeJS/Express/NextJS SSR methods), que contiene los siguientes campos:
  • Tipo GetNextJSVisitorCodeParametersType (para NextJS SSR server actions), que contiene los siguientes campos:
  • Tipo GetDenoVisitorCodeParametersType (para Deno), que contiene los siguientes campos:
  • Tipo GetCustomVisitorCodeParametersType (para la implementación personalizada de VisitorCodeManager), que contiene los siguientes campos:
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()

Use el método addData() para agregar datos de direccionamiento al almacenamiento para que otros métodos puedan utilizar esta información para determinar si dirigirse al visitante actual. El método addData() no devuelve ningún valor y no interactúa directamente con los servidores back-end de Kameleoon. En su lugar, todos los datos que recopila el método se guardan para transmisión futura usando el método flush(). Este enfoque minimiza el número de llamadas al servidor, ya que los datos generalmente se agrupan en una única llamada al servidor que es activada por el método flush(). Además, el método trackConversion() transmite cualquier dato previamente asociado. Los métodos getFeatureFlagVariationKey() y getFeatureFlagVariable() transmiten datos cuando se activa una regla de experimentación.
Cada visitante solo puede tener una instancia de datos asociados para la mayoría de tipos de datos; sin embargo, CustomData es una excepción, ya que los visitantes pueden tener una instancia de CustomData asociada para cada customDataIndex.
Verifique la lista de condiciones soportadas para ver los tipos de datos que puede usar para el direccionamiento.
Parámetros
  • kameleoonData es un argumento variádico: se puede pasar como uno o varios argumentos (vea el ejemplo).
  • El índice o ID de los datos personalizados se puede encontrar en su cuenta de Kameleoon. Tenga en cuenta que este índice comienza en 0, lo que significa que los primeros datos personalizados que cree para un sitio determinado se asignarán 0 como su ID, en lugar de 1.
Excepciones lanzadas
Verifique la referencia tipos de datos para obtener más detalles sobre cómo administrar diferentes tipos de datos.

flush()

flush() toma los datos de Kameleoon asociados al visitante y programa los datos para ser enviados con la siguiente solicitud de seguimiento. El momento de la siguiente solicitud de seguimiento está definido en el parámetro trackingInterval de la Configuración del SDK. Puede agregar datos del visitante usando los métodos addData() y getRemoteVisitorData().El SDK enviará todos sus datos almacenados a los servidores remotos de Kameleoon si no especifica un visitorCode. Además, si hubiera alguna solicitud de seguimiento que fallo previamente y se almacenó localmente en modo sin conexión, el SDK intentará enviar esas solicitudes almacenadas antes de procesar la última solicitud.
Si necesita enviar solicitudes de seguimiento inmediatamente, use flushInstant()—la versión asincrónica de flush que devuelve Promise<void>. Puede await (esperar) cuando necesite garantías de entrega (por ejemplo, antes de finalizar un ciclo de solicitud/respuesta), o llamarlo sin await como una solicitud de disparar y olvidar:
  • await client.flushInstant(visitorCode) envía solicitudes de seguimiento inmediatamente para un visitante específico y espera la finalización
  • await client.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 getRemoteData() recupera datos que se almacenan en un servidor remoto de Kameleoon para un código de sitio especificado. Por ejemplo, puede usar este método para acceder a preferencias del usuario, datos históricos u otra información pertinente a la lógica de su aplicación. Al almacenar estos datos en nuestros servidores altamente escalables usando nuestra API de datos, puede administrar eficientemente grandes volúmenes de datos y recuperarlos para cada uno de sus visitantes o usuarios.
Parámetros
Valor de retorno
Excepciones lanzadas

getRemoteVisitorData()

El método getRemoteVisitorData() es una función asincrónica que recupera Datos de visitas de Kameleoon para un visitorCode específico desde la API de datos de Kameleoon. Este método almacena los datos para que se pueda acceder a ellos al tomar decisiones de orientación.Los datos obtenidos a través de este método son cruciales cuando desea:
  • Acceder a datos recopilados de múltiples dispositivos.
  • Revisar el historial de un usuario, incluyendo páginas visitadas durante sesiones anteriores.
  • Utilizar datos del lado del cliente, como variables de capa de datos y objetivos que solo son aplicables en el frontend.
Para una mejor comprensión de los casos de uso potenciales, lea este artículo.
Por defecto, getRemoteVisitorData() recupera los últimos datos personalizados almacenados con scope=Visitor y los adjunta al visitante sin la necesidad de llamar al método addData(). Esta característica es particularmente útil para sincronizar datos personalizados entre múltiples dispositivos.
Parámetros
Un objeto con el tipo RemoteVisitorDataParamsType, conteniendo:
Valor de retorno
Excepciones lanzadas
Uso de parámetros en getRemoteVisitorData()
El método getRemoteVisitorData() proporciona flexibilidad permitiéndole definir varios parámetros al recuperar datos del visitante. Este método puede orientar datos basándose en objetivos, experimentos o variaciones, y el mismo enfoque se aplica a todos los tipos de datos.Por ejemplo, si desea recuperar datos sobre visitantes que completaron el objetivo “Transacción de pedido,” puede especificar parámetros en el método getRemoteVisitorData() para refinar su orientación. Si le interesan los usuarios que se convirtieron en el objetivo durante sus últimas cinco visitas, puede establecer el parámetro previousVisitAmount a 5 y conversions a true.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 getVisitorWarehouseAudience es asincrónico y recupera todos los datos de audiencia relacionados con un visitante de su almacén de datos. Para usar este método, deberá proporcionar un visitorCode y una warehouseKey, que típicamente corresponden a su ID de usuario interno. El parámetro customDataIndex se refiere a los datos personalizados que Kameleoon usa para orientar a sus visitantes. Para más detalles, consulte la documentación de orientación de almacén.
Parámetros
Objeto de parámetros que consta de:
Valor de retorno
Excepciones lanzadas

setLegalConsent()

Al manejar el consentimiento legal, es importante que use el método getVisitorCode de la clase KameleoonClient, en lugar del método deprecado de KameleoonUtils. Tenga en cuenta que este método no requiere el domain como argumento. En su lugar, debería pasar el domain al constructor de KameleoonClient. Consulte el ejemplo anterior para clarificación.
El método setLegalConsent determina si un visitante ha proporcionado consentimiento legal para el uso de sus datos personales. Si establece el parámetro legalConsent en false, restringe los tipos de datos que puede incluir en solicitudes de seguimiento. Esta medida asegura que cumpla con los requisitos legales y regulatorios mientras gestiona responsablemente los datos del visitante. Para más información sobre datos personales, consulte la política de gestión de consentimiento.
Parámetros
El objeto de parámetros está sobrecargado con dos tipos:
  • Tipo SetLegalConsentParametersType (para NodeJS/Express/NextJS SSR methods), que contiene los siguientes campos:
  • Tipo SetNextJSLegalConsentParametersType (para NextJS SSR server actions), que contiene los siguientes campos:
  • Tipo SetDenoLegalConsentParametersType (para Deno), que contiene los siguientes campos:
  • Tipo SetCustomLegalConsentParametersType (para la implementación personalizada de VisitorCodeManager), que contiene los siguientes campos:
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

trackConversion()

  • 📨 Envía datos de seguimiento a Kameleoon
Utilice este método para rastrear una conversión para un objetivo específico y usuario. Este método requiere visitorCode y 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ó al desencadenar 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 usar esta función, implemente tanto el SDK de NodeJS como Kameleoon Engine.js. Porque Engine.js se usa 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

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.
DataFileUpdateEventDataType contiene información sobre una actualización del archivo de datos del SDK.
Parámetros

Tipos de datos

Los tipos de datos de Kameleoon son clases de ayuda utilizadas para almacenar datos 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, usando el método addData()). Consulte usar historial de visitas para orientar usuarios para obtener más información.
Si está utilizando Kameleoon en modo híbrido, puede llamar a getRemoteVisitorData() para llenar automáticamente todos los datos que Kameleoon recopiló previamente.

Browser

Browser contiene información del navegador.
Cada visitante solo puede tener un Browser. Agregar un segundo Browser sobrescribe el primero.

UniqueIdentifier

Los datos de UniqueIdentifier se utilizan para identificación única de visitante. Si agrega UniqueIdentifier para un visitante, visitorCode se utiliza como el identificador único de visitante, que es útil para Experimentación entre dispositivos. Vinculación de un UniqueIdentifier a un visitante informa al SDK que este visitante está asociado con otro visitante. El parámetro UniqueIdentifier puede ser beneficioso en ciertos casos extremos. Por ejemplo, si no puede acceder al visitorCode anónimo inicialmente asignado a un visitante pero tiene un ID interno vinculado a través de fusión de sesiones, este parámetro es útil.
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. El SDK de NodeJS no requiere un request o response para extraer la cookie. En su lugar, agregue la cookie manualmente usando datos de Cookie.
Cada visitante solo puede tener una Cookie. Agregar una segunda Cookie sobrescribe la primera.
Métodos
Los datos de Cookie tienen un método de utilidad estática, fromString, que puede ayudarle a crear una cookie analizando una cadena que contiene datos de cookie válidos. El método acepta string como parámetro, y devuelve una instancia de Cookie inicializada.

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 contiene los siguientes campos:

CustomData

CustomData permite asociar fácilmente cualquier tipo de datos con cada visitante. Luego se puede usar como condición de orientación en segmentos o como filtro/desglose en informes de experimentos. Para obtener más información sobre datos personalizados, consulte este artículo. Para mantener los datos personalizados en futuras visitas, el SDK envía CustomData con el alcance Visitor con la siguiente solicitud de seguimiento. Puede establecer el alcance en el panel de datos personalizados.
  • 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: Usar estos datos solo localmente con fines de orientación 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

Device contiene información sobre su dispositivo.
Cada visitante solo puede tener un Device. Agregar un segundo Device sobrescribe el primero.

OperatingSystem

OperatingSystem contiene información sobre el sistema operativo del visitante.
Cada visitante puede tener solo un OperatingSystem. Añadir un segundo OperatingSystem sobrescribe el primero.

PageView

PageView contiene información sobre su página web.
Cada visitante puede tener un PageView por URL única. Agregar un PageView con la misma URL notifica 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
Puede encontrar el índice o ID del referente en su cuenta de Kameleoon. Tenga en cuenta que este índice comienza en 0, lo que significa que el primer canal de adquisición que cree para un sitio determinado se asignará 0 como su ID, no 1.

UserAgent

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 usa la Lista Internacional de Spiders y Bots de IAB/ABC para identificar bots y spiders 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 usa 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.

Ayudantes Edge

Estos métodos auxiliares están diseñados principalmente para tiempos de ejecución de corta duración o estilo edge donde el SDK puede necesitar una revalidación explícita entre solicitudes.

refreshDataFileIfStale()

El método refreshDataFileIfStale() desencadena una revalidación del archivo de datos solo cuando la configuración actual está obsoleta. Si el archivo de datos sigue siendo válido y la última actualización ocurrió hace menos del updateInterval configurado, el método devuelve false y no se realiza ninguna solicitud de actualización. Si el archivo de datos está obsoleto, el método espera a que se complete la solicitud de revalidación y devuelve true cuando se realizó la solicitud. Devolver true significa que se ejecutó la verificación, pero la configuración en sí puede permanecer sin cambios, por ejemplo cuando el servidor informa que el archivo de datos actual ya está actualizado.
En un tiempo de ejecución típico de Node.js de larga duración, generalmente no se recomienda usar este método, porque el SDK ya mantiene el archivo de datos actualizado automáticamente durante la inicialización y la ejecución normal. Aún puede ser útil en entornos de estilo edge como Cloudflare Workers, donde el comportamiento del tiempo de ejecución es más de corta duración y la revalidación puede necesitar ser desencadenada explícitamente.
Valor de retorno

Métodos obsoletos

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

getFeatureFlagVariationKey()

  • 📨 Envía Tracking Data a Kameleoon
  • 🎯 Eventos: EventType.Evaluation
Utilice el método getVariation en su lugar.
El método getFeatureFlagVariationKey() recupera la clave de variación del visitorCode especificado en la feature flag correspondiente. Este método incluye una verificación de targeting, búsqueda de la variación apropiada expuesta al visitante, guardado en el almacenamiento y envío de una solicitud de seguimiento.
Si un usuario no ha sido previamente asignado a una clave de variación para la feature flag, el SDK determinará aleatoriamente una variación según las reglas de la feature flag. Si el usuario ya está vinculado a la feature flag, el SDK devolverá su clave de variación previamente asignada. Si el usuario no cumple con ninguna de las reglas especificadas, se devolverá el valor por defecto definido en las reglas de entrega de feature flags de Kameleoon. Este valor por defecto no siempre es una clave de variación—también puede ser un booleano u otro tipo de dato, según la configuración de la feature flag.
Parámetros
Valor de retorno
Excepciones lanzadas

getVisitorFeatureFlags()

Utilice el método getVariations en su lugar.
El método getVisitorFeatureFlags() devuelve una lista de feature flags que están activas para el visitante con el visitorCode especificado, asegurando que el visitante esté asignado a una de las variaciones.
  • 🚫 No envía Tracking Data a Kameleoon
  • 🎯 Eventos: EventType.Evaluation (para cada feature flag)
Este método solo recopila las feature flags activas del visitante, lo que significa que el resultado excluye todas las feature flags para las que el visitante está asignado a la variación off (por defecto o control).Por ejemplo:
Utilice getFeatureFlags cuando necesite todas las feature flags del visitante:
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 en su lugar.
El método getActiveFeatureFlags() devuelve un Map, donde la clave representa la clave de feature, y el valor contiene información detallada sobre la variación del visitante y sus variables.
Este método solo recopila las feature flags activas del visitante, lo que significa que el resultado excluye todas las feature flags para las que el visitante está asignado a la variación off (por defecto o control).Consulte la sección CAUTION 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 en su lugar.
El método getFeatureFlagVariable() recupera una variable para el visitante basándose en el visitorCode dentro de la feature flag identificada. Este método incluye una verificación de targeting, determina la variación apropiada para el visitante, la guarda en el almacenamiento y envía una solicitud de seguimiento.
Parámetros
Objeto de parámetros de tipo GetFeatureFlagVariableParamsType con 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 getVariation en su lugar.
El método getFeatureFlagVariables() recupera una lista de valores variables para un visitante y feature flag especificados. Este método verifica si el usuario está dirigido, identifica la variación asignada del visitante, la almacena y envía 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() ejecuta una devolución de llamada al actualizar la configuración del cliente.
Este método solo es aplicable a eventos enviados por el servidor para actualizaciones en tiempo real.
Parámetros
Excepciones lanzadas

getFeatureFlags()

Utilice el método getDataFile() en su lugar.
🚫 No envía Tracking Data a Kameleoon El método getFeatureFlags() recupera una lista de feature flags que se almacenan en la configuración del cliente.
Valor de retorno
Excepciones lanzadas

onEvent()

Utilice setEventHandler() en su lugar.
El método onEvent() dispara un callback cuando se activa un evento específico. La función callback accede a los datos asociados con el evento. El SDK proporciona métodos documentados que señalan qué tipos de eventos disparan, si los hay.
Solo puede asignar un callback a cada EventType.
Eventos
Los eventos se definen en la enumeración EventType. El parámetro eventData tendrá un tipo diferente según el tipo de evento.
Parámetros
Excepciones lanzadas