Diagnosing a Leak: Recordings, Surveys and Support Tickets
Step rates say where; diagnosis needs evidence of why. This guide runs a leak diagnosis end to end: the recording sample, the survey question, the support-ticket read, and how to write the finding so the repair is aimed at a cause, not a symptom.
The short answer
Diagnose with three evidence types in sequence. Recordings show the behaviour at the leaking stage (where visitors hesitate, err and leave). A short survey or question captures the reason in the visitor's words (the doubt, the missing fact, the price reaction). Support tickets and chat logs corroborate at scale and supply the exact vocabulary. A finding is ready to repair when it can be written as one sentence naming the cause, the stage and the evidence: 'Checkout starters on mobile abandon at the delivery step because the date is shown as a range they cannot plan against - seen in 9 of 20 recordings and named in 6 of last month's 14 delivery tickets.' Anything vaguer is a symptom with good PR.
The recording sample: who to watch
Sample deliberately: sessions that reached the stage and left (the leak in action), a smaller set that passed the stage (the contrast that shows what success looks like), and sessions from the segment where the step rate moved (mobile, a source, new visitors). Twenty to thirty sessions per diagnosis is usually enough for the pattern to repeat itself into visibility. Watch at natural speed for the first pass - the hesitation is the data - and note timestamps of the moments that matter so the team watches evidence, not summaries of evidence.
The one-question survey
Where a question can be asked - on the exit path, post-purchase, in the follow-up - ask the diagnostic one: 'What nearly stopped you?' or, for the stage, 'What were you looking for that you did not find?' Keep it single, optional, open-texted; multiple-choice lists teach you your own hypotheses back. Read every answer the first months; code them into themes only when volume forces it. The answers' value is their vocabulary: visitors name the leak in the words your repair copy should later use.
Support tickets as funnel data
Tag or tally tickets by funnel stage monthly: delivery questions before purchase are a product-page leak speaking; 'where is my order' volume after it is a post-sale communication leak; questions your pages claim to answer are answer-placement failures with names and dates. Tickets are the only evidence stream that arrives uninvited and continuous, which makes their trend the funnel's background monitor. A repair that works shows in the tickets before it shows in the quarter's rates; a repair that misses shows there too.
Triangulation: when the streams disagree
The streams will disagree, and the disagreements are informative. Recordings show hesitation at price while surveys blame delivery: both can be true for different segments - split the evidence by the segment before averaging it into mush. Surveys praise the page while the step rate falls: the respondents are the survivors; the leavers' evidence is in the recordings. Hold the streams side by side in the finding, name the segment for each, and let the repair sequence follow the segment economics rather than a false consensus.
Write the finding so it can be acted on
The diagnosis document is short: the stage and its rate, the finding sentence, the evidence (counts of recordings, quotes, ticket tallies), the proposed repair, and the read rule for verifying it. File it in the change log before the repair ships. This format disciplines everything upstream - vague evidence cannot fill it - and everything downstream, because the verification compares against a stated cause, not a hope. A quarter of such documents is a research asset competitors cannot buy; it is also, not coincidentally, the audit bench's core method.
Watching recordings well: ethics and craft
Recording tools should be configured to mask form inputs and personal data, and the team watching them should work to a simple ethic: you are watching your own shop's failings, not judging the visitor. Practically, keep sessions anonymised in notes (describe behaviour, never identity), and respect the consent settings your privacy setup applies - the analytics bench covers consent configuration. Craft matters too: diagnose in pairs where possible, because two watchers catch different behaviours, and write observations as behaviour ('retyped the postcode three times') rather than interpretation ('was confused'), keeping the interpretation for the finding, where it can be argued with.
Sources and evidence on the record
- Microsoft, Microsoft Clarity documentation - heatmaps, session recordings and frustration signals such as rage clicks.
- Google, Google Analytics support - reports, events, key events and funnel documentation.
Evidence basis: Method guide. Any figure quoted is attributed to a named published source listed below; worked examples are labelled illustrations with round numbers, not measurements. Applies when: Any stage whose step rate says 'leak' but not 'why'