Attribution model selector

Outputs an attribution brief, a dated platform settings inventory and, for a multi-touch view, a model contract approved before any query runs. Every allocation rule redistributes credit for observed outcomes; none recovers missing interactions or proves what a channel caused.

When to use

Use this skill when:

• Someone asks which attribution model to use, or for "multi-touch attribution" without naming the decision it serves.
• GA4, Google Ads, Meta, LinkedIn or the CRM credit different channels for the same outcomes and someone asks which is right.
• A team is about to switch a platform between data driven and last click, or change a lookback or conversion window.
• Marketing wants pipeline or revenue by channel from HubSpot or Salesforce and the grain is undecided.
• Someone wants attribution to justify cutting or growing a channel.
• Explanation only ("explain multi-touch attribution", "linear vs time decay"): answer from references/models-explained.md with its worked path and availability list, then offer the brief once a decision is named. Skip steps 3 to 9.

Use something else when (fallback if that skill is not installed):

• A row-by-row bridge between two platform totals: platform-number-reconciliation. Fallback: the comparison rules in references/platform-attribution.md, then a ledger bridge.
• An agreed contract needs tables and tests: multi-touch-attribution-kit. Fallback: step 5.
• Step 1 routes the decision to causal evidence: incrementality-test-design or mmm-readiness-check. Fallback: the feasibility screens and vendor tools in references/decision-map.md.
• Pipeline credit needs full design: b2b-pipeline-attribution. Fallback: step 6 and its reference.
• ROI, ROAS and payback maths: marketing-roi-and-payback. Fallback: label every ROAS attributed or incremental, period or cohort, and stop there.
• App installs, SKAdNetwork, AdAttributionKit or an MMP: mobile-attribution-fundamentals. Fallback: the mobile rule in step 1.
• Missing or duplicated conversions: tracking-break-map or google-ads-conversion-diagnostics. Fallback: trace one known ledger outcome through tag, platform and report.

Inputs

Read first if they exist:

• martech-context/metrics.md: the outcome definition, its ledger query and its owner.
• martech-context/stack.md: ad platforms, analytics, CRM, MMP, warehouse and account owners.
• martech-context/decisions.md: earlier model and window choices with dates.
• martech-context/naming-rules.md: UTM and channel rules that decide which touchpoints exist.

Then gather:

• The decision in one sentence (action, size, date, alternative), who makes it, when, and the owner's tolerance for being wrong.
• The outcome: event, grain, time basis, value basis, refund cutoff, currency.
• The lag from first observed touch to outcome (median and 90th percentile), computed as in step 4, and the date the touchpoint data starts.
• Current platform settings, read live in step 3. Never from memory or an old screenshot.
• For B2B: the CRM, how contacts associate to deals or opportunities, and whether a "How did you hear about us?" field exists.

Never ask for, print or store credentials or customer personal data. Path samples use pseudonymous IDs.

Procedure

1. Classify the question

Write the decision, then place it in one class. Full map: references/decision-map.md.

• Operate a campaign inside one platform (bids, creative, audiences): use that platform's own configured attribution. Do not push a cross-channel model into bidding.
• Describe observed paths (where measurable demand enters, what precedes conversion, where journeys stall): attribution answers this.
• Predict the effect of a budget change: attribution only frames the hypothesis. Route one intervention to an incrementality test and recurring cross-channel allocation with enough history to MMM.
• Discover influences that leave no click (podcasts, peers, communities, AI assistants): self-reported attribution, reported beside software attribution, never merged into it.

Rules:

• Costly to reverse means the change is at least 20% of the channel's monthly spend, or the decision owner says the downside if wrong exceeds their stated tolerance. If neither is known, ask the owner for the tolerance and record it in the brief.
• If the action moves budget between channels or cuts a channel and is costly to reverse, attribution is hypothesis evidence only. The brief names the causal evidence still needed.
• If outcomes include iOS installs or in-app events, read references/mobile-limits.md before classifying and state the share of outcomes visible only through SKAdNetwork or AdAttributionKit postbacks. They have no user-level path, so no user-level MTA.

2. Fix the outcome before the model

• One outcome per view. Form fills, qualified opportunities and paid customers need separate views.
• Name the grain and dedupe rule (first paid order per customer, one opportunity, one account).
• Name the value basis: discounts, refunds as of which cutoff, tax, shipping, currency.
• Maturity: a value is final only when the outcome date plus the refund cutoff (plus 12 days for GA4 attributed data, 41 days for iOS postback values) is on or before the read date. Otherwise label the view provisional and give the date it matures.
• Link the metric in metrics.md. If it is missing, propose it there and stop until the owner agrees.

3. Read what each platform does today

Read settings read-only into assets/platform-settings-inventory.yaml, each with the read date and doc URL. How to read each one, and the GAQL: references/platform-attribution.md. The facts that settle most disputes (checked 2026-10-17 to 2026-10-20):

• GA4 offers data driven, paid and organic last click, and Google paid channels last click. The reporting model changes only event-scoped dimensions; First user and Session dimensions (and Traffic acquisition) always use paid and organic last click. A model change restates history; lookback changes apply going forward. Key events and conversions shared with Google Ads carry separate settings.
• Google Ads offers data driven (the default for most actions) and last click, per action, feeding Smart Bidding through the Conversions column. Window changes are not retroactive. Standard columns use the interaction date; "by conv. time" columns the conversion date.
• Meta, from March 2026 (staggered per account): click-through for website and in-store conversions counts link clicks only; other clicks moved to engage-through. The Insights API stopped returning 7d_view and 28d_view on 12 January 2026. Since 10 June 2025 it ignores use_unified_attribution_setting and action_report_time: pulls use each ad set's attribution setting and mixed report time (on-Meta actions at impression time, off-Meta conversions such as web purchases at conversion time).
• LinkedIn uses last touch for most conversion types and credits views as well as clicks. API-created rules default to LAST_TOUCH_BY_CAMPAIGN (each ad set); read the counting setting on each rule.
• Platforms overlap. Never add platform-attributed conversions to get a business total.

4. Choose the view by the question

Mechanics and worked numbers: references/models-explained.md.

• "Where do new customers first enter our measurable journey?" First observed touch: GA4 First user dimensions, CRM original source, or a warehouse view, labelled "first observed" with the history start date.
• "What is the last measurable route into conversion?" Last non-direct: GA4 paid and organic last click, or session-scoped reports for session questions.
• "How does a channel contribute across paths?" A rule-based view (linear, position based, time decay) under a contract (step 5). GA4 data driven qualifies only for a GA4 web key event where every in-scope channel arrives by tagged clicks; it never sees Meta or LinkedIn views. Show it beside first observed and last non-direct, never alone.
• "Is this campaign meeting its in-platform target?" The platform's own model and columns.
• "Should we move money?" No model answers this; step 1 routed it.

Rules:

• Lag: compute it on all touch history with no lookback cap, using only outcomes dated at least the longest candidate lookback after the history start. If over 10% of converters' first observed touch falls on the history start date, mark the lag itself truncated.
• Lookback at or above the 90th percentile of that lag. If touchpoint history is shorter, label first observed as truncated.
• If that lag exceeds the window a platform view uses (maximums: GA4 key events and Google Ads clicks 90 days, LinkedIn 90, or 365 for some Conversions API types; read Meta's on the ad set), label that view "truncated by design" with the gap in days, and answer cross-channel or pipeline questions from a CRM or warehouse view under the contract.
• If under 50% of outcomes, by count or by value, have an eligible touch, lead with coverage, not channel shares.
• Treat data driven as the platform's estimate: you cannot audit or reproduce its weights.
• Time decay half-life defaults to the median observed lag, with sensitivity at half and double that value. Position based only with written one-touch and two-touch rules.

4a. Switching a platform model

Detail and change list fields: the switching section of references/platform-attribution.md.

• Read data_driven_model_status. If it is not AVAILABLE, do not move the action to data driven; record the status.
• Preview with the Google Ads Model comparison report, never by switching.
• A switch on an action that is primary or in a custom goal is a bidding change, and so is a GA4 "channels that can receive credit" change for GA4 conversions used in bidding. Draft a change list; never apply it.
• Never switch a model to make GA4 and Google Ads match.

5. Write the contract before any multi-touch query

Fill assets/mta-contract-template.yaml, including the touch ordering and rounding rules, and get it approved before SQL runs. Field rules, touchpoint source checks and invariant SQL: references/mta-contract.md. Building tables is multi-touch-attribution-kit's job; without it, compute each view as CTEs inside one read-only SELECT. Every view must pass:

• The outcome table reconciles with the ledger query in metrics.md by count and value per currency before any credit is computed.
• Each eligible outcome appears once, and every outcome has credit rows.
• Credited touches occur before the outcome, inside the lookback, through an identity link the contract allows; NULL timestamps fail.
• Weights sum to 1 per outcome; credited value equals outcome value per currency; NULL credit fails.
• Unattributed outcomes stay as a row with count and value.

6. B2B: choose the grain and the source fields

Details, CRM checks and a worked deal: references/b2b-attribution.md.

• Contact grain answers lead generation questions, opportunity grain pipeline questions, account grain buying-group questions. One grain per view. Never credit one deal amount to several contact paths.
• Date MQL or SQL outcomes from a dated stage-entry property or stage history, never the current lifecycle stage. Pipeline uses amount from a dated snapshot; weighted pipeline is expected value, never revenue or ROI.
• Anchor lag and lookback on opportunity create date for pipeline-created views and on close date only for won-revenue views. Name the anchor in the view title.
• Before any source report, run the reference's CRM checks: HubSpot deals with no contact and Salesforce opportunities with no contact roles (both get no credit) with their share of amount, how Lead Source is filled (never the first web touch), and one multi-contact deal. Record contacts as pseudonymous counts, never names or emails.
• Self-reported: one optional open-text question on the highest-intent form, raw answer stored per submission, coded with a versioned codebook, reported as coded counts with its response rate as a separate view. Never quote raw answers in the brief.

7. Test the choice

• Compute at least two views on the same outcome population.
• Change one assumption at a time: lookback, new versus returning, brand versus non-brand search, identity rule, tie order when tied touches carry over 5% of value.
• If the recommended action flips under any plausible alternative, recommend a smaller reversible step or a test.

8. Mobile apps

In the brief, state the postback-only share from step 1, the app's AdAttributionKit window settings, and that iOS postback values stay provisional for 41 days. Android Play installs carry a click-level install referrer; report the two platforms separately. Limits: references/mobile-limits.md.

9. Write the brief and propose the record

Fill assets/attribution-brief-template.md. Label every number with platform or view, model, window and date basis. Keep attributed and incremental ROAS apart. Propose a dated entry for martech-context/decisions.md and wait for approval.

Common failure modes

The most frequent. Full list with detection rules (model switches, GA4 scope, Meta's click change, summed platform claims, referrals and internal UTMs, scanner clicks, native lead forms, in-app browsers, ties, identity resets): references/failure-modes.md.

• Connector Meta numbers differ from Ads Manager. Detect: pull one ad set for one week with no requested windows and compare with Ads Manager, then each window the dashboard requests. The unified setting and report time parameters change nothing.
• Dashboards still requesting 7d_view or 28d_view. Detect: values missing or the request failing for any request made on or after 12 January 2026, whatever the date range.
• Immature values reported as final. Detect: latest outcome date plus refund cutoff falls after the read date with no provisional label.
• Outcome table built from GA4 events or an inner join to sessions. Detect: outcome count or value differs from the ledger query.
• GA4 export touches built from traffic_source. Detect: among users with two or more sessions from different sources, 5% or more have every touch equal to their first-acquisition source.
• Paid clicks classed as direct. Detect: touches with a click ID (gclid, wbraid, gbraid, fbclid, li_fat_id, msclkid, ttclid, plus any platform in stack.md) classed as direct or organic.

Worked example

Fictional $1,200 first order after organic search (day 0), paid social (day 7), email (day 14), paid brand search (day 21) and a direct visit (day 22): first observed gives organic search $1,200, last non-direct paid brand search $1,200, linear $300 each, position based 40/20/40 $480, $120, $120, $480, time decay with a 7-day half-life $80, $160, $320, $640. Data driven cannot be computed from one path. Full mechanics: references/models-explained.md.

assets/example-acme-brief.md shows a cohort brief where paid social prospecting earns 6% of new-customer value last non-direct and 18% first observed, the proposed cut flips between views, and the brief recommends a geo holdout before any cut.

Acceptance checks

• All classes, decision: one sentence with action, size, date and alternative, and one question class. Pass: a budget decision states whether it is costly to reverse by the step 1 rule and names the causal evidence still needed or the accepted risk.
• All classes, outcome: grain, dedupe rule, time basis and value basis linked to metrics.md. Pass: no bare "conversions".
• All classes, maturity: latest outcome date plus refund cutoff (plus 12 days for GA4 attributed data, 41 for iOS postback values) is on or before the read date, or every number is labelled provisional. Pass: the mature date is stated.
• All classes, inventory: each in-scope platform (for "operate", the one platform) has model, windows, eligible channels, date basis, counting, time zone and value basis, with read date and doc URL. Pass: no value from memory; a window below the p90 lag is labelled truncated by design.
• Describe and budget, views: at least two computed on the same outcome population, each titled with its question, after coverage by count and by value. Pass: both coverage shares present; shares include an unattributed line.
• MTA, when used: contract approved before the first query; outcome table reconciles to the ledger by count and value before any credit is computed; all invariant checks return zero rows. Pass: query results attached.
• B2B, any class: grain and anchor in each view title; zero-contact deals or zero-contact-role opportunities counted. Pass: credited pipeline equals distinct opportunity amounts in scope.
• Self-reported view, when used: raw answers stored per submission, codebook version named, response rate beside every share. Pass: all three present, no raw answer quoted.
• Model switch question: change list names the action, DDA status, Model comparison read, bidding use, series break and date. Pass: nothing switched.
• All classes, labels: platform or view, model, window and date basis on every number. Pass: attributed and incremental never share a column.
• All classes, approval: the decisions.md entry was proposed and approved. Pass: no platform setting or warehouse object was changed by this work.

Boundaries

• Read-only. This skill never changes an attribution model, window, conversion action, goal or channel credit setting. A wanted change is a change list with expected effects (bidding, history restated or not, series break) for the account owner to approve and apply.
• Warehouse: SELECT only. Any CREATE, INSERT or MERGE needed to materialise outcome or credit tables is drafted as SQL for approval and runs in a schema the user names. Use a read-only role where one exists.
• It does not run experiments, fit MMMs or set budgets. It frames the hypothesis and names the evidence.
• Hand-offs:
  • GA4: Google's GA4 MCP server (experimental, local, analytics.readonly); read attribution settings in Admin or with the Admin API getAttributionSettings.
  • Google Ads: Google's read-only Google Ads MCP server; search with the GAQL in the platform reference.
  • Meta: the Ads MCP server's reporting tools only; it can also edit campaigns, and lift studies need approval.
  • LinkedIn: no official MCP server; read conversion rules in Campaign Manager.
  • HubSpot: the remote MCP server can write CRM records and has no documented read-only mode; read properties and associations only.
  • Salesforce: an admin reads Customizable Campaign Influence settings (enabled models, auto-association rules, time frame) in Setup.
  • MMM: Google's Meridian skills, after mmm-readiness-check or its fallback.

Live docs

Platform settings, limits and menu paths change. Before stating any parameter name, limit, quota or UI path:

• Fetch the current page from the vendor docs MCP server or llms.txt listed in sources.yaml, or open the canonical URL.
• If the live page disagrees with this skill, follow the live page and tell the user what changed.
• Cite the URL you used.

Entries that matter most: GA4 attribution, scope and shared conversion pages; Google Ads attribution and window pages; Meta's click attribution post and Insights API best-practices page (it overrides the Insights reference on the unified setting); LinkedIn's attribution pages and Conversions API schema; HubSpot's traffic source and attribution articles; Salesforce's campaign influence pages; Apple's AdAttributionKit window and attribution rules pages. Meta's default ad set attribution setting could not be read; read it on the ad set.