What it does. When the user wants to figure out which marketing actually drives conversions and revenue, choose or interpret an attribution model, or reconcile conflicting numbers across tools. Also use when the user mentions "attribution," "attribution model," "first-touch vs last-touch," "multi-touch," "which channel drives revenue," "what's my real CAC," "my dashboards disagree," "Google/Meta says X but GA says Y," "media mix model," "MMM," "incrementality," "geo lift," "holdout test," "how did you hear about us," "self-reported attribution," "dark social," or wants to instrument attribution themselves — "stitch my bookings to their source," "SavvyCal/Calendly attribution," "close the identify gap," "track conversions on a third-party domain," "first-party / self-hosted attribution." For event tracking setup and UTMs, see analytics. For ad-platform pixels/CAPI, see ads. For pipeline and CRM revenue reporting, see revops. For the AI-search attribution blind spot, see ai-seo. Part of coreyhaines31/marketingskills (marketing skills for agents) (coreyhaines31/marketingskills).

Upstream	coreyhaines31/marketingskills
Skill file	skills/attribution/SKILL.md
License	MIT
Author	Corey Haines
Fetched	2026-09-10

Install

• npx skills add coreyhaines31/marketingskills --skill attribution, or copy the skill folder into ~/.claude/skills/attribution/.
• Raw file: curl -sL https://raw.githubusercontent.com/coreyhaines31/marketingskills/HEAD/skills/attribution/SKILL.md

SKILL.md (verbatim)

name: attribution
description: When the user wants to figure out which marketing actually drives conversions and revenue, choose or interpret an attribution model, or reconcile conflicting numbers across tools. Also use when the user mentions "attribution," "attribution model," "first-touch vs last-touch," "multi-touch," "which channel drives revenue," "what's my real CAC," "my dashboards disagree," "Google/Meta says X but GA says Y," "media mix model," "MMM," "incrementality," "geo lift," "holdout test," "how did you hear about us," "self-reported attribution," "dark social," or wants to instrument attribution themselves — "stitch my bookings to their source," "SavvyCal/Calendly attribution," "close the identify gap," "track conversions on a third-party domain," "first-party / self-hosted attribution." For event tracking setup and UTMs, see analytics. For ad-platform pixels/CAPI, see ads. For pipeline and CRM revenue reporting, see revops. For the AI-search attribution blind spot, see ai-seo.
metadata:
  version: 1.1.0

Attribution

You help users answer the hardest question in marketing: which of my efforts actually caused this conversion and this revenue? Attribution is where marketers lose the most money — to channels that look good in one dashboard and terrible in another, to "direct" and "branded search" that hide the real source, and to models that quietly encode an opinion as if it were fact.

This skill has two pillars. Know which one the user needs before you dive in:

• (A) Interpretation — choosing an attribution model, picking a measurement approach, and reconciling the conflicting numbers your tools report. This applies to everyone, even with zero engineering.
• (B) Own your attribution (first-party) — instrumenting and stitching attribution yourself when you control the site/app. This is the build track. Use it when the user says "I want to track this myself" or is hitting a conversion that lives on a domain they don't own.

Most requests start with (A). Reach for (B) only when they control the surface and want to build.

Product context: check for .agents/product-marketing.md and read it if present — business type, sales cycle, and primary conversion drive almost every recommendation here.

Boundaries — what this skill does NOT own

State these up front so you don't rebuild neighboring skills:

• General event tracking, tracking plans, UTM setup, GA4/GTM → analytics. Attribution assumes tracking exists. The line: analytics = "what events and how to fire them"; attribution = "how touches join to conversions and survive to revenue."
• Ad-platform pixels, CAPI, server-side conversion tracking → ads (references/conversion-tracking.md). Attribution consumes platform-reported numbers and corrects for their bias; it doesn't set up the pixels.
• Pipeline stages, lead lifecycle, CRM revenue dashboards → revops. Attribution feeds pipeline data; it doesn't define stages.
• Showing up in / measuring AI search → ai-seo. Attribution names AI traffic as a blind spot only.

---

Pillar A — Interpretation

1. What attribution can and can't tell you

Set expectations before touching a number:

• Attribution is directional, not truth. It's a model of causality built from incomplete data (cookies expire, sessions fragment, offline touches vanish, people research on one device and buy on another). Treat it as a strong hint, never a verdict.
• Every model is an opinion. "First-touch" says the first ad gets all the credit; "last-touch" says the closing click does. Both are wrong in opposite directions. Choosing a model is choosing whose story to believe — say so out loud.
• The attribution gap is normal. The sum of channel-reported conversions almost always exceeds real conversions, because every platform claims credit for the same sale. Your job is to shrink and explain the gap, not to make the numbers tie out perfectly. They won't.

When a user demands one true number, reframe: "We can get you a defensible, consistent number and a read on which channels are trending up. A single objective truth doesn't exist — here's why, and here's what we use to make decisions anyway."

2. Attribution models

The six standard models and when each one lies:

Model	Credit rule	Best for	How it lies
First-touch	100% to the first known touch	Top-of-funnel / demand-gen valuation; short cycles	Ignores everything that closed the deal; over-credits awareness channels
Last-touch	100% to the last touch before conversion	Direct-response, quick e-comm	Over-credits bottom-funnel + branded search/direct; ignores what created demand
Last non-direct	100% to last touch, skipping "direct"	A cheap fix for direct pollution	Still single-touch; just moves the blind spot
Linear	Equal credit to every touch	Long, multi-touch journeys where every step matters	Treats a throwaway visit like a demo; flatters high-frequency channels
Time-decay	More credit to touches nearer conversion	Longer cycles where recency matters	Under-credits the top of funnel; still an assumption, not a measurement
Position-based (U-shaped)	40% first, 40% last, 20% middle	B2B with clear "created" + "closed" moments	The 40/40/20 split is arbitrary; middle touches get shortchanged
Data-driven (algorithmic/Shapley)	Credit from modeled marginal contribution	High-volume accounts with enough conversions	A black box; needs volume; can't see offline/dark touches it was never fed

Rules of thumb:

• Never report a single model in isolation for a long sales cycle. Show first-touch and last-touch side by side — the truth lives between them, and the gap between them is the insight.
• Data-driven attribution needs volume (Google Ads historically gated it behind ~3,000 ad interactions and ~300 conversions in 30 days; it has since relaxed the minimums and made DDA the default, but low volume still makes it noise dressed as science). Use position-based instead when you're thin.
• The model matters far less than being consistent and pairing it with an out-of-model sanity check (Pillar A §4, self-reported).

For the model math, worked examples of one journey scored six ways, and Shapley explained plainly, see references/attribution-models.md.

3. The three measurement paradigms

Models split credit within your tracked data. Paradigms are how you get at causality — increasingly rigorous, increasingly expensive:

Paradigm	What it is	Answers	Needs	Watch out
MTA (multi-touch attribution)	Stitch user-level touches, apply a model	"Which touchpoints appear on converting journeys?"	Clean cross-device user-level tracking	Cookie loss + privacy have gutted user-level data; it silently under-measures
MMM (media/marketing mix modeling)	Top-down regression of spend vs. outcomes over time	"What's each channel's aggregate contribution, including offline/brand?"	2–3 yrs of weekly data, spend variation	Correlational; slow to react; needs real budget swings to learn
Incrementality (geo holdout, PSA, ghost ads, on/off)	Controlled experiment: exposed vs. withheld	"Did this channel cause lift I wouldn't have gotten anyway?"	Ability to withhold; enough volume for significance	The gold standard, but you can only test a few things at a time

How to choose: small budget / short cycle → good UTM + last-non-direct + a self-reported survey beats a fancy model. Mid budget, several channels → MTA for day-to-day + periodic incrementality tests on your biggest line items. Large budget, offline + brand spend → MMM for the portfolio + incrementality to validate MMM's coefficients. Incrementality is the tiebreaker whenever two channels both claim the same conversions.

Decision table by budget × sales cycle × channel count, and how to read a geo-holdout / PSA test (not a stats tutorial), in references/measurement-paradigms.md.

4. Self-reported attribution

The most underused signal, and often the most honest for long cycles and dark social. A post-conversion "How did you hear about us?" survey catches what tracking structurally cannot: podcasts, word of mouth, Slack communities, a founder's tweet, "a friend told me."

• When it beats tracking: long consideration cycles, high word-of-mouth, brand/community-led, or heavy dark-social (see §5). If a big slice of your journeys are "direct," you have a self-reported-shaped hole.
• Ask at the moment of conversion (signup, first purchase, demo request) — highest recall, before memory fades.
• Wording: open-ended ("How did you first hear about us?") captures dark social; a short pick-list is easier to quantify but pre-biases the answer. Best practice: pick-list of your known channels plus a free-text "other/tell us more."
• Treat it as a triangulation input, not gospel — recall is fuzzy and people credit the memorable touch, not the first. It's the out-of-model check that keeps your tracked models honest.
• On the build side, this is a form field written to your CRM/analytics as a person property — see Pillar B and references/first-party-tracking.md.

5. Reconciling conflicting sources

The request behind most attribution work: "Google says 50, Meta says 40, GA says 60, my CRM says 35 — who's right?" Nobody is. Here's the framework.

Why each source systematically lies:

Source	Biased toward	Because
Ad platforms (Google/Meta/LinkedIn)	Over-counts itself	Claims view-through + click conversions in its own window; every platform counts the same sale; motivated to look good
GA / web analytics	Last non-direct click	Loses cross-device, loses cookie-blocked users, dumps the unknown into direct
CRM	Whatever the rep typed / the form captured	Human entry, lead-source overwrites, offline deals with no digital trail
Self-reported survey	The memorable touch	Recall bias; under-counts boring-but-real touches like retargeting

How to triangulate:

1. Pick one source of truth for the conversion count — usually your CRM or backend (the system where money is real). Everything else explains where those came from, they don't get to redefine how many.
2. Never sum across platforms. If Google and Meta both claim a conversion, you have one conversion with two claimants, not two conversions. De-dupe against the source-of-truth total.
3. Read directional agreement, not absolute match. If every source says paid search is up and organic is down this quarter, that trend is trustworthy even though no two numbers match.
4. Use self-reported as the tiebreaker when platforms fight over the same conversions, and incrementality when the stakes justify a test.
5. Expect and budget for the gap. Report "platforms claim N; we can verify M; the delta is over-claiming + view-through + untracked — here's our best allocation."

The output is an honest allocation with confidence levels, not a false reconciliation to the decimal.

6. The blind spots

Where conversions hide, making real channels look weak:

• Direct — the junk drawer. Bookmarks and typed URLs, yes, but also stripped referrers, app-to-web, dark social, and any touch your tracking dropped. A large direct share is a measurement problem, not a channel.
• Branded search — people who discovered you elsewhere and Googled your name. Last-touch hands the credit to paid/organic branded search; the real driver was whatever made them search. Segment branded vs. non-branded or you'll defund the top of funnel.
• Dark social — sharing that carries no referrer: DMs, Slack/Discord, podcasts, newsletters, screenshots. Structurally invisible to tracking; self-reported is the only way to see it (§4).
• AI traffic — assistants and AI search increasingly influence buyers, then send them via branded search or direct, so the AI touch is invisible in analytics. Name it and hand deeper work to ai-seo.

The through-line: when "direct" and "branded search" dominate, your top of funnel is working and your attribution is hiding it. Say that explicitly — it's the single most common misread in marketing.

7. Business-type fork

Defaults differ sharply. Summary here; full playbooks in references/by-business-type.md.

• B2B SaaS (long cycle, sales-assisted): journeys span weeks–months and multiple people, so single-touch models mislead badly. Anchor on the CRM as source of truth, use first-touch + position-based side by side, lean hard on self-reported at demo/signup, and treat pipeline/revenue attribution (→ revops) as the real scoreboard. Offline touches (events, sales convos) make MTA weakest and self-reported strongest here.
• Ecommerce / DTC (short cycle, self-serve): fast journeys, high volume, spend concentrated in paid social + search. Anchor on platform ROAS but distrust it (iOS/CAPI inflation), validate with MMM once spend is material and incrementality/geo-holdouts on your biggest channels, and use a post-purchase survey to catch what pixels miss. Last-touch is defensible for quick-turn SKUs; MMM+incrementality is how you allocate the real budget.

---

Pillar B — Own your attribution (first-party)

Use this when the user controls the site/app and wants to instrument attribution themselves — especially for a conversion that happens on a domain they don't own (a SavvyCal/Calendly/Cal.com booking, a Stripe Checkout page). This pillar is grounded in real production builds; the full runbook with code patterns is in references/first-party-tracking.md. The essentials:

The identity graph

First-party attribution is one idea: join anonymous browsing to the eventual conversion.

1. A visitor arrives anonymously; your analytics tool assigns an anonymous distinct_id and stamps first-touch properties ($initial_referrer, $initial_utm_*) on their events.
2. At conversion (signup, booking, purchase) you call identify() with a stable id (email or user UUID). This merges the anonymous history into a known person — first-touch now survives all the way to the conversion.
3. Every conversion event can now be broken down by first-touch channel. That's the whole game.

Closing the identify() gap

The most common first-party failure: nothing ever calls identify(), so conversions never join to browsing history and every customer looks like they appeared from nowhere. (Framing adapted from Tessa Kriesel's PostHog approach.) The fix is to call identify at each real conversion. Audit first — many SaaS apps already identify at signup; don't rebuild what works. Find the specific un-instrumented conversions and close only those.

Stitching conversions on a third-party domain

The one case that needs real machinery: a conversion that completes on a domain you don't control (a booking tool, a hosted checkout). You can't run your analytics there, so:

1. At click time, a capture-phase link decorator appends the visitor's anonymous distinct_id to the outbound URL via the tool's metadata passthrough (e.g. ?metadata[ph_distinct_id]=<id>). One document-level listener covers every CTA — no per-link edits.
2. The third-party tool stores that metadata and returns it in its webhook.
3. Your webhook handler fires an identity merge ($identify with the booking email as distinct_id and the smuggled anonymous id as $anon_distinct_id) plus a conversion event — joining the booking back onto the marketing journey.

Guardrails (do not skip)

• Anonymity guard — fail closed. Only ever smuggle the anonymous id. After identify(), the current id becomes the user's email/UUID; leaking that into a third-party URL or merging on it corrupts profiles (person A's email folds into whoever books). Reject ids that look like PII (contain @), cap length, and when identity is ambiguous, send nothing. If the app identifies by UUID, test distinct_id === device_id rather than an @ check.
• First-touch data quality. Redirects overwrite the true first touch. Exclude OAuth/checkout referrers (accounts.google.com, checkout.stripe.com, login.*), your own subdomains (self-referrals), and dev hosts (localhost) from referrer classification. This is usually a settings change, not code, and it's the highest-trust-per-effort fix.
• Cross-subdomain stitching. Marketing site → app on a subdomain must share one analytics project + a cross-subdomain cookie, or the journey breaks at the handoff. Expect near-zero numbers until the stitch is verified in prod — don't panic at empty data; use a campaign-window heuristic fallback and backfill the pre-stitch cohort in the meantime (details in the reference).

Reporting and the last mile

The first payoff is one insight: your conversion event broken down by first-touch channel ($initial_utm_source / $initial_referring_domain), and — joined to revenue — channel → conversion → revenue. Confirm first-touch vs. last-touch config in the tool (many default to last-touch; first-party attribution wants $initial_*).

But first-touch alone can't run the multi-touch models from §2. Store the full ordered touch path (not just $initial_*) and the build track feeds the interpretation track — you can score your own journeys position-based / linear / time-decay instead of only reading about them.

The last mile — get it into the CRM (production refinement from Tessa Kriesel). A breakdown in an analytics tool is a report; sales and lifecycle act on attribution written onto the record. Sync a source field with confidence and basis (journey-linked vs self-reported vs campaign-window fallback) plus a Paid-vs-Organic read off the medium, rolled up to the account (not just the contact — one B2B org is several people with mixed work/personal emails). How pipeline/lifecycle then use it is revops' job.

The pattern is tool-agnostic: identify + merge exists in PostHog, Segment, Amplitude, and via user-id in GA4; the third-party stitch works with any tool that has a metadata passthrough + webhook. PostHog + SavvyCal are the worked example in references/first-party-tracking.md.

---

Output format

Deliver an attribution readout, not a data dump:

# Attribution Readout — [date]

## The question
[What decision this informs — e.g. "where should next quarter's budget go?"]

## Source of truth
[Which system defines the conversion count, and why]

## What each source says
| Channel | Platform-reported | GA | CRM | Self-reported | Our read |
|---------|------------------|----|----|--------------|----------|
[De-duped against source of truth; not summed]

## Model comparison (for long cycles)
[First-touch vs last-touch side by side; the gap is the insight]

## Confidence & gaps
[The attribution gap, the blind spots, what we can't see]

## Recommendation
[Allocation call with confidence levels; the tiebreaker test worth running]

Tool Integrations

For implementation, see the tools registry. Key tools:

Tool	Best For	MCP	Guide
PostHog	First-party attribution, identify/merge, funnels	-	posthog.md
GA4	Web analytics, model comparison, user-id stitching	✓	ga4.md
Dub	Short-link + click attribution	✓	dub-co.md
Segment	CDP — route identify/track to every destination	-	segment.md
HubSpot	CRM lead-source + self-reported fields	✓	hubspot.md
Salesforce	CRM as revenue source of truth	-	salesforce.md
Supermetrics	Pull platform numbers into one place to reconcile	✓	supermetrics.md
RB2B	De-anonymize B2B website visitors	-	rb2b.md

---

Related Skills

• analytics — event tracking, tracking plans, UTMs, GA4/GTM setup. Do this before attribution.
• ads — ad-platform pixels, CAPI, server-side conversion tracking (references/conversion-tracking.md).
• revops — pipeline stages, lead lifecycle, CRM revenue reporting. Attribution feeds it.
• ai-seo — the AI-search attribution blind spot in depth.
• ab-testing — controlled experiments; the incrementality mindset applied to on-site changes.

Other files in this skill

• evals/evals.json
• references/attribution-models.md
• references/by-business-type.md
• references/first-party-tracking.md
• references/measurement-paradigms.md

references/attribution-models.md (verbatim)

Attribution Models — The Math, Worked

Six standard models, one journey scored six ways, and data-driven attribution explained without the black box. Use this when the user wants to understand why two models disagree, or needs to pick one defensibly.

The worked journey

A single B2B buyer's path to a $12,000 annual deal, five touches over 38 days:

#	Day	Touch	Role in the story
T1	0	LinkedIn ad (paid social)	First discovered you — created awareness
T2	5	Organic blog post (organic search)	Came back to learn — built interest
T3	12	Retargeting ad (paid social)	Nudged back mid-consideration
T4	30	Branded search (paid search, branded)	Ready to act — searched your name
T5	38	Direct → demo request (direct)	Converted

The whole point: the touch that gets credit depends entirely on the model, and each model tells a different story about where your $12k came from.

The six models, applied

Credit for the $12,000 deal under each model:

Touch	Channel	First-touch	Last-touch	Last non-direct	Linear	Time-decay	Position (U)
T1	Paid social	$12,000	$0	$0	$2,400	$175	$4,800
T2	Organic	$0	$0	$0	$2,400	$290	$800
T3	Paid social	$0	$0	$0	$2,400	$575	$800
T4	Paid search (branded)	$0	$0	$12,000	$2,400	$3,415	$800
T5	Direct	$0	$12,000	$0	$2,400	$7,545	$4,800

(Time-decay uses a 7-day half-life — weight = 0.5^(days-before-conversion / 7), normalized: shares of ~1.5% / 2.4% / 4.8% / 28.5% / 62.9% (dollars rounded to sum to $12,000). With a 38-day journey the credit concentrates hard on the last two touches — which is exactly why time-decay behaves almost like last-touch on long cycles. Position-based is 40/40/20, the 20% split evenly across T2–T4.)

Read the disagreement:

• First-touch hands everything to the LinkedIn ad — great for arguing paid social's demand-gen value, blind to what closed it.
• Last-touch hands everything to Direct — which is really "we don't know," the junk-drawer channel (see SKILL.md §6). This is how top-of-funnel gets defunded.
• Last non-direct hands it to branded search — but branded search only happened because the LinkedIn ad and blog created the demand. Crediting the closing branded click is crediting your own brand for demand someone else's channel created.
• Linear spreads it evenly — honest that all five mattered, useless for deciding what to cut (everything looks equally important).
• Time-decay favors the recent — reasonable for short cycles, but here it under-credits the LinkedIn ad that started everything.
• Position-based credits the bookends (discovered + closed) — usually the most defensible single model for B2B, because "what created this deal" and "what closed it" are the two decisions you actually make.

The takeaway to give the user: report first-touch and last-touch side by side. The LinkedIn-vs-Direct gap is the insight — it tells you paid social creates demand that later shows up as direct/branded. No single number captures that; the spread does.

Data-driven / algorithmic attribution (Shapley), plainly

Data-driven attribution (Google's DDA, most MTA tools) doesn't use a fixed rule. It asks a counterfactual: how much does each touch actually change the probability of conversion? The formal engine is the Shapley value from cooperative game theory.

The plain-English version:

• Treat each touch as a "player" on a team that produced the conversion.
• Look across all your journeys — converting and non-converting.
• For a given touch, compare conversion rates of journeys that had it vs. otherwise-similar journeys that didn't, across every possible combination of the other touches.
• A touch's credit = its average marginal lift to conversion probability across all those combinations.

So if journeys with a retargeting touch convert meaningfully more often than identical journeys without it, retargeting earns real credit. If adding a channel changes nothing, it earns ~zero — even if it appears on every path.

When it's worth it:

• You have volume — the counterfactuals need enough conversions to be stable. (Google Ads historically gated data-driven attribution behind ~3,000 ad interactions and ~300 conversions in 30 days; it has since relaxed the hard minimums and made data-driven the default model, but the underlying reality is unchanged: below real volume, DDA is noise dressed as science.) Use position-based instead when you're thin.
• Your journeys are mostly digital and tracked — Shapley can only weigh touches it was fed. Offline events, dark social, and cookie-lost touches are invisible to it, so a high-word-of-mouth B2B motion will get a confidently-wrong DDA. Pair it with self-reported (SKILL.md §4).

Its honest limitations:

• Black box — you can't easily explain to a CFO why LinkedIn got 23%. "The model says so" is a weak budget argument on its own.
• Correlation, not causation — it models what co-occurs with conversion, not what causes it. That's why incrementality testing (see measurement-paradigms.md) exists: to validate what DDA claims.
• Garbage in — inherits every blind spot in your tracking. If half your journeys are "direct," DDA is confidently splitting credit on half-blind data.

Choosing — a short decision guide

• Short cycle, few touches, small volume → last non-direct, plus a self-reported survey. Don't over-model.
• Long B2B cycle, clear created/closed moments → position-based as the primary, first-touch + last-touch shown alongside.
• High volume, mostly-digital, need day-to-day allocation → data-driven, validated periodically by incrementality.
• Offline + brand-heavy, real budget → don't rely on any user-level model; go MMM + incrementality (see measurement-paradigms.md).

In every case: pick one model, stay consistent, and pair it with an out-of-model check. Model-switching to make a channel look good is the fastest way to lose trust in the whole attribution program.

references/by-business-type.md (verbatim)

Attribution by Business Type

Attribution defaults differ sharply by business model. The same "which channel drives revenue?" question wants a different source of truth, model, and paradigm depending on how long your cycle is, how many people are involved, and where your budget goes. Two playbooks: B2B SaaS and Ecommerce/DTC. Match the user's product to one (or blend, for PLG-with-sales).

---

B2B SaaS (long cycle, sales-assisted)

Shape of the problem: journeys run weeks to months, span multiple people (champion, economic buyer, users), and include touches that never appear in web analytics — a conference conversation, a sales call, a Slack-community mention, a peer recommendation. Deal values are high and volume is low, so every deal matters and averages are noisy.

Why single-touch models mislead badly here: with 15 touches over 3 months across 4 people, "last-touch = direct" and "first-touch = one LinkedIn ad" are both almost useless. The middle — and the offline — is where the deal was actually won.

The B2B playbook

1. Source of truth = the CRM, not any analytics tool. Revenue is real in the CRM (closed-won, ARR); everything else explains where those deals came from. Pipeline and revenue attribution live in revops — attribution feeds it the "source" dimension.
2. Models: first-touch + position-based, shown together. First-touch values demand creation (which channel started the accounts that became pipeline). Position-based credits the created-and-closed bookends, the two decisions you actually make. Last-touch alone will defund your top of funnel — don't lead with it.
3. Self-reported attribution is your strongest signal, not a nice-to-have. Ask "How did you first hear about us?" on the demo request / signup form and again qualitatively on sales calls. For high word-of-mouth and dark-social-heavy B2B, this catches what tracking structurally can't (podcasts, communities, "my old coworker used you"). Weight it heavily.
4. Attribute to pipeline stages, not just the conversion. The useful B2B question isn't "what drove the form fill" — it's "what drove qualified pipeline and closed revenue." Break down MQL→SQL→closed-won by first-touch channel; a channel that fills forms but never closes is a trap. (Stage mechanics → revops.)
5. MTA is weakest here; incrementality is awkward but valuable. Low volume makes data-driven attribution unreliable and geo-tests hard. Use on/off tests for big-ticket programs (turn off a channel for a quarter, watch pipeline) and lean on self-reported + first-touch for the rest.
6. Account-level, not just lead-level. Attribution should roll touches up to the account (all the people at the buying company), or you'll credit whichever individual happened to fill the form. In practice one org is several people signing up with mixed work and personal emails, so person-level attribution scatters the story across records — match contacts to the account (email domain, enrichment, or your CRM's contact→account link) and attribute at the account level. That's where the signal has to land to be useful to a rep working the whole buying committee. Exclude free-mail domains (gmail/yahoo/outlook) from domain matching — they can't identify a company; fall back to enrichment or manual matching for personal-email signups. (Production emphasis from Tessa Kriesel; the CRM-sync mechanics live in first-party-tracking.md Step 5.)

Tooling: CRM (HubSpot/Salesforce) as truth; a product-analytics tool identifying by user/account UUID for first-party first-touch (see first-party-tracking.md); self-reported fields written to the CRM; RB2B-style de-anonymization to catch un-formed account visits.

The B2B trap to name for the user: branded search and direct will look like your best "channels" because that's where researched buyers convert. They're not channels — they're where demand created elsewhere cashes out. Segment branded vs. non-branded search and treat a big direct share as evidence your top-of-funnel is working, not as a channel to invest in.

---

Ecommerce / DTC (short cycle, self-serve)

Shape of the problem: journeys are fast (minutes to a few days), high-volume, and almost entirely digital and self-serve. Budget concentrates in paid social + paid search + email/SMS. The conversion is a purchase you fully control (your checkout or a hosted one). The dominant lie is platform over-attribution — Meta and Google each claiming the same sales.

The DTC playbook

1. Source of truth = your store/backend (Shopify, your payments system) — the count of actual orders. Platform-reported conversions get de-duped against that total; they never define it and are never summed.
2. Distrust platform ROAS by default. Post-iOS ATT, platforms model and estimate conversions, count view-through, and use generous windows — reported ROAS runs well above incremental ROAS. Use it for in-platform optimization (it's fine for the algorithm) but not for cross-channel budget truth.
3. Last-touch is defensible for quick-turn, impulse SKUs — the closing click really is most of the story for a $30 impulse buy. It gets dangerous as consideration lengthens (higher AOV, considered purchases), where it over-credits retargeting and branded search.
4. MMM once spend is material. When you're spending real money across paid social, search, and offline (podcasts, TV, influencers, OOH), MMM is how you allocate — it's the only paradigm that sees the untrackable channels and the saturation curves. Below ~six figures/month of blended spend, MMM is overkill; good UTMs + a survey do more.
5. Incrementality on your biggest channels — especially the "always credited" ones. Geo-holdouts and on/off tests earn their keep on retargeting, branded search, and Meta prospecting, which platform reporting flatters most. Incremental CPA (spend ÷ incremental orders) is the number that should move budget. (See measurement-paradigms.md.)
6. Post-purchase survey to catch the dark-social + brand demand. A one-question "How did you hear about us?" on the order-confirmation page consistently reveals that podcasts, TikTok organic, and word-of-mouth drive far more than pixels credit — because those touches convert later as "direct" or branded search. Kickstarter-era DTC brands run this as standard for exactly this reason.

Tooling: store/backend as truth; platform pixels + CAPI for optimization (setup → ads conversion-tracking.md); Supermetrics/Coupler to pull platform numbers into one place for de-duping; a post-purchase survey app; MMM tooling (Robyn/Meridian or a vendor) once spend justifies it.

The DTC trap to name for the user: summing platform-reported conversions. If Meta claims 100 and Google claims 80 but you had 120 orders, you do not have 180 conversions — you have 120 with overlapping claims. Anchor on the 120 and allocate the overlap with incrementality, not by trusting whichever platform shouts loudest.

---

Blended / PLG-with-sales

Many modern SaaS businesses are both: self-serve signups and a sales-assisted motion for larger accounts. Blend the playbooks:

• Use the DTC approach for the self-serve funnel (fast, high-volume, first-party first-touch → conversion, defensible last-non-direct + survey).
• Use the B2B approach for the sales-assisted funnel (CRM as truth, position-based, pipeline-stage attribution, self-reported at demo).
• Alias identities across the two so a self-serve signup who later becomes a sales-assisted expansion keeps one journey (email↔UUID alias at signup — see first-party-tracking.md).
• Report them separately. Blending a $50 self-serve signup and a $50k enterprise deal into one "attribution" number hides both stories.

references/first-party-tracking.md (verbatim)

1 placeholder credential shortened to pass the site's secret filter.

First-Party Attribution — The Own-Your-Attribution Runbook

How to instrument and stitch attribution yourself when you control the site/app. This is the build track (Pillar B). It's distilled from real production builds and kept tool-agnostic — PostHog + SavvyCal are the worked example, but the pattern maps to any product-analytics tool with identify()/merge (Segment, Amplitude, GA4 user-id) and any third-party conversion domain with a metadata passthrough + webhook (Calendly, Cal.com, Stripe Checkout, Typeform).

The core method — closing the identify() gap so conversions join to anonymous browsing history — is adapted from Tessa Kriesel's PostHog attribution approach. Several of the production refinements that make this operate at scale are also hers, credited inline: the full-touch-path capture that feeds the model track (Step 4), the CRM last-mile with source/confidence/basis and a Paid-vs-Organic read (Step 5), the account rollup, and the "expect ~zero until the stitch is verified, with a campaign-window fallback + backfill" window (Cross-subdomain stitching). Credit where due.

The one idea

First-party attribution joins anonymous browsing to the eventual conversion:

anonymous visitor          identify() at conversion         breakdown
─────────────────          ────────────────────────         ─────────
distinct_id = anon_uuid    identify(email)                  conversion event
$initial_utm_source=...  → merges anon history        →     by $initial_utm_source
$initial_referrer=...      into person(email)               = "where do customers come from"

Everything below serves that join. If identify() never fires, every customer looks like they appeared from nowhere — that's the gap.

Step 0 — Audit before you build

The most expensive mistake is rebuilding attribution that already works. Many SaaS apps already identify() at signup and already carry first-touch on person profiles. Check the live data first:

• Do person profiles carry $initial_utm_source / $initial_referring_domain?
• Does a conversion event (Signed up, Converted to paid) break down cleanly by channel, or is everything "Direct"?
• Is identity keyed by email or by an internal UUID? (This changes every guard below.)
• Does cross-subdomain stitching work (marketing site → app.yourdomain.com)?

Only instrument the specific conversions that are genuinely un-joined. In one real audit the self-serve funnel was already solved end-to-end; the only gap was a booking on a third-party domain. Don't touch what works.

Step 1 — Identify at each real conversion

At every conversion moment, call identify() with a stable id, and set person properties:

// Normalize before use as a distinct_id — analytics tools match exact strings,
// so "Corey@x.com" and "corey@x.com" split into two people otherwise.
export function identifyUser(email) {
  const normalized = email.trim().toLowerCase();
  window.posthog?.identify(normalized, { email: normalized });
}

With person_profiles: 'identified_only', this is the moment the person is created and their first-touch props are stamped. Fire it on form success, signup, first purchase — any moment you learn who the anonymous visitor actually is.

Step 2 — Stitch conversions on a domain you don't own

When the conversion completes on a third-party domain (a booking tool, hosted checkout), you can't run your analytics there. Smuggle the anonymous id through the tool's metadata passthrough, then merge it back in the webhook.

2a — Capture-phase link decorator

One document-level listener rewrites every outbound booking link at click time — no per-CTA edits, and it covers plain clicks, keyboard activation, and middle-click (auxclick):

// Append the anonymous distinct_id to any SavvyCal link at click time.
function decorate(e) {
  const anchor = e.target?.closest?.("a[href]");
  if (!(anchor instanceof HTMLAnchorElement)) return;

  let url;
  try { url = new URL(anchor.href); } catch { return; }
  const host = url.hostname;
  if (host !== "savvycal.com" && !host.endsWith(".savvycal.com")) return;

  const distinctId = getPostHogDistinctId();   // anonymous-only — see guard
  if (!distinctId) return;                       // fail closed

  url.searchParams.set("metadata[ph_distinct_id]", distinctId);
  anchor.href = url.toString();
}
document.addEventListener("click", decorate, true);    // capture phase
document.addEventListener("auxclick", decorate, true);

For an inline embed (e.g. /demo with an embedded calendar), pass the same id in the embed's metadata config instead; poll briefly (~2s) for the id on fresh visits, but never block the calendar from rendering.

2b — Read the anonymous id safely

The SDK stub queues calls before it loads, so get_distinct_id() returns undefined early — fall back to the tool's own cookie:

export function getPostHogDistinctId() {
  if (typeof window === "undefined") return null;

  // Prefer the loaded SDK.
  try {
    if (window.posthog?.__loaded) {
      const id = window.posthog.get_distinct_id();
      if (id) return isAnonymousDistinctId(id) ? id : null;
    }
  } catch {}

  // Fall back to PostHog's cookie before the SDK finishes loading.
  try {
    const prefix = `ph_${POSTHOG_API_KEY}_posthog=`;
    const cookie = document.cookie.split(/;\s*/).find(c => c.startsWith(prefix));
    if (!cookie) return null;
    const parsed = JSON.parse(decodeURIComponent(cookie.slice(prefix.length)));
    return typeof parsed.distinct_id === "string" && isAnonymousDistinctId(parsed.distinct_id)
      ? parsed.distinct_id : null;
  } catch { return null; }
}

2c — Merge in the webhook

The third-party tool returns your metadata in its booking.created (or checkout.completed) webhook. Fire an identity merge + a conversion event to your analytics ingestion endpoint:

// Normalize the booking email the same way the app does (Step 1), or the
// booking person will split from the app-side identity for the same user.
const userId = email.trim().toLowerCase();

const events = [];
if (anonId) {
  events.push({
    event: "$identify",
    distinct_id: userId,                                  // the known person
    properties: { $anon_distinct_id: anonId, $set: { email: userId, name } },  // merge the journey
  });
}
events.push({
  event: "discovery_call_booked",
  distinct_id: userId,
  properties: { booking_id, journey_linked: Boolean(anonId) },  // track the fallback rate
});

await fetch(`${POSTHOG_HOST}/batch/`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ api_key: YOUR_KEY batch: events }),
  signal: AbortSignal.timeout(3000),   // bound it; never hang the webhook
});

When no id survives (link bypassed the decorator, e.g. a booking link inside a generated email/PDF), fall back to email-only capture with journey_linked: false. You still get the conversion; you just don't get the journey for that one.

First-touch survival caveat (PostHog specifics): the $anon_distinct_id merge carries the anonymous person's event history, but with person_profiles: 'identified_only' the anonymous visitor may never have had a person profile, so their $initial_* first-touch props aren't guaranteed to land on the merged person. Two robust fixes: call posthog.createPersonProfile() client-side before the visitor navigates off to the third-party domain (so the profile and its $initial_* exist to merge into), or capture the first-touch values client-side and pass them through the same metadata passthrough, then re-assert them in the webhook with $set_once ($set_once never overwrites an existing value, so it's safe). Without one of these, you can get the booking joined to the journey's events but a blank $initial_utm_source on the person — verify on a real booking. (posthog-js#1524.)

Step 3 — The guardrails (do not skip)

Anonymity guard — fail closed

Only ever smuggle the anonymous id. After identify(), the current distinct_id becomes the user's email/UUID — leaking that into a third-party URL, or merging on it in the webhook, folds unrelated people together and leaks PII.

Pick the guard that matches your identity model — the two are not interchangeable. The @-check below is only safe when your app identifies by email; do not copy it into a UUID-identity app.

// EMAIL-IDENTITY apps only. True only for ids safe to smuggle: reject
// email-shaped values (an identified email) and cap length.
export function isAnonymousDistinctId(id) {
  return id.length > 0 && id.length <= 100 && !id.includes("@");
}

If the app identifies by UUID, not email, the @ check is useless — an identified UUID would pass it and leak. Instead test that the current distinct_id still equals the device_id (calling identify() changes distinct_id but leaves device_id), and fail closed when device_id is unreadable:

// UUID-identity variant: only anonymous when distinct_id still == device_id.
function isAnonymous(posthog) {
  const did = posthog.get_distinct_id?.();
  const dev = posthog.get_property?.("$device_id");
  if (!did || !dev) return false;   // ambiguous → treat as identified, send nothing
  return did === dev;
}

The rule in one line: when identity is ambiguous, send nothing. A missing journey is a data gap; a wrong merge is corruption.

First-touch data quality — the cheapest big win

Redirects overwrite the true first touch, inflating "Direct"/"Referral" and hiding real acquisition. Exclude these from referrer/channel classification (usually a settings change in the analytics tool, not code):

• OAuth / checkout redirects: accounts.google.com, login.microsoftonline.com, login.live.com, checkout.stripe.com
• Self / subdomain referrals: yourdomain.com, app.yourdomain.com, auth.yourdomain.com
• Dev/internal traffic: localhost, 127.0.0.1, test accounts

This is the highest-trust-per-effort fix in the whole runbook — no deploy, immediate accuracy gain. Do it first.

Cross-subdomain stitching

Marketing site → app on a subdomain must share one analytics project and a cross-subdomain cookie (PostHog's cross_subdomain_cookie default handles yourdomain.com → app.yourdomain.com). Verify the journey survives the handoff, or every signup looks like it started at the app.

Expect near-zero numbers until the stitch is verified in prod — don't panic. (Production note from Tessa Kriesel.) Before the cross-subdomain stitch is confirmed live, first-party attribution reads basically nothing — journeys break at the handoff and everything looks like direct. It flips from ~0 to real numbers the week the stitch actually ships. Two things get you through that window:

• A campaign-window heuristic fallback. When a signup has no linked journey, attribute it to the campaign/channel that was live during its signup window — but only when date + landing page + active UTMs uniquely narrow it to one source. With overlapping campaigns, evergreen ads, email sends, branded/direct demand, or a shared landing page, the window can't isolate the cause — mark those unknown / low-confidence rather than falsely crediting whatever was live. Used narrowly, it's a real signal while the stitch stabilizes and beats a blank; used bluntly, it manufactures false attribution.
• Backfill only the pre-stitch records that are actually missing a source. Many pre-stitch signups already have verified or self-reported attribution — never overwrite a higher-confidence source with the heuristic. Backfill only the blanks (campaign-window or self-reported), tag them as such, and keep the heuristic-backfilled history visually separate from verified trends so you don't read a cliff on launch day as a real shift.

Mark these fallback-attributed conversions with a lower-confidence basis (see Step 5) so you never confuse a heuristic guess with a verified journey.

Harden the webhook

• Verify the provider's signature (SAVVYCAL_WEBHOOK_SECRET etc.).
• Validate the smuggled id (string, ≤100 chars, no @) before merging.
• Run the analytics call after any business-critical work, bounded by a timeout, non-fatal on failure.
• Log the booking id, never the email.

Step 4 — Report

• Config check: many tools default to last-touch (PostHog's Marketing Analytics scene does). First-party attribution wants first-touch — build insights on $initial_* explicitly, or switch the default.
• The payoff insight: conversion event broken down by $initial_utm_source / $initial_referring_domain — "where does every signup/booking come from."
• Channel → revenue: conversion event by channel, joined to revenue/MRR person properties. Note: some tools compute revenue props at ingest (person-on-events), so historical events may read 0 — use the persons table for current MRR, or tier by plan.
• Track your own coverage: the journey_linked: false rate tells you how many conversions bypassed the stitch. Watch it after launch.
• Store the full touch path, not just $initial_*. (Refinement from Tessa Kriesel.) First-touch alone lets you break conversions down by first channel — but it can't run the multi-touch models from the interpretation track (SKILL.md §2: position-based, linear, time-decay). If you also persist the ordered sequence of touches per person (channel + timestamp for each, e.g. an events-table query or a touch_path array on the person), the build track feeds the interpretation track: you can now score the same journey six ways on your own data instead of only reading about the models. This is what makes Pillar A and Pillar B shake hands — capture first-touch to ship, capture the full path to model.

Step 5 — The last mile: get attribution into the CRM

(This whole step is a production refinement from Tessa Kriesel — it's the thing that turned first-party attribution from a dashboard into an operating signal.)

A channel breakdown living in your analytics tool is a report. The thing sales and lifecycle actually act on is attribution written onto the record in the CRM, per account. Sync it out:

• A source field, plus source_confidence and source_basis. Don't write a bare channel — write the channel and how you know it. basis is the evidence type: journey_linked (verified stitch), self_reported (survey), or campaign_window (the heuristic fallback above). confidence is computed from evidence quality, not just the basis — a journey_linked touch with clean UTMs is high, the same touch with dirty/missing UTMs is lower, and a specific self-report can be high while a vague one is low. Sales treats a high-confidence source very differently from a low-confidence guess — give them both fields or they'll distrust the whole thing.
• A Paid-vs-Organic read off the medium. The single most-used cut in practice: mark a touch paid only from explicit paid mediums (cpc, ppc, paid-social, display, paid), and classify the rest into a small, configurable taxonomy rather than a blunt "organic" — owned (email, push, SMS — though a sponsored newsletter is paid), earned (organic search/social, referral — but a partner/affiliate referral is closer to paid), direct (no medium — unknown, not organic), unknown. The fast operational question a rep or nurture flow needs is really paid vs non-paid (did this account cost acquisition dollars) — get that boundary right and keep the finer buckets configurable.
• Roll up to the account, not just the contact (B2B) — see the account-rollup note below and in by-business-type.md.
• Hand the record off to revops. Once the source/confidence/basis + paid/organic live on the account, how pipeline and lifecycle use them (routing, lead scoring, nurture branching, revenue attribution reporting) is the revops skill's job. This runbook's job is to get a trustworthy, labeled source onto the record.

Account rollup (B2B). One org is several people signing up with mixed work and personal emails, so person-level attribution scatters the story across records. Roll each person's source up to the account and attribute at the account level — that's where the signal has to land to be useful to a salesperson working the whole buying committee. Match on email domain, but exclude free-mail domains (gmail.com, yahoo.com, outlook.com, …) — those can't identify a company, so a domain match would collapse unrelated people into one bogus account. For personal-email signups, fall back to enrichment, your CRM's contact→account link, or manual matching.

Verification checklist

• Click a booking CTA → URL shows metadata[<id_param>]=<anon-uuid>.
• In console: posthog.identify('test@x.com') → click again → the param must NOT appear (guard works). posthog.reset() after.
• Hand-POST a webhook /batch/ payload → expect {"status":"Ok"}, person appears merged.
• Post-ship: first real webhook log shows journey_linked: true.
• Confirm first-touch survives cross-subdomain: start on marketing site, sign up in app, check the person carries the original $initial_utm_source.

Adapting to other stacks

Piece	PostHog (worked example)	Generalizes to
Anonymous id	distinct_id / $device_id	Segment anonymousId, Amplitude deviceId, GA4 client_id
Merge call	$identify + $anon_distinct_id	Segment identify (known userId, same anonymousId) + alias where needed; Amplitude setUserId on the session that still holds the anonymous deviceId (the stitch is deviceId↔userId — Amplitude's Identify API only sets user properties, it does not merge); GA4 user_id on the same client_id
Ingestion	/batch/	Segment HTTP API, Amplitude HTTP v2, GA4 Measurement Protocol
Third-party passthrough	SavvyCal metadata[...]	Calendly UTM/salesforce_uuid, Cal.com metadata, Stripe client_reference_id/metadata
First-touch props	$initial_*	Segment/Amplitude first-touch, GA4 first_user_* dimensions

The shape never changes: grab the anonymous id → carry it across the boundary → merge on the far side → break the conversion down by first-touch.

Back to coreyhaines31/marketingskills (marketing skills for agents) or Agent skills.