Saltar al contenido principal
Este tutorial describe cómo solicitar los resultados de los experimentos y determinar las variaciones ganadoras usando la Automation API. Sigue a los tutoriales anteriores sobre creación de experimentos, modificación de variaciones, asociación de objetivos y segmentos y lanzamiento de experimentos.

Requisitos

  • access_token
La Automation API requiere un token de acceso. Obtenga el token de forma programática siguiendo las instrucciones de la sección sobre cómo obtener un token de acceso.
  • experimentId
El experimentId es el identificador numérico del experimento del que desea obtener los resultados. Puede encontrarlo en la URL de la aplicación Kameleoon mientras visualiza el experimento (por ejemplo, https://app.kameleoon.com/.../experiments/188308/...). Para los experimentos de feature flag, el ID se muestra en el Rollout Planner.

Objetivo

El tutorial utiliza el siguiente experimento de ejemplo:
Experiment_188308
Este experimento, llamado Product Page Redesign, incluye dos variaciones además de la versión original: Redesign 1 (ID 828220) y Redesign 2 (ID 828221). Aunque el experimento tiene varios objetivos, este tutorial se centrará únicamente en el objetivo principal, que es hacer seguimiento de las suscripciones a seguros mediante Click Tracking.
El tutorial también se aplica a los experimentos de Feature Flag; sin embargo, utilice los endpoints https://api.kameleoon.com/feature-flags/* en lugar de https://api.kameleoon.com/experiments/*:El experimentId se encuentra en el Rollout Planner:

Cómo funciona la recuperación de resultados

La recuperación de resultados es un proceso de dos pasos:
  1. Solicitar los resultados — envíe una solicitud POST a /experiments/{experimentId}/results. La respuesta devuelve un hash dataCode, no los resultados en sí.
  2. Consultar los resultados — envíe una solicitud GET a /results?dataCode=<dataCode> para recuperar los datos reales.
Los dos casos del paso 1 solo se diferencian en cómo se autentica: directamente con su token de acceso (Caso 1) o mediante un token compartido que permite a usuarios no autenticados ver los resultados (Caso 2).

1. Recuperar el código de datos

Los siguientes parámetros clave del cuerpo controlan lo que incluye el informe. Para la referencia completa de parámetros, consulte el endpoint Request experiment’s results.

Caso 1: Recuperar resultados directamente

Envíe una solicitud POST al endpoint Request experiment’s results usando su token de acceso. Ejemplo:
Respuesta:
Pase este dataCode al paso 2 para recuperar los resultados reales.

Caso 2: Compartir resultados sin autorización

Utilice este enfoque para permitir que los usuarios vean los resultados sin un token de acceso — por ejemplo, para compartir una vista de resultados en vivo con una parte interesada.

1. Recuperar un SharedToken

Obtenga un SharedToken del endpoint Share experiment results. Este endpoint acepta el mismo cuerpo de solicitud que el endpoint de resultados.
Respuesta:

2. Recuperar el dataCode con el SharedToken

Envíe una solicitud POST al endpoint Request experiment’s results usando el SharedToken de la respuesta anterior en lugar de un token de acceso.
Respuesta:

2. Recuperar los resultados del experimento

Tras recibir el dataCode de cualquiera de los casos anteriores, llame al endpoint result.
Si la respuesta devuelve "status": "PENDING", el informe aún se está generando. Reintente la solicitud tras un breve retraso hasta que el estado sea "READY".
Respuesta:

3. Interpretar los resultados para determinar la variación ganadora

Las variaciones ganadoras deben demostrar una alta fiabilidad (superior al 95%) y una tasa de mejora positiva en comparación con la variación de referencia. La respuesta JSON muestra que tanto Redesign 1 como Redesign 2 tienen una tasa de fiabilidad del 100%. Sin embargo, Redesign 1 tiene una tasa de mejora del +211,48% frente a la tasa del -43,33% de Redesign 2. Por lo tanto, Redesign 1 es la ganadora. Redesign 1
Redesign 2

4. Filtrar los resultados del experimento

Obtenga resultados específicos utilizando los parámetros breakdown y filters. El parámetro breakdown organiza los datos por una única dimensión (como el navegador, el sistema operativo o el día de la semana). El parámetro filters restringe los datos a un subconjunto de visitantes antes de aplicar el desglose.
El parámetro breakdown acepta un único objeto por solicitud, no un array. Para comparar varias dimensiones, envíe una solicitud por cada breakdown.

Formatos de breakdown

La mayoría de los tipos de breakdown solo requieren un campo type, por ejemplo:
Tres tipos de breakdown requieren campos adicionales: INTERVAL — segmenta los resultados por un intervalo de tiempo. Combine "type": "INTERVAL" con un campo interval:
El campo interval acepta HOUR, DAY, WEEK, MONTH o YEAR. CUSTOM_DATUM — segmenta los resultados por índice de datos personalizados. Combine "type": "CUSTOM_DATUM" con un campo index:
CROSS_CAMPAIGN — segmenta los resultados por la exposición a otro experimento o personalización. Proporcione al menos uno de los campos experiments o personalizations:

Tipos de filtro

Cada objeto de filtro requiere una cadena type y un booleano include. Establezca include en true para restringir los resultados a los visitantes coincidentes, o en false para excluirlos. Los campos adicionales dependen de type:

Ejemplo: desglose por navegador filtrado a nuevos visitantes

La siguiente solicitud aplica un desglose por navegador restringido a los nuevos visitantes mediante el envío de una solicitud POST al endpoint Request experiment’s results:
Tras recibir el dataCode, recupere los resultados:
Una respuesta exitosa devuelve los resultados desglosados por navegador. La respuesta sigue la misma estructura que el paso 2 anterior, con cada tipo de navegador (CHROME, FIREFOX, OTHERS, etc.) como clave dentro de breakdownData. La siguiente respuesta está truncada para mayor claridad: