attribution-modeling

name	attribution-modeling
description	Build, audit, and operate a profit-first attribution model that connects ad-platform spend to your real revenue and profit, not the platforms' reported ROAS. Use when asked to "set up attribution", "build the profit pipeline", "join ads to revenue", "fix our ROAS reporting", "design an incrementality test", "audit our attribution model", or anytime someone says "the platform numbers don't match the bank account".
metadata	{"version":"1.0.0"}

Attribution Modeling

The deeper, more rigorous version of the profit-first principle that runs through this entire skill stack. This skill is for the case where you need to design, build, and operate the actual data pipeline that produces your ground-truth profit-per-campaign — and the incrementality tests that tell you which of those numbers are real.

When to use

• "Our ROAS looks great but profit isn't growing" — start here
• "Set up attribution modeling for our account" — this is the build skill
• "How do we know if our paid ads are incremental?" — incrementality test design
• "We want to join Google Ads to our BigQuery / Shopify / Stripe data" — pipeline design
• "Audit the attribution model we already have" — gap analysis
• Setting up paid-ads-context.md section 4 (Attribution & data)

The North Star

Profit-to-spend ratio is the metric. Not ROAS. Not conversions. Not platform-reported conversion value.

Why: ad platforms have an incentive to make themselves look good. View-through conversions, multi-touch attribution that defaults to last-click, lookbacks that overlap with email and direct — all of these inflate reported ROAS without inflating your bank account.

Profit-to-spend is computed from YOUR data:

profit_to_spend = (revenue from your own system - COGS - refunds - fees - partner payouts) / ad spend

Every component except spend comes from inside your business. Spend comes from the ad platforms. The pipeline is the join.

What the skill builds

A four-layer attribution model:

1. Data ingestion — pulling spend (from platforms) and orders (from your system)
2. Identity / UTM resolution — joining the two on a stable key
3. Profit calculation — applying refunds, COGS, fees, partner cuts
4. Incrementality overlay — the holdout tests that tell you which numbers are real

Each layer has known failure modes. The skill builds defenses for each.

Layer 1: Data ingestion

Spend sources

Source	How to pull	Refresh cadence
Google Ads	GAQL via the official MCP, or BigQuery Data Transfer Service	Hourly possible; daily is enough
Meta	Marketing API insights endpoint	Same
LinkedIn	Marketing API	Daily
TikTok	Marketing API	Daily
Other	CSV export, refreshed by hand	Weekly minimum

The skill defaults to daily ingestion at 9am account-time, pulling yesterday's data. See n8n-recipes/daily-ad-spend-to-sheet for the implementation.

Order sources

The "true revenue" layer. From your platform:

Platform	Where the data lives	Join key options
Shopify	Orders API, Stripe Sigma if you use Stripe	utm_campaign, landing_site_ref
Stripe	Sigma queries, or directly via the API	metadata.utm_*, customer-level email
Custom warehouse	Whatever schema you have	Whatever join column you chose
Marketplace (e.g., AppSumo, App Store)	Often delayed and aggregated	UTM if it survives the marketplace redirect

Refunds / margin layer

This is the part most attribution models skip and that destroys their accuracy:

• Refunds: pull at least 60 days after the order date (refund tail is long for most categories)
• Partner payout: subtract if you're a marketplace
• Payment processing fees: ~3% on average, sometimes more for international cards
• Variable COGS: per-order shipping, fulfillment, packaging

The profit_usd column is the sum after all these subtractions. A dollar of revenue is not a dollar of profit.

Layer 2: Identity / UTM resolution

The join key is what makes the attribution model work or fail.

Three join strategies (best to worst)

1. Server-side enhanced conversions / first-party data

You set conversion events server-side with the order's email hash, customer ID, and gclid/fbclid. Platforms accept this and can match to actual ad clicks.

Best for: e-commerce with checkout flows you control.

2. UTM parameter resolution

Every paid click gets UTMs. Every order captures the landing-page UTMs. Match on utm_campaign (or whatever level you chose).

Best for: B2B SaaS, content sites, anywhere the conversion is form-fill not server-checkout.

3. Last-touch via Google Analytics

You trust GA4's attribution and pull from there.

Best for: nothing. Use this only when nothing else is available. GA4's default attribution model is opinionated and not yours.

UTM hygiene rules

The join is only as good as your UTMs. Enforce these:

• Every paid ad has a utm_campaign that matches its campaign name (or a derived label you control)
• utm_campaign is lowercase, no spaces, kebab-case (search-non-brand-aitools not Search Non-Brand AI Tools)
• Your order capture stores utm_* server-side at the moment of conversion, not client-side later
• You also store gclid and fbclid for platform-level joins as a backup
• Audit your UTM dictionary quarterly

Common UTM failures

Symptom	Cause	Fix
Many orders attributed to "direct"	UTM gets stripped on a redirect	Audit the redirect chain end-to-end
Orders show wrong campaign	UTM persists across sessions in localStorage with no expiration	Set expiration to 30 days, refresh on each new paid click
Mobile orders all "direct"	App / Safari ITP stripping	Use server-side conversion APIs as primary, UTMs as secondary
Marketplaces show no UTM	Marketplace redirect drops UTM	Negotiate UTM pass-through with the marketplace, or use marketplace's own attribution layer

Layer 3: Profit calculation

The final table the skill outputs has these columns:

Column	Type	Notes
date	date	Day-level granularity
campaign_id	string	Platform's campaign ID
campaign_name	string	Cleaned, role-labeled name
platform	string	google / meta / linkedin / tiktok / etc
spend_usd	numeric	From platform API
revenue_usd	numeric	From your order system
refunds_usd	numeric	Within the lookback window
fees_usd	numeric	Processing + fulfillment
cogs_usd	numeric	Variable cost per order
partner_payout_usd	numeric	Marketplaces only
profit_usd	numeric	revenue - refunds - fees - cogs - partner_payout
orders	integer	Count
new_buyer_orders	integer	First-time buyers
profit_to_spend	numeric	profit_usd / spend_usd

This is the table that google-ads-manager and paid-channel-recap consume.

Layer 4: Incrementality

Even with perfect attribution, you have a question: would these conversions have happened anyway?

This is the cannibalization problem. The platform claims credit for a buyer who would have come through email, direct, or organic. Without an incrementality overlay, you over-spend on cannibalized channels.

Incrementality methods, ranked

1. Geo-holdout (gold standard)

Pause ads in 2-3 comparable geographic regions for 3-4 weeks. Compare total revenue (not just attributed) in test vs control.

Use references/geo-holdout-design.md for the full protocol.

2. Google Conversion Lift / Meta Conversion Lift

The platforms run their own incrementality experiments. Available at $5K+ budget (used to be $100K+). Useful as a sanity-check on what you'd find with a geo-holdout.

3. Spend-step changes

Briefly +20% / -20% a campaign's daily budget for 14 days. Compare incremental revenue to incremental spend. Crude but cheap.

4. New-vs-returning buyer ratio (proxy)

If a campaign is 90%+ returning customers, it's likely cannibalizing email and direct. The new-buyer percentage is your incrementality proxy.

Reports from google-ads-manager include this column.

What incrementality typically tells you

For most B2B SaaS / DTC accounts:

• Brand search: 20-40% incremental (high cannibalization)
• Non-brand search: 70-90% incremental (mostly new demand)
• Performance Max / Advantage+: 30-60% incremental (variable, depends on signals)
• Retargeting / display: 10-30% incremental (heavy cannibalization)

Your numbers will vary. The point is: a 5x platform-reported ROAS at 30% incrementality is a real 1.5x — and that's the number you should manage to.

Anti-patterns

Anti-pattern	Why	Fix
Trust Google's "conversion value" for profit	View-through inflates it 30-50% in most accounts	Always join to your own order data
Skip the refund layer	Refunds happen 7-90 days later; ignoring them inflates profit	Include refund tail in the lookback
Use GA4 default attribution	Opinionated, not yours, hides cannibalization	Build your own model with your own join
No incrementality testing	You'll over-scale cannibalized channels	At least annual geo-holdouts on top-spend channels
Average profit-to-spend across days	Hides the day where one campaign collapsed	Compute per-campaign, per-day
Single attribution model for all decisions	Different decisions need different models	Use platform-reported for bid signals; use your model for budget allocation

When you don't have the data yet

If you can't build the full pipeline today, the skill helps you triage:

Minimum viable attribution:

1. A weekly manual export from each ad platform
2. A weekly manual export from your order platform
3. A Google Sheet that joins them on utm_campaign
4. A profit_usd column computed from revenue * (1 - refund_rate) * (1 - cogs_pct) - spend
5. A profit_to_spend column computed weekly

This is bad. But it's better than trusting platform ROAS. Use it for 30 days while you build the real pipeline.

Related skills

Skill	Relationship
paid-ads-context	Section 4 (Attribution & data) is where the pipeline location lives
google-ads-manager	Consumes the profit table for weekly review
paid-channel-recap	Consumes the profit table for stakeholder reports
ppc-profit-intelligence	The free starter guide; this skill is the deeper version
weekly-ops-review	Rolls up the profit table into a weekly health check
n8n-recipes	The utm-attribution-join recipe implements layer 1-3 of this skill

References

• references/utm-hygiene-guide.md — how to set up and audit UTMs end-to-end
• references/geo-holdout-design.md — the gold-standard incrementality test protocol
• references/server-side-conversions.md — moving from cookie-based to server-side conversion APIs
• references/profit-calculation-formulas.md — the math for refunds, fees, COGS, partner payout
• templates/attribution-audit.md — checklist for auditing an existing attribution model
• templates/profit-table-schema.sql — BigQuery / Postgres schema for the profit table