Only 28% of B2B organizations have a unified attribution model connecting marketing activity to closed revenue, per Forrester's 2025 B2B Attribution Benchmark Report. That number hasn't moved much in three years. Meanwhile, Gartner's February 2026 CFO Survey placed marketing spend visibility in the top three financial planning priorities, up from outside the top ten two years prior. The attribution trust gap is no longer a marketing ops problem. It's a CFO problem.
The reason the gap persists isn't that teams lack data. It's that dbt for marketing attribution gets implemented as a modeling exercise rather than a trust architecture. Teams build mart models that produce a number, that number goes into a dashboard, and at the next QBR the finance team produces a different number from the same underlying data. Neither team is wrong. Both are reading from a layer that was never designed to reconcile with the other.
What follows covers the specific architectural decisions, in staging conventions, metric definitions, and lineage documentation, that determine whether your attribution model survives a finance audit or collapses under the first question.
Why marketing and finance produce different revenue numbers from the same data
The disagreement is almost never about intent. It's about grain.
Marketing measures touches. A prospect visits via paid search, returns via organic, converts via a direct visit. The marketing model sees three touchpoints, distributes credit across them, and arrives at a cost-per-acquisition tied to campaign activity. Finance measures booked ARR. A deal closes on March 31. Finance recognizes it in Q1. The CRM records the close date; the billing system records the first invoice. Those dates are rarely the same.
When a marketing analyst and a finance analyst both write ad-hoc SQL against the same warehouse, they produce different numbers because they're joining at different grains, on different date fields, through logic that was never coordinated. Nobody is making an error. The queries are just answering different questions that happen to share a name: "revenue attributed to marketing."
The downstream damage is documented. CaliberMind's 2025 State of Marketing Attribution Report found that only 52% of teams track Marketing Cost per $1 of Pipeline, meaning nearly half can't produce the basic ratio that a CFO would ask for in a budget review. That gap doesn't come from missing data; it comes from the absence of a defined, versioned metric layer that both functions agree to read from.
Three structural conditions create this problem:
Inconsistent grain across models. Attribution logic written at the touchpoint grain produces different totals than revenue logic written at the opportunity grain. Without an explicit intermediate model that bridges the two grains, both teams join their preferred upstream table and get different answers.
No single metric definition. When "pipeline" means one thing in Salesforce, another thing in the BI tool, and a third thing in a dbt mart model built six months ago by a contractor, you don't have a data quality problem. You have a governance problem.
No version control on logic. Ad-hoc SQL queries don't have test coverage, change history, or documentation. When the number changes, nobody knows why. Finance stops trusting marketing's number not because it's wrong but because it's unprovable.
The 65.7% of martech practitioners who named data integration as their top martech management challenge (MarTech.org 2025 State of Your Stack Survey) aren't describing a tooling gap. They're describing the upstream version of this problem: fragmented ingestion means the data entering the warehouse was never structured to support a unified attribution view in the first place.
Where dbt fits: staging models, the semantic layer, and a single metric definition
The three-layer dbt convention, staging, intermediate, and mart, is taught as a modeling pattern. It should be treated as a governance pattern.
Staging models are where raw source data gets cleaned, typed, and renamed consistently. A staging model for Salesforce opportunities doesn't add logic; it produces a stable, documented representation of what Salesforce actually contains. Every downstream model reads from the staging layer, not from raw source tables. This matters for attribution because when the CRM field that defines "closed won" changes, you update one staging model and every model downstream inherits the fix automatically.
Intermediate models are where attribution logic belongs. Not in mart models, and not in BI tool calculated fields. The intermediate layer is where you write the join between touchpoint history and opportunity outcome, where you define the lookback window, where you encode the attribution algorithm. Keeping that logic in intermediate models means it's versioned, testable, and visible in the lineage DAG. When finance asks "how did you get that number," the answer is a GitHub commit history and a documented model, not a Looker calculated field that nobody can find.
Mart models are the read layer. They should be thin: they select from intermediate models, apply final business logic like date filtering or segment definitions, and expose a clean surface to BI tools and stakeholders. Attribution logic that lives in mart models is harder to test and harder to audit because it sits closest to the reporting surface, where business pressure to make numbers look right is highest.
The dbt Fusion Semantic Layer and what it changes
As of June 1, 2026, dbt Core v2.0 shipped with the Fusion engine, and the dbt Fusion Semantic Layer is now the production baseline for teams building on modern warehouse architecture. The core capability: you define each metric once in code and expose it consistently to Tableau, Power BI, Looker, and whatever spreadsheet environment finance uses. "Pipeline influenced by marketing" becomes a single versioned definition, not four different calculated fields maintained independently across tools.
This directly addresses the finance-vs-marketing number problem. When both functions query the same semantic layer metric, they can disagree about the business interpretation but they can't disagree about the number. The reconciliation conversation moves from "whose SQL is right" to "do we agree on what pipeline influenced by marketing should mean," which is a more tractable problem.
A practical caveat is worth stating clearly: as of early 2026, a number of small-to-mid-size data teams have reverted to simple materialized dbt models rather than adopting the Semantic Layer, citing implementation complexity and additional tooling cost. A February 2026 analysis in the practitioner community noted this pattern specifically. The Semantic Layer is the right architecture for teams above a certain threshold: multiple BI tools consuming the same metrics, cross-functional stakeholders who need to trust the same numbers, and at least one analytics engineer with capacity to maintain the metric definitions. For teams below that threshold, well-documented materialized mart models with strict naming conventions and test coverage will do more good than a half-implemented Semantic Layer.
The dbt Labs, Snowflake, and Salesforce Open Semantic Interchange (OSI) Initiative, launched in 2025, is moving toward a vendor-neutral metric format standard. That direction is worth tracking, but as of July 30, 2026, OSI is still maturing. Build your metric definitions to be portable; don't design your architecture around OSI being stable.
Building for the dual-model reality: MTA in dbt, MMM inputs from dbt
As of April 2026, multi-touch attribution (MTA) has reached 47% adoption among B2B teams, while last-touch still sits at 41%. These numbers are important to read carefully: MTA has not replaced last-touch. Most attribution-mature teams run both, using last-touch for platform reporting and optimization, and MTA for internal budget conversations. Marketing Mix Modeling (MMM) adoption tripled from 9% to 26% between 2023 and April 2026. The median mature attribution team now runs MTA and MMM in parallel.
dbt serves these two workstreams differently, and conflating them produces architectural problems.
MTA in dbt
For MTA, the key dbt design decision is incremental models on the touchpoint grain. Touchpoint history grows continuously; full refreshes become prohibitively slow once you're past a few million rows. An incremental model strategy, appending new touchpoints and recalculating attribution windows on a rolling basis, keeps the model performant without requiring a full rebuild on every run.
The Snowplow dbt-snowplow-attribution package (maintained as of 2024-present) provides an open-source baseline for teams starting this work. It supports first-touch, last-touch, and custom multi-touch models in a dbt-native architecture. Using it as a starting point rather than building from scratch means you inherit tested incremental logic and documented schemas. Adapt it to your schema rather than rewriting from scratch.
One design choice that consistently matters: define the attribution lookback window as a model-level variable, not a hardcoded filter in the SQL. When the business changes the window from 30 to 90 days, you update one variable and rerun the model. When it's hardcoded, you find it three months later when the numbers change unexpectedly and nobody remembers why.
MMM inputs from dbt
MMM is not built in dbt. dbt's role in an MMM workstream is upstream: producing clean, weekly-aggregated inputs that a model like Google's Meridian can actually consume. That means spend by channel by week, impressions by channel by week, and pipeline or revenue by week, all at a consistent grain, with no gaps and no double-counting.
Google launched Meridian as an open-source Bayesian MMM framework on January 29, 2025, and updated it in September 2025 to support non-media variables including pricing and promotions. It has lowered the barrier to in-house MMM substantially. But a Forrester January 2025 analysis noted explicitly that Meridian is not a universal solution and requires strong in-house data engineering, data science, and visualization capacity to implement. If your team is considering Meridian, the dbt work to build clean aggregated inputs is a prerequisite, not an afterthought. A team that skips the input preparation step and feeds Meridian raw platform exports will get a model that produces numbers, but those numbers won't be defensible because the inputs weren't governed.
The practical architecture: a set of dbt models that produce a mart_mmm_inputs table, joining spend from your ad platform staging models to pipeline from your CRM staging models, at the week-channel grain, with explicit documentation of what's included and what's not.
The dark funnel problem: what your dbt models structurally cannot capture
As of April 2026, the dark funnel gap averages 38% of B2B pipeline overall. For product-led growth motions, it reaches 51%. These figures come from a single April 2026 research source and should be treated as directional rather than precise, but the order of magnitude is consistent with what attribution practitioners report from their own data.
The dark funnel is not a dbt problem to fix. It is a modeling boundary to document.
A finance-ready attribution model doesn't pretend to measure what it can't measure. It defines, explicitly, what signals are in scope and what signals are structurally outside the model's reach. Peer review in a dark community, a sales conversation that happened on a personal phone, a conference interaction that preceded the first tracked web visit by three months: none of these are in your touchpoint table. Your dbt model doesn't know they happened.
The practice that earns finance credibility here is encoding that boundary directly in dbt model metadata. Use the description field and meta blocks in your intermediate and mart model YAML files to document the model's coverage scope. A well-written description for your int_attribution_touchpoints model says something like: "Covers tracked digital touchpoints from web analytics and paid media APIs. Does not include offline interactions, partner-sourced pipeline, or direct sales activity logged as meetings in CRM without a corresponding web session. Coverage is estimated at 60-65% of total pipeline based on Q1 2026 reconciliation against finance's opportunity data."
When a CFO asks "what's missing from this model," the answer should already exist in the lineage graph. The worst version of that conversation is the one where the marketing team reconstructs the model's limitations in a meeting while the CFO watches. The best version is where the data engineer pulls up the model documentation and reads the coverage statement directly. That document exists because someone wrote it before the meeting, not in response to it.
McKinsey's 2024 B2B Pulse data puts the average B2B buyer across 10 channels, with 42% using more than 11. No deterministic attribution model covers all 10 channels, let alone 11. Documenting that boundary isn't an admission of failure. It's what makes the model credible.
Making the model auditable: lineage, testing, and finance sign-off
The dbt test blocks, description fields, and lineage DAG are not documentation overhead. They are the audit trail that converts a marketing number into a number finance will co-sign.
The Brinker and Riemersma 2026 attribution maturity study found that attribution maturity correlated not with having more data, but with knowing which data was usable, being honest about the rest, and aligning teams around trusted data. The teams with the most mature attribution practices weren't the ones with the most sophisticated models. They were the ones with the clearest documentation of what their models could and couldn't prove.
That finding translates directly to a dbt implementation pattern.
Source freshness tests
Attribution models break silently when upstream sources stop refreshing. The Salesforce opportunity sync runs four hours late on Mondays because of a job conflict. The Google Ads API returns a 200 but delivers partial data during reporting windows. These failures don't throw errors in your BI tool; they just produce quietly wrong numbers.
Source freshness tests in dbt's sources.yml define a maximum acceptable lag for each upstream table. If the Salesforce opportunities table hasn't updated in more than six hours, the dbt run fails before the attribution models execute. Finance doesn't see a stale number; they see a freshness failure that someone is actively investigating.
This is a prerequisite for any server-side measurement consulting conversation about signal quality: the dbt layer is only as trustworthy as the events and CRM records feeding it.
Join key integrity tests
Attribution models depend on joins. Those joins fail silently when key columns contain nulls, duplicates, or unexpected values. A not_null test on opportunity_id in your touchpoint-to-opportunity bridge model catches the case where a touchpoint was logged without a resolvable identity match. An accepted_values test on attribution_model_type prevents an upstream process from silently introducing a new model variant that isn't handled downstream.
These tests aren't defensive programming; they're the mechanism that lets you tell finance "this model has automated integrity checks that run before every refresh." That statement changes the nature of the trust conversation. You're not asking finance to trust a number; you're showing them the mechanism that would surface a problem before they saw it.
For teams with pixel loss or incomplete paid social signal, this is where the connection to server-side GTM and CAPI implementation becomes directly relevant. Attribution mart models built in dbt frequently break at the paid social join because client-side pixel data is incomplete. A Meta CAPI implementation that improves event match quality directly improves the completeness of the touchpoint table your dbt models depend on.
Finance sign-off as a protocol, not an event
The most effective pattern we've seen is treating finance review of mart-layer definitions as a step in the model deployment process, not a post-hoc validation. Before the mart_attribution_revenue model goes to production, a finance stakeholder reviews the metric definitions, the coverage statement, and the join logic in plain English. They don't need to read SQL; they need to confirm that the model's definition of "attributed revenue" matches the definition they would use in a board presentation.
That review happens once per major model version, not once per quarter. When the logic changes, a new review happens. This is low overhead if the documentation is already written; it's impossible if the documentation doesn't exist.
Teams starting this process from scratch usually benefit from a measurement architecture assessment before they build the dbt layer. The input data quality baseline, knowing which CRM fields are reliably populated, which ad platform APIs have gaps, and which identity resolution logic is actually working, determines whether a production attribution model will be defensible or just plausible-looking. Building the dbt models before validating the signal architecture typically produces a model that has to be rebuilt six months later.
The attribution trust gap is structural, not political. Finance and marketing produce different numbers from the same data because they're reading from different layers of a stack that was never designed to reconcile. dbt gives you the architecture to fix that, but only if you treat the staging conventions, metric definitions, and model documentation as governance decisions rather than implementation details. The SQL is the easy part. The part that earns the co-signature is the coverage statement in the YAML file and the source freshness test that runs at 6am before anyone opens the dashboard.