How to Trace a Closed-Won Cohort Backward - With the Comparison Group

Two labels mark evidence boundaries on this page. Documented marks a platform definition or behaviour directly supported by the linked provider documentation. Recommendation means a workflow, threshold or decision rule that CoreAEX prescribes and no source specifies. Published research is attributed in the prose with its venue, design and scope, and is not tagged - it is evidence about a method, not documentation of how a product behaves. The single Documented tag on this page marks Apple's own description of how Mail Privacy Protection loads remote content; it documents that vendor's product behaviour and nothing about anyone's buyers. Untagged text is ordinary explanation or a conclusion following from something already labelled.

The obvious way to start is to pull your won deals into a spreadsheet and look for what they have in common. The spreadsheet fills up, the patterns appear, and the patterns are compelling - three of your five biggest wins read the same comparison page, two came through the same partner, four had a security review.

That procedure produces a description of your winners. It does not produce evidence about what distinguishes them, and the difference between those two things is the whole subject of this page. The trace has two halves. The first is the chain of joins that runs from a closed-won deal back through the account, the people on it, the touchpoints, the channels, the content and eventually the buyer question behind it all. The second is the same chain, run identically, on the comparable opportunities that did not close. Only the second half lets you ask a question that has an answer: did recorded exposure differ between the winners and the eligible opportunities that lost? Note how much narrower that is than "what separated the winners." A comparison estimates an observed difference in prevalence. It does not establish that the exposure did the separating.

This page is the procedure for both halves, taken from the reverse funnel marketing pillar, which sets out why the design works and what it can establish. Here we are doing it.

What has to be settled before the first join

Three things, and the trace is not improved by starting before they are done. Each belongs to another page in this cluster, which is why this section is short.

1. The outcome and the eligible cohort are fixed. Which stage values count as a win, which opportunities were eligible to reach that outcome, and which cohort period you are working in - decided and written down before you look at any result. The pillar owns this.
2. You know what the fields you are about to join on actually record. A lifecycle stage is a label your team applies; an attribution percentage is a credit rule somebody selected. What your lifecycle stages and attribution fields actually record owns the audit, and its comparability check is this page's entry requirement rather than an optional extra.
3. You have chosen the rung. Whether you are tracing back from closed-won deals or from a proxy outcome further upstream changes what the trace can conclude. Where to start a backward analysis owns the decision, and if you are starting from SQL or MQL rather than closed-won, working from an upstream proxy outcome owns what that substitution changes in the procedure below.

One boundary worth stating plainly, because this site publishes advice that looks like it points the other way. Building or refreshing an ideal customer profile from closed-won and retention patterns - which our ICP-driven content gap analysis workflow asks you to do - is a descriptive use of a winners-only cohort, and it is a legitimate one. Describing who buys from you is a different claim from establishing what distinguishes buyers from non-buyers, and it needs less to support it. That page performs one hop of this trace for a descriptive purpose. This page owns the full chain and the comparison that licenses a distinguishing claim. If you only need to know who your customers look like, you do not need what follows.

The hops, and the rules you are choosing at each one

The trace runs backward through a chain of joins. Each hop answers "and what preceded that?" - and each one is a decision you are making about how records relate, whether or not you notice making it.

The backward chain, hop by hop

Hop	The join you are making	The rule you have to choose	What the hop costs
Won deal → account	Opportunity to the company record	Which account, when a group has several records, and whether subsidiaries roll up	Low. The exposure is a group structure with several account records, not the join itself
Account → contacts	Company to the people associated with it	All contacts at the account, or only those associated with this opportunity, or only those active in the cohort window	The three rules produce different people. The first sweeps in colleagues who had nothing to do with the purchase
Contacts → buying roles	People to the part they played	Whether role comes from a recorded field, from job title, or from a judgement made after the fact	Titles are not roles. A judgement made after the outcome is known is not independent of the outcome
Account → use case	The company to the problem it was buying for	A structured field, a picklist, or free text on the opportunity	Free text is not comparable across reps, and a field completed at close reflects what was sold, not what was sought
Opportunity → touchpoints	The deal to the recorded interactions on it	Which objects count, whose activity counts, and how far back a touch still counts	The heaviest hop. What is present depends on what got logged, by whom, and under what habit
Touchpoints → channels and campaigns	Interactions to their origin	The channel grouping and the campaign membership rule - both configured, both editable	Regrouping channels changes the answer without changing anything that happened
Touchpoints → content consumed	Interactions to specific pages or assets	Whether an anonymous session is stitched to a known contact, and on what basis	Identity stitching is an assumption. Pre-identification browsing is largely invisible
Content → topics	Assets to what they are about	Your own taxonomy	Low risk, and the one hop you fully control - provided the taxonomy was not built after seeing the wins
Topics → buyer questions and queries	Subject matter to the demand behind it	Whether you are describing the page's query profile or that buyer's actual questions	An inference rather than an observation, and the place a claim widens most easily. See below

Three things about that table matter more than the sequence itself.

Every hop is a join, and every join is a rule you chose. None of them is neutral. "Contacts on the account" and "contacts associated with the opportunity" are different populations, and picking one is an analytical decision that belongs in your write-up next to the result, not buried in a spreadsheet formula. Recommendation Record each join rule in the same document as the finding, in the form "we joined X to Y by Z, and the alternative was W." A trace whose join rules are not written down cannot be repeated, and a trace that cannot be repeated cannot be tested later.

The last hop is an inference, not an observation, and it should be labelled as one. You can observe that an opportunity's contacts read three pages. You can observe what queries those pages rank for or receive impressions on. What you cannot observe is that this buyer arrived with those questions - you are describing the page's demand profile and attaching it to a person who may have arrived from a newsletter, a colleague's link or a saved bookmark. That inference is often reasonable and worth making. It stops being reasonable the moment it is written as a finding about the buyer.

The role hop needs the vocabulary another page owns. Going from contacts to buying roles without inventing them means using a defined set rather than reading titles - mapping content gaps to the buying committee sets out the roles and the buying jobs this site uses, and notes that buying groups loop between those jobs rather than moving through them in a fixed order. Use that vocabulary here rather than a new one. And note the direction of the risk: assigning roles retrospectively, once you already know which deals closed, is a judgement made in full view of the outcome. Recommendation Assign roles from recorded fields where they exist, and where they do not, have the assignment done blind to the outcome - by someone who cannot see the win or loss column, or from a snapshot taken before the deal closed.

Which design you are running, and over what window

Name the design before you build anything, because two of them live under the same procedure and they do not license the same numbers.

• If you retain every eligible won and lost opportunity in the window, this is a retrospective cohort comparison. If every eligible opportunity has also reached the prespecified outcome horizon, cohort outcome rates are estimable: you can say what share of exposed opportunities were won. If some are still open at the cutoff, report them, and then either describe what you calculate as conditional on closure by that cutoff or move to a time-to-event or competing-risk analysis. That qualifier is not only about absolute rates. A contrast between exposed and unexposed groups is also computed from the closed records alone, and the unresolved deals could sit anywhere in it - so an odds ratio, a risk difference and a win rate all inherit the same condition. A rate calculated on the closed records alone is not the cohort's win rate, whatever the sample size, and a contrast calculated on them is not the cohort's contrast.
• If you retain all the wins but deliberately sample the losses, it is a case-control sample. You can still compare exposure odds between the groups, but outcome-dependent sampling changes which absolute probabilities and population rates you can estimate without weighting or correction. A raw win rate calculated inside a sampled set is not your win rate.

Both are legitimate. What is not legitimate is running the second and reporting the first. Recommendation Write down which of the two you are running, in one sentence, before you pull a single record - and if you sampled, write down the source population, the sampling rule and the sampling fraction alongside it.

Fix the exposure window at the same time

Deals that run longer accumulate more of everything, so a comparison between a long-cycle group and a short-cycle one measures duration as well as difference. The clean answer is to equalise the opportunity to be exposed by design rather than to subtract the difference afterwards.

Recommendation Define a common exposure window before you look at results, measured relative to each opportunity rather than to the calendar - the first thirty or sixty days after opportunity creation, say, or a fixed window before close where that choice does not depend on knowing the outcome. Compare only events recorded inside that window, and re-run across two or three other reasonable windows to see whether the answer moves. Raw touch counts accumulated over unequal durations are not comparable. Where the timing itself is the question, that is time-to-event work rather than a prevalence comparison.

Building the comparison group

The comparison group is the half that makes the other half mean something, and it has a published design behind it rather than being a matter of taste.

Bernard Forgues sets out the case-control approach for strategic organization research in a peer-reviewed methodological essay (Strategic Organization, 2012). His argument is that selecting on the outcome is a recognised design rather than an automatic error - and that it is valid under conditions he then specifies. The conditions are the load-bearing part. He gives four design steps, and they map onto a CRM cohort almost directly.

Step one: "Defining the dependent variable"

Forgues' requirement is a clear-cut boundary that dichotomises the outcome. In a pipeline that is less obvious than it sounds, and the questions are yours to answer before you start: does a renewal count as a win, or only a new logo? Does an expansion on an existing account? What about a deal that closed won and churned inside ninety days - is that a case, or is it a different outcome you have not defined yet? Whichever way you answer, answer it once and in writing. What "closed won" actually is in your configuration is the page that helps you find out what your own system is doing.

Step two: "Selecting cases"

Either take all available cases or select them at random. What you must not do is choose the interesting ones, and the failure mode is subtler than it sounds - dropping the two wins that came through an odd route because they are "not representative" is a selection made after seeing the data, and it is the kind of choice that manufactures a clean result.

Forgues also names a hazard specific to retrospective work: prevalent cases are length biased, "in that prevalent cases having occurred earlier have longer exposure frequencies." Translated: a deal that took fourteen months to close has had fourteen months in which to accumulate touchpoints. If your cases skew long-cycle and your controls skew short, some of what you find is duration rather than difference. That is what the common exposure window above is for, and it is why the window is set by design rather than corrected for afterwards.

Step three: "Choosing controls"

The requirement is that controls "should be representative of the population at risk of becoming cases," and that phrase does the most work of anything on this page.

One risk set per outcome. Having accepted that you need non-winners, the tempting move is to sweep in every record that did not become revenue - disqualified leads, accounts that never replied, deals that died before an opportunity existed. But a disqualified lead never became a qualified opportunity, so it was never at risk of becoming a closed-won one under the same stage definition. It is not a control for this analysis. It may be a perfectly good control for a different analysis, at the stage it actually reached. Recommendation For a closed-won outcome, the controls are the comparable closed-lost opportunities from the same eligible, mature cohort. Still-open opportunities are neither: they have not had an outcome, and folding them into the loss group misrepresents them.

Step four: "Determining the number of cases and controls"

More controls buy statistical power, and the return falls off. Forgues states it in full as: "For a given number of cases, increases in the ratio of controls to cases lead to gains in statistical power until a certain point is reached. Beyond a ratio of 4 to 1, gains in power are usually minimal." Note the "usually," and note what the sentence is about - the marginal power bought by adding controls.

That makes four-to-one a data-collection rule of thumb, not an analytical ceiling. Recommendation When every eligible loss record is already available and comparable, retain them all: there is no benefit in discarding clean records to hit a ratio, and the sentence above says nothing about doing so. When reconstructing controls is expensive - a manual pull, a stitched history, a data request to another team - a random sample of roughly four controls per case is a defensible stopping point, and then you document the source population, the sampling rule and the sampling fraction, and analyse in a way that accounts for the design.

If you have forty wins and sixty comparable losses, you use the sixty and you say so. What the ratio does not do, in any of these cases, is tell you whether your counts can separate anything - that arithmetic lives on the starting-point page, and it depends on the denominators, the difference you care about and the design, not on the ratio.

Matching is optional, and the wrong match is worse than none

Forgues is direct about the first half of that: "Although it is quite common to match controls to cases, this is in no way required, and the logic is different." He adds a condition that is routinely dropped - "matching can eliminate biased comparisons in case-control studies only if subsequent analyses account for matching" - and, on the cost of doing it, "let me insist once again that it is not an essential part of case-control designs."

The second half is where a reusable list of matching fields does damage. Choose matching or adjustment variables from a causal model you write down before the analysis, not from a checklist. The rule has three parts:

• Prefer baseline common causes measured before the exposure - cohort period, market, segment, product line - and only where they plausibly affect both the exposure and the outcome.
• Never match on the exposure you are testing. If you are asking whether a channel is associated with winning, matching on acquisition source removes the variation you came to measure.
• Do not automatically match on variables measured after the defined exposure. Stage progression, logged activity and opportunity duration may be downstream variables, mediators, or genuinely pre-exposure ones, depending on when each was measured relative to the exposure you are testing - activity logged in the month before a first content touch is not the same variable as activity logged across the whole deal. Establish the temporal and causal role of each one, for each exposure, before matching or adjusting on it. Where it is downstream or mediating, conditioning on it can block part of the association you are looking for, or introduce a new bias.

Recommendation If you do match, keep the matched-set identifiers in the data and use an analysis that accounts for the matching - a matched analysis, not an ordinary comparison run on matched rows.

One clarification, because this site publishes a matching list. Measuring content-market fit sets out ICP tier, acquisition source, opportunity stage and age, deal-size band and comparable sales-contact intensity as the fields to align for engaged-versus-unengaged account comparisons. That is a different design with a different exposure, and the same variable can be a baseline confounder in one and a candidate exposure or a downstream variable in another. Acquisition source is a confounder when the exposure is content engagement and a candidate exposure when the exposure is the channel itself. Take the discipline from that page - align before comparing - and derive the actual variable list from the causal timing of the comparison you are running here.

Matching does not create causality in either design. It can make a comparison less structurally misleading, which is a smaller and more honest claim.

When the losing side is recorded worse

This condition decides whether a real CRM can support the design at all, and it deserves its own section because the naive response to it is to give up.

Forgues states the requirement with an exception that matters:

"Following the comparable accuracy principle, independent variables should be measured with the same accuracy in controls as they are in cases, unless the effect of inaccuracy is controlled in analyses."

Read the last clause. Unequal measurement is not fatal. It has to be either fixed or accounted for, and both routes are legitimate. That distinction is the difference between "our CRM is too messy for this" and "we know which fields are usable and which need adjusting."

The asymmetry is structural rather than accidental. Deals that progress accumulate more logged activity because there is more activity to log and more incentive to log it; a deal that died in month two has less history because less happened. Both mechanisms push the same way, which is why the direction of the bias is predictable even when its size is not.

Two routes, and you choose per field rather than for the whole analysis. Recommendation

• Equalise. Restrict the analysis to fields whose collection rules and capture coverage were stable and comparable across cases and controls. System-written fields are candidates for that, not automatic passes - the audit is what qualifies them. Check consent and tracking coverage, identity stitching, privacy or security automation, platform configuration, and whether the field's definition or the tracking behind it changed inside your cohort window. Report unknown and unobservable states separately rather than folding them in.
• Adjust, where equalising is impossible. Use a validation sample where you know the true value for a subset, a documented measurement model, a restriction to teams or periods whose capture was stable, an explicit missingness analysis, and sensitivity checks across the assumptions you had to make. Choose covariates by the timing rule above, not by their correlation with logging volume - the obvious candidates here (opportunity age, days in stage, activity count) are exactly the post-exposure variables that rule excludes. And treat survival after adjustment as a robustness result, not as proof that the recording bias is gone.

An illustration of why "the system wrote it" is not enough. Email opens are the standard example of a machine-written field that looks clean. Apple documents that its Mail Privacy Protection feature "downloads remote content in the background by default - regardless of whether you engage with the email," and its Mail support guidance describes remote content being "privately downloaded in the background when you receive a message (instead of when you view it)," with the sender prevented from learning "when and how many times you view it." Documented An open event of that kind is generated by a mail platform rather than by a person, and security scanners can generate clicks on the same principle. The values were written automatically and consistently; what they measure is not what the field name says, and the mix of clients can differ between two groups of deals for reasons having nothing to do with buying intent.

And one rule that is not negotiable either way: an absent record is not an absent touchpoint. A blank field on a lost deal means one of three things - the thing did not happen, the thing happened and was not recorded, or the field was never in use for that record's period or team. Those are different, and collapsing them into "no" is how a logging gap becomes a finding. Recommendation Carry a third state through the analysis. Where a field cannot distinguish "did not happen" from "not captured," code it as unknown and report the unknown share for cases and controls separately - if the unknown share differs between the two, that difference is a result about your data, and it has to be reported before any result about your buyers.

What the output is: one row per opportunity

The shape of the output decides what question you are answering, and getting it wrong is easy because the wrong shape is the one that falls out of a touchpoint export naturally.

The unit of analysis is the opportunity. One row, won or lost, with the exposures collapsed onto it. If your rows are touchpoints, you have changed the question from "did opportunities with this exposure win more often" to "were there more touches" - and a single long deal with sixty logged activities will dominate the second question while counting once in the first.

A workable row has five blocks, and the separation between the second and the third is the point of the previous section:

1. Identity and outcome. Opportunity ID, account ID, cohort period, and the outcome as three states - won, lost, still open - never two.
2. Eligibility and candidate baseline covariates. Segment, market, product line, deal-size band - the things fixed before the exposure could occur. These are the candidates for matching or adjustment, subject to the causal-timing test above.
3. Timing and process variables. Opportunity age, days in stage, logged-activity count, sales-contact intensity, exposure-window length. Keep them, because you need them to check the design and to run sensitivity work - but keep them here, in their own block, so they are not treated as confounders by default. Their timing relative to each defined exposure has to be established before they are used analytically.
4. Exposures. One column per thing you are testing, as a yes/no/unknown, or a count where a count is meaningful and the exposure window is equal. Whether a topic was consumed, whether a channel appeared, whether a role was present.
5. Provenance. For each exposure column, the capture rule behind it, whether the value was system-written or human-entered, whether the tracking or definition changed inside the window, and the unknown share for cases and controls separately. This is the block people skip, and it is what lets the comparable-accuracy question be answered rather than assumed.

One row per opportunity is necessary and not sufficient, because opportunities may not be independent when the same account or contact contributes multiple rows. One account can produce several - a lost deal last year and a won one this year, two product lines, two regions - and those rows share firmographics, stakeholders, content history and often the same rep and sales process. Treating them as independent observations overstates your precision, and the intervals you report can then be too narrow for what the data supports. Recommendation Record the account ID on every row and identify repeat opportunities before analysing. Then either define one eligible opportunity per account by a rule set in advance, aggregate to the account, or use an analysis that clusters uncertainty by account. Do not compute independent-row intervals once you know independence is violated.

Not every won deal will be traceable, and that is a result rather than a problem to hide. Some wins have no usable touchpoint history, some accounts predate your current stack, some records were merged. Recommendation Report the traceable share alongside the finding, and check whether the untraceable deals differ from the traceable ones on the fields you do have. If they do, the analysis is running on a subset chosen by data availability, which is its own selection rule and needs saying out loud.

A worked trace, on a company that does not exist

Northwind Ledger is a fictional mid-market accounting-automation vendor, invented for this example, and every number below is round and illustrative rather than a benchmark. No CoreAEX client data appears on this page.

Northwind fixes the outcome as new-logo closed-won, excluding expansions. It defines a twelve-month opportunity-creation cohort and sets an analysis cutoff that gives every opportunity in it at least four months of follow-up. At that cutoff the cohort contains 46 closed-won opportunities, 120 comparable closed-lost ones, and 25 still open - the open ones reported as their own group and folded into neither of the others. Because 25 of the cohort's 191 opportunities are unresolved, everything Northwind calculates below - rates and contrasts alike - is conditional on closure by the cutoff, and that qualifier travels with every number in the table. Six of the 46 wins have no usable touchpoint history - older accounts migrated from a previous system - so the exposure analysis runs on 40 cases, and the six are described rather than dropped silently: they are larger and older than the rest, which is stated next to every result below. Forty cases against a hundred and twenty controls is a three-to-one ratio - below Forgues' point of diminishing returns, so all 120 controls are used rather than sampled.

The naive version of this analysis pulls the 40 wins and reports that 30 of them, 75%, touched the pricing-comparison page. Written up, that becomes "three quarters of our wins engage with pricing content," and from there it is a short step to a budget decision.

Running the same trace on the 120 controls produces the number that changes the conclusion:

Northwind Ledger (fictional): two exposures, traced on cases and controls

Exposure	Wins (40)	Comparable losses (120)	Direct contrast
Touched the pricing-comparison page	30 - 75% [60%-86%]	80 - 67% [58%-75%]	Among opportunities closed by the cutoff, unadjusted exposure odds ratio 1.50 [0.67-3.37]
Demo attendance logged	38 - 95% [84%-99%]	40 - 33% [26%-42%]	Not interpretable until the differential recording is resolved

Group percentages carry 95% Wilson intervals, the method the starting-point page recommends at these sample sizes. The odds ratio carries an approximate 95% interval on the log scale.

Read the fourth column, not the first two, and this is worth being pedantic about because the shortcut is so natural. Two separate intervals describe two separate estimates. Whether they overlap is not a test of the difference between them, and neither is "one is significant and the other is not."

Altman and Bland make both halves of that explicit in a BMJ Statistics Note on comparing two estimates (2003). On the first: "it is not correct to assume that when two confidence intervals overlap the two estimates are not significantly different." On the second: "It is not sufficient for the relative risk to be significant in one subgroup and not in another." And on what to do instead: "Statistical analysis should be targeted on the question in hand, and not based on comparing P values from separate analyses." Their worked example is a subgroup comparison inside a medical meta-analysis, and the method they set out estimates the difference between two ratios; the principle is what carries across, and the principle is that the question is about the contrast, so you estimate the contrast. Here that is the exposure odds ratio, computed directly from the counts - the natural unadjusted comparison in a design where the groups are defined by outcome.

Two conditions travel with that method, and both bite on a cohort this size. Altman and Bland require that "the two estimates should be independent, not obtained from the same individuals," and that "the samples should be large." The first is the account-clustering problem from the previous section wearing different clothes: if the same account contributes rows on both sides of the comparison, the two estimates are not independent, and that has to be dealt with before the contrast means anything. The second is a caution about the arithmetic itself. They also note that "there is limited power to detect interactions," which is the same warning the starting-point page gives about denominators.

So the first row is the point of the whole procedure, and its conclusion is "inconclusive" rather than "nothing." The winners-only version produced a striking 75% and a clear recommendation. The direct comparison produces, among the opportunities closed by the cutoff, an odds ratio of 1.50 with an approximate interval running from 0.67 to 3.37 - a point estimate above 1, an interval that crosses it, and a range wide enough to contain both a meaningful association and a meaningful one in the opposite direction. This sample does not show clear separation, and it is too imprecise to rule one out. What the comparison group has done is prevent the 75% from becoming a budget decision. What it has not done is show that pricing-page consumption is irrelevant.

And take the large-sample condition seriously rather than nodding at it. That 0.67-to-3.37 interval is a normal approximation on the log scale, and the smallest cell in the table has ten records in it. Recommendation At counts like these, pre-specify an interval method appropriate to the design, and optionally report an exact conditional interval as a sensitivity check. Here the approximate log-scale interval is 0.67 to 3.37 and the exact conditional interval is 0.63 to 3.79; both support the same conclusion. If the methods differ materially, report their assumptions and both results - do not select whichever interval turns out to be wider. Choosing an interval after seeing which one you prefer is a decision made in view of the answer, and exact conditional intervals can be conservative rather than simply better.

The second row is the trap the previous section describes, and the correct move is to refuse it. A 62-point gap is enormous, and the first question is not "how do we get more demos" but "is demo attendance recorded to the same standard on both sides?" At Northwind it is not: demos are logged by the rep who ran them, and reps log more against deals that are progressing. So the exposure is not interpretable as it stands, and no odds ratio is reported for it - a number that large computed on a field that unevenly captured would be worse than no number. Under the equalise route it comes out of the analysis. Under the adjust route it needs a validation sample or a documented correction - not a regression on logged-activity count and opportunity age. Both of those are measured across the life of the deal here, which puts them downstream of the very progression that produced the recording gap - and establishing that, rather than assuming it, is what the timing rule asks of you. Surviving that kind of adjustment would be a robustness note, not a finding.

One more thing Northwind writes down, because it will be asked about later: the join rule for contacts was "associated with the opportunity" rather than "at the account," which excluded roughly a third of the people at those companies. It sits in the same document as the result, next to the note about the six untraceable wins, so that anyone re-running the trace in six months runs the same one.

What you have at the end, and what it is not

A completed trace with a comparison group gives you a list of candidate differences between cases and controls, on a defined cohort, with intervals around each one and a written record of every join rule that produced them.

It does not yet give you a finding, and it is worth being precise about why, because the wrong reason is easy to reach for. A comparison-group trace produces an observational association. The threats to it are these, in roughly the order they bite:

• Confounding by baseline account characteristics - something that was true of the account before any exposure occurred, and that affects both the exposure and the outcome.
• Differential recording - the comparable-accuracy problem, which is a property of your CRM rather than of your buyers.
• Selective traceability - the analysis runs on the opportunities that could be traced, and those were not chosen at random.
• Non-representative control selection - controls that were not drawn from the population at risk of becoming cases.

What is not on that list is the case-control selection itself. Retaining wins and eligible losses and comparing them is the design; it is what makes the trace interpretable at all. Hernán, Hernández-Díaz and Robins describe a structure in which "a conditional association between E and D will occur within strata of a common effect C of 2 other variables, one of which is either exposure or a cause of exposure and the other is either the outcome or a cause of the outcome" (Epidemiology, 2004 - a theoretical paper using causal diagrams, with epidemiological examples). That structure requires inclusion or conditioning to depend on a common effect. Choosing cases and controls by outcome is not automatically an instance of it, and describing it that way would make a sound design sound broken.

Where the structure can apply on this page is traceability. Traceability can create collider selection when inclusion depends on the exposure or its causes and, separately, on the outcome or its causes. Marketing exposure may generate the very events that make a deal traceable, while deal progression independently increases how much gets logged - two arrows into the same inclusion criterion. Whether conditioning on usable history actually biases the exposure-win association depends on the complete causal structure, and that is something to establish with an explicit causal diagram rather than to assume from the fact that both things affect logging. Drawing it is a short exercise and it is the point at which you find out whether your traceable subset is a problem or merely a smaller sample. Either way, the traceable share and the comparison of traceable against untraceable records belong next to the result. The other instance is the winners-only analysis this page exists to replace: filter to the wins and you have conditioned on the outcome directly, which is the case the pillar sets out and the page on patterns and artefacts works through in full.

Building the comparison group is what makes the trace interpretable. It is not what makes a surviving difference true.

So the trace hands off immediately. Before a candidate difference becomes anything you act on, it goes through selection, survivorship, multiplicity and halo - four mechanisms that can produce a difference of exactly this shape from data of exactly this kind. That is the next page in this cluster, and it is not optional reading after this one.

What a completed trace licenses

What you ran	What you can say	What you cannot
Winners only, no comparison group	This is what our closed-won accounts look like, and here is the profile they share	That any of it distinguishes them from the deals that lost, in any wording
Every eligible win and loss retained, every opportunity past the outcome horizon, fields of comparable capture quality	A retrospective cohort comparison: in this cohort, recorded exposure prevalence differed between wins and eligible losses by this much, with an interval on the contrast itself - and cohort outcome rates are estimable	That the exposure caused, drove, led to or made the wins more likely
The same, but opportunities remain open at the cutoff	A descriptive exposure contrast among opportunities closed by the cutoff, explicitly labelled as conditional on closure, with exposure patterns among the still-open group assessed alongside it - and time-to-event or competing-risk methods when the target is the complete cohort outcome	A cohort win rate, or any rate or contrast presented as final while part of the cohort is unresolved
All wins retained, losses deliberately sampled	A case-control sample: the exposure odds ratio, with the source population, sampling rule and fraction stated	A win rate, a conversion rate or any population share read off the sampled set without weighting
Either design, but the field's capture rules differ between the groups	Here is a difference, and here is the part of it that may be a recording difference	Anything about buyers, until capture is equalised or a validated correction is in place
Any of the above, before the artefact checks	Here is a candidate difference worth testing	That it is a finding

That table assumes the trace was run from closed-won. If it was run from an SQL or MQL cohort instead because closed-won was too thin to support it, the same table redrawn for a proxy outcome - what each rung of substitution still lets you say - is worked out on its own page.

---

Sources

Sources. Case-control design, the four design steps, the controls-to-cases ratio and the comparable accuracy principle: Bernard Forgues, "Sampling on the dependent variable is not always that bad: Quantitative case-control designs for strategic organization research," Strategic Organization 10(3), 2012, pp. 269-275 - a peer-reviewed methodological essay in a strategy journal, not an empirical test in a marketing setting; its conditions are the load-bearing part and travel with every use of it. The four steps are quoted by their own names; the ratio sentence is quoted in full, including the clause establishing that it concerns the marginal power gained by adding controls for a given number of cases, so it is a collection-efficiency guide rather than a cap on how many eligible records may be analysed; the statements that matching is "in no way required" and that it "can eliminate biased comparisons in case-control studies only if subsequent analyses account for matching" are both quoted directly, because the second is the condition that decides whether matching helps or merely reassures; and the comparable-accuracy sentence is quoted in full including its exception clause, "unless the effect of inaccuracy is controlled in analyses," because unequal measurement between wins and losses may be either corrected or adjusted for and both routes are legitimate. The "representative of the population at risk of becoming cases" formulation is Forgues drawing on Schlesselman (1982). The application of all of it to a CRM opportunity cohort is CoreAEX's, not the author's. Structural selection bias: Miguel A. Hernán, Sonia Hernández-Díaz and James M. Robins, "A Structural Approach to Selection Bias," Epidemiology 15(5), 2004, pp. 615-625 - a theoretical paper using causal diagrams with epidemiological examples; the authors note that their structural definitions "might not coincide perfectly with the traditional, often discipline-specific, terminologies." The paper is used here only for the collider structure - inclusion or conditioning on a common effect - and this page is deliberate about not applying it to ordinary case-control selection by outcome, which is a design rather than a bias; confounding by baseline characteristics and selection on a common effect are kept as separate ideas throughout. The two applications made here, to traceability-based inclusion and to the winners-only filter, are CoreAEX's, stated as applications of a general structure rather than findings about sales pipelines. Comparing two estimates: Douglas G. Altman and J. Martin Bland, "Interaction revisited: the difference between two estimates," BMJ 326(7382), 25 January 2003, p. 219 - a Statistics Note, which is a short methods column rather than a research paper, illustrated with a subgroup comparison inside a published meta-analysis of hormone replacement therapy and non-vertebral fractures. It is cited here for two statements of principle, quoted directly: that overlapping confidence intervals do not establish that two estimates are not significantly different, and that significance in one subgroup and not another is not sufficient. Its stated conditions travel with it and are reproduced on the page rather than in this note: the two estimates "should be independent, not obtained from the same individuals," and "the samples should be large." The method the note sets out estimates the difference between two ratios on the log scale; this page instead computes the exposure odds ratio directly from the counts, which answers the same question in one step for a 2×2 table - the note is the authority for targeting the analysis on the contrast, not for the particular estimator used here. The odds ratio, its approximate interval and the exact conditional interval quoted alongside it are ordinary arithmetic on the illustrative counts. Machine-written fields and capture quality: Apple, "Mail Privacy Protection & Privacy" (page dated 2025-12-12, reviewed September 4, 2026) - "Protect Mail Activity downloads remote content in the background by default - regardless of whether you engage with the email"; corroborated by Apple's Mail user guide, which describes remote content "privately downloaded in the background when you receive a message (instead of when you view it)." This is vendor documentation of one vendor's product behaviour, cited as an illustration that an automatically written event may not record what its field name implies; it is not evidence about the size of that effect in any dataset, and no figure is attached to it. Buying-committee roles and buying jobs, and the observation that buying groups loop between those jobs, are taken from this site's own page on mapping content gaps to the buying committee, which owns that vocabulary. Matching fields, win-rate denominators, lookback windows and the content-sourced versus content-influenced distinction belong to measuring content-market fit. The Wilson interval recommendation at these sample sizes, and the sample-size arithmetic the ratio does not answer, belong to where to start a backward analysis, which cites Brown, Cai and DasGupta for it. Northwind Ledger is fictional and its numbers are illustrative. No client data, first-party dataset or case study appears on this page; the intervals shown are ordinary Wilson intervals computed on the illustrative counts, and they are arithmetic rather than evidence about anything.

This page is part of the reverse funnel marketing cluster. The rest of the sub-pillars are in production and will be linked here as they publish.