• Reads: account/offer topic and bid goal (tROAS vs max-conversion-value); the user's own GA4 purchase-value / ecommerce revenue export and a margin or COGS breakdown (by SKU, category, or blended); optional lead→sale close-rate and average-order-value inputs for proxy-value derivation.
• Writes: a user-facing value-model spec + value QA sheet to

  memory/ad/conversion-value-mapper/

  .
• Promotes: the approved value model (net-value formula, proxy values, dynamic-vs-static decision) and any value-integrity blockers (values missing, margin unknown, count-vs-value mismatch) to

  memory/hot-cache.md

  and

  memory/open-loops.md

  .
• Done when: every revenue-bearing conversion has a stated value and a net-value adjustment (or an explicit "revenue = net, margin flat" note); non-revenue conversions have a proxy value with a labeled derivation (never a guessed round number presented as fact); the static-vs-dynamic rule is chosen with a reason; the value-vs-count reconciliation is run and either passes or names the gap; and the spec says the value model is launch-ready for value-based bidding or lists exactly what to fix.
• Primary next skill: ad-account-auditor to score

  R1

  /

  R2

  and the full RQS once the value model and signal are both fixed.

Emit the standard shape from skill-contract.md §Handoff Summary Format.

1. Confirm bid goal and scope — name the bid strategy (tROAS, max-conversion-value, or value-based Advantage+) and the conversion actions in scope (purchase, lead, phone, signup). Restate the scope line: you define the values, not whether the tag fires (conversion-signal-qa) and not whether R1/R2 pass (ad-account-auditor). If the account bids to max-conversions (count) with no value goal, say so — a value model is optional there, and route back rather than over-building.
2. Inventory every conversion action — list each action the account counts, split into revenue-bearing (purchase/checkout) and non-revenue (lead, call, signup, add-to-cart). Each row needs a value or a reason it has none.
3. Set the revenue-bearing value basis — confirm whether the platform receives dynamic transaction value (per-order revenue passed from GA4/ecommerce) or a static per-conversion value, and mark which. Dynamic is the default for ecommerce; static is only defensible when order values are near-uniform — state which and why.
4. Adjust to net value (margin) — this is the profit lever. Map margin or COGS onto the revenue value so tROAS bids toward contribution, not gross revenue: net_value = revenue × margin (or revenue − COGS). Use the per-category/SKU margin from the export; if only a blended margin exists, apply it and label the value Estimated with the blended rate named. If no margin data exists at all, that row is needs-input, not a guessed 50%.
5. Derive proxy values for non-revenue actions — a lead or call has no transaction value, so give it a defensible proxy: proxy_value = expected_downstream_net_value = avg_order_net_value × lead→sale close_rate. Show the derivation and label it Estimated. Never drop a round number ("$50 per lead") with no basis — if close-rate or AOV is missing, mark the proxy needs-input.
6. Choose static vs dynamic value rules — decide whether values are fixed or adjusted by a value rule (by location, device, audience, or new-vs-returning). Recommend the simplest that fits: a single dynamic transaction value with no rules unless the user has a real margin/close-rate split across a segment. Flag rule-vs-signal collisions (a value rule that double-adjusts an already-margin-netted value).
7. Run the value-vs-count reconciliation — cross-check that total value the platform would receive over a recent period tracks the net profit the business actually booked. If the platform's summed conversion value is 3× the real contribution, tROAS is optimizing to a phantom number — flag it. This is a sanity check on the value model, not the cross-platform order-ID de-dup, which stays in attribution-reconciler; if the live totals won't reconcile across platforms, route there.
8. State launch-readiness — say plainly whether the value model is launch-ready for value-based bidding or list exactly what to fix (missing margins, undefined proxies, count-vs-value gap), then hand off to the auditor to score

   R1

   /

   R2

   .

• conversion-signal-qa — the sibling that verifies the event fires + UTMs are clean; run it before this skill (values are meaningless if the event never fires)
• attribution-reconciler — the standing cross-platform order-ID de-dup + incrementality workbook; owns which platform gets credit, not what the value is
• ROAS Benchmark — where

  R1

  /

  R2

  (measurement-signal integrity, of which value integrity is part) sit in the Return dimension; this skill is their value-side prerequisite
• ad-account-auditor — scores

  R1

  /

  R2

  and the full RQS once the value model and signal are fixed
• CONNECTORS.md —

  ~~web analytics

  ,

  ~~ecommerce

  own-data export recipes
• SECURITY.md — untrusted-data boundary for exported reports