Trouver les sessions à regarder

La plupart des gens ouvrent une session replay avec un objectif ("pourquoi les inscriptions chutent-elles ?") mais sans idée de laquelle parmi des milliers d'enregistrements regarder. Une liste brute et non filtrée est la pire réponse possible — elle noie les sessions utiles dans le bruit. Votre travail consiste à transformer leur intention en filtre ciblé, retourner une poignée d'enregistrements à haut signal, et proposer d'en creuser un.

Les points de départ ci-dessous sont les mêmes que ceux que le produit surface comme « modèles de filtre » — ils encodent les tâches pour lesquelles les gens utilisent réellement replay. Traitez-les comme un menu, pas un script.

La seule règle

Ne dumez jamais une liste d'enregistrements non filtrée. Appliquez toujours soit (a) un filtre basé sur l'objectif, soit (b) triez par un signal (activité, erreurs) pour que les premières lignes valent un clic. Si l'objectif de l'utilisateur n'est pas clair, posez une courte question ou proposez le menu avant de lancer une requête.

Outils disponibles

Passez à la skill investigating-replay une fois que l'utilisateur choisit un enregistrement à comprendre en détail.

Flux de travail

1. Préciser l'objectif

Mappez la requête à l'un des points de départ ci-dessous. Si c'est vague ("montre-moi quelque chose d'intéressant"), proposez 3-4 options plutôt que de deviner, ou par défaut les sessions les plus actives (haut signal, pas de configuration).

2. Découvrir avant de filtrer

Les noms d'événements et les URLs varient par projet — n'assumez jamais que $pageview paths, un événement signup_completed, ou une propriété personne existe. Confirmez avec read-data-schema (event_properties, event_property_values, entity_property_values) avant de mettre une valeur dans un filtre. Si l'événement/propriété nécessaire n'existe pas, dites-le et suggérez le signal disponible le plus proche.

3. Lancer une requête minimale

Appelez query-session-recordings-list avec seulement les filtres qui servent l'objectif. Paramètres recommandés :

• définir filter_test_accounts: true (l'outil par défaut est false) pour exclure les utilisateurs internes, sauf si l'utilisateur débogue sa propre session.
• date_from de -7d à -30d pour les recherches basées sur l'objectif; -3d pour "récent".
• Un order délibéré — activity_score pour "intéressant", console_error_count pour "cassé", start_time pour "récent".
• limit: 10 — vous voulez une liste restreinte, pas un dump.

4. Trier et présenter

Ne relayez pas les lignes brutes. Choisissez les 3-5 plus promettantes et dites pourquoi chacune vaut la peine d'être regardée (durée active longue, nombreuses erreurs, page clé atteinte, score d'activité élevé). Deep-linkez chacune comme {posthog_base_url}/replay/{id} — jamais /replay/home?sessionRecordingId={id}. Notez le nombre total de correspondances pour que l'utilisateur sache combien il y a derrière la liste restreinte.

5. Offrir l'étape suivante

• "Vous voulez que je parcours une ?" → investigating-replay.
• "Vous voulez continuer à regarder celles-ci ?" → sauvegardez-la comme vue de filtre sauvegardée avec session-recording-playlist-create (type: 'filters' — une vue de filtre, pas une 'collection', qui est pour les enregistrements manuellement curés et ne peut pas porter de filtres).

Points de départ → filtres

Deux formes de filtre couvrent presque tout :

• Page atteinte → métrique d'enregistrement visited_page ({ "type": "recording", "key": "visited_page", "operator": "icontains", "value": "/pricing" }).
• Événement spécifique effectué (signup, search, rageclick, utilisé une feature) → il n'y a pas de filtre par nom d'événement sur la requête d'enregistrements, donc d'abord collecter les IDs de session avec execute-sql, puis les passer comme session_ids (voir le modèle à deux étapes ci-dessous).

Modèle à deux étapes : "sessions où l'événement X s'est produit"

La requête d'enregistrements filtre par propriétés d'événement, pas par noms d'événement. Pour trouver les sessions qui contiennent un événement particulier, collectez d'abord les IDs de session :

posthog:execute-sql
SELECT $session_id
FROM events
WHERE event = '$rageclick'          -- ou votre signup/search/feature event (confirmez via read-data-schema)
    AND timestamp > now() - INTERVAL 7 DAY
    AND $session_id != ''
GROUP BY $session_id
ORDER BY max(timestamp) DESC         -- récent en premier : les UUIDs ne sont pas ordonnés temporellement, donc le LIMIT doit garder les sessions les plus fraîches
LIMIT 100

Puis récupérez ces enregistrements (certains IDs de session n'auront pas d'enregistrement — c'est attendu). Passez la même fenêtre date_from que l'étape SQL — avec seulement session_ids, la requête revient à son défaut -3d et laisserait tomber les sessions dont l'événement était plus ancien :

posthog:query-session-recordings-list
{ "date_from": "-7d", "session_ids": ["<id1>", "<id2>", "..."] }

Exemple travaillé

Utilisateur : "Pourquoi les gens rebondissent-ils sur notre page pricing ? Montre-moi des sessions."

1. Objectif = friction page pricing → approche visited_page.
2. read-data-schema (event_property_values pour $pathname) pour confirmer que le chemin est /pricing.
3. Requête :

posthog:query-session-recordings-list
{
  "date_from": "-14d",
  "filter_test_accounts": true,
  "order": "activity_score",
  "limit": 10,
  "properties": [
    { "type": "recording", "key": "visited_page", "operator": "icontains", "value": "/pricing" }
  ]
}

4. Présentez les 3-5 les plus actives, chacune comme {base}/replay/{id}, notant lesquelles ont traîné ou ont eu des erreurs.
5. Proposez d'investiguer la plus prometteuse (investigating-replay) ou sauvegardez-la comme vue de filtre sauvegardée (type: 'filters').

Conseils

• Préférez un bon filtre à plusieurs — le sur-filtrage retourne rien et se lit comme "pas de données".
• Si une requête retourne zéro enregistrements, élargissez la plage de dates ou relâchez le filtre avant de conclure qu'il n'y a rien à regarder ; si c'est toujours vide, les enregistrements peuvent ne pas être capturés pour ce flux (pointez l'utilisateur vers diagnosing-missing-recordings).
• activity_score est un bon proxy par défaut pour "vaut la peine d'être regardé" quand il n'y a pas de signal plus pointu — mais il récompense le volume d'interaction brut, préférez donc un filtre basé sur l'objectif (erreurs, une page clé) quand vous en avez un.
• Gardez la liste restreinte courte. La valeur est de choisir pour l'utilisateur, pas de rendre la botte de foin.