Analyser les rejoues de sessions d'expériences

Cette skill vous guide à travers l'analyse des enregistrements de sessions pour les variantes d'expériences afin de comprendre les différences comportementales entre les groupes de contrôle et de test.

Quand utiliser cette skill

Utilisez cette skill quand :

L'utilisateur demande d'analyser les rejoues de sessions pour une expérience
L'utilisateur souhaite comprendre comment les utilisateurs se comportent différemment selon les variantes d'expériences
L'utilisateur demande de comparer le comportement des utilisateurs entre les variantes de contrôle et de test
L'utilisateur souhaite des insights qualitatifs pour compléter les métriques d'expérience
L'utilisateur pose des questions comme « Comment les utilisateurs se comportent-ils dans mon expérience ? » ou « Montrez-moi les rejoues de sessions pour la variante X »

Prérequis

Avant d'analyser les rejoues de sessions :

L'expérience doit être lancée (pas à l'état de brouillon)
La rejoue de session doit être activée pour le projet
Les utilisateurs doivent avoir été exposés aux variantes d'expériences
L'expérience doit avoir une date de démarrage

Flux de travail

1. Récupérer les détails de l'expérience et les variantes du feature flag

Commencez par récupérer les informations de l'expérience et les variantes du feature flag (source de vérité).

Étape 1a : Récupérer les métadonnées de l'expérience

Vous pouvez soit :

Option A : Utiliser l'outil experiment_results_summary si vous avez déjà l'ID de l'expérience dans le contexte
Option B : Interroger la table des expériences via HogQL :

SELECT
    id,
    name,
    feature_flag_key,
    start_date,
    end_date
FROM system.experiments
WHERE id = <experiment_id>
  AND team_id = <team_id>

À partir des données d'expérience, extraire :

feature_flag_key : Le feature flag contrôlant l'expérience
start_date et end_date : La plage horaire de l'expérience

Étape 1b : Récupérer les variantes du feature flag

IMPORTANT : Toujours récupérer les variantes du feature flag, PAS de experiment.parameters.feature_flag_variants. Les paramètres peuvent être dés synchronisés ou obsolètes. Le feature flag est la source de vérité.

Interroger le feature flag pour obtenir les variantes actuelles :

SELECT
    key,
    filters
FROM system.feature_flags
WHERE key = '<feature_flag_key>'
  AND team_id = <team_id>

Extraire les clés de variantes de l'array filters.multivariate.variants. Exemple de structure : [{"key": "control", "name": "Control", "rollout_percentage": 50}, {"key": "test", ...}]

Les valeurs de key de variantes (ex. « control », « test », « variant_a ») sont ce que vous utiliserez pour filtrer les enregistrements de sessions.

2. Créer les filtres de rejoue de session pour chaque variante

Pour chaque variante dans l'expérience, construire des filtres de rejoue qui correspondent aux utilisateurs exposés à cette variante.

Structure de filtre pour une variante :

{
  "date_from": "<experiment.start_date>",
  "date_to": "<experiment.end_date or current time>",
  "filter_test_accounts": true,
  "events": [
    {
      "id": "$feature_flag_called",
      "type": "events",
      "properties": [
        {
          "key": "$feature_flag",
          "value": ["<feature_flag_key>"],
          "operator": "exact",
          "type": "event"
        },
        {
          "key": "$feature/<feature_flag_key>",
          "value": ["<variant_key>"],
          "operator": "exact",
          "type": "event"
        }
      ]
    }
  ]
}

Points clés :

Filtrer par les événements $feature_flag_called où le flag correspond au feature flag de l'expérience
Utiliser la propriété $feature/<flag_key> pour filtrer sur la valeur de variante spécifique
Définir la plage de dates sur les dates de démarrage et de fin de l'expérience
Activer filter_test_accounts: true pour exclure les utilisateurs de test

3. Récupérer les enregistrements pour chaque variante

Utiliser l'outil filter_session_recordings avec les filtres construits à l'étape 2.

Appeler l'outil une fois par variante pour obtenir les enregistrements de chaque groupe :

Variante « control » → enregistrements pour le groupe de contrôle
Variante « test » → enregistrements pour la variante de test
Variantes supplémentaires si l'expérience en compte plus de 2

L'outil retourne une liste d'enregistrements avec des métadonnées incluant :

Utilisateur/distinct_id
Durée de session
Métriques d'activité (clics, frappes)
Erreurs console
Première URL visitée
Heure de démarrage

4. Comparer et analyser

Comparer les enregistrements entre variantes en cherchant :

Motifs quantitatifs :

Différences de durée de session
Niveaux d'activité (clics, frappes)
Taux d'erreurs console
Taux de rebond

Insights qualitatifs :

Indicateurs de confusion ou de frustration des utilisateurs
Chemins de navigation différents
Motifs de découverte de fonctionnalités
Comportement de récupération d'erreurs

5. Présenter les conclusions

Résumer les différences comportementales entre les variantes, en mettant en évidence :

Nombre total d'enregistrements par variante
Motifs de comportement notables uniques à chaque variante
Problèmes d'utilisabilité ou points de friction observés
Recommandations basées sur les données qualitatives

Exemple d'interaction

Utilisateur : « Comment les utilisateurs se comportent-ils dans mon expérience de paiement ? »
Étapes de l'agent :
1. Interroger les détails de l'expérience (ID : 123, feature_flag_key : « checkout-flow-test », plage de dates : 2025-01-01 à 2025-01-31)
2. Interroger le feature flag « checkout-flow-test » pour obtenir les variantes de filters.multivariate.variants
3. Extraire les clés de variantes : « control » et « new-checkout »
4. Créer les filtres pour la variante de contrôle :
   - Événements : $feature_flag_called avec $feature_flag="checkout-flow-test" et $feature/checkout-flow-test="control"
   - Plage de dates : 2025-01-01 à 2025-01-31
5. Appeler filter_session_recordings avec les filtres de contrôle → 147 enregistrements trouvés
6. Créer les filtres pour la variante new-checkout et appeler filter_session_recordings → 152 enregistrements trouvés
7. Comparer les motifs :
   - Contrôle : Durée de session moyenne de 3m 45s, 12 % d'erreurs console
   - New-checkout : Durée de session moyenne de 2m 30s, 5 % d'erreurs console
8. Présenter les conclusions :
   « J'ai analysé les rejoues de sessions pour votre expérience de paiement. Le nouveau flux de paiement montre :
   - 33 % plus rapide (2m 30s vs 3m 45s)
   - 58 % moins d'erreurs console (5 % vs 12 %)
   - Les utilisateurs de la nouvelle variante naviguent directement vers le paiement, tandis que les utilisateurs du contrôle reviennent souvent vérifier le panier
   - Recommandation : Le nouveau flux de paiement réduit les frictions et les erreurs »

Notes importantes

Ne pas faire d'hypothèses :

Toujours vérifier que l'expérience dispose d'enregistrements avant d'analyser
Vérifier que l'expérience est lancée (a une date de démarrage)
Si aucun enregistrement n'est trouvé, informer clairement l'utilisateur

Construction de filtres :

La propriété $feature/<flag_key> est comment PostHog suit quelle variante un utilisateur a vues
Toujours utiliser $feature_flag_called comme type d'événement
Les propriétés $feature_flag et $feature/<flag_key> sont toutes deux requises

Gestion des erreurs :

Si l'expérience est à l'état de brouillon, dire à l'utilisateur qu'elle n'a pas encore démarré
Si aucun enregistrement n'existe, suggérer d'activer la rejoue de session ou d'attendre le trafic utilisateur
Si le nombre de variantes est inattendu, revérifier la configuration de l'expérience

Outils connexes

filter_session_recordings : Outil principal pour récupérer les enregistrements de sessions avec filtres
experiment_results_summary : Obtenir les métadonnées d'expérience et les résultats statistiques
execute_sql : Interroger la table des expériences pour les détails via HogQL

analyzing-experiment-session-replays