Guía del desarrollador
Esta sección muestra cómo integrar nuestro SDK e iniciar experimentos en sus aplicaciones Ruby. Siga este tutorial para configurar una prueba A/B simple que cambie el número de productos recomendados según diferentes variaciones.Primeros pasos
Instalar el SDK
Instale el SDK usando un paquete gem estándar, alojado en el repositorio oficial de RubyGems. Para instalar, ejecute el siguiente comando:Configurar el cliente
Proporciona credenciales para el SDK de Ruby usando un archivo de configuración, que también puede usar para personalizar el comportamiento del SDK. Puede comenzar con nuestro archivo de configuración de ejemplo. Recomendamos agregar este archivo a la ruta predeterminada/etc/kameleoon/client-ruby.yaml. Si usa otra ubicación, debe pasar la ruta como argumento al método Kameleoon::KameleoonClientFactory.Create() durante la inicialización. Estas son las claves disponibles en el SDK más reciente:
El SDK de Ruby de Kameleoon utiliza la API de Automation y sigue el flujo de credenciales de cliente OAuth 2.0.
Inicializar el cliente
Después de instalar el SDK en su aplicación y configurar las credenciales correctas (en/etc/kameleoon/client-ruby.yaml o Kameleoon::KameleoonClientConfig), debe configurar un experimento del lado del servidor en la aplicación Kameleoon.
El siguiente paso es crear el cliente Kameleoon en el código de su aplicación. El siguiente código proporciona un ejemplo de creación del cliente Kameleoon. Un Kameleoon::KameleoonClient es un objeto singleton que actúa como puente entre su aplicación y Kameleoon. Incluye todos los métodos y propiedades que necesita para ejecutar un experimento.
Los desarrolladores son responsables de garantizar la lógica correcta de su código de aplicación al implementar pruebas A/B con Kameleoon. Una práctica recomendada es asumir siempre que un visitante puede excluirse del experimento si aún no se ha lanzado. Esta práctica es simple de implementar, ya que se alinea con la lógica de variación predeterminada o de referencia, que siempre debe estar en su lugar. Los ejemplos de código de la siguiente sección demuestran este enfoque.
Activación de un feature flag
Asignación de un ID único a un usuario
Para asignar un ID único a un usuario, puede utilizar el métodoget_visitor_code(). Si un visitor code no existe (desde la cookie del encabezado de solicitud), el método genera un ID único aleatorio o utiliza un default_visitor_code que habría generado. El ID se establece luego en una cookie del encabezado de respuesta.
Si está usando Kameleoon en modo híbrido, llamar al método get_visitor_code() garantiza que el ID único (visitor code) se comparta entre el archivo de aplicación engine.js (anteriormente llamado kameleoon.js) y el SDK.
Recuperación de 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 usar el métodoget_variation() o feature_active?() para recuperar la configuración basada en feature_key.
El método get_variation() gestiona tanto los feature flags simples con estados ON/OFF como los 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 en función del feature_key y el visitor_code.
El método feature_active?() puede utilizarse si desea recuperar la configuración de un feature flag simple que solo tiene un estado ON u OFF, a diferencia de los 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 asociados 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 verifica si el usuario es objetivo, encuentra la variación asignada del visitante y la guarda en el almacenamiento. Cuando track=true, el SDK enviará el evento de exposición al experimento especificado en la siguiente solicitud de seguimiento, que se activa automáticamente según el tracking_interval_millisecond del SDK. De forma predeterminada, este intervalo se establece en 1000 milisegundos (1 segundo).
El método get_variation() le permite controlar si se realiza el seguimiento. Si track=false, el SDK no enviará eventos de exposición. Esto es útil si prefiere no rastrear datos a través del SDK y en su lugar confiar en el seguimiento del lado del cliente administrado por el motor Kameleoon, por ejemplo. Además, establecer track=false es útil cuando se usa el método get_variations(), donde podría necesitar solo las variaciones para todos los flags sin activar ningún evento de seguimiento. Si desea saber más sobre cómo funciona el seguimiento, vea este artículo
Adición de puntos de datos para segmentar a un usuario o filtrar / desglosar visitas en informes
Para dirigirse a un usuario, asegúrese de haber añadido puntos de datos relevantes a su perfil antes de recuperar la variación de la característica o verificar 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 de usuario anteriores (recopilados del lado del cliente al utilizar Kameleoon en modo híbrido), utilice el método get_remote_visitor_data(). Este método obtiene datos de los servidores de forma asincrónica. Es importante llamar a get_remote_visitor_data() antes de recuperar la variación o verificar si el feature flag está activo, ya que estos datos podrían ser necesarios 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 este tema.
Además, los puntos de datos que añade al perfil del visitante estarán disponibles al analizar sus experimentos, lo que le permite 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 en el lado del cliente, lo que facilita desglosar sus resultados en función de estos puntos de datos previamente recopilados. 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. Custom Data le permite capturar y analizar información específica relevante para sus experimentos. No olvide llamar al método flush() para enviar los datos recopilados a los servidores de Kameleoon para su análisis.
Para asegurarse de que sus resultados sean precisos, se recomienda filtrar los bots utilizando el tipo de dato
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 hacer seguimiento de las conversiones, utilice el métodotrack_conversion() y proporcione los parámetros requeridos visitor_code y goal_id.
La solicitud de seguimiento de conversiones se enviará junto con la siguiente solicitud de seguimiento programada, que el SDK envía a intervalos regulares (definidos por tracking_interval_millisecond). Si prefiere enviar la solicitud de inmediato, utilice el método flush() con el parámetro instant=true.
Envío de eventos a soluciones de analítica
Para rastrear conversiones y enviar eventos de exposición a su solución de analítica de clientes, primero debe implementar Kameleoon en modo híbrido. Luego, 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.
Experimentación entre dispositivos
Para dar soporte a los visitantes que acceden a una aplicación desde varios dispositivos, Kameleoon permite sincronizar los datos del visitante previamente recopilados entre cada uno de sus dispositivos y reconciliar su historial de visitas entre dispositivos mediante la experimentación entre dispositivos. Los casos de estudio y la información detallada sobre cómo Kameleoon gestiona los datos entre dispositivos están disponibles en el artículo sobre experimentación entre dispositivos.Sincronización de datos personalizados entre dispositivos
Aunque la sincronización de mapeo personalizado se utiliza para alinear los datos del visitante entre dispositivos, no siempre es necesaria. A continuación se presentan dos escenarios en los que no se requiere la sincronización de mapeo personalizado: Mismo ID de usuario en todos los dispositivos Si el mismo ID de usuario se utiliza de forma coherente en todos los dispositivos, la sincronización se gestiona automáticamente sin una sincronización de mapeo personalizada. Es suficiente llamar al métodoget_remote_visitor_data() cuando desee sincronizar los datos recopilados entre varios dispositivos.
Instancias multi-servidor con IDs consistentes
En configuraciones complejas con múltiples 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 sincronización de mapeo personalizada adicional.
Los clientes que necesitan datos adicionales pueden consultar la descripción del método get_remote_visitor_data() para obtener más orientación. En el código siguiente, se asume que el mismo identificador único (en este caso, el visitor_code, que también puede denominarse userId) se utiliza de forma coherente entre los dos dispositivos para la recuperación precisa de datos.
Si desea sincronizar los datos recopilados en tiempo real, debe elegir el ámbito Visitor para sus datos personalizados.
Device A
Device B
Uso de datos personalizados para la fusión de sesiones
La experimentación entre dispositivos permite combinar el historial de un visitante en cada uno de sus dispositivos (reconciliación de historial). La reconciliación de historial permite fusionar diferentes sesiones de un visitante en una sola. Para reconciliar el historial de visitas, utiliceCustomData para proporcionar un identificador único del visitante. Para más información, consulte la documentación dedicada.
Después de habilitar la reconciliación entre dispositivos, 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 verán 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 entre dispositivos. Estas limitaciones se describen aquí.
Siga la guía de activación de la reconciliación de historial entre dispositivos para configurar sus datos personalizados en la plataforma Kameleoon.
Posteriormente, puede usar el SDK de forma normal. Los siguientes métodos pueden ser útiles en el contexto de la fusión de sesiones:
get_remote_visitor_data()conUniqueIdentifier(true)agregado—para recuperar datos de todos los visitantes vinculados.track_conversion()oflush()con datosUniqueIdentifier(true)agregados—para rastrear algunos datos de visitantes específicos que están asociados con otro visitante.
get_visitor_code(). Después de que el usuario inicia sesión, el visitante anónimo se asocia con el ID de usuario y se utiliza como identificador único del visitante.
Uso de una clave de bucketing personalizada
De forma predeterminada, Kameleoon utiliza un ID de visitante único y anónimo (visitor_code) para asignar usuarios a variaciones de feature flag. Este ID se genera y almacena típicamente en el dispositivo del usuario (en una cookie del navegador para SDKs del lado del cliente y del lado del servidor; en almacenamiento persistente para SDKs móviles). Sin embargo, en ciertos escenarios puede ser necesario garantizar que todos los usuarios de la misma organización vean la misma variante de un feature flag.
La opción Custom Bucketing Key le permite anular este comportamiento predeterminado proporcionando su propio identificador personalizado para 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
El uso de una clave de bucketing personalizada es esencial para mantener la consistencia y 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
accountId. Las claves de bucketing personalizadas son cruciales para probar mediante A/B funcionalidades que afecten 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 de los datos de su aplicación:- Proporcionar la clave personalizada: Proporciona tu identificador personalizado al SDK de Kameleoon usando el método
add_data(). En este método, pasarás tu clave de bucketing personalizada elegida como un objetoCustomData. Aquí,newVisitorCodese refiere al identificador que deseas usar para tu bucketing (por ejemplo, el nuevouserIdoaccountId).
- Lógica de bucketing: Una vez que se proporciona una clave de bucketing personalizada a través del método
add_data(), todos los cálculos hash para asignar usuarios a variaciones usarán estenewVisitorCode(tu clave personalizada) en lugar delvisitor_codepredeterminado. Usar elnewVisitorCodesignifica que la decisión de bucketing está vinculada a tu identificador personalizado, garantizando asignaciones consistentes en varios contextos donde ese identificador está presente. - Seguimiento de datos y análisis: Es crucial notar que aunque
newVisitorCode(tu clave personalizada) se usa para decisiones de bucketing, todos los datos posteriores (eventos de seguimiento y conversiones, por ejemplo) se envían y se asocian con el originalvisitor_code. Esta separación garantiza que tu análisis refleje con precisión los viajes y las interacciones de usuarios individuales dentro del contexto más amplio de tu experimento, incluso cuando el bucketing se realiza a un nivel superior (como una cuenta) o en múltiples dispositivos/sesiones. Tus datos de visitante originales permanecen intactos para informes comprensivos.
Requisitos técnicos
Para utilizar eficazmente una clave de bucketing personalizada:- La clave debe ser un
String. - Debe ser única para la entidad que pretende agrupar (por ejemplo, si utiliza un
userId, el ID de cada usuario debe ser único). - La clave debe estar disponible para el SDK en el momento exacto en que se evalúa la decisión del feature flag para ese usuario o solicitud.
Condiciones de segmentación
Los SDKs de Kameleoon admiten una variedad de condiciones de segmentación predefinidas que puede usar para segmentar a los usuarios en sus campañas. Para ver la lista de condiciones que admite este SDK, consulte usar el historial de visitas para segmentar a los usuarios. También puede utilizar sus propios datos externos para segmentar a los usuarios.Registro de eventos
El SDK genera registros que reflejan diversos procesos internos y problemas.Niveles de registro
El SDK admite la configuración para limitar el registro mediante un nivel de log.Gestión personalizada de los registros
El SDK escribe sus registros en la salida de la consola de forma predeterminada. Este comportamiento puede anularse.El filtrado por nivel de log se realiza de forma independiente de la lógica de gestión de los registros.
Referencia
Esta es la documentación de referencia completa del SDK de Ruby.Inicialización
create()
El punto de partida para utilizar el SDK es el paso de inicialización. Todas las interacciones con el SDK se realizan a través de un objeto llamado Kameleoon::KameleoonClient, por lo que necesita crear este objeto.Argumentos
Excepciones lanzadas
wait_init()
Utilicewait_init() cuando su aplicación deba esperar a que el cliente de Kameleoon termine su inicialización antes de evaluar feature flags.
La llamada devuelve el resultado de la recuperación de la configuración: true cuando el cliente termina su inicialización, y false si la recuperació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 se realiza correctamente, las llamadas posteriores devuelven true. Si no hay ningún resultado de inicialización disponible antes de que expire el tiempo de espera, la llamada devuelve false. Si no proporciona un valor de timeout_millisecond, el SDK utiliza el tiempo de espera predeterminado de default_timeout_millisecond. El fallo que impidió que el SDK se inicializase se comunica al registro.
Parámetros
Valor de retorno
is_ready?()
is_ready?() comprueba si el SDK está listo para usar, lo que significa que su configuración se ha cargado correctamente. A diferencia de wait_init(), este método devuelve el resultado inmediatamente sin bloquear ni lanzar excepciones.
Valor de retorno
Feature flags y variaciones
feature_active?()
- 📨 Envía datos de seguimiento a Kameleoon (dependiendo del parámetro
track)
Anteriormente se denominaba
activate_feature—se eliminó desde la versión 3.0.0 del SDK.visitor_code, el método feature_active? usa el visitor_code como identificador único del visitante, lo cual es útil para la experimentación entre dispositivos. Cuando especifica un visitor_code y establece el parámetro is_unique_identifier en true, el SDK vincula los datos vaciados con el visitante asociado al identificador especificado.
El parámetro
is_unique_identifier está obsoleto. Use UniqueIdentifier en su lugar.is_unique_identifier también puede ser útil en otros escenarios excepcionales, como cuando no puede acceder al visitorCode anónimo asignado originalmente al visitante, pero sí tiene acceso a un ID interno conectado al visitante anónimo mediante la fusión de sesiones.Parámetros
Valor de retorno
Excepciones lanzadas
get_variation()
- 📨 Envía datos de seguimiento a Kameleoon (dependiendo del parámetro
track)
Variation asignada a un visitante dado para un feature flag específico.
Este método toma un visitor_code y feature_key como argumentos obligatorios. El argumento track es opcional y tiene un valor predeterminado de true.
Devuelve la Variation asignada al visitante. Si el visitante no está asociado con ninguna regla de feature flag, el método devuelve la Variation predeterminada para el feature flag dado.
Asegúrese de implementar un manejo de errores adecuado en su código para gestionar las posibles excepciones.
La variación predeterminada se refiere a la variación asignada a un visitante cuando no coincide con ninguna regla de entrega predefinida para un feature flag. En otras palabras, es la variación de respuesta que se aplica a todos los usuarios que no son segmentados por reglas específicas. Se representa como la variación en la sección “Entonces, para todos los demás servir…” en una interfaz de gestión.
Parámetros
Valor de retorno
Excepciones lanzadas
get_variations()
- 📨 Envía datos de seguimiento a Kameleoon (dependiendo del parámetro
track)
Variation asignados a un visitante dado para todos los feature flags.
Este método itera sobre todos los feature flags disponibles y devuelve la Variation asignada para cada flag asociado con el visitante especificado. Toma visitor_code como argumento obligatorio, mientras que only_active y track son opcionales.
- Si
only_activese establece entrue, el métodoget_variations()devolverá variaciones de feature flags siempre que el usuario no esté asignado a la variaciónoff. - El parámetro
trackcontrola si el método realizará el seguimiento de las asignaciones de variación. Por defecto, se establece entrue. Si se establece enfalse, el seguimiento estará deshabilitado.
Variation correspondiente como valores. Si no se asigna ninguna variación para un feature flag, el método devuelve la Variation predeterminada para ese flag.
Se debe implementar un manejo de errores adecuado para gestionar las posibles excepciones.
La variación predeterminada se refiere a la variación asignada a un visitante cuando no coincide con ninguna regla de entrega predefinida para un feature flag. En otras palabras, es la variación de respuesta que se aplica a todos los usuarios que no son segmentados por reglas específicas. Se representa como la variación en la sección “Entonces, para todos los demás servir…” en una interfaz de gestión.
Parámetros
Valor de retorno
Excepciones lanzadas
set_forced_variation()
El método le permite asignar mediante programación unaVariation específica a un usuario, omitiendo el proceso de evaluación estándar. Esto es especialmente valioso para experimentos controlados donde la lógica de evaluación habitual no es necesaria o debe omitirse. También puede ser útil en escenarios como depuración o pruebas personalizadas.
Cuando se establece una variación forzada, esta anula la lógica de evaluación en tiempo real de Kameleoon. Los procesos como segmentación, condiciones de segmentación y cálculos algorítmicos se omiten. Para preservar la segmentación y las condiciones de segmentación durante un experimento, establece force_targeting=false en su lugar.
Las variaciones simuladas siempre tienen prioridad en el orden de ejecución. Si se activa un cálculo de variación simulada, se procesará y completará completamente primero.
Parámetros
Excepciones lanzadas
En la mayoría de los casos, solo el error básico
KameleoonError necesita ser manejado, como se demuestra en el ejemplo. Sin embargo, si diferentes tipos de errores requieren una respuesta, maneja cada uno por separado según los requisitos específicos. Además, para una confiabilidad mejorada, los errores generales del lenguaje pueden ser manejados incluyendo StandardError.evaluate_audiences()
- 📨 Envía datos de seguimiento a Kameleoon
evaluate_audiences() debe llamarse después de que todos los datos relevantes del visitante se hayan establecido o actualizado, y justo antes de obtener una variación de feature o de verificar un feature flag. Este enfoque garantiza que el visitante se evalúe con los datos más recientes disponibles, lo que permite una asignación precisa de audiencia basada en todos los criterios.
Después de llamar a este método, puede realizar un análisis detallado del rendimiento de segmentos en Audiences Explorer.
Parámetros
Excepciones lanzadas
En la mayoría de los casos, solo el error básico
KameleoonError necesita ser manejado, como se demuestra en el ejemplo. Sin embargo, si diferentes tipos de errores requieren una respuesta, maneja cada uno por separado según los requisitos específicos. Además, para una confiabilidad mejorada, los errores generales del lenguaje pueden ser manejados incluyendo StandardError.get_data_file()
Devuelve la configuración actual del SDK como un objetoDataFile.
Valor de retorno
Datos del visitante
get_visitor_code()
Anteriormente se denominaba
obtain_visitor_code—se eliminó desde la versión 3.0.0 del SDK.get_visitor_code para obtener el visitor_code de Kameleoon del visitante actual. Este método es importante al utilizar Kameleoon en un entorno mixto de front-end y back-end, donde se debe garantizar la precisión en la identificación del usuario. La lógica de implementación es la siguiente:
- Verifique si existe una cookie kameleoonVisitorCode o parámetro de consulta asociado a la solicitud HTTP actual. Si se encuentra, utilícelo como identificador del visitante.
- Si no se encuentra ninguna cookie o parámetro, verifica el argumento default_visitor_code. Si se encuentra, úsalo como el identificador.
default_visitor_code_permite que nuestros clientes usen sus propios identificadores como códigos de visitante si lo desean, lo cual puede tener el beneficio adicional de hacer coincidir visitantes de Kameleoon con tus propios usuarios sin búsquedas adicionales en una tabla de coincidencia. - Si no se encuentra ninguna cookie, parámetro o argumento, genera aleatoriamente un identificador único.
Si proporciona su propio
visitor_code, debe garantizar su unicidad—el SDK no puede verificarla. Además, tenga en cuenta que la longitud del visitor_code está limitada a 255 caracteres. Los caracteres excedentes generarán una excepción.El método
get_visitor_code() le permite establecer variaciones simuladas para un visitante. Cuando las cookies (de una request o document) contienen la clave kameleoonSimulationFFData, se omite el proceso de evaluación estándar. En su lugar, el método devuelve directamente una Variation basada en los datos proporcionados.Puede aplicar simulaciones de dos formas:- Automáticamente (recomendado): Si utiliza Kameleoon Web Experimentation o el SDK en Modo híbrido, la cookie se crea automáticamente al simular la visualización de una variante usando el Panel de Simulación.
- Manualmente: Establezca la cookie
kameleoonSimulationFFDatamanualmente.
- Variaciones simuladas: Afectan el resultado general del feature flag.
- Variaciones forzadas: Son específicas de un experimento individual.
kameleoonSimulationFFData siga este formato:kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}: Simula la variación convarIddel experimentoexpIdpara elfeatureKeyindicado.kameleoonSimulationFFData={"featureKey":{"expId":0}}: Simula la variación predeterminada (definida en la sección Luego, para todos los demás en Producción, servir) para elfeatureKeyindicado.
encodeURIComponent.Parámetros
Valor de retorno
add_data()
El métodoadd_data() añade datos de segmentación al almacenamiento para que otros métodos puedan utilizar los datos para 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, todos los datos declarados se guardan para su transmisión futura mediante el método flush(). Este enfoque reduce el número de llamadas al servidor, ya que los datos se agrupan habitualmente en una única llamada al servidor que desencadena el flush().
El método track_conversion() también envía cualquier dato previamente asociado, al igual que flush(). Lo mismo aplica para los métodos get_variation() y get_variations() si se desencadena una regla de experimentación.
Parámetros
Excepciones
flush()
- 📨 Envía datos de seguimiento a Kameleoon
flush() toma los datos de Kameleoon asociados con el visitante y todos los datos que se añadieron anteriormente usando el método add_data, que no han sido enviados aún al llamar a uno de estos métodos, y envía una solicitud de seguimiento. flush() es sin bloqueo, ya que la llamada al servidor se realiza de forma asincrónica.
flush() le permite controlar cuándo se envían los datos asociados con un visitor_code determinado a nuestros servidores. Por ejemplo, si llama a add_data() una docena de veces, sería ineficiente enviar datos al servidor cada vez que se invoca add_data(), por lo que solo tiene que llamar a flush() una vez al final.
Si especifica un visitor_code, el método flush() lo usa como identificador único del visitante, lo cual es útil para la experimentación entre dispositivos. Cuando especifica un visitor_code y establece el parámetro is_unique_identifier en true, el SDK vincula los datos vaciados con el visitante asociado al identificador especificado.
El parámetro
is_unique_identifier está obsoleto. Use UniqueIdentifier en su lugar.is_unique_identifier también puede ser útil en otros escenarios excepcionales, como cuando no puede acceder al visitorCode anónimo asignado originalmente al visitante, pero sí tiene acceso a un ID interno conectado al visitante anónimo mediante la fusión de sesiones.Argumentos
get_remote_data()
Anteriormente se denominaba:
retrieve_data_from_remote_source—se eliminó desde la versión 3.0.0 del SDK.get_remote_data() te permite recuperar datos (según una clave pasada como argumento) para un siteCode especificado (especificado en Kameleoon::KameleoonClientFactory.create()) almacenado en un servidor remoto de Kameleoon. Generalmente, los datos se almacenan en nuestros servidores remotos usando nuestra API de Datos. Este método, junto con la disponibilidad de nuestros servidores altamente escalables para este propósito, proporciona una forma conveniente de almacenar cantidades masivas de datos que se pueden recuperar para cada uno de tus visitantes/usuarios.
Parámetros
Valor de retorno
Excepciones lanzadas
get_remote_visitor_data()
get_remote_visitor_data() es un método asincrónico para recuperar Datos de Visitas de Kameleoon para el visitor_code de la API de Datos de Kameleoon. El método almacena datos para que otros métodos los usen al tomar decisiones de segmentación.
Los datos obtenidos mediante este método desempeñan un papel importante cuando desea:
- usar datos recopilados de otros dispositivos.
- acceder al historial de un usuario, como páginas visitadas anteriormente durante visitas pasadas.
- usar datos que solo son accesibles en el lado del cliente, como variables de datalayer y objetivos que solo se convierten en el front-end.
El parámetro
is_unique_identifier está obsoleto. Use UniqueIdentifier en su lugar.is_unique_identifier también puede ser útil en otros escenarios excepcionales, como cuando no puede acceder al visitorCode anónimo asignado originalmente al visitante, pero sí tiene acceso a un ID interno conectado al visitante anónimo mediante la fusión de sesiones.Parámetros
Valor de retorno
Uso de parámetros en get_remote_visitor_data()
El métodoget_remote_visitor_data() ofrece flexibilidad al permitirle definir varios parámetros al recuperar datos del visitante. Ya sea que esté segmentando en función de objetivos, experimentos o variaciones, el mismo enfoque se aplica a todos los tipos de datos.
Por ejemplo, supongamos que deseas recuperar datos sobre visitantes que completaron una meta «Transacción de pedido». Puedes especificar parámetros dentro del método get_remote_visitor_data() para refinar tu segmentación. Por ejemplo, si deseas dirigirte solo a usuarios que se convirtieron en la meta en sus últimas cinco visitas, puedes establecer el parámetro previous_visit_amount en 5 y conversions en true.
La flexibilidad mostrada en este ejemplo no se limita a los datos de objetivos. Puede usar parámetros dentro del método get_remote_visitor_data() para recuperar datos sobre una variedad de comportamientos del visitante.
Aquí está la lista de opciones disponibles de
Kameleoon::Types::RemoteVisitorDataFilter:get_visitor_warehouse_audience()
Recupera todos los datos de audiencia asociados con el visitante en tu almacén de datos usando elvisitor_code y warehouse_key especificados. El warehouse_key es típicamente tu ID de usuario interno. El parámetro custom_data_index corresponde a los datos personalizados de Kameleoon que Kameleoon utiliza para dirigirse a tus visitantes. Puedes consultar la documentación de segmentación del almacén para detalles adicionales. El método devuelve un objeto CustomData, confirmando que los datos han sido agregados al visitante y están disponibles para propósitos de segmentación.
Parámetros
Valor de retorno
Excepciones lanzadas
set_legal_consent()
Debes usar este método para especificar si el visitante ha dado consentimiento legal para usar datos personales. Configurar el parámetroconsent en false limita los tipos de datos que puedes incluir en solicitudes de seguimiento. Este método te ayuda a cumplir con los requisitos legales y regulatorios mientras administras de manera responsable los datos del visitante. Puedes encontrar más información sobre datos personales en la política de gestión de consentimiento.
Parámetros
Excepciones lanzadas
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 prorrogar la fecha de expiración de la cookie, permitiendo que esta persista hasta que expire de forma natural.
Si sus requisitos de cumplimiento exigen la eliminación inmediata del archivo de cookie al revocar el consentimiento, 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 argumentos opcionales revenue, negative y metadata. El visitor_code generalmente es idéntico al que se utilizó al activar el experimento.
El método track_conversion() no devuelve ningún valor. Este método no es bloqueante, ya que la llamada al servidor se realiza de forma asíncrona.
El parámetro
isUniqueIdentifier está obsoleto. Utilice en su lugar UniqueIdentifier.isUniqueIdentifier también puede ser útil en otros escenarios excepcionales, como cuando no puede acceder al visitor_code anónimo asignado originalmente al visitante, pero sí tiene acceso a un ID interno conectado al visitante anónimo mediante la fusión de sesiones.Parámetros
Los valores de metadatos son accesibles a través de exportaciones de datos sin procesar y la página de resultados.Si se proporciona el parámetro
metadata, Kameleoon usará estos valores especificados para la conversión actual en lugar de lo recopilado anteriormente usando el método add_data(). Si se omite el parámetro, Kameleoon usará los últimos valores rastreados para esos CustomData anteriores a la conversión y dentro de la misma visita.Kameleoon solo considerará 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 solo con el valor de datos personalizados proporcionado explícitamente como parámetro (aquí: índice 5 con el valor “Amex Credit Card”).Excepciones
get_engine_tracking_code()
Kameleoon se integra con varias soluciones de análisis, incluyendo Mixpanel, Google Analytics 4 y Segment. Para rastrear correctamente 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 últimos cinco segundos. Cuando inserta este código en la página, Engine.js procesa los comandos y envía los eventos de exposición a través de la integración de análisis activa.
Consulte experimentación híbrida para más información sobre cómo implementar este método.
- Para usar esta característica, implementa tanto el SDK de Ruby como Kameleoon Engine.js. Como Engine.js se utiliza solo para seguimiento en este flujo, puedes instalar la etiqueta asincrónica antes de la etiqueta de cierre
</body>. - Si solo desea rastrear experimentos en Kameleoon y no necesita enviar eventos de exposición a herramientas de análisis de terceros, use el SDK de JavaScript / TypeScript. Esta opción funciona bien para plataformas de computación de borde sin servidor. El SDK de JavaScript / TypeScript rastrea automáticamente las variaciones cuando llama a
getVisitorCode, siempre y cuando agregue las asignaciones de experimento correspondientes awindow.kameleoonQueue. - Puede insertar el código de rastreo devuelto directamente en una etiqueta HTML
<script>.
123456 y 234567 son IDs de experimento, y 7890 y 8901 son IDs de variación. En su implementación, el SDK genera estos valores en el código de seguimiento devuelto.Parámetros
Valor de retorno
Eventos
set_event_handler()
Utilice este método para registrar un handler para eventos del SDK. El SDK llama al handler cuando se produce el evento seleccionado. Registrar un nuevo handler para el mismo tipo de evento reemplaza al handler anterior. Pasarnil como handler elimina el handler actual para el tipo de evento seleccionado.
- DATAFILE_UPDATE
- HTTP_REQUEST
Parámetros
Tipos de datos
Browser
El conjunto de datosBrowser almacenado aquí puede utilizarse para filtrar los informes de experimentación y personalización por cualquier valor asociado a él.
PageView
El índice (ID) del remitente está disponible en la página de configuración del canal de adquisición en nuestro Back-Office. Ten cuidado: este índice comienza en 0, por lo que el primer canal de adquisición que crees para un sitio tendría el ID 0, no 1.
Conversion
El conjunto de datosConversion almacenado aquí puede utilizarse para filtrar los informes de experimentación y personalización por cualquier objetivo asociado a él.
CustomData
CustomData te permite asociar fácilmente cualquier tipo de dato con un visitante. Luego puedes usarlo como condición de segmentación en segmentos o como filtro/desglose en informes de experimentos.
Para obtener más información sobre datos personalizados, consulte este artículo.
- Cada visitante puede tener solo un
CustomDatapara cadaindexúnico. Añadir otroCustomDatacon el mismoindexreemplazará elCustomDataexistente. - El
indexde datos personalizados se puede encontrar en el panel de Control de Datos Personalizados bajo la columna “INDEX”. - Para evitar que el SDK envíe datos con el índice seleccionado a los servidores de Kameleoon por razones de privacidad, habilita la opción Usar estos datos solo localmente para propósitos de segmentación al crear datos personalizados.
- Añadir una instancia
CustomDatacreada con un nombre cuando la configuración de instancia del SDK no está actualizada o el nombre no está registrado resultará en que los datos se ignoren.
Device
UserAgent
Almacena información del user-agent del visitante. Los experimentos del lado del servidor son más vulnerables al tráfico de bots que los experimentos del lado del cliente. Para abordar esta vulnerabilidad, Kameleoon usa la Lista Internacional de Arañas y Bots de IAB/ABC para identificar bots y arañas conocidos. Kameleoon también usa el campoUserAgent para filtrar bots y otro tráfico no deseado que de otro modo podría sesgar tus métricas de conversión. Para más detalles, consulta el artículo de ayuda sobre filtrado de bots.
Si utiliza bots internos, le sugerimos pasar el valor curl/8.0 del userAgent para excluirlos de nuestra analítica.
UniqueIdentifier
Si no añadeUniqueIdentifier para un visitante, se utiliza visitor_code como identificador único del visitante, lo cual es útil para la experimentación entre dispositivos. Cuando añade UniqueIdentifier para un visitante, el SDK vincula los datos vaciados con el visitante asociado al identificador especificado.
UniqueIdentifier también puede ser útil en otros escenarios excepcionales, como cuando no puede acceder al visitorCode anónimo asignado originalmente al visitante, pero sí tiene acceso a un ID interno conectado al visitante anónimo mediante la fusión de sesiones.
OperatingSystem
OperatingSystem contiene información sobre el sistema operativo del visitante.
Cada visitante solo puede tener un
OperatingSystem. Agregar un segundo OperatingSystem sobrescribe el primero.Cookie
Cookie contiene información sobre la cookie almacenada en el dispositivo del visitante.
Cada visitante solo puede tener una
Cookie. Agregar una segunda Cookie sobrescribe la primera.Geolocation
Geolocation contiene los detalles de geolocalización del visitante.
ApplicationVersion
ApplicationVersion representa el número de versión semántica de su aplicación.
Tipos devueltos
DataFile
ElDataFile contiene los detalles de configuración del SDK.
Puede extenderse con información adicional si es requerido por los clientes. Si necesita más detalles, contacte con su Gestor de Éxito del Cliente.
FeatureFlag
FeatureFlag representa un conjunto de propiedades que definen un feature flag en sí — por ejemplo, sus Variations, Rules, estado del entorno y otros detalles relacionados.
Puede extenderse con información adicional si es requerido por los clientes. Si necesita más detalles, contacte con su Gestor de Éxito del Cliente.
Rule
Rule representa un conjunto de propiedades que definen una regla en sí — por ejemplo, sus Variations.
Puede extenderse con información adicional si es requerido por los clientes. Si necesita más detalles, contacte con su Gestor de Éxito del Cliente.
Variation
Variation contiene información sobre la variación asignada al visitante (o la variación predeterminada, si no existe una asignación específica).
- El objeto
Variationproporciona detalles sobre la variación asignada y su experimento asociado, mientras que el objetoVariablecontiene detalles específicos sobre cada variable dentro de una variación. - Asegúrese de que su código maneje el caso en el que
idoexperiment_idpueden sernil, indicando una variación predeterminada. - El hash
variablespodría estar vacío si no hay variables asociadas con la variación.
Variable
Variable contiene información sobre una variable asociada con la variación asignada.
Métodos obsoletos
get_feature_variation_key()
- 📨 Envía datos de seguimiento a Kameleoon
Utilice
get_variation() en su lugar.get_feature_variation_key.
Este método toma visitor_code y feature_key como argumentos obligatorios para obtener la clave de variación de un usuario.
Si tal usuario nunca ha sido asociado con este feature flag, el SDK devuelve una clave de variación aleatoriamente (de acuerdo con las reglas del feature flag). Si un usuario con un visitor_code dado ya está registrado con este feature flag, detectará el valor de variation key anterior. Si el usuario no coincide con ninguna de las reglas, se devolverá el valor predeterminado, que puede definir en su cuenta.
Debe asegurarse de que se haya configurado un manejo de errores adecuado en su código, como se muestra en el ejemplo a la derecha, para capturar posibles excepciones.
Si especifica un visitor_code, el método get_feature_variation_key usa el visitor_code como identificador único del visitante, lo cual es útil para experimentación entre dispositivos. Cuando especifica un visitor_code y establece el parámetro is_unique_identifier en true, el SDK vincula los datos vaciados al visitante asociado con el identificador especificado.
El parámetro
is_unique_identifier está obsoleto. Use UniqueIdentifier en su lugar.is_unique_identifier también puede ser útil en otros escenarios excepcionales, como cuando no puede acceder al visitorCode anónimo asignado originalmente al visitante, pero sí tiene acceso a un ID interno conectado al visitante anónimo mediante la fusión de sesiones.Parámetros
Valor de retorno
Excepciones lanzadas
get_active_feature_list_for_visitor()
Utilice
get_active_features() en su lugar.visitorCode como parámetro de entrada. El resultado solo contiene los feature flags activos para un visitante determinado.
Argumentos
Valor de retorno
Excepciones lanzadas
get_active_features()
get_active_features recupera información sobre los feature flags activos que están disponibles para el código de visitante especificado.
Este método está deprecado y será eliminado en la versión
4.0.0 del SDK. Utilice get_variations() en su lugar.Argumentos
Valor de retorno
Excepciones lanzadas
get_feature_variable()
- 📨 Envía datos de seguimiento a Kameleoon
Utilice
get_variation() en su lugar.Anteriormente llamado
obtain_feature_variable - deprecado desde la versión 2.1.0 del SDK y será eliminado en versiones futuras.get_feature_variable.
Este método toma visitor_code, feature_key y variable_name como argumentos obligatorios para obtener una variable de la clave de variación para un usuario determinado.
Si tal usuario nunca ha estado asociado con este feature flag, el SDK devuelve un valor de variable de clave de variación aleatoriamente (de acuerdo con las reglas del feature flag). Si un usuario con un visitor_code dado ya está registrado con este feature flag, detectará el valor variable para la variation previamente asociada. Si el usuario no coincide con ninguna de las reglas, se devolverá la variable predeterminada.
Debe asegurarse de que se haya configurado un manejo de errores adecuado en su código, como se muestra en el ejemplo a la derecha, para capturar posibles excepciones.
Si especifica un visitor_code, el método get_feature_variable usa el visitor_code como identificador único del visitante, lo cual es útil para experimentación entre dispositivos. Cuando especifica un visitor_code y establece el parámetro is_unique_identifier en true, el SDK vincula los datos vaciados al visitante asociado con el identificador especificado.
El parámetro
is_unique_identifier está obsoleto. Use UniqueIdentifier en su lugar.is_unique_identifier también puede ser útil en otros escenarios excepcionales, como cuando no puede acceder al visitorCode anónimo asignado originalmente al visitante, pero sí tiene acceso a un ID interno conectado al visitante anónimo mediante la fusión de sesiones.Parámetros
Valor de retorno
Excepciones lanzadas
get_feature_variation_variables()
Utilice
get_variation() en su lugar.get_feature_variation_variables. Una variable de feature puede ser cambiada usando la aplicación web de Kameleoon.
Este método toma feature_key y variation_key como argumentos obligatorios. Devolverá los datos con el tipo de objeto, según se define en la interfaz web. Lanza un error (FeatureNotFound) si el feature flag solicitado no se ha encontrado en la configuración del cliente del SDK. Si no se encuentra la clave de variación, el método lanza un error (FeatureVariationNotFound).
Parámetros
Valor de retorno
Excepciones lanzadas
get_feature_list()
Devuelve una lista de claves de feature flags disponibles actualmente en el SDK.Valor de retorno
on_update_configuration()
El métodoon_update_configuration() le permite manejar el evento cuando la configuración ha actualizado datos. Toma un parámetro de entrada, handler. El handler que se llamará cuando la configuración se actualice mediante un evento de configuración en tiempo real.