Sourced, influenced, accelerated: an event attribution primer
Sourced, influenced, accelerated and associated are four different claims. What evidence each one owes, and the guards that keep an event report honest.
- Sourced, influenced, accelerated and associated are four separate claims about the same event. Reporting them as one number is what makes finance stop believing the number.
- Every claim needs two things before it is worth writing down: a rule for what qualifies, and a confidence tier for how the person was matched to the record.
- The guards matter more than the model. A lookback window, one sourced claim per opportunity, and a review queue for weak matches will survive a CFO reading the report line by line.
Somebody in your company is going to ask what the event program produced, and the honest answer is that it depends which question they are asking. The CFO wants to know what would not exist without the events. The VP of Sales wants to know which events help deals move. The event marketer wants to know which of the twelve sponsorships to renew. Those are three questions, and a single pipeline number answers none of them well.
The usual response is to pick one number and defend it. That works until somebody opens the underlying report, finds an opportunity credited to an event that the account executive says was already in flight, and stops believing the rest of it.
The way out is to stop treating attribution as one number and start treating it as a set of claims, each with its own rule and its own evidence. This is a primer on those claims. It is written from the reporting problem rather than from any particular tool, and everything here can be built in Salesforce or HubSpot by hand if you want to.
One number cannot answer four different questions
Consider one account. A director attends your booth session in March. In April, a different person at the same company fills in a form and an opportunity is created. In June, your customer summit hosts two people from the account, and the deal moves from discovery to proposal the following week. In August it closes.
How much of that revenue did the events produce?
Every answer between zero and all of it can be argued. “How much did events produce” is underspecified, and underspecified questions get answered by whoever builds the report, which is how event attribution ends up being a negotiation rather than a measurement.
Break it into claims that can each be true or false on their own and the argument disappears:
- Did an event touch precede the creation of this opportunity, with nothing open on the account beforehand?
- Did an event touch land while this opportunity was already open?
- Did the opportunity move stage shortly after an event touch?
- Did somebody from this account attend, without any link to a person on the deal?
Each of those has a yes or no answer, and each owes different evidence. That is the model.
The four claims, and what each one owes
Each claim carries a different burden of proof, and each one convinces a different person in the room.
| Claim | What it asserts | Evidence it owes | Who it convinces |
|---|---|---|---|
| Sourced | The event created this opportunity | An event touch on a person at the account, before opportunity creation, with no open opportunity at the time of the touch | The CFO. This is the number that survives a budget review |
| Influenced | The event touched an open deal | An event touch on a person at the account, inside the window the opportunity was open | The CMO. It is the honest measure of program contribution |
| Accelerated | The deal moved after the event | A stage change on an open opportunity, after an event touch, inside a defined window | The VP of Sales. This is the claim that justifies customer summits and dinners |
| Associated | Somebody from the account was there | An account-level match with no person-level link to the deal | Nobody, on its own. It is a planning signal, not a revenue claim |
The fourth row is the one teams argue about. Associated is not pipeline. It tells you an account is showing up at the events you are showing up at, which is genuinely useful for choosing next year’s calendar. It is not evidence that your event did anything, and including it in a revenue report is what gets the whole report challenged.
The third row is the one that goes missing from standard reporting models, and it is the one with the clearest sales-side value. Late-stage events exist to move deals. A model that can only express created and touched cannot report what an executive dinner is for.
Match confidence is the second axis
The claims above all begin with the same phrase: an event touch on a person at the account. That phrase covers a matching step, and the matching step is where attribution models go wrong.
A badge scan gives you a name, a title and a company. A conversation at a booth gives you a first name and a business card that may be two roles out of date. An attendee list gives you a company and a job title with no email at all. None of those are a CRM record, and turning them into one is a matching problem with an error rate.
Grade the match before you grade the claim:
| Confidence | Basis | What it should be allowed to do |
|---|---|---|
| High | A work email that matches a known Contact or Lead | Write to the record automatically |
| Medium | Company domain plus a name that agrees | Write to the record, flagged for review |
| Low | Company name only, no person-level agreement | Hold as a suggestion until a human confirms it |
The rule that matters is the third row. Low-confidence matches must not write to the CRM. At a large enterprise, a company-name-only match will eventually attach a booth conversation to the wrong person, and the account executive who owns that account will notice.
This is also the answer to the objection RevOps raises first, which is some version of “will this fill my CRM with rubbish”. The honest answer is that any attribution system will, unless there is a confidence gate and a review queue in front of the write. Ask any vendor where their gate is. If there is not one, the cleanup is your job.
Six guards that keep the numbers honest
The model is the easy part. These constraints decide whether the report holds up when a sceptical reader goes through it.
- A lookback window, written down. Sourced needs a maximum gap between the touch and the opportunity. Influenced needs the opportunity to have been open at the time of the touch. Pick both from your own sales cycle, put them in the report definition, and hold them constant. A window that changes between events makes every comparison worthless.
- One sourced claim per opportunity. Several events can influence a deal and they usually do. Only one can have created it. Without a tiebreak rule, sourced pipeline summed across events will exceed your actual pipeline, and somebody will notice. Earliest qualifying touch is the simplest rule to defend.
- Deduplicate people, then accounts. The same person appears on the attendee list, the badge scan file and the dinner RSVP sheet. Three touches from one human at one event is one touch. Programs that skip this step report attendance numbers that look excellent and pipeline numbers that do not move.
- Never overwrite the original source. Whichever system creates the record writes the event into a field that nothing downstream is allowed to touch. A sequencer that stamps its own value into the source field on sync will erase the event from every report built on that field, and it does it. Event ROI breaks when the CRM is an afterthought covers what else goes wrong when the fields are decided late.
- Keep the claims in separate fields. Sourced and influenced belong in different columns, on the opportunity, with the event name and the timestamp beside them. Once they are added into a single number, the reader has no way to check any part of it.
- No retroactive rewrites. When a deal closes eight months later, resist the urge to go back and improve the attribution. The record of what was known at the time is what makes the trend line real. Corrections belong in a dated adjustment, not in a silent edit.
Guard five is the one that changes how the conversation goes. A finance partner who can see cost, meetings, sourced, influenced and accelerated as separate columns can challenge the column they doubt and accept the rest. A blended number leaves them nothing smaller to challenge than the whole report.
What the report looks like when the model is settled
One row per event, the same columns every time:
| Column | Where it comes from |
|---|---|
| Event cost | The campaign cost field, all-in, including travel and staff time if you can get it |
| Meetings booked before the event | Campaign member status, set before the event |
| Conversations at the event | Booth notes and badge capture, deduplicated |
| Opportunities created | Opportunities with a sourced claim from this event |
| Sourced pipeline | Sum of those opportunity amounts |
| Influenced pipeline | Open pipeline that carries an influenced claim, reported separately and never added to sourced |
| Deals accelerated | Count of stage changes inside the accelerated window |
| Cost per opportunity | Event cost divided by opportunities created |
Cost per opportunity is the column that makes the whole thing operational, because it is the only one that lets you compare a $180,000 flagship sponsorship against a $9,000 regional summit on the same axis. If you want to sanity check the shape before you build it, the event ROI calculator uses the same inputs.
The columns after that are for the CRM owner. The Salesforce event ROI report shape covers the campaign hierarchy and Opportunity writeback in detail, and the HubSpot event ROI equivalent covers the same ground for teams whose CRM is marketing-owned.
The three decisions to make before your next event
None of this is expensive to set up. It is expensive to set up twice, because the second attempt has to reconcile against the first.
Decide the windows. Two numbers, agreed by marketing and RevOps together, written into the report definition. Do this before the event rather than while building the report afterwards, because a window chosen after you have seen the data will be chosen to flatter it.
Decide the confidence gate. What writes automatically, what writes flagged, what waits for a human. Then decide who works the review queue, because an unowned queue stops getting worked.
Decide which claims you will report. Reporting all four is fine. Reporting sourced and influenced only is fine. Reporting a single blended number is the option that fails, and it fails in the budget review.
Attribution built this way is slower to produce and much harder to argue with. For how the matched records land back in the CRM after the event, post-event attribution and ROI covers the writeback path, and your attribution model was built for inbound covers why the defaults you inherited do not fit a booth conversation in the first place.
Frequently asked questions
What is the difference between sourced and influenced pipeline?
Sourced means the event created the opportunity: there was no open opportunity on that account when the event touch happened, and one appeared afterwards inside your agreed window. Influenced means the opportunity already existed and the event touched it while it was open. Sourced is a claim about origin and only one event can hold it. Influenced is a claim about contribution and several events can hold it at once.
What is accelerated pipeline in event reporting?
Accelerated is the claim that a deal moved forward after an event touch. The evidence is a stage change that happened after the touch and inside a defined window, on an opportunity that was already open. It is the most useful claim for late-stage events like customer summits and executive dinners, where the job is moving deals rather than creating them, and it is the claim most reporting models leave out entirely.
How many days should an event attribution lookback window be?
Pick the window from your own sales cycle rather than from a vendor default. A practical starting point is to set the sourced window near your median time from first touch to opportunity creation, and the influenced window to the length of your median open-deal stage. Whatever you pick, write it into the report definition and hold it constant, because a window that changes between events makes every trend line meaningless.
Should low-confidence attribution matches be written to the CRM?
No. Hold them as suggestions for a human to confirm. A match built only on a company name will occasionally attach a conversation at a booth to the wrong person at a large company, and one visibly wrong row is enough for a sales leader to distrust the whole report. Writing only high and medium confidence matches keeps the CRM clean and keeps the review queue short enough that somebody works it.
Can one opportunity be attributed to more than one event?
It can carry influenced or accelerated claims from several events, and it should, because that is usually what happened. It can only be sourced by one event. If two events both claim to have sourced the same opportunity, the model has no tiebreak rule, and the sum of your sourced pipeline across events will be larger than your actual pipeline. Earliest qualifying touch is the simplest tiebreak to defend.
