Skip to main content

Objectif

Ce tutoriel décrit, étape par étape, le fonctionnement du script kameleoon_to_airtable.py. À partir d’un ID d’expérience Kameleoon, d’un ID de base Airtable et d’un ID de table Airtable, le script récupère les métadonnées de l’expérience et ses résultats statistiques, détermine la variation la plus performante, mappe les données sur le schéma Airtable Experiments, et écrit l’enregistrement dans Airtable. Réexécuter le script pour la même expérience met à jour la ligne existante au lieu d’en créer un doublon. Ce tutoriel fait suite au tutoriel précédent sur la récupération des résultats d’expériences avec l’Automation API et réutilise le même flux de demande et d’interrogation.

Prérequis

  • Identifiants API Kameleoon. L’Automation API nécessite un access token. Le script en obtient un de manière programmatique à partir d’un client_id et d’un client_secret grâce au grant client_credentials. Consultez Obtenir un access token.
  • Un personal access token Airtable avec le scope data.records:write sur la base cible.
  • L’ID de base et l’ID de table Airtable. Les deux apparaissent dans l’URL de la table, ou dans la documentation API de la base. L’ID de base commence par app, l’ID de table par tbl.
  • Une table Airtable avec le schéma Experiments déjà construit. Le script écrit dans les champs suivants : Experiment Name, Status, Start date, End date, Notes, Actual, Probability, et Result. Il s’attend aussi à ce que les champs à saisie manuelle Assignee, Category, Prediction, Mkt Est, Eng Est, et Attachments existent, même s’il ne les définit jamais. Airtable rejette une écriture sur un nom de champ qui n’existe pas déjà dans la table, et typecast ne fait que convertir le type des valeurs pour les champs existants (il ne crée ni champs manquants ni options de sélection). Créez la table avec ces champs, et les options de sélection Status correspondantes, avant d’exécuter le script. Consultez l’étape 6 pour connaître la valeur reçue par chaque champ.
  • Python 3.9 ou supérieur avec la bibliothèque requests (pip install requests).
Stockez tous les identifiants dans des variables d’environnement. N’écrivez jamais les secrets en dur dans le script.
Le tutoriel utilise l’expérience d’exemple Product Page Redesign (ID 188308), avec deux variations en plus de l’originale : Redesign 1 (ID 828220) et Redesign 2 (ID 828221).

1. S’authentifier auprès de l’Automation API

Endpoint : obtenez un access token en envoyant une requête POST à l’endpoint de token.
Exemple :
Réponse :
Envoyez l’access_token retourné en tant que token Bearer pour chaque requête suivante à l’Automation API. Les access tokens restent valides 2 heures par défaut.

2. Récupérer l’expérience

Endpoint : récupérez les métadonnées de l’expérience en envoyant une requête GET à l’endpoint Get an experiment.
Exemple :
Réponse (abrégée) :
Le script lit name, status, dateStarted, dateEnded, et description pour l’enregistrement Airtable, ainsi que mainGoalId pour restreindre la requête de résultats à l’étape suivante.
L’API retourne mainGoalId par défaut ; vous n’avez donc pas besoin d’un paramètre optionalFields pour le lire. L’Automation API ne publie pas d’énumération fixe pour le champ status, mais les autres champs de type statut de l’API utilisent systématiquement des tokens en majuscules (par exemple, STOPPED, ACTIVE, DRAFT). L’étape 6 mappe le champ status sur cette hypothèse. Confirmez les tokens exacts que votre compte retourne avec une requête réelle avant de vous fier à ce mapping.

3. Demander les résultats de l’expérience

Endpoint : déclenchez la génération du rapport de résultats en envoyant une requête POST à l’endpoint Request experiment’s results.
Exemple :
Réponse :
Kameleoon génère le rapport de manière asynchrone. L’endpoint retourne un dataCode, que l’étape 4 utilise pour interroger le résultat.
Ce script nécessite bayesian: true. Avec Bayesian activé, la valeur reliability du rapport porte la probabilité de succès bayésienne (la probabilité qu’une variation batte la référence), que le script mappe sur le champ Probability. Confirmez cette valeur par rapport au même rapport dans l’application Kameleoon si votre compte utilise une méthode statistique par défaut différente. La spécification de l’Automation API marque dateIntervals comme obligatoire, mais l’exemple ci-dessus l’omet et retourne malgré tout un rapport valide. La spécification ne documente pas la valeur par défaut appliquée quand dateIntervals est omis ; ce tutoriel suppose qu’elle couvre l’intégralité de la durée de l’expérience, donc confirmez ce comportement sur votre propre compte avant de vous y fier. Transmettez plutôt un tableau dateIntervals pour limiter le rapport à une période spécifique.

4. Interroger les résultats

Endpoint : récupérez le rapport en envoyant des requêtes GET à l’endpoint Poll results jusqu’à ce qu’il soit prêt.
Le status de la réponse est WAITING pendant que Kameleoon calcule le rapport, READY quand les données sont disponibles, ou ERROR / TIMEOUT en cas d’échec. Quand le statut est ERROR ou TIMEOUT, la réponse inclut un errorDescription de premier niveau. Le script interroge à intervalle fixe jusqu’à ce que le statut soit READY. Exemple :
Réponse (abrégée) :

5. Sélectionner la variation la plus performante

Les résultats contiennent une entrée par variation sous variationData, ainsi que la ligne _reference pour la page originale. Pour chaque variation, les métriques de l’objectif demandé se trouvent sous breakdownData._reference.generalData.goalsData[goalId]. Le script ignore l’entrée _reference, lit l’improvementRate et la reliability (la probabilité de succès bayésienne) de chaque variation, et sélectionne comme meilleure performance la variation ayant le taux d’amélioration le plus élevé. Le champ Result mappé à l’étape suivante indique si cette variation a réellement gagné : si elle a atteint une probabilité de succès suffisamment élevée avec un uplift positif. Exemple :
Dans l’exemple, les deux variations atteignent une probabilité de succès bayésienne de 100 %, mais Redesign 1 (828220) affiche une amélioration de +211,48 % contre -43,33 % pour Redesign 2. Redesign 1 est donc la variation la plus performante et, avec une probabilité supérieure à 95 % et un uplift positif, une véritable gagnante.

6. Mapper les données aux champs Airtable

Le script transforme les métadonnées de l’expérience et les métriques de la variation la plus performante en schéma Airtable Experiments. Le script ne définit pas les champs sans source Kameleoon : Assignee, Category, Prediction, Mkt Est, Eng Est, et Attachments. Ces champs restent disponibles pour une saisie manuelle dans Airtable. Le script omet aussi les valeurs vides, il n’écrase donc jamais une cellule existante avec une valeur vide. Exemple :
L’Automation API ne publie pas d’énumération fixe pour le champ status de l’expérience, et les tokens peuvent évoluer. map_status effectue une correspondance sans distinction de casse et retourne None pour un statut non reconnu, ce qui supprime la cellule Status au lieu d’écrire une valeur incorrecte. Confirmez les tokens que votre compte retourne avec un simple GET /experiments/{experimentId} et étendez STATUS_MAP si nécessaire.

7. Upserter l’enregistrement dans Airtable

L’endpoint Airtable Update table (PATCH /v0/meta/bases/{baseId}/tables/{tableId}) modifie uniquement le nom et la description d’une table ; il ne peut pas écrire de données dans les lignes. Pour renseigner un enregistrement, utilisez l’endpoint records avec l’option performUpsert.
Endpoint : créez ou mettez à jour l’enregistrement en envoyant une requête PATCH à l’endpoint records.
Exemple :
Réponse (abrégée) :
La réponse indique le résultat pour chaque enregistrement : un ID retourné sous createdRecords signifie qu’Airtable a créé une nouvelle ligne, tandis qu’un ID sous updatedRecords signifie qu’Airtable a mis à jour une ligne existante.

8. Exécuter le script

Transmettez l’ID de l’expérience ainsi que les ID de base et de table Airtable en arguments :
Le script affiche chaque étape : l’authentification, l’expérience récupérée, la variation la plus performante, les champs mappés, et s’il a créé ou mis à jour l’enregistrement Airtable.

Script complet

Le script complet ci-dessous correspond fonction par fonction à kameleoon_to_airtable.py. Copiez-le directement, ou téléchargez le fichier depuis ce lien.

Notes de personnalisation

  • Le mapping de statut se trouve dans la constante STATUS_MAP, indexée sur les tokens de statut en majuscules retournés par l’API. Ajustez les valeurs cibles si vos options Status diffèrent de Running / Implementing / Completed / Defunct, et confirmez les tokens que votre compte retourne avec une requête GET /experiments/{experimentId} réelle avant de vous fier au mapping.
  • Probability provient de la probabilité de succès bayésienne mesurée, ce qui nécessite bayesian: true sur la requête de résultats. Si votre champ Probability est plutôt une estimation pré-expérience que vous saisissez manuellement, supprimez la ligne Probability de build_airtable_fields.
  • La sélection de l’objectif utilise le mainGoalId de l’expérience. Pour établir un rapport sur un objectif différent, transmettez son ID à request_results et à pick_best_variation.
  • Clé d’upsert. Airtable fait correspondre le champ de fusion de manière exacte, donc des différences de casse ou d’espacement dans Experiment Name créent une nouvelle ligne au lieu de mettre à jour celle existante. Gardez des noms d’expérience stables, ou effectuez la fusion sur un champ identifiant dédié et stable.
  • Format du champ Actual. Le script écrit la valeur brute d’improvementRate (par exemple, 211.48) dans Actual. Si Actual est un champ Airtable de type Percent, configurez-le pour qu’il attende un nombre simple plutôt qu’une fraction, ou divisez la valeur par 100 dans build_airtable_fields pour correspondre à un champ Percent basé sur une fraction.
  • Limites de débit. L’Automation API autorise jusqu’à 50 requêtes par 10 secondes et 1 000 par heure, mais Kameleoon recommande de rester sous 12 appels par minute et par compte, et déconseille l’utilisation de l’Automation API pour du tracking à haute fréquence. Si vous traitez de nombreuses expériences en lot, mettez les tokens en cache, limitez le débit des requêtes, et envisagez la Data API pour les besoins à fort volume.