Enquêter sur un enregistrement de session

Quand un utilisateur demande « que s'est-il passé dans cette session ? » ou fournit un ID d'enregistrement/session à enquêter, rassemblez tous les contextes pertinents en parallèle plutôt que de le faire demander chaque information.

Outils disponibles

Workflow

Étape 1 — Obtenir les métadonnées d'enregistrement et le profil de personne

Commencez par l'enregistrement pour obtenir les métadonnées et l'ID distinct de la personne :

posthog:session-recording-get
{
  "id": "<recording_id>"
}

La réponse inclut distinct_id, person, la durée, les compteurs d'interactions, les compteurs d'erreurs console et le statut de visualisation. Utilisez distinct_id pour récupérer le profil de personne complet :

posthog:persons-retrieve
{
  "id": "<person_uuid_from_recording>"
}

Étape 2 — Interroger les événements de la même session

Obtenez la chronologie de ce que l'utilisateur a fait pendant la session :

posthog:execute-sql
SELECT
    timestamp,
    event,
    properties.$current_url AS url,
    properties.$browser AS browser,
    properties.$os AS os,
    properties.$device_type AS device_type,
    properties.$screen_width AS screen_width
FROM events
WHERE $session_id = '<session_id>'
ORDER BY timestamp ASC
LIMIT 200

Pour les sessions avec beaucoup d'événements, concentrez-vous sur les plus informatifs :

posthog:execute-sql
SELECT
    timestamp,
    event,
    properties.$current_url AS url,
    if(event = '$exception', properties.$exception_message, null) AS exception_message,
    if(event = '$exception', properties.$exception_type, null) AS exception_type
FROM events
WHERE $session_id = '<session_id>'
    AND event IN ('$pageview', '$pageleave', '$autocapture', '$exception', '$rageclick')
ORDER BY timestamp ASC
LIMIT 100

Étape 3 — Vérifier les problèmes de suivi d'erreurs liés

Si l'enregistrement contient des erreurs console ou des exceptions, trouvez les problèmes de suivi d'erreurs associés :

posthog:execute-sql
SELECT DISTINCT
    properties.$exception_fingerprint AS fingerprint,
    properties.$exception_type AS type,
    properties.$exception_message AS message,
    count() AS occurrences
FROM events
WHERE $session_id = '<session_id>'
    AND event = '$exception'
GROUP BY fingerprint, type, message
ORDER BY occurrences DESC
LIMIT 10

Si des empreintes digitales sont trouvées, recherchez les problèmes de suivi d'erreurs correspondants pour fournir des liens et un statut :

posthog:error-tracking-issues-list
{
  "search": "<exception_type or message>"
}

Étape 4 — Synthétiser l'enquête

Présentez les résultats comme un récit cohérent :

1. Qui — propriétés de la personne (nom, email, pays, forfait, etc.)
2. Quoi — séquence de pages visitées et actions clés effectuées
3. Problèmes — exceptions, erreurs console, rage clicks et leur fréquence
4. Problèmes liés — problèmes de suivi d'erreurs liés avec leur statut (actif/résolu)
5. Contexte — durée de la session, appareil/navigateur, score d'activité

Optionnel : Résumé par IA

Si l'utilisateur souhaite une analyse plus approfondie sans lire manuellement les événements, proposez session-recording-summarize. Avertissez que les premiers résumés prennent environ 5 minutes :

posthog:session-recording-summarize
{
  "session_ids": ["<session_id>"]
}

Astuces

• Exécutez les étapes 1-3 en parallèle si possible — ce sont des requêtes indépendantes.
• Si l'enregistrement a très peu d'événements, la session a probablement été très courte. Notez cela plutôt que de suggérer qu'il y a un problème.
• Le compteur d'erreurs console dans les métadonnées d'enregistrement est un bon indicateur pour déterminer s'il faut approfondir les exceptions. S'il est à 0, ignorez l'étape 3.
• L'start_url de l'enregistrement vous indique où a commencé le parcours de l'utilisateur — utilisez cela pour encadrer le récit.
• Si person est null sur l'enregistrement, l'utilisateur était anonyme. Les propriétés de personne ne seront pas disponibles, mais les événements le sont.