[TortoiseWolfe]

Closes #1197

A paid OpenAI Ads campaign is running against scripthammer.com with $500 in credits, and nothing
could tell whether it worked. GA was dead (loader ships, no G- id in the bundle, variable unset),
no code read any inbound click id, and the campaign's Tracking parameters field was empty — so a
click from ChatGPT was indistinguishable from a bookmark.

FR-024a, read correctly

The obvious implementation is forbidden: FR-024a bans storing marketing attribution, enforced in
the migration comment, in create-lead/resolve.ts building its row by naming two fields, and in a
test. I initially read that as ruling out server-side reporting entirely — and that was wrong.

Its literal subject is "a booking confirmation received from the scheduler." It says nothing
about orders or payment_intents, its recorded reasoning (spec.md:486) is about consent
rather than tables, and it names its own revisit condition:

Revisit when campaign volume makes the gap visible.

This takes that invitation. leads is untouched. Attribution lives on the purchase path and is
captured, stored and reported only with marketing consent — honouring the reasoning, not merely
the letter. The revisit is written into the spec rather than worked around quietly.

Design

ad click ──► /?oppref=…       (trailing-slash 301 preserves query strings — verified live)
  ├─ no marketing consent ──► nothing captured, nothing reported
  ├─ pixel (consent-gated)  ──► lead_created on "Book a call"
  └─ /checkout ─► create-order ─► payment_intents.metadata.oppref
        └─► create-stripe-checkout ─► Stripe payment_intent_data.metadata.oppref
              └─► stripe-webhook, payment PROVEN ─► Conversions API order_created

No migration. payment_intents.metadata is already JSONB and create-order already builds a
metadata object.

Server-side for the sale, because a browser-only order_created is lost whenever the buyer closes
the tab on Stripe's page. It fires after the order advances and the receipt sends, and
ad-conversions.ts cannot throw — a rejection inside a Stripe handler is a 500, Stripe retries a
500 for three days, and that is how the webhook was lost for a month (#1180). Ad measurement is not
permitted to cost the money path.

Four guards caught incomplete wiring

Each a different way to ship a variable that does nothing, and worth naming because they are the
reason this is complete: deploy.yml not passing it, .env.example not documenting it, the fork
inventory having no consequence recorded, and a committed talk slide that lists every value. The
inventory table is generated — I hand-edited the markdown first and had to revert.

Verification

• 5876/5876 vitest · 989/989 test:scripts · deno check clean on create-order,
  create-stripe-checkout, stripe-webhook.
• Both consent mutations bite: making captureOppref ignore the flag reddens 2 tests, making
  readOppref ignore it reddens 1 — so a withdrawal provably still takes effect, not just a
  refusal.
• The component test asserts it renders nothing on analytics-only consent, so accepting site
  measurement is never silently treated as accepting an ad network.

Not live until you set four values

NEXT_PUBLIC_OPENAI_PIXEL_ID   repo VARIABLE             Ads Manager → Conversions
OPENAI_ADS_PIXEL_ID           Supabase function secret  same value, for stripe-webhook
OPENAI_ADS_API_KEY            Supabase function secret  genuinely secret
NEXT_PUBLIC_GA_MEASUREMENT_ID repo VARIABLE             revives GA

Plus the campaign's Tracking parameters: oppref={oppref}&campaign_id={campaign_id}&ad_id={ad_id}.
Unconfigured is a clean no-op — the pixel renders null, reportAdConversion returns false.

🤖 Generated with Claude Code