Trouver la meilleure capture pour un problème de suivi d'erreur

Quand un utilisateur dit « montre-moi une capture pour cette erreur » ou « trouve un enregistrement pour le problème X », l'objectif n'est pas juste n'importe quelle session liée — c'est celle qui montre le mieux ce qui a conduit à l'erreur. Les problèmes populaires peuvent avoir des centaines de sessions liées, et la plupart sont des fragments de crash uniquement ou des occurrences dupliquées. Cette compétence sélectionne la plus utile.

Outils disponibles

Flux de travail

Étape 1 — Récupérer les détails du problème

Récupérez le problème de suivi d'erreur pour comprendre ce que vous cherchez :

posthog:error-tracking-issues-retrieve
{
  "id": "<issue_id>"
}

Notez l'empreinte, le nom et la description du problème — vous aurez besoin de l'empreinte pour trouver les sessions liées.

Étape 2 — Trouver les sessions avec cette erreur

Interrogez les événements d'exception pour obtenir les ID de session où cette erreur s'est produite. Classez par récence et incluez le contexte de base :

posthog:execute-sql
SELECT
    $session_id AS session_id,
    count() AS occurrences,
    min(timestamp) AS first_seen,
    max(timestamp) AS last_seen,
    any(properties.$current_url) AS url
FROM events
WHERE event = '$exception'
    AND properties.$exception_fingerprint = '<fingerprint>'
    AND $session_id IS NOT NULL
    AND timestamp > now() - INTERVAL 30 DAY
GROUP BY session_id
ORDER BY last_seen DESC
LIMIT 20

Cela vous donne jusqu'à 20 sessions candidates. Plus de candidats signifie une meilleure sélection.

Étape 3 — Classer les candidats

Récupérez les métadonnées d'enregistrement pour les sessions candidates afin de les classer :

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

Choisissez le meilleur enregistrement en filtrant les mauvais candidats, puis en classant ce qui reste :

Éliminer :

• Les sessions de moins de 10 secondes (fragments de crash uniquement, pas de contexte avant l'erreur)
• Les sessions de plus de 1 heure (trop de données à charger, l'erreur est une aiguille dans une botte de foin)

Classer par :

1. Durée idéale — 2-15 minutes est l'idéal. Assez long pour montrer le parcours de l'utilisateur avant l'erreur, assez court pour être pratique à regarder ou résumer.
2. Rapport de temps actif — comparez active_seconds à recording_duration. Un enregistrement de 20 minutes avec 10 secondes d'activité est principalement des onglets inactifs — l'utilisateur s'est éloigné. Préférez les sessions où active_seconds / recording_duration est supérieur à 0,3 (30 %).
3. Score d'activité — un score activity_score plus élevé signifie que l'utilisateur était activement en interaction, pas inactif. Plus intéressant à regarder.
4. Récence — les sessions plus récentes reflètent le comportement actuel de l'application.

Étape 4 — Présenter le résultat

Récupérez les détails complets de l'enregistrement sélectionné :

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

Présentez à l'utilisateur :

• L'enregistrement avec un lien pour le regarder
• Pourquoi celui-ci — expliquez brièvement la sélection (« la session la plus longue avec l'erreur, l'utilisateur a consulté 3 pages avant de la rencontrer »)
• Contexte avant l'erreur — quelles pages l'utilisateur a visitées et les actions clés avant l'exception, dérivés de la requête d'événements de l'étape 2 (les colonnes url et first_seen)
• Fréquence de l'erreur — combien de fois l'erreur s'est produite dans cette session

Optionnel : Résumé IA

Si l'utilisateur veut un résumé narratif sans regarder :

posthog:session-recording-summarize
{
  "session_ids": ["<best_recording_id>"],
  "focus_area": "<error description or type>"
}

Avertissez que cela prend ~5 minutes pour les premiers résumés.

Conseils

• Si toutes les sessions candidates sont très courtes (<10 secondes), l'erreur plante probablement la page immédiatement. Notez ceci — c'est un contexte utile même sans une longue capture.
• Quand le problème a très peu de sessions liées (<3), ignorez le classement et présentez juste ce qui est disponible avec une note sur la petite taille de l'échantillon.
• Si $session_id est null sur de nombreux événements d'exception, la capture de session n'est probablement pas activée pour les utilisateurs affectés. Mentionnez ceci comme une lacune possible.
• Le paramètre focus_area sur session-recording-summarize est puissant ici — passez le type d'exception ou le message pour que le résumé se concentre sur le contexte de l'erreur plutôt que sur la session entière.