Revenue Attribution Field Map

Id

RLR-34

Link

6

Link Name

Attribution + Decision Intelligence

Role

template

Loop Step

Repair

Purpose

Define the canonical fields required to connect every Revenue Chain stage from original source through revenue and gross profit, establishing a logical data contract the whole business can implement in any CRM. When the Attribution Integrity Audit (RLR-33) finds broken or missing attribution, this Field Map is what the business installs to repair it.

Governing Principle

Attribution is a data contract, not a report. Every stage of the Revenue Chain must write specific, defined fields into a system of record, on a defined schedule, with a defined overwrite rule — so the trace survives from first touch to revenue. The single most important rule: ORIGINAL SOURCE is captured once and never silently overwritten by later activity.

Original Vs Latest Source

Rule

Original Source and Latest Source are distinct, separately stored fields. Original Source is written once, at opportunity creation, and must NEVER be silently overwritten by later activity (only an audited correction may change it). Latest Source may update (overwrite) on each new touch. A system that has only one 'source' field, overwritten on every interaction, fails this contract because it destroys the original-source trace the audit depends on.

Original Source

First-touch source that created the opportunity. Immutable after creation.

Latest Source

Most recent touch/source before the measured action. Mutable.

Crm Agnostic

Note

This Field Map is CRM-agnostic at the methodology level. The field names below are canonical business definitions; each business maps them to its own CRM/system field names. Platform-specific examples are illustrative only and must not make the contract dependent on one CRM.

Platform Examples

A HubSpot 'Original Source' property or a Salesforce 'LeadSource' + custom 'Original_Source__c' can hold the canonical Original Source, provided it is set once and protected from overwrite.; Call-tracking platforms (e.g. CallRail, WhatConverts) can populate Source and Call Tracking Source; the contract requires the value to persist onto the CRM record, not just live in the call-tracking tool.

Field Groups

Data Contract Rule

A field is only 'implemented' when every stage that should write it actually writes it, into its system of record, on its defined schedule, respecting its overwrite rule. Partial population is a data leak the Attribution Integrity Audit (RLR-33) will catch on re-measurement.

Measured Vs Modeled

Rule

This map governs MEASURED attribution fields only. Modeled figures (e.g. Revenue Leak Calculator projections) are never written into these fields or presented as if reconciled from them.

Compliance Guardrail

The Field Map instructs the business to capture only the attribution and outcome data it needs, under its approved privacy, retention, and consent policy. It does not require storing unnecessary personal or financial data, respects opt-outs and suppression, and never recommends bypassing provider or platform restrictions. Jurisdiction- and industry-specific requirements are applied by the operator.

What To Measure

Whether every canonical field — across Identity, Source, Response, Qualification, Follow-Up, Booking, Outcome, and Governance — is actually captured, in its system of record, with original source protected from overwrite, so the Revenue Chain connects source to revenue.

Data Required

The business's current CRM/telephony/scheduler/billing field inventory, mapped against this canonical field list to expose which required fields are missing, mutable when they should be immutable, or stranded in a tool instead of the system of record.

How To Interpret

A missing or mutable required field (especially original_source) is a structural attribution leak, not a one-off data-entry error. Read field completeness beside the Audit's confidence level: high completeness with an overwritable original source is still a broken contract.

Action That Follows

Implement the missing/repaired fields and overwrite protections in the CRM, pair with the UTM & Lead Source Tracking Standard (RLR-09) for capture, normalize definitions against the KPI Dictionary (RLR-35), and record the change on the Repair Plan (RLR-39).

Owner

A named revenue-operations/CRM administrator owns the field contract; each stage's write responsibility is assigned to that stage's owner.

How To Implement

Map each canonical field to a real CRM field, set original_source (and other first-touch fields) to write-once with overwrite protection, wire each stage to populate its fields into the system of record, add validation rules, and document the mapping so it is CRM-agnostic at the methodology level.

How To Test

Create a test opportunity, drive it through each stage, and confirm every required field is written to its system of record and that original_source survives later touches unchanged. Attempt an overwrite of original_source and confirm it is blocked or audited.

When To Remeasure

Re-run the Attribution Integrity Audit (RLR-33) at 14 and 30 days after the field contract is implemented to confirm completeness and traceability improved on real records.

How To Know It Improved

The contract is working only when re-measured field completeness, source persistence, and source-to-revenue traceability rise on real records — not because a field list was documented.