Marketing attribution that reconciles to booked revenue, not platform-reported conversions

Every CFO has been here. The marketing team presents a deck showing $4.2M of marketing-sourced revenue. The financial system shows $52M of total revenue. The dispatch system shows 14,000 booked jobs. Nothing reconciles. The CFO can either trust the marketing report and accept that 8 percent of the topline is unverifiable, or treat the marketing report as directional and run the business off the financials. Most run off the financials.

This is the root cause of the broader problem operators describe as 'my agency reports activity but the P&L isn't moving.' It isn't that the agency is lying. It's that the attribution they use is built from ad-platform exports, not from the operation's actual booked-revenue ledger. Those two systems disagree by design, and the disagreement compounds every month.

Why platform-reported attribution doesn't reconcile

Google Ads, Meta, and the rest of the ad platforms measure conversions using their own pixel data and click attribution windows. A 'conversion' in Google Ads is a tracked event that fired within the conversion window after an ad click. A 'lead' in your CRM is a record created when someone called or filled a form. A 'booked job' in your dispatch system is a record created when the dispatcher confirmed the appointment.

These three systems use different identity resolution, different time windows, different definitions of a 'conversion,' and different attribution models. They will never reconcile to each other on their own, and the gap between them is where the operator's view of marketing performance goes to die.

• Google Ads counts a conversion if a tagged form was submitted within 30 days of a click. It doesn't know whether the form became a booked job or revenue.
• Meta counts a conversion if its pixel fired (often a Lead event) within a 7-day click or 1-day view window. Same problem.
• Your CRM records leads by source as captured at form-fill or call. Source attribution is often whatever the form's UTM parameters said, which is often blank or 'direct.'
• Your dispatch system records booked jobs and revenue. It generally has no idea where the customer came from in marketing terms.

Four systems, four definitions of a 'conversion,' four attribution windows. They will never reconcile on their own. The CFO is right not to trust them.

The attribution warehouse pattern

The fix is an attribution warehouse: a data layer that ingests events from every system, resolves them to a single customer identity, and produces a reconciled view of marketing-sourced revenue that the CFO can sign off on. Conceptually it's three things: an identity graph, an event store, and a reconciliation layer.

1. Identity graph

Every customer interaction across every system needs to resolve to one canonical customer record. The graph stitches phone numbers, email addresses, form fingerprints, ad-click IDs (GCLID, FBCLID), CallRail session IDs, and dispatch-system customer IDs into a single resolved identity. This is the unsexy 70 percent of the work and the part most operators skip.

2. Event store

Every event from every system flows into one Postgres-or-equivalent event store, timestamped, with the source system tagged. Ad clicks, form submissions, calls, bookings, dispatch outcomes, invoices, payments. The warehouse is the source of truth for what happened. The reporting tools query it; they don't define it.

3. Reconciliation layer

A set of SQL transforms (dbt-style is the cleanest) that produces the canonical 'marketing-sourced revenue' view. Joins the booked-job record back through the customer identity graph to the original ad click, applies the attribution methodology you've decided on (first-touch, last-touch, multi-touch with a defined model), and outputs revenue by source/medium/campaign/DMA. This is the view that gets shown in the dashboard. This is the view that reconciles to the GL.

Picking an attribution methodology

There's no universally correct attribution model. There's a model that fits how your business actually generates demand, and you need to pick it consciously. Three pragmatic choices for residential home services:

1. Last-non-direct-click. Default option. Simple. Defensible. Captures most of the truth for emergency-demand trades (plumbing, restoration, garage door) where the considered cycle is short.
2. First-touch within a 90-day window. Right model for considered-purchase trades (HVAC replacement, panel upgrades, roof replacement, flooring) where the customer often researches for weeks before calling. Last-touch under-credits the brand and content that drove the first visit.
3. Time-decay multi-touch. More complex. Right for platforms running coordinated brand + performance spend at scale. Worth the engineering investment only if you have the budget volume to justify the optimization decisions it enables.

The wrong move is picking a model in vendor marketing-speak ('data-driven attribution!') without understanding what it actually does to your numbers. The right move is documenting your methodology choice, the rationale, and the audit trail so a future CFO or buyer's CDD team can review it.

How long this takes, what it costs

For a single-location operator: 6 to 10 weeks to build a basic warehouse and reconciliation layer. Ongoing infrastructure cost typically $500-$2,000 per month (Postgres hosting, ETL tooling, dashboard layer). Operator effort: significant up front, light ongoing once it's running.

For a multi-DMA roll-up: 12 to 20 weeks to build the warehouse across all locations and the cross-portco roll-up layer. Cost scales with location count and the diversity of source systems. Most platforms with 5+ locations recover the investment within 6 months from the channel-mix optimization the new view enables.

How Sheppard deploys this

Sheppard's Build-it mode builds attribution warehouses inside the operator's perimeter, not as a SaaS the operator rents. The warehouse is owned by the operation; we set it up, document the methodology, and operate the dashboards as part of the marketing function. When the business sells, the warehouse transfers cleanly to the next owner. We've built variants on top of Postgres + dbt + standard reporting tooling, integrated into ServiceTitan, FieldEdge, Housecall Pro, Salesforce, and HubSpot. The architecture is well-understood; the work is in the integration and the methodology decisions.