The difficult part of an attribution system is often the data pipeline before the model. Events arrive late, identifiers change, and CRM outcomes use different dates. Build a system that makes those differences visible before assigning credit.
This guide follows the decisions behind that pipeline: the outcome definition, source records, identity rules, transformations, and checks. If you are new to the subject, start with the beginner’s guide.
Define the conversion before the schema
Choose the business outcome the model will explain. A form submission, qualified lead, booked sale, and recognized revenue use different source records and dates. Name the source of record and the field that determines inclusion in the report.
Then define the unit of credit. If the model allocates deal value, decide how it handles reopened deals, partial refunds, currency, and later corrections. Those choices affect the result as much as the weighting formula.
The technical end-to-end MTA data architecture
Keep the pipeline in layers so a disputed total can be traced back to source records. Raw ingestion should preserve what arrived. Normalization and attribution rules belong in transformations that can be inspected and rerun.
| Layer | Responsibility | Useful evidence |
|---|---|---|
| Raw ingestion | Preserve source records and arrival times | Source IDs, extraction timestamps, and refresh logs |
| Normalization | Standardize types, timestamps, currencies, and channel fields | Mappings and excluded-record counts |
| Identity and paths | Connect eligible interactions to outcomes | Join keys, match rules, and unmatched records |
| Attribution | Apply versioned eligibility and credit rules | Model version, lookback window, and allocated credit |
| Reporting | Expose the agreed metrics and limitations | Definitions, data-through dates, and reconciliation notes |
A warehouse can hold these layers without making them trustworthy automatically. The value comes from explicit rules and checks, not from moving the same unexplained spreadsheet logic into SQL.
Build paths with defensible identity rules
Start with identifiers that have a documented meaning in your sources. An event ID identifies an event. A contact ID identifies a CRM record. Neither necessarily represents every device or person in a buying group.
Record the method used for each connection. Keep deterministic matches separate from probabilistic assumptions, and leave unresolved outcomes visible. A missing join is information about coverage, not a reason to invent a match.
Consent and destination restrictions still apply when the processing moves to a server or warehouse. Only collect and use identifiers for permitted purposes. Review what leaves each system, including URLs, form values, and automatically attached properties.
Choose a model and record its assumptions
Rule-based models are useful starting points because the team can inspect how the credit was assigned. Statistical models can answer more complex questions, but they still depend on coverage, training data, and assumptions.
| Model family | Allocation rule | What to question |
|---|---|---|
| First or last touch | One eligible interaction receives the credit | Which part of the path is omitted? |
| Linear | Eligible interactions receive equal weight | Are repeated interactions inflating a channel’s share? |
| Time decay | Recent interactions receive more weight | Does the decay rate fit the buying cycle? |
| Position based | Specified milestones receive extra weight | Why should those milestones receive that weight? |
| Statistical or learned | Weights are estimated from the available data | What assumptions, coverage gaps, and validation support the result? |
State the lookback window and rules for direct traffic, repeat touches, and channel classification. A model name without those details is not enough to reproduce the report.
Reconcile the allocation before using it
For an eligible outcome, the model’s fractional credits should add up to the intended total. Across outcomes, allocated value plus any explicitly unassigned value should reconcile to the source total under the same definitions.
Inspect individual journeys as well as aggregate totals. A many-to-many join can duplicate value while still producing a plausible-looking chart. Test repeated events, multiple conversions, missing identifiers, and late updates deliberately.
- Enforce uniqueness at the intended event and outcome grain.
- Check that eligible touchpoints precede the outcome and fall inside the lookback window.
- Verify credit sums at both outcome and reporting levels.
- Expose unmatched records and coverage changes.
- Compare a sample of paths with the original source records.
- Record model versions and review the effect of rule changes before release.
Set a refresh cadence the decision needs
A monthly budget review may not need real-time attribution. A daily operational workflow may need fresher data, but the upstream CRM could still update later. Set a cadence that reflects both the decision and the source behavior.
Plan for late events and corrected outcomes. Rerun the affected periods, retain enough provenance to explain changes, and tell report readers which periods are still settling.
Keep the model maintainable
Assign an owner for source changes, definitions, and model releases. Keep the tests and documentation beside the transformations so a new maintainer can understand why a rule exists.
When a model changes the channel story, show the comparison and the reason. A result that differs from last-click reporting is not automatically more accurate. It is another view that needs evidence and explanation.
For implementation examples, see GA4 attribution in BigQuery and the model comparison. For CRM-specific builds, see multi-touch attribution in HubSpot and multi-touch attribution in Salesforce. To scope the data work first, book a tracking audit.
Part of: Why your numbers don't match
Also in When the gap is attribution: What an attribution audit looks like: a real 30/60-day scope of work, Marketing attribution models, explained, and when to actually use each, Beginner’s guide to multi-touch attribution
Frequently asked questions
What is multi-touch attribution?
Multi-touch attribution assigns credit for an outcome across the eligible interactions on a path. Attribution describes observed paths; it does not establish causality on its own.
What does an MTA data pipeline include?
The pipeline is built in layers: raw ingestion preserves source records, normalization standardizes fields, identity and paths connect eligible interactions to outcomes, attribution applies versioned credit rules, and reporting exposes the agreed metrics.
What are the main MTA model types?
Rule-based models include first or last touch, linear, time decay, and position based, and the team can inspect how credit was assigned. Statistical or learned models estimate weights from data, but they depend on coverage, training data, and assumptions.
How do I check that MTA credit reconciles?
For each eligible outcome, the fractional credits should add up to the intended total. Across outcomes, allocated value plus any explicitly unassigned value should reconcile to the source total under the same definitions.