Skip to main content
Integrar el SDK en su aplicación es sencillo, y su huella (uso de memoria y de red) es reducida. Primeros pasos: Para obtener ayuda para comenzar, consulte la guía del desarrollador. Última versión: 0.8.5. Consulte el changelog del SDK de C++ para ver las notas de la versión, o el índice de changelogs de los SDKs para todos los SDKs. Métodos del SDK: Para la documentación de referencia completa del SDK de C++, consulte la sección referencia.

Guía del desarrollador

Esta guía está diseñada para ayudarle a integrar rápidamente el SDK de C++ y empezar a evaluar feature flags en su aplicación C++.

Primeros pasos

Instalar el cliente C++

El SDK de C++ es una biblioteca C++17 construida sobre el Kameleoon SDK Core, una biblioteca compartida nativa (libkameleoon_ffi) escrita en Rust que implementa el comportamiento del SDK. Su aplicación enlaza la biblioteca C++ de forma estática y carga la biblioteca core en tiempo de ejecución.
El Kameleoon SDK Core se compila desde el código fuente para su plataforma y arquitectura de destino. Asegúrese de que Rust y Cargo estén instalados y disponibles en el PATH de su sistema, e instale cbindgen, que genera el encabezado C de la biblioteca core:
Instale Rust y Cargo: https://rust-lang.org/tools/installLas versiones futuras proporcionarán bibliotecas core precompiladas para las plataformas más comunes a fin de simplificar la instalación. La compilación local seguirá estando disponible para los usuarios que prefieran compilar desde el código fuente.
Requisitos:
  • Un compilador C++17 (GCC, Clang o MSVC) y CMake 3.16 o posterior.
  • Rust 1.91 o posterior, Cargo y cbindgen para compilar la biblioteca SDK Core (libkameleoon_ffi.so en Linux, libkameleoon_ffi.dylib en macOS, kameleoon_ffi.dll con su biblioteca de importación kameleoon_ffi.dll.lib en Windows).
Clone el repositorio del SDK de C++ y compile la biblioteca core; a continuación, compile la biblioteca C++ contra ella:
Para integrar el SDK en su propio proyecto CMake, añada el directorio cpp/client con add_subdirectory() y enlace el target Kameleoon::CppClient. Apunte KAMELEOON_FFI_LIBRARY a la biblioteca core que compiló; el encabezado C se genera con cbindgen, o puede pasar uno existente con KAMELEOON_FFI_HEADER:
CMakeLists.txt
  • libkameleoon_ffi se carga en tiempo de ejecución: instálela en una ubicación estándar de bibliotecas o distribúyala junto a su ejecutable. En Linux y macOS, distribuirla junto al ejecutable requiere un RPATH de $ORIGIN o @loader_path (por ejemplo, set_target_properties(my_app PROPERTIES INSTALL_RPATH "$ORIGIN")). En Windows, copie kameleoon_ffi.dll junto a sus binarios.
  • Cuando crea un cliente, el SDK comprueba que la libkameleoon_ffi cargada coincide con la versión contra la que fue compilado y, en caso contrario, lanza una KameleoonException con ErrorCode::Internal. Actualice siempre la biblioteca C++ y la biblioteca core juntas.
  • Todos los tipos públicos del SDK residen en el espacio de nombres kameleoon. Incluya kameleoon/kameleoon.hpp para obtener toda la API pública.

Configuración adicional

Cree un archivo de configuración JSON (por ejemplo, client-cpp.json) para proporcionar las credenciales y personalizar el comportamiento del SDK. También puede descargar un archivo de configuración de ejemplo. El SDK de C++ puede configurarse con un archivo JSON cuya ruta se pasa a KameleoonClientFactory::create(), o rellenando directamente en el código una estructura KameleoonClientConfig. La siguiente tabla muestra las propiedades disponibles que puede establecer:

Inicializar el cliente Kameleoon

Una vez que haya instalado el SDK y configurado sus credenciales, cree un KameleoonClient mediante KameleoonClientFactory.
Los ejemplos de esta página utilizan los designated initializers de C++20 (GetVariationOptions{.track = false}) para rellenar las estructuras de configuración, opciones y datos del SDK. Con un compilador C++17, declare la estructura y establezca sus campos uno a uno.
Un KameleoonClient es el objeto principal utilizado para evaluar feature flags, añadir datos de visitantes y enviar solicitudes de seguimiento.
  • Se recomienda utilizar KameleoonClient como un objeto singleton, ya que actúa como puente entre su aplicación y la plataforma Kameleoon. Expone todos los métodos y propiedades necesarios para ejecutar experimentos de forma eficiente. KameleoonClient es de tipo move-only: manténgalo en un solo lugar y páselo por referencia.
  • El SDK de C++ se inicializa de forma asíncrona. Debe llamar a initialize() antes de depender de la evaluación de funcionalidades en código de producción.
  • Cada fallo del SDK se notifica como una KameleoonException. Envuelva las llamadas al SDK en bloques try/catch.

Activación de un feature flag

Asignar un ID único a un usuario
Para asignar un ID único a un usuario, puede utilizar el método get_visitor_code(). Si no existe un visitor code (procedente de la cookie de los encabezados de la solicitud), el método genera un ID único aleatorio o utiliza un default_visitor_code que usted haya generado. A continuación, el ID se establece en una cookie de los encabezados de la respuesta. Si utiliza Kameleoon en modo híbrido, llamar al método get_visitor_code() garantiza que el archivo de aplicación engine.js (anteriormente llamado kameleoon.js) y el SDK compartan el ID único (visitor code).
Recuperar la configuración de un 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 la variación de un feature flag para un usuario específico, debe utilizar el método get_variation() o is_feature_active() para recuperar la configuración según la feature_key. El método get_variation() gestiona tanto feature flags simples con estados ON/OFF como flags más complejos con múltiples variaciones. El método recupera la variación adecuada para el usuario comprobando las reglas de la funcionalidad, asignando la variación y devolviéndola según la feature_key y el visitor_code. Puede utilizar el método is_feature_active() para recuperar la configuración de un feature flag simple que solo tiene un estado ON u OFF, a diferencia de feature flags más complejos con múltiples variaciones u opciones de segmentación. Si su feature flag tiene variables asociadas (como comportamientos específicos vinculados a cada variación), get_variation() 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 feature flag segmenta al usuario, encuentra la variación asignada al visitante y la guarda en el almacenamiento. Cuando track=true, el SDK envía el evento de exposición al experimento especificado en la siguiente solicitud de seguimiento, que se activa automáticamente según el tracking_interval_millis del SDK. El intervalo predeterminado es de 1000 milisegundos (1 segundo). El método get_variation() le permite controlar si el SDK realiza el seguimiento del visitante. Si track=false, el SDK no envía eventos de exposición. Esta opción es útil si prefiere no realizar el seguimiento de datos a través del SDK y, en su lugar, confiar en el seguimiento del lado del cliente gestionado por el motor de Kameleoon, por ejemplo. Además, establecer track=false resulta útil al utilizar el método get_variations(), cuando es posible que solo necesite las variaciones de todos los flags sin activar ningún evento de seguimiento. Si desea saber más sobre cómo funciona el seguimiento, consulte este artículo
Añadir puntos de datos para segmentar a un usuario o filtrar / desglosar visitas en los informes
Para segmentar a un usuario, asegúrese de haber añadido los puntos de datos relevantes a su perfil antes de recuperar la variación de la funcionalidad o comprobar si el flag está activo. Utilice el método add_data() para añadir estos puntos de datos al perfil del usuario. Para recuperar puntos de datos recopilados en otros dispositivos o para acceder a datos pasados del usuario (recopilados del lado del cliente al utilizar Kameleoon en modo híbrido), utilice el método get_remote_visitor_data(). Este método obtiene los datos de los servidores de forma asíncrona. Es importante llamar a get_remote_visitor_data() antes de recuperar la variación o comprobar si el feature flag está activo, porque el SDK podría necesitar estos datos para asignar un usuario a una variación determinada. Para obtener más información sobre las condiciones de segmentación disponibles, consulte el artículo detallado sobre el tema. Además, los puntos de datos que añada al perfil del visitante estarán disponibles al analizar sus experimentos, lo que le permitirá filtrar y desglosar sus resultados por factores como el dispositivo y el navegador. El modo híbrido de Kameleoon recopila automáticamente una variedad de puntos de datos del lado del cliente, lo que facilita el desglose de los resultados en función de estos puntos de datos recopilados previamente. Consulte la lista completa aquí. Si necesita realizar el seguimiento de puntos de datos adicionales más allá de los que se recopilan automáticamente, puede utilizar la funcionalidad de Custom Data de Kameleoon. Los custom data le permiten capturar y analizar información específica relevante para sus experimentos. No olvide llamar al método flush() para enviar los datos recopilados a los servidores de Kameleoon para su análisis.
Para garantizar que sus resultados sean precisos, se recomienda filtrar los bots utilizando el tipo de datos UserAgent.
Seguimiento de conversiones de objetivos
Cuando un usuario completa una acción deseada (como realizar una compra), se registra como una conversión. Para realizar el seguimiento de las conversiones, utilice el método track_conversion() y proporcione los parámetros obligatorios visitor_code y goal_id. El SDK envía la solicitud de seguimiento de la conversión junto con la siguiente solicitud de seguimiento programada, que se produce a intervalos regulares (definidos por tracking_interval_millis). Si prefiere enviar la solicitud inmediatamente, utilice el método flush_instant().
Enviar eventos a soluciones de analítica
Para realizar el seguimiento de las conversiones y enviar eventos de exposición a su solución de analítica de clientes, primero debe implementar Kameleoon en modo híbrido. Después, utilice el método get_engine_tracking_code(). El método get_engine_tracking_code() recupera el código de seguimiento único necesario para enviar eventos de exposición a su solución de analítica. El uso de este método le permite registrar eventos y enviarlos a la plataforma de analítica que desee.

Gestión de errores

Cada error que lanza el SDK es una KameleoonException, por lo que un único manejador para ese tipo captura todos los fallos del SDK. Gestione un tipo de error específico cuando su aplicación necesite reaccionar a un fallo concreto, por ejemplo para recurrir a su comportamiento predeterminado cuando un feature flag no está en la configuración o el SDK aún no está inicializado. La sección de referencia de cada método enumera los errores que puede lanzar. KameleoonException deriva de std::runtime_error. Llame a code() para obtener el ErrorCode que distingue los errores, y a what() para obtener el mensaje.
Las cadenas que se pasan al SDK deben ser UTF-8 válido. Los callbacks que proporciona al SDK (las sobrescrituras de CookieAccessor, los manejadores de eventos y los loggers) no deben lanzar excepciones: cualquier excepción que escape de ellos se captura en el límite del SDK y se descarta.
Los errores del SDK son un comportamiento esperado, no fallos del programa: un feature flag que aún no está activado, un SDK que todavía está cargando su configuración o un fallo de red son condiciones normales. Cuando la evaluación de una funcionalidad falla, registre el error y recurra a su comportamiento predeterminado para que el visitante siga teniendo una experiencia funcional.

Operaciones asíncronas

Las operaciones que dependen de la red (initialize(), flush_instant(), get_remote_data(), get_remote_visitor_data() y get_visitor_warehouse_audience()) se ejecutan en el hilo de trabajo propio del SDK. Cada una está disponible en tres formas, de modo que pueda elegir la que mejor se adapte al hilo que realiza la llamada:
Un completion es un Completion<void> (std::function<void(std::exception_ptr)>), o un Completion<T> (std::function<void(std::exception_ptr, T)>) para las operaciones que devuelven un valor. El SDK lo invoca exactamente una vez. Puede omitir el completion para ejecutar la operación en modo fire-and-forget: los fallos solo aparecerán entonces en el log del SDK.
Los completions y los manejadores de eventos suelen ejecutarse en el hilo de trabajo del SDK, pero un completion también puede ejecutarse en el hilo que realiza la llamada, antes de que la llamada *_async retorne: por ejemplo, cuando el SDK falla rápidamente (el cliente no está listo, el visitor code no es válido) o cuando se llama a initialize_async() sobre un cliente que ya está inicializado. No asuma que un completion se ejecuta en un hilo concreto ni después de que la llamada retorne, y no mantenga un lock a través de la llamada que el completion también adquiere. Los completions y los manejadores de eventos no deben bloquear, no deben lanzar excepciones y no deben llamar a la forma bloqueante de una operación del SDK: esta espera al mismo hilo de trabajo y se produce un interbloqueo. Entregue el resultado a su propio event loop y termine el trabajo allí.
C++20 no tiene un tipo de tarea de corrutina integrado, por lo que co_await solo funciona dentro de una corrutina cuyo promise type acepte el Awaitable<T> del SDK (KAMELEOON_HAS_COROUTINES se define en kameleoon/async.hpp cuando las corrutinas están disponibles). De forma predeterminada, la corrutina se reanuda en el hilo de trabajo del SDK; llame a .via(executor) sobre el awaitable para reanudarla en su propio event loop. Los frameworks con sus propios tipos de corrutinas, como Boost.Asio, necesitan un pequeño adaptador alrededor de la forma completion; consulte el ejemplo de servidor incluido con el SDK.
Los métodos de evaluación (get_visitor_code(), get_variation(), get_variations(), is_feature_active(), add_data(), track_conversion() y flush()) son llamadas síncronas en memoria y no necesitan nada de esto.

Uso de una clave de bucketing personalizada

De forma predeterminada, Kameleoon utiliza un ID de visitante único y anónimo (visitor_code) para asignar a los usuarios a las variaciones de los feature flags. Este ID normalmente se genera y se almacena en el dispositivo del usuario (en una cookie del navegador para los SDKs del lado del cliente y del lado del servidor, y en almacenamiento persistente para los SDKs móviles). Sin embargo, en determinados escenarios puede necesitar garantizar que todos los usuarios de la misma organización vean la misma variante de un feature flag. La opción de clave de bucketing personalizada le permite anular este comportamiento predeterminado proporcionando su propio identificador personalizado para el bucketing. Esta anulación garantiza que la lógica de asignación de Kameleoon utilice la clave que usted especifique en lugar del visitor_code predeterminado.

Casos de uso

Utilizar una clave de bucketing personalizada es esencial para mantener la coherencia y la precisión en las asignaciones de sus feature flags, especialmente 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 account_id. Las claves de bucketing personalizadas son cruciales para las pruebas A/B de funcionalidades que afectan a todo un equipo o empresa.
Al implementar una clave de bucketing personalizada, garantiza una mayor coherencia y precisión en sus experimentos, lo que conduce a resultados más fiables y a 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: Proporciona su identificador personalizado al SDK de Kameleoon mediante el método add_data(). En este método, pasará la clave de bucketing personalizada elegida como un objeto CustomData. Aquí, new_visitor_code hace referencia al identificador que desea utilizar para su bucketing (por ejemplo, el nuevo user_id o account_id).
Para que la clave de bucketing personalizada funcione correctamente, también debe definirla y configurarla 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 obtener instrucciones detalladas sobre cómo configurarlo en Kameleoon, consulte este artículo.
  • Lógica de bucketing: Una vez que proporciona una clave de bucketing personalizada mediante el método add_data(), todos los cálculos de hash para asignar usuarios a variaciones utilizan este new_visitor_code (su clave personalizada) en lugar del visitor_code predeterminado. El uso del new_visitor_code significa que la decisión de bucketing depende de su identificador personalizado, lo que garantiza asignaciones coherentes en los distintos contextos donde ese identificador esté presente.
  • Seguimiento de datos y analítica: Es crucial tener en cuenta que, aunque el new_visitor_code (su clave personalizada) se utiliza para las decisiones de bucketing, el SDK envía todos los datos posteriores (eventos de seguimiento y conversiones, por ejemplo) y los asocia con el visitor_code original. Esta separación garantiza que su analítica refleje con precisión los recorridos e interacciones individuales de los usuarios dentro del contexto más amplio de su experimento, incluso cuando realiza el bucketing a un nivel superior (como una cuenta) o entre varios dispositivos/sesiones. Los datos originales de sus visitantes permanecen intactos para disponer de informes completos.

Requisitos técnicos

Para utilizar eficazmente una clave de bucketing personalizada:
  • La clave debe ser una std::string.
  • Debe ser única para la entidad sobre la que desea hacer bucketing (por ejemplo, si utiliza un user_id, el ID de cada usuario debe ser único).
  • La clave debe estar disponible para el SDK en el momento exacto en que 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 a los usuarios en sus campañas. Para ver la lista de condiciones que admite este SDK, consulte utilizar el historial de visitas para segmentar a los usuarios. También puede utilizar sus propios datos externos para segmentar a los usuarios.

Experimentación cross-device

Para dar soporte a los visitantes que acceden a una aplicación desde varios dispositivos, Kameleoon permite sincronizar los datos de visitante recopilados previamente en cada uno de los dispositivos del visitante y reconciliar su historial de visitas entre dispositivos mediante la experimentación cross-device. Encontrará casos prácticos e información detallada sobre cómo Kameleoon gestiona los datos entre dispositivos en el artículo sobre experimentación cross-device.

Sincronizar custom data entre dispositivos

Aunque la sincronización de mapeo personalizado alinea los datos de los visitantes entre dispositivos, no siempre es necesaria. A continuación se muestran dos escenarios en los que la sincronización de mapeo personalizado no es necesaria: Mismo ID de usuario en todos los dispositivos Si utiliza el mismo ID de usuario de forma coherente en todos los dispositivos, el SDK gestiona la sincronización automáticamente sin una sincronización de mapeo personalizado. Basta con llamar al método get_remote_visitor_data() cuando desee sincronizar los datos recopilados entre varios dispositivos. Instancias multiservidor con IDs coherentes En configuraciones complejas con varios servidores (por ejemplo, instancias de servidor distribuidas), donde el mismo ID de usuario está disponible en todos los servidores, la sincronización entre servidores (con get_remote_visitor_data()) es suficiente sin una sincronización de mapeo personalizado adicional. Los clientes que necesiten datos adicionales pueden consultar la descripción del método get_remote_visitor_data() para obtener más orientación. En el siguiente código, se asume que utiliza el mismo identificador único (en este caso, el visitor_code, también conocido como userId) de forma coherente entre los dos dispositivos para una recuperación precisa de los datos.
Si desea sincronizar los datos recopilados en tiempo real, debe elegir el ámbito Visitor para sus custom data.
Device A
Device B

Uso de custom data para la fusión de sesiones

La experimentación cross-device permite combinar el historial de un visitante en cada uno de sus dispositivos (reconciliación del historial). La reconciliación del historial permite fusionar diferentes sesiones del visitante en una sola. Para reconciliar el historial de visitas, utilice CustomData para proporcionar un identificador único para el visitante. Para obtener más información, consulte la documentación específica. Después de habilitar la reconciliación cross-device, llamar a get_remote_visitor_data() con el parámetro userId recupera todos los datos conocidos de un usuario determinado. Las sesiones con el mismo identificador siempre ven la misma variación en un experimento. En la vista Visitor de las páginas de resultados de su experimento, estas sesiones aparecerán como un único visitante. La configuración del SDK garantiza que las sesiones asociadas siempre vean la misma variación del experimento. Sin embargo, existen algunas limitaciones en cuanto a la asignación de variaciones cross-device. La documentación de experimentación cross-device describe estas limitaciones. Siga la guía de activación de la reconciliación del historial cross-device para configurar sus custom data en la plataforma Kameleoon. Después, puede utilizar el SDK con normalidad. Los siguientes métodos pueden resultar útiles en el contexto de la fusión de sesiones:
  • get_remote_visitor_data() con el dato UniqueIdentifier(true) añadido - para recuperar los datos de todos los visitantes vinculados.
  • track_conversion() o flush() con el dato UniqueIdentifier(true) añadido - para realizar el seguimiento de datos de un visitante específico que está asociado con otro visitante.
Dado que los custom data que utiliza como identificador requieren el ámbito Visitor, debe utilizar la sincronización de custom data cross-device para recuperar el identificador con el método get_remote_visitor_data() en cada dispositivo.
A continuación se muestra un ejemplo de cómo utilizar custom data para la fusión de sesiones.
En este ejemplo, la aplicación tiene una página de inicio de sesión. Como el ID de usuario es desconocido en el momento del inicio de sesión, la aplicación utiliza un identificador de visitante anónimo generado por el método get_visitor_code(). Después de que el usuario inicie sesión, la aplicación asocia el visitante anónimo con el ID de usuario y lo utiliza como identificador único del visitante.

Registro de eventos

El SDK genera logs para reflejar diversos procesos e incidencias internos.

Niveles de log

El SDK admite la configuración del logging limitándolo por nivel de log.

Gestión personalizada de los logs

De forma predeterminada, el SDK escribe sus logs en la salida de consola. Este comportamiento puede sobrescribirse.
El SDK limita el logging por nivel de log de forma independiente de la lógica de gestión de logs.

Referencia

Esta es la documentación de referencia completa del SDK de C++.

Inicialización

create()

Para utilizar el SDK, cree un KameleoonClient con KameleoonClientFactory::create(), ya sea a partir de una estructura KameleoonClientConfig o de un archivo de configuración JSON. Los clientes se almacenan en caché por site code y entorno: las llamadas repetidas a create() con el mismo site code y entorno devuelven clientes sobre la misma instancia subyacente del SDK, y prevalece la configuración de la primera llamada.
Parámetros
Valor devuelto
Excepciones

initialize()

Utilice initialize() cuando su aplicación deba esperar a que el cliente Kameleoon termine la inicialización antes de evaluar feature flags. La llamada devuelve el resultado de la obtención de la configuración: se completa correctamente cuando el cliente termina de inicializarse, y falla si la obtención inicial de la configuración falla antes de que el cliente esté listo. Los reintentos en segundo plano continúan después de ese primer fallo. Una vez que un reintento tiene éxito, las llamadas posteriores devuelven un resultado satisfactorio. Si no hay ningún resultado de inicialización disponible antes de que expire el tiempo de espera, la llamada falla. Si no proporciona un valor de timeout, el SDK utiliza el tiempo de espera predeterminado de default_timeout_millis.
Llame a initialize() una vez al arrancar la aplicación para esperar hasta que el SDK haya cargado su configuración o expire el tiempo de espera. En cada solicitud entrante, utilice is_ready() como protección no bloqueante antes de evaluar feature flags. Incluso si initialize() falla, el SDK sigue reintentando la obtención de la configuración en segundo plano, por lo que is_ready() empieza a devolver true cuando un reintento tiene éxito.
Parámetros
Valor devuelto
Excepciones

is_ready()

is_ready() comprueba si el SDK está listo para su uso, lo que significa que su configuración se ha cargado correctamente. A diferencia de initialize(), este método retorna inmediatamente sin bloquear ni lanzar excepciones.
  • Una vez que el SDK está listo, permanece listo. Si una actualización posterior de la configuración falla, el SDK sigue utilizando la configuración descargada previamente y no vuelve a un estado de no listo.
  • Llame a initialize() una vez al arrancar la aplicación para esperar hasta que el SDK haya cargado su configuración o expire el tiempo de espera. En cada solicitud entrante, utilice is_ready() como protección no bloqueante antes de evaluar feature flags. Incluso si initialize() falla, el SDK sigue reintentando la obtención de la configuración en segundo plano, por lo que is_ready() empieza a devolver true cuando un reintento tiene éxito.
Valor devuelto

forget()

Elimina el cliente SDK en caché asociado al site_code especificado, de modo que la siguiente llamada a create() con el mismo site code y entorno cree uno nuevo. forget() solo elimina la referencia de la factoría. Cada KameleoonClient creado para ese site code mantiene viva la instancia subyacente del SDK (y su hilo de trabajo, polling y seguimiento) hasta que se destruye, y las operaciones asíncronas pendientes la mantienen viva hasta que sus completions terminan. Para liberar los recursos en segundo plano, llame a forget() y destruya todas las instancias de KameleoonClient de ese site code.
Parámetros

Feature flags y variaciones

is_feature_active()

  • 📨 Envía datos de seguimiento a Kameleoon (según la opción track)
Determina si un feature flag está activo para un usuario determinado. Si el visitante aún no ha sido evaluado para este feature flag, el SDK evalúa las reglas de segmentación y devuelve el resultado. Si el visitante ya tiene una evaluación almacenada para la funcionalidad, el SDK reutiliza el resultado existente para garantizar la coherencia.
Kameleoon utiliza el seguimiento para contar sesiones y visitantes cuando llama a determinados métodos, como is_feature_active(), get_variation() o get_variations().Utilice el valor predeterminado true para el parámetro track cuando exponga a los 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 a los visitantes.Por ejemplo, si llama a get_variations() para recuperar todas las variaciones antes de exponer a los visitantes, establezca el parámetro track en false. Esta configuración evita que Kameleoon cuente prematuramente una sesión. Después puede activar el seguimiento más adelante, cuando exponga explícitamente al visitante.Kameleoon envía los datos de seguimiento cada segundo de forma predeterminada. Puede configurar este intervalo hasta 5 segundos mediante la opción de configuración del intervalo de seguimiento. Kameleoon agrupa los eventos de seguimiento en una única sesión siempre que el intervalo entre eventos sea inferior 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 is_feature_active() evalúa la variante servida, no el estado del flag maestro. Si excluye reglas, el método utiliza el estado predeterminado Then, for everyone else serve. Si selecciona Off para este estado predeterminado, el método siempre devuelve false, incluso cuando el feature flag maestro está en On.
Parámetros
Valor devuelto
Excepciones

get_variation()

  • 📨 Envía datos de seguimiento a Kameleoon (según el parámetro track)
Recupera la Variation asignada a un visitante determinado para un feature flag específico. Este método toma un visitor_code y una feature_key como argumentos obligatorios. El argumento track es opcional y su valor predeterminado es true. Devuelve la Variation asignada al visitante. Si el visitante no está asociado a ninguna regla del feature flag, el método devuelve la Variation predeterminada para el feature flag dado. Asegúrese de que su código incluye una gestión de errores adecuada para manejar posibles excepciones.
La variación predeterminada hace referencia a la variación asignada a un visitante cuando no coincide con ninguna regla de entrega predefinida de un feature flag. En otras palabras, es la variación de respaldo que se aplica a todos los usuarios que no están segmentados por reglas específicas. Se representa como la variación de la sección “Then, for everyone else…” en la interfaz de administración.
Parámetros
El parámetro opcional track se pasa como el campo track de una estructura GetVariationOptions.
Valor devuelto
Excepciones

get_variations()

  • 📨 Envía datos de seguimiento a Kameleoon (según el parámetro track)
Recupera un mapa de objetos Variation asignados a un visitante determinado en todos los feature flags. Este método itera sobre todos los feature flags disponibles y devuelve la Variation asignada para cada flag asociado al visitante especificado. Toma visitor_code como argumento obligatorio, mientras que only_active y track son opcionales.
  • Si establece only_active en true, el método get_variations() devuelve las variaciones de los feature flags solo si el visitante no está asignado a la variación off.
  • El parámetro track controla si el método realiza el seguimiento de las asignaciones de variaciones. De forma predeterminada, es true. Si es false, el método no realiza el seguimiento de las asignaciones de variaciones.
El mapa devuelto está formado por las claves de los feature flags como claves y su Variation correspondiente como valores. Si el SDK no asigna ninguna variación para un feature flag, el método devuelve la Variation predeterminada de ese flag. Implemente una gestión de errores adecuada para manejar posibles excepciones.
La variación predeterminada hace referencia a la variación asignada a un visitante cuando no coincide con ninguna regla de entrega predefinida de un feature flag. En otras palabras, es la variación de respaldo que se aplica a todos los usuarios que no están segmentados por reglas específicas. Se representa como la variación de la sección “Then, for everyone else…” en la interfaz de administración.
Parámetros
Los parámetros opcionales only_active y track se pasan como los campos de una estructura GetVariationsOptions.
Valor devuelto
Excepciones

set_forced_variation()

Este método le permite asignar mediante programación una Variation específica a un usuario, omitiendo el proceso de evaluación estándar. El método es especialmente valioso para experimentos controlados donde la lógica de evaluación habitual no es necesaria o debe omitirse. También puede ser útil en escenarios como la depuración o las pruebas personalizadas. Cuando establece una variación forzada, esta anula la lógica de evaluación en tiempo real de Kameleoon. El SDK omite procesos como la segmentación, las condiciones de segmentación y los cálculos algorítmicos. Para conservar la segmentación y las condiciones de segmentación durante un experimento, establezca force_targeting=false en su lugar.
Las variaciones simuladas siempre tienen prioridad en el orden de ejecución. Si comienza el cálculo de una variación simulada, el SDK la procesa y la completa totalmente primero.
Kameleoon trata una variación forzada igual que una variación evaluada. Se registra en la analítica y se almacena en el contexto del usuario como cualquier variación evaluada estándar, lo que garantiza la coherencia en los informes. El método puede lanzar excepciones en determinadas condiciones (por ejemplo, parámetros no válidos, contexto de usuario o problemas internos). Una gestión adecuada de las excepciones es esencial para garantizar que su aplicación permanezca 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 al resultado global del feature flag.
Parámetros
El parámetro opcional force_targeting se pasa como el campo force_targeting de una estructura SetForcedVariationOptions.
Excepciones

evaluate_audiences()

  • 📨 Envía datos de seguimiento a Kameleoon
Este método evalúa a los visitantes con respecto a todos los segmentos disponibles de Audiences Explorer y realiza el seguimiento de los que coinciden. Llame a evaluate_audiences() después de establecer o actualizar todos los datos relevantes del visitante, y justo antes de obtener la variación de una funcionalidad o comprobar un feature flag. Este enfoque garantiza que Kameleoon evalúe al visitante con los datos más actuales disponibles, lo que permite una asignación de audiencias precisa basada en todos los criterios. Después de llamar a este método, puede realizar un análisis detallado del rendimiento de los segmentos en Audiences Explorer.
Parámetros
Excepciones
En la mayoría de los casos, solo necesita gestionar el error básico, KameleoonException, como muestra el ejemplo. Sin embargo, si distintos tipos de errores requieren una respuesta, gestione cada uno por separado según los requisitos específicos. Además, para una mayor fiabilidad, puede gestionar los errores generales del lenguaje incluyendo std::exception.

get_datafile()

Para evaluar todos los feature flags, utilice get_variations(). Este método es más eficiente que llamar a DataFile e iterar por los flags con get_variation().
Devuelve la configuración actual del SDK como un objeto DataFile. El DataFile devuelto es una copia de la configuración actual: no cambia cuando el SDK actualiza su configuración.
Valor devuelto
Excepciones

Datos del visitante

get_visitor_code()

Utilice get_visitor_code() para obtener el visitor_code de Kameleoon del visitante actual. El método funciona con cualquier almacén de cookies que implemente la interfaz CookieAccessor. La lógica de implementación es la siguiente:
  1. El SDK comprueba si ya hay una cookie kameleoonVisitorCode disponible a través del accessor proporcionado.
  2. Si la cookie no existe, el SDK utiliza default_visitor_code si usted proporciona uno.
  3. En caso contrario, el SDK genera un nuevo visitor code y lo almacena a través del accessor.
Para obtener más información, consulte Experimentación híbrida.
Si proporciona su propio visitor_code, su unicidad debe garantizarse por su parte. Tenga en cuenta también que la longitud del visitor_code está limitada a 255 caracteres.
El método get_visitor_code() le permite establecer variaciones simuladas para un visitante. Cuando las cookies (de una solicitud o un documento) contienen la clave kameleoonSimulationFFData, el método lee la cookie y almacena las variaciones simuladas para ese visitante; su valor devuelto no cambia. Las evaluaciones de funcionalidades posteriores para el visitante, como get_variation() e is_feature_active(), omiten entonces el proceso de evaluación estándar y devuelven la Variation simulada según los datos proporcionados.Puede aplicar simulaciones de dos maneras:
  • Automáticamente (recomendado): Si utiliza Kameleoon Web Experimentation o el SDK en modo híbrido, Kameleoon crea la cookie automáticamente cuando simula la visualización de una variante mediante el panel de simulación.
  • Manualmente: Establezca la cookie kameleoonSimulationFFData manualmente.
Es importante distinguir las variaciones simuladas de las variaciones forzadas:
  • Variaciones simuladas: Afectan al resultado global del feature flag.
  • Variaciones forzadas: Son específicas de un experimento individual.
⚙️ Configuración manualAsegúrese de que la cookie kameleoonSimulationFFData sigue este formato:
  • kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: Simula la variación con varId del experimento expId para la featureKey dada.
  • kameleoonSimulationFFData={"featureKey":{"expId":0}}: Simula la variación predeterminada (definida en la sección Then, for everyone else in Production, serve) para la featureKey dada.
⚠️ Para garantizar que el valor de la cookie funcione correctamente, codifíquelo como componente URI utilizando un método como encodeURIComponent.
Interfaz CookieAccessor
Implemente kameleoon::CookieAccessor para conectar las lecturas y escrituras de cookies del SDK con su framework HTTP:
  • get() debe devolver una cookie ya escrita mediante set() en la respuesta con preferencia sobre la cookie de la solicitud con el mismo nombre. El SDK no mantiene ningún estado de cookies entre llamadas, por lo que esto es lo que hace que una segunda llamada a get_visitor_code() dentro de la misma solicitud devuelva el código escrito por la primera en lugar de generar uno nuevo.
  • Las sobrescrituras se invocan desde el interior del SDK y no deben lanzar excepciones. Una excepción que escape de get() se trata como una cookie ausente. Los valores de las cookies deben ser UTF-8 válido.
Parámetros
Valor devuelto
Excepciones

add_data()

El método add_data() añade datos de segmentación al almacenamiento para que otros métodos puedan utilizar los datos a la hora de decidir si segmentar o no al visitante actual. El método add_data() no devuelve ningún valor y no interactúa por sí mismo con los servidores backend de Kameleoon. En su lugar, el SDK guarda todos los datos declarados para su transmisión futura mediante el método flush(). Este enfoque reduce el número de llamadas al servidor, ya que los datos normalmente se agrupan en una única llamada al servidor activada por flush(). El método track_conversion() también envía cualquier dato asociado previamente, igual que flush(). Lo mismo ocurre con los métodos get_variation() y get_variations() si se activa una regla de experimentación.
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 asociada por índice.
El parámetro data es un std::vector<Data>, donde Data es un std::variant de todos los tipos de datos. Cada tipo de dato se convierte implícitamente a Data, por lo que puede pasar una lista entre llaves de objetos de datos.
Parámetros
Excepciones

flush()

  • 📨 Envía datos de seguimiento a Kameleoon
El método flush() agrega todos los datos de Kameleoon asociados a un visitante y envía una solicitud de seguimiento al servidor. Esta solicitud incluye cualquier dato añadido previamente mediante el método add_data que aún no se haya transmitido a través de otros mecanismos de seguimiento (consulte los métodos mencionados para más detalles). La operación flush() es no bloqueante, ya que la llamada al servidor se realiza de forma asíncrona. Este método proporciona control sobre cuándo se transmiten los datos vinculados a un visitor_code específico. Por ejemplo, si se llama a add_data() varias veces, enviar una solicitud después de cada invocación sería ineficiente. En su lugar, puede agrupar estas actualizaciones y llamar a flush() una sola vez para enviar todos los datos acumulados en una única solicitud. El método flush() utiliza el visitor_code proporcionado como identificador único del visitante.
  • flush(): Pone en cola una operación de flush según el intervalo de seguimiento configurado.
  • flush_instant(): Envía los datos de seguimiento inmediatamente sin esperar al intervalo.
Parámetros
Excepciones

get_remote_data()

El método get_remote_data() le permite recuperar datos remotos almacenados en los servidores de Kameleoon para la key especificada. En la mayoría de las configuraciones, estos datos se escriben a través de la Data API de Kameleoon y su servicio C++ puede recuperarlos más tarde siempre que necesite contexto adicional de la aplicación. Este método es útil cuando desea mantener información estructurada en la infraestructura remota de Kameleoon y reutilizarla desde su back-end sin mantener un mecanismo de recuperación independiente.
Parámetros
Valor devuelto
Excepciones

get_remote_visitor_data()

get_remote_visitor_data() recupera los datos de visita de Kameleoon para el visitor_code proporcionado. El método añade los datos al almacenamiento local del visitante para que otros métodos del SDK puedan utilizarlos en las decisiones de segmentación. Los datos obtenidos con este método son especialmente útiles cuando desea:
  • utilizar datos recopilados desde otros dispositivos.
  • acceder al historial de un visitante, como las páginas vistas en visitas anteriores.
  • utilizar datos que solo están disponibles del lado del cliente, como variables del datalayer y conversiones de objetivos del front-end.
Lea este artículo para comprender mejor los posibles casos de uso.
De forma predeterminada, get_remote_visitor_data() recupera automáticamente los últimos custom data almacenados con scope=Visitor y los asocia al visitante sin necesidad de llamar a add_data(). Esto es especialmente útil para sincronizar custom data entre varios dispositivos.
Parámetros
Excepciones
Uso de parámetros en get_remote_visitor_data()
El método get_remote_visitor_data() le permite controlar qué datos se recuperan para un visitante. El mismo enfoque de filtrado funciona para objetivos, experimentos, variaciones y otros datos del visitante. Por ejemplo, si desea segmentar a los usuarios que convirtieron en un objetivo durante sus últimas cinco visitas, puede establecer previous_visit_amount en 5 y conversions en true. La flexibilidad que muestra este ejemplo no se limita a los datos de objetivos. Puede utilizar el filtro para recuperar muchos comportamientos diferentes del visitante y ponerlos a disposición de la lógica de segmentación e informes de su aplicación C++.
Campos de RemoteVisitorDataFilter

get_visitor_warehouse_audience()

Este método recupera los datos de audiencia asociados a un visitante en su integración de warehouse utilizando el visitor_code especificado y, opcionalmente, una warehouse_key. La warehouse_key suele ser su ID de usuario interno. El parámetro custom_data_index corresponde al custom data de Kameleoon que Kameleoon utiliza para segmentar a sus visitantes. Cuando la llamada tiene éxito, el SDK convierte la lista de audiencias devuelta en CustomData, la añade al visitante localmente y la pone a disposición con fines de segmentación. Para obtener más contexto, consulte la documentación de segmentación por warehouse.
Parámetros
Excepciones
Debe utilizar este método para especificar si el visitante ha dado su consentimiento legal para el uso de datos personales. Establecer consent en false limita los tipos de datos que pueden incluirse en las solicitudes de seguimiento. Esto le ayuda a cumplir los requisitos legales y normativos mientras gestiona de forma responsable los datos de los visitantes. Para obtener más información, consulte la política de gestión del consentimiento. Si pasa un CookieAccessor, el SDK también actualiza las cookies del visitante según el estado del consentimiento.
Parámetros
Excepciones
Comportamiento al revocar el consentimiento
Cuando llama a set_legal_consent() con consent=false, el SDK no elimina la cookie kameleoonVisitorCode. En su lugar, deja de ampliar la fecha de expiración de la cookie, permitiendo que la cookie persista hasta que expire de forma natural. Si sus requisitos de cumplimiento exigen la eliminación inmediata del archivo de la cookie al darse de baja, 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

track_conversion()

  • 📨 Envía datos de seguimiento a Kameleoon
Utilice este método para realizar el seguimiento de una conversión para un objetivo y un usuario específicos. Este método requiere visitor_code y goal_id. Además, este método también acepta los argumentos opcionales revenue, negative y metadata. El visitor_code suele ser idéntico al que utilizó al activar el experimento.
Este método es no bloqueante porque el SDK realiza la llamada al servidor de forma asíncrona.
Parámetros
Los parámetros opcionales revenue, negative y metadata se pasan como los campos de una estructura TrackConversionOptions.
Los valores de metadata son accesibles mediante las exportaciones de datos sin procesar y la página de resultados.Si proporciona el parámetro metadata, Kameleoon utiliza estos valores especificados para la conversión actual en lugar de los que recopiló previamente con el método add_data(). Si omite el parámetro, Kameleoon utiliza los últimos valores registrados de esos CustomData antes de la conversión y dentro de la misma visita.Kameleoon solo tendrá en cuenta los valores de metadata que se pasen explícitamente como parámetros al método track_conversion().En el siguiente ejemplo, Kameleoon asociará la conversión únicamente con el valor de custom data proporcionado explícitamente como parámetro (aquí: el índice 5 con el valor ‘Amex Credit Card’).
Excepciones

get_engine_tracking_code()

Kameleoon se integra con varias soluciones de analítica, como Mixpanel, Google Analytics 4 y Segment. Para realizar correctamente el seguimiento de los experimentos del lado del servidor, llame al método get_engine_tracking_code() después de que el visitante active un experimento. El SDK devuelve comandos de cola de JavaScript para los experimentos que el visitante activó durante los 5 segundos anteriores. 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 analítica activa. Consulte experimentación híbrida para obtener más información sobre la implementación de este método.
  • Para utilizar esta funcionalidad, implemente tanto el SDK de C++ como Engine.js de Kameleoon. Dado que este flujo utiliza Engine.js solo para el seguimiento, puede instalar la etiqueta asíncrona antes de la etiqueta de cierre </body>.
  • Si solo desea realizar el seguimiento de los experimentos en Kameleoon y no necesita enviar eventos de exposición a herramientas de analítica de terceros, utilice el SDK de JavaScript / TypeScript. Esta opción funciona bien para las plataformas serverless de edge compute. El SDK de JavaScript / TypeScript realiza automáticamente el seguimiento de las variaciones cuando llama a getVisitorCode, siempre que añada las asignaciones de experimentos correspondientes a window.kameleoonQueue.
  • Puede insertar el código de seguimiento devuelto directamente en una etiqueta HTML <script>.
En este ejemplo, 123456 y 234567 son IDs de experimentos, y 7890 y 8901 son IDs de variaciones. En su implementación, el SDK genera estos valores en el código de seguimiento devuelto.
Parámetros
Valor devuelto
Excepciones

Eventos

set_event_handler()

Utilice este método para registrar un manejador de eventos del SDK. El SDK llama al manejador cuando se produce el evento seleccionado. El cliente mantiene como máximo un manejador por tipo de evento: registrar un nuevo manejador para el mismo tipo de evento sustituye al anterior. El constructor de EventHandler que utilice (EventHandler::datafile_update() o EventHandler::http_request()) selecciona el tipo de evento, por lo que un manejador y los eventos que recibe no pueden desincronizarse. Pasar un std::function vacío ({}) elimina el manejador actual para el tipo de evento seleccionado.
DataFileUpdateEvent contiene información sobre una actualización del archivo de datos del SDK.
Los manejadores se llaman de forma síncrona en el único hilo de trabajo del SDK, por lo que no deben bloquear: el tiempo que se pasa en un manejador retrasa el polling del archivo de datos y los envíos de seguimiento. Deben ser thread-safe y no deben lanzar excepciones: una excepción que escape de un manejador se captura y se descarta, y nunca afecta al comportamiento del SDK. No llame a operaciones bloqueantes del SDK desde un manejador; utilice las formas *_async y termine el trabajo en un hilo de la aplicación.Una invocación ya en curso puede terminar después de que elimine el manejador o destruya el cliente, y el manejador (con sus capturas) se destruye en un hilo del SDK una vez que ya no se utiliza. Mantenga los objetos capturados vivos y thread-safe en consecuencia. Un manejador puede eliminarse o sustituirse a sí mismo.Todas las instancias de KameleoonClient creadas para el mismo site code y entorno comparten un manejador por tipo de evento: prevalece el último manejador establecido, y destruir cualquiera de esas instancias lo elimina. Mantenga una única instancia de cliente por site code y entorno.
Parámetros

Tipos de datos

Esta sección enumera los tipos de datos de C++ declarados por el SDK en el espacio de nombres kameleoon (kameleoon/data/*.hpp). Todos ellos son estructuras simples que se pasan a add_data().

ApplicationVersion

ApplicationVersion representa el número de versión semántica de su aplicación.
Un visitante solo puede tener una ApplicationVersion. Añadir una segunda instancia sobrescribirá la primera.

Browser

El conjunto de datos Browser almacenado aquí puede utilizarse para filtrar los informes de experimentos y personalizaciones por cualquier valor asociado a él.

Conversion

El conjunto de datos Conversion almacenado aquí puede utilizarse para filtrar los informes de experimentos y personalizaciones por cualquier objetivo asociado a él.
  • Cada visitante puede tener varios objetos Conversion.
  • Puede encontrar el goal_id en la aplicación de Kameleoon.
Cookie contiene información sobre las cookies almacenadas en el dispositivo del visitante.
Cada visitante solo puede tener una Cookie. Añadir una segunda Cookie sobrescribe la primera.

CustomData

CustomData permite asociar cualquier tipo de datos a cada visitante, lo que lo convierte en una herramienta eficaz para las condiciones de segmentación en los segmentos. Además, puede utilizarse como filtro o desglose en los informes de experimentos. Para obtener más información sobre los custom data, consulte este artículo. Defina los tipos de custom data en la aplicación de Kameleoon o en la Data API y utilícelos desde el SDK. CustomData tiene dos constructores: uno identifica el custom data por su id (índice) y el otro por su name.
  • Cada visitante solo puede tener un CustomData por cada id (name) único. Añadir otro CustomData con el mismo id (name) sustituirá al existente.
  • El ‘índice’ del custom data puede encontrarse en el panel de Custom Data, en la columna “INDEX”.
  • Para evitar que el SDK envíe los datos con el índice seleccionado a los servidores de Kameleoon por motivos de privacidad, active la opción: Use this data only locally for targeting purposes al crear el custom data.
  • Añadir una instancia de 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

Puede utilizar los datos del dispositivo para filtrar los informes de experimentos y personalizaciones por cualquier valor asociado.

Geolocation

Geolocation contiene los detalles de geolocalización del visitante.
  • Cada visitante solo puede tener una Geolocation. Añadir una segunda Geolocation sobrescribe la primera.

OperatingSystem

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

PageView

Almacena eventos de páginas vistas.
El índice del referrer está disponible en la aplicación de Kameleoon en la página de configuración del canal de adquisición. Tenga cuidado: el índice empieza en 0, por lo que el primer canal de adquisición que cree tiene el ID 0, no 1.

UniqueIdentifier

Si no añade UniqueIdentifier para un visitante, el visitor_code se utiliza como identificador único del visitante, lo cual es útil para la experimentación cross-device. Cuando añade UniqueIdentifier{true}, el SDK vincula los datos enviados con el visitante asociado al identificador especificado. Esto puede ser útil en situaciones en las que no puede acceder al visitor_code anónimo asignado originalmente a un visitante, pero sí tiene acceso a un identificador interno conectado a ese visitante mediante la fusión de sesiones.

UserAgent

Los experimentos del lado del servidor tienen más probabilidades de verse afectados por el tráfico de bots que los experimentos del lado del cliente. Kameleoon utiliza la lista IAB/ABC International Spiders and Bots List para reconocer los bots y spiders conocidos, y también utiliza el campo UserAgent para filtrar otro tráfico no deseado que podría distorsionar sus métricas de conversión. Para obtener más información, consulte el artículo de ayuda sobre el filtrado de bots. Si utiliza bots internos, envíe el valor de user-agent curl/8.0 para excluirlos de la analítica.

Tipos devueltos

DataFile

El DataFile contiene los detalles de la configuración del SDK. Puede ampliarse con información adicional si los clientes lo requieren. Si necesita más detalles, póngase en contacto con su Customer Success Manager.

FeatureFlag

El FeatureFlag representa un conjunto de propiedades que definen el propio feature flag (por ejemplo, sus Variations, Rules, el estado del entorno y otros detalles relacionados). Puede ampliarse con información adicional si los clientes lo requieren. Si necesita más detalles, póngase en contacto con su Customer Success Manager.

Rule

La Rule representa un conjunto de propiedades que definen la propia regla (por ejemplo, sus Variations). Puede ampliarse con información adicional si los clientes lo requieren. Si necesita más detalles, póngase en contacto con su Customer Success Manager.

Variation

Variation contiene información sobre la variación asignada al visitante, o la variación predeterminada cuando no existe una asignación específica.
  • Variation describe la variación asignada o predeterminada, mientras que Variable contiene los detalles de cada variable individual.
  • id y experiment_id pueden ser std::nullopt, lo que indica una variación predeterminada que no está vinculada a una asignación de experimento específica.
Métodos auxiliares adicionales:

Variable

Variable contiene información sobre una variable asociada a la variación asignada.
JsonValue
JsonValue representa el valor de una variable de variación en C++. El campo kind distingue los tipos que contienen cadenas; value es un std::variant<bool, double, std::string>. Los accesores tipados devuelven std::nullopt cuando el valor es de otro tipo: