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.
Requisitos:
- Un compilador C++17 (GCC, Clang o MSVC) y CMake 3.16 o posterior.
- Rust 1.91 o posterior, Cargo y
cbindgenpara compilar la biblioteca SDK Core (libkameleoon_ffi.soen Linux,libkameleoon_ffi.dyliben macOS,kameleoon_ffi.dllcon su biblioteca de importaciónkameleoon_ffi.dll.liben Windows).
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_ffise 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$ORIGINo@loader_path(por ejemplo,set_target_properties(my_app PROPERTIES INSTALL_RPATH "$ORIGIN")). En Windows, copiekameleoon_ffi.dlljunto a sus binarios.- Cuando crea un cliente, el SDK comprueba que la
libkameleoon_fficargada coincide con la versión contra la que fue compilado y, en caso contrario, lanza unaKameleoonExceptionconErrorCode::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. Incluyakameleoon/kameleoon.hpppara 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 unKameleoonClient mediante KameleoonClientFactory.
- Archivo de configuración
- Código
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.KameleoonClient es el objeto principal utilizado para evaluar feature flags, añadir datos de visitantes y enviar solicitudes de seguimiento.
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étodoget_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étodoget_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étodoadd_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étodotrack_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étodoget_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 unaKameleoonException, 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:
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.
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.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.
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 objetoCustomData. Aquí,new_visitor_codehace referencia al identificador que desea utilizar para su bucketing (por ejemplo, el nuevouser_idoaccount_id).
- 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 estenew_visitor_code(su clave personalizada) en lugar delvisitor_codepredeterminado. El uso delnew_visitor_codesignifica 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 elvisitor_codeoriginal. 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étodoget_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, utiliceCustomData 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 datoUniqueIdentifier(true)añadido - para recuperar los datos de todos los visitantes vinculados.track_conversion()oflush()con el datoUniqueIdentifier(true)añadido - para realizar el seguimiento de datos de un visitante específico que está asociado con otro visitante.
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 unKameleoonClient 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.
- create(config struct)
- create(config file)
Parámetros
Valor devuelto
Excepciones
initialize()
Utiliceinitialize() 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.
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.
Valor devuelto
forget()
Elimina el cliente SDK en caché asociado alsite_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)
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.Parámetros
Valor devuelto
Excepciones
get_variation()
- 📨 Envía datos de seguimiento a Kameleoon (según el parámetro
track)
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)
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_activeentrue, el métodoget_variations()devuelve las variaciones de los feature flags solo si el visitante no está asignado a la variaciónoff. - El parámetro
trackcontrola si el método realiza el seguimiento de las asignaciones de variaciones. De forma predeterminada, estrue. Si esfalse, el método no realiza el seguimiento de las asignaciones de variaciones.
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 unaVariation 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.
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
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()
Devuelve la configuración actual del SDK como un objetoDataFile.
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()
Utiliceget_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:
- El SDK comprueba si ya hay una cookie
kameleoonVisitorCodedisponible a través del accessor proporcionado. - Si la cookie no existe, el SDK utiliza
default_visitor_codesi usted proporciona uno. - En caso contrario, el SDK genera un nuevo visitor code y lo almacena a través del accessor.
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
kameleoonSimulationFFDatamanualmente.
- Variaciones simuladas: Afectan al resultado global del feature flag.
- Variaciones forzadas: Son específicas de un experimento individual.
kameleoonSimulationFFData sigue este formato:kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: Simula la variación convarIddel experimentoexpIdpara lafeatureKeydada.kameleoonSimulationFFData={"featureKey":{"expId":0}}: Simula la variación predeterminada (definida en la sección Then, for everyone else in Production, serve) para lafeatureKeydada.
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 medianteset()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 aget_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.
- Custom
- Drogon
Parámetros
Valor devuelto
Excepciones
add_data()
El métodoadd_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.
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
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.
Parámetros
Excepciones
get_remote_data()
El métodoget_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.
Parámetros
Excepciones
Uso de parámetros en get_remote_visitor_data()
El métodoget_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 elvisitor_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
set_legal_consent()
Debe utilizar este método para especificar si el visitante ha dado su consentimiento legal para el uso de datos personales. Establecerconsent 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 aset_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
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.
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étodoget_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 awindow.kameleoonQueue. - Puede insertar el código de seguimiento devuelto directamente en una etiqueta HTML
<script>.
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 deEventHandler 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.
- datafile_update
- http_request
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 nombreskameleoon (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.
Browser
El conjunto de datosBrowser almacenado aquí puede utilizarse para filtrar los informes de experimentos y personalizaciones por cualquier valor asociado a él.
Conversion
El conjunto de datosConversion almacenado aquí puede utilizarse para filtrar los informes de experimentos y personalizaciones por cualquier objetivo asociado a él.
Cookie
Cookie contiene información sobre las cookies almacenadas en el dispositivo del visitante.
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
CustomDatapor cadaid(name) único. Añadir otroCustomDatacon el mismoid(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
CustomDatacreada 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.
OperatingSystem
OperatingSystem contiene información sobre el sistema operativo del dispositivo del visitante.
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ñadeUniqueIdentifier 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 campoUserAgent 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
ElDataFile 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
ElFeatureFlag 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
LaRule 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.
Variationdescribe la variación asignada o predeterminada, mientras queVariablecontiene los detalles de cada variable individual.idyexperiment_idpueden serstd::nullopt, lo que indica una variación predeterminada que no está vinculada a una asignación de experimento específica.
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: