The Account Graph
One canonical buying unit, the contacts that resolve to it, the buying episodes in which it can buy, and the state it was in when treated. Two grains at once, and every measurement downstream depends on which one a number is counted at.
The decision it encodes
Who is this account, who is inside it, and which people resolve to it?
The campaign generated 2,400 leads. The pipeline report shows 60 opportunities. Somebody asks what the conversion rate was and gets four different answers in the same meeting.
The 2,400 leads are people. The 60 opportunities are accounts. Nine of those accounts already had an open opportunity before the campaign ran, four are subsidiaries of one parent that the CRM holds as separate companies, and around three hundred of the leads are people at accounts that were already in a deal cycle and would have appeared regardless. Every one of the four answers is arithmetically correct.
The decision it encodes
Who is this account, who is inside it, and which people resolve to it?
This is the component that makes any number in the system comparable to any other. It is the same job the customer state model does for a lifecycle program, made harder by the fact that the thing being measured and the thing being contacted are different objects.
Two grains, and neither one is optional
The buying decision is where the outcome lives. Pipeline, deals, and revenue happen to a buying unit in a buying episode: a business unit renewing, a region expanding, a new logo’s first purchase. A company can have several of those open at once, so the analytical row is usually the account together with an opportunity or an eligibility period, and “one account per company” is the simplification that fails first in the organizations this system is built for. The graph has to distinguish the legal company, the CRM account, the purchasing unit, the opportunity, the parent hierarchy, and the contacts and their buying-group membership, because each is the right grain for some question.
The contact is where the treatment lands. You market to people. Six people at one company reading a whitepaper is one account touched, not six.
A program that counts at the contact grain will report a campaign as enormously successful because a single interested account sent nine people to a webinar. One that counts only at the account grain cannot say which interventions reached anybody. Both numbers are needed and they answer different questions, so the schema has to carry both and every reported figure has to say which one it is.
| Problem | What it breaks if unresolved |
|---|---|
| Parent and subsidiary | One buying decision counted as four accounts, or four independent buyers counted as one. |
| Contact to account | Free-domain email addresses and personal contacts that never join the company they work for. |
| Buying group | The people who decide are rarely the people who filled in the form, so treatment and outcome sit on different humans. |
| Open opportunity at assignment | Which question the account is eligible for. An account already in a deal cycle is excluded from an estimand about creating pipeline and belongs to one about accelerating it; pooling the two flatters the first with the second. |
| Territory and segment | The strata a design will randomize within, and the level at which sales capacity is allocated. |
| Account state over time | Whether an account was a customer, a prospect, or dormant at the moment it was treated, not what it is today. |
Existing pipeline is the row most often skipped and the one that most often produces a spectacular false positive, because the accounts easiest to influence are the ones that were already buying.
Four questions, four risk sets
An account’s state at assignment decides which question a program can be asked about it. Treating every account as a candidate for “did we create pipeline” is how existing customers and open deals end up counted as marketing’s creation.
| State at assignment | Question | Outcome |
|---|---|---|
| No open opportunity | Did the program create pipeline? | Qualified opportunity created, per eligible account |
| Open opportunity | Did it accelerate or improve the deal? | Time to the next stage, win rate, cycle length |
| Existing customer | Did it expand or protect the account? | Expansion opportunity, retained revenue at renewal |
| Dormant or lost | Did it reactivate demand? | Reopened opportunity or purchase |
Each row is its own population and its own estimand. A program can be measured on more than one of them, and it is reported separately on each, never pooled across the rows.
Point in time, for the same reason it matters everywhere else
Six months after a program ran, the account that was a 200-person prospect is a 900-person customer in a different segment with a different owner. A readout that joins to the account as it is today has stratified on the outcome.
The requirement is identical to the one the lifecycle customer state model sets: every field a design or a readout can read has to be answerable as of a past date. The difference is that B2B outcomes lag by quarters, so the gap between assignment state and current state is much wider, and the error much larger.
Maturity, honestly staged
Stage 1: one canonical account, with contacts resolved to it. Lead counts and account counts stop being confused for each other, which settles most of the recurring arguments on its own.
Stage 2: hierarchy and state at assignment. Each account carries which of the four questions it is eligible for, and a parent stops being counted four times.
Stage 3: point-in-time state. A readout can ask what an account looked like when it was treated rather than what it looks like now.
Stage 4: the buying group modeled. Treatment reaching one person is distinguished from treatment reaching the people who decide, which is what makes a contact-grain effect interpretable at all.
Why the two grains cannot be reconciled by aggregation Technical
Summing contact-level treatment to the account is not a solution, because the aggregation rule is itself a modeling choice with consequences. Any contact touched, a majority of the buying group, or a weighted count each define a different treatment, and they produce different effect estimates on the same data. The rule has to be declared before the readout, for the same reason an outcome window does.
The practical convention that survives scrutiny is to randomize at the account, define treatment as an intention applied to the account, and treat contact-level reach as an exposure measure rather than as the treatment itself. That mirrors the structure the lifecycle system uses for delivery: the assignment is what you randomized, the reach is what happened, and the second is reported alongside rather than used as a filter.
Buying-group reach is a mechanism diagnostic rather than a subgroup. Reach happens after assignment, so “the effect on accounts where two members of the buying committee were reached” selects on a post-treatment quantity and is not a causal effect without an encouragement design or an instrumental argument to identify it. Report the assignment effect first, then reach by arm and the association between reach and outcome as evidence about how the program worked, without treating the reached accounts as if they had been randomized.
Context
Best suited for
Any organization where the outcome is a company buying and the marketing reaches individuals, which is every B2B program and a good share of B2B2C ones.
Data requirements
- A canonical account identifier, with a hierarchy that reflects purchasing rather than only legal ownership
- Contact records resolvable to an account, including the free-domain addresses that will not resolve automatically
- Opportunity history with stage transitions and dates, not just current stage
- Change history on account attributes, since segment and size at treatment are what a readout needs
What changes by context
- B2B SaaS
- The canonical case. Buying groups run to six or more people, product usage gives a second signal of account state, and the tension between self-serve signups and enterprise accounts means one company can appear as both a customer and a prospect.
- Sales-led
- Territory and owner are load-bearing fields rather than metadata, because they are the strata any design will randomize within and the level at which rep effort is allocated.
- Partner-led
- The buying account and the transacting account differ, so the graph has to carry the partner relationship as a first-class edge or attribution to marketing becomes impossible to state at all.
When it breaks down
- Self-serve products where the buyer is an individual and the account is a formality, in which case the lifecycle system is the better fit.
- Markets of a few dozen named accounts, where the graph is a spreadsheet everyone knows by heart and the effort belongs elsewhere.
- Organizations where the CRM is edited freely and no history is captured, since point-in-time state cannot be reconstructed after the fact at any price.