Quickstart d’Experiment Center

Apprenez à créer un feature flag, à ajouter des variations, à créer une expérience, à l’activer et à consulter des données enrichies sur l’expérience dans le log du tenant.

Pendant la période bêta, Experiment Center est offert uniquement pour les tenants de développement. Les tenants de production ne sont pas pris en charge.

​

Prérequis

Pour commencer à utiliser Experiment Center, vous avez besoin de :

• Un tenant Auth0 de développement

• Une application machine à machine avec les scopes Management API suivants :

  read:experimentation
  create:experimentation
  update:experimentation
  delete:experimentation
  

​

1. Créer et activer le feature flag

Un feature flag définit ce que vous testez et les variations possibles.

Pour créer un feature flag, envoyez une requête POST au point de terminaison /api/v2/experimentation/feature-flags.

• La réponse comprend une valeur feature_flag_id ; vous en aurez besoin dans les étapes suivantes.
• Le feature flag est d’abord à l’état draft.

​

Ajouter deux variations

Le feature flag doit comporter au moins deux variations avant de pouvoir être activé : un témoin et un traitement.

​

Créer la variation témoin

Vous pouvez créer une variation témoin à l’aide du paramètre overrides pour un feature flag précis.

Pour ajouter une variation témoin, faites une requête POST vers le point de terminaison /api/v2/experimentation/feature-flags/{feature_flag_id}/variations.

La réponse inclut une valeur variation_id pour la variation témoin. Vous en aurez besoin lors de la configuration des allocations.

​

Créer la variation de traitement

La variation de traitement remplace les paramètres que vous souhaitez modifier.

Pour ajouter la variation de traitement, effectuez une requête POST vers le point de terminaison /api/v2/experimentation/feature-flags/{feature_flag_id}/variations et configurez l’objet overrides.

Example

    "overrides": {
      "show_passkey_prompt": { "value": true },
      "prompt_style": { "value": "modal" }
    }

​

Activer le feature flag

Maintenant que vous avez deux variations, activez le feature flag. Une expérience ne peut pas être activée tant que le feature flag auquel elle est associée n’a pas le statut active.

Pour faire passer le statut du feature flag à active, effectuez une requête POST vers le point de terminaison /api/v2/experimentation/feature-flags/{feature_flag_id}/status.

​

2. Créer un segment (facultatif)

Si vous voulez cibler un trafic précis, créez un segment. Ignorez cette étape si vous voulez simplement répartir un pourcentage sur l’ensemble du trafic.

Pour créer un segment, effectuez une requête POST vers le point de terminaison /api/v2/experimentation/segments.

Cet exemple crée un segment qui cible les utilisateurs mobiles aux États-Unis :

Example

    "name": "mobile-us-users",
    "description": "Mobile users from the United States",
    "rules": [
      {
        "match_type": "all",
        "conditions": [
          { "attribute": "device_type", "operator": "equals", "value": "mobile" },
          { "attribute": "country", "operator": "equals", "value": "US" }
        ]
      }
    ]

La réponse contient une valeur segment_id. Les segments ne s’appliquent que lorsque vous utilisez la stratégie d’allocation segment dans l’expérience.

​

3. Créer et activer une expérience

Créez une expérience qui renvoie à votre feature flag et définit la façon de répartir le trafic.

Pour créer une expérience, envoyez une requête POST au point de terminaison /api/v2/experimentation/experiments.

Cet exemple utilise une répartition 90/10 au moyen de l’objet allocations : 90 % des utilisateurs reçoivent le groupe témoin et 10 % reçoivent le traitement. Il s’agit d’un point de départ typique pour un déploiement prudent.

Example

    "allocations": [
      {
        "variation_id": "var_Id",
        "weight": 90,
        "is_control": true
      },
      {
        "variation_id": "var_Id",
        "weight": 10,
        "is_control": false
      }
    ]

L’expérience démarre avec le statut draft et is_valid: false. C’est normal : la vérification complète de l’état de préparation s’effectue à l’étape suivante.

​

Valider l’expérience

Avant de l’activer, assurez-vous que l’expérience est prête. Le point de terminaison /validate renvoie les mêmes vérifications que celles effectuées lors de l’activation.

Pour confirmer l’expérience, effectuez une requête POST au point de terminaison /api/v2/experimentation/experiments/{experiment_id}/validate.

La réponse inclut la valeur is_valid pour indiquer si vous êtes prêt à l’activer.

​

Activer l’expérience

Lorsque l’expérience est valide et que vous avez testé les deux variations, activez-la.

Pour faire passer le statut de l’expérience à active, envoyez une requête POST à l’point de terminaison /api/v2/experimentation/experiments/{experiment_id}/status.

La valeur started_at de l’expérience est définie lors de la première activation et ne change pas si vous la mettez en pause, puis la réactivez.

Une seule expérience active par tenant. Si une autre expérience est déjà active, l’activation renvoie 400 experiment_active_limit_exceeded. Mettez d’abord l’autre expérience en pause ou terminez-la.

​

4. Déclenchez un événement d’authentification et observez les résultats

Déclenchez une connexion de test à partir de votre tenant de test. Par exemple, ouvrez un navigateur et accédez à votre URL /authorize sans aucun paramètre de remplacement.

Terminez le flux de connexion. Experiment Center résout l’expérience active, attribue une variation à l’aide d’un hachage déterministe, injecte le contexte de l’expérience et enrichit l’événement d’authentification qui en résulte.

​

Vérifier les journaux enrichis

Vous pouvez consulter les logs Auth0 pour les événements d’expérience :

• Accédez à Auth0 Dashboard > Monitoring > Logs.

• Utilisez la diffusion des journaux : si vous diffusez déjà les logs du tenant vers un outil d’analytique (Datadog, Splunk, Segment, etc.), les métadonnées d’expérience enrichies transitent automatiquement par le même flux.

L’événement comprend des métadonnées d’expérience dans l’objet details.experiment. Le champ variation_id vous indique à quelle variation l’utilisateur a été attribué.

Vous avez mené avec succès votre première expérience lorsque :

1. Vos événements d’authentification dans les logs du tenant incluent details.experiment avec experiment_id et variation_id
2. Les deux variations produisent le comportement attendu lorsqu’elles sont testées avec des surcharges par paramètres de requête
3. Le même appareil ou utilisateur obtient toujours le même variation_id dans plusieurs événements d’authentification (attribution déterministe)

​

En savoir plus

• Consultez le guide d’intégration ACUL pour découvrir comment adapter le code de votre composant ACUL en fonction du contexte de l’expérience.
• Consultez le guide d’intégration Actions pour utiliser event.experiment dans les déclencheurs post-login et d’enregistrement.