SaaS attribution specification
Use this working document to align lifecycle definitions, source data, events, reporting limits, and ownership before asking a dashboard to answer a revenue question.
USE IT FOR
A CRM cleanup, new demand program, reporting rebuild, or any moment when marketing, sales, and product describe the same funnel differently.
The specification
Five sections to agree before the dashboard.
Write the current operating truth, including unknowns. A clear limitation is more useful than a dashboard that hides it behind a single attribution number.
Decisions the model must support
- Which decisions should this reporting make easier: budget allocation, channel learning, sales capacity, activation, or forecasting?
- Which claims must the model never make because the available data cannot support them?
- Who can change definitions, fields, or dashboard logic—and how are changes documented?
Lifecycle definitions and ownership
- Name each stage from first known interaction to customer, expansion, and churn where relevant.
- For every stage, define entry criteria, exit criteria, the accountable team, and the source of truth.
- Record how duplicates, recycled leads, disqualification, reactivation, and sales-created records are handled.
Source and campaign fields
- Specify the original source, latest source, campaign, content, landing page, referral, and account fields that need to persist.
- Set a naming convention for campaign and UTM values before launch; state which system writes each field.
- Identify which values are self-reported, inferred, imported, or unavailable so reports do not imply false precision.
Events and data handoffs
- List the events that matter: form completion, demo booked, meeting held, product activation, opportunity created, closed-won, and any relevant product milestones.
- For each event, define the trigger, timestamp, identifier, destination, owner, and how it is monitored.
- Test that identifiers can connect web, CRM, product, and revenue records without overwriting the original context.
Reporting, caveats, and review
- Name the core report views, their audience, refresh cadence, and decisions they support.
- State the model used for credit and its limits; do not present influenced or correlated activity as causal proof.
- Set a recurring data-quality review for missing fields, stage drift, routing failures, and definition changes.
Before you publish reporting
Make the limits visible to the people using the numbers.
Attribution is a decision model, not a neutral picture of reality. Keep the definitions, data gaps, and crediting rules close to each report so a number is interpreted in context.
If the system cannot preserve the required source or lifecycle data, fix the handoff before using the report to reallocate budget or judge a channel.
Built for the working session
A template should make ownership visible.
Use the structure to bring customer context, a focused constraint, and the people responsible for the next decision into the same conversation.