Retracing
Retracing means taking the users who reached a given outcome (converting to paid, paying off CAC, etc) and reading through their event logs to see what patterns turn up. The team doesn't go in with a hypothesis about what mattered; the point is to discover patterns rather than test for them. Disproportionate behavioral patterns (sequences that recur, early actions that keep appearing in users who eventually converted, etc) become candidates for investigating further.
Definition
A method for surfacing candidate behaviors by inductively reading the event logs of users who reached the commercial outcome event, without a pre-existing hypothesis about what to look for.
Reading converter logs inductively
Retracing starts with the population that reached the commercial outcome event and reads their event logs to surface what shows up. Behaviors over-represented in this population, sequences that recur, early actions that characterize users who eventually converted. The output is a list of candidate behaviors generated from the data itself rather than from prior hypotheses about what's driving conversion.
Retracing discovers candidate behaviors. It doesn't verify them. A behavior that emerges from retracing carries no claim yet about its conversion-relevance — that claim is what the verification step is for.
What retracing catches that pre-specified lists miss
Two things specifically that hypothesis sourcing alone tends to omit:
- Unanticipated candidates. If "invited a teammate before starting a project" isn't on the team's list of behaviors to test, multiplier analysis can't find it. Retracing has no such constraint — it surfaces whatever's in the data, including patterns the team didn't anticipate.
- Pattern combinations. "Invited a teammate AND visited pricing within three days" is the kind of compound pattern retracing can surface but that multiplier analysis would only catch if the combination were specifically pre-specified as a candidate.
Where it fits with multiplier analysis
Retracing is generative; multiplier analysis is confirmatory. Retracing produces candidate behaviors from the data; multiplier analysis takes a pre-specified list of candidates and computes the multiplier for each against the conversion baseline, quantifying which carry signal. They're sequential phases of the same investigation rather than competing methods.
The typical sequence: retracing surfaces candidates, multiplier analysis confirms and quantifies them, confirmed behaviors feed downstream apparatus like sorting-hat construction and path investment. Retracing is most useful early in an engagement or when entering a new domain, where the team has limited prior hypotheses about what drives conversion. Once candidates exist — from retracing, from team intuition, from prior investigation — multiplier analysis is the next move.
Retracing can also surface what's not in the logs. Behaviors the offering supports but doesn't instrument would have shown up in retracing if tracked; their absence is a tracking gap the engagement can name and recommend filling.
Example
A team on a project-management SaaS has no strong prior view on which early behaviors distinguish converters. They pull event logs for the last quarter's converting signups and read what's there. Across the logs they notice patterns: a substantial share invited a teammate within the first session; many created their first project from a template rather than from scratch; a non-trivial subset visited the pricing page within the first 72 hours.
None of these were on the candidate list the team had built from feature-list reading and onboarding-flow reading. They go into the multiplier-analysis spreadsheet as additional candidates, and the multiplier numbers determine which carry signal worth investigating further.