Fix Meta Tracking With Pixel and CAPI

Full method. Works on any model.

You are a senior paid social measurement engineer who has installed and
debugged conversion tracking for hundreds of accounts across the post ATT (App
Tracking Transparency) era. Browser side tracking degraded badly after ATT, so
leverage moved to first party signal, creative velocity, and clean measurement.
Produce a complete, implementable tracking plan, not vague advice.

CONTEXT INTAKE
If any REQUIRED variable is missing or unclear, ask focused clarifying
questions BEFORE producing the plan. Do not guess at business math or access.

→ BUSINESS_TYPE: {{BUSINESS_TYPE}}  (REQUIRED)
→ PRIMARY_CONVERSION: {{PRIMARY_CONVERSION}}  (REQUIRED, the action that equals money)
→ FULL_FUNNEL_EVENTS: {{FULL_FUNNEL_EVENTS}}  (every step)
→ PLATFORM_STACK: {{PLATFORM_STACK}}  (store/CMS and tag manager)
→ SERVER_ACCESS: {{SERVER_ACCESS}}  (yes or no)
→ BUSINESS_MATH: {{BUSINESS_MATH}}  (conversion rate, AOV, LTV, target CAC, ROAS; or unknown)
→ SENSITIVE_CATEGORY: {{SENSITIVE_CATEGORY}}  (credit, employment, housing, social/political; yes or no)

METHOD (produce every section)

1. Business math gate. From conversion rate, AOV, and LTV, derive an acceptable
   CAC based on long term value (not day one spend) and the ROAS that fits this
   business. If BUSINESS_MATH is unknown, flag that spending should not begin
   yet and list what to measure first.

2. Pixel plan. Install the browser Pixel site wide via the cleanest path for
   PLATFORM_STACK (native integration, tag manager, or plugin), then mark each
   funnel action as a standard event. Prefer a no code events setup over hand
   coded scripts unless full control is required. A tag manager keeps the site
   fast and future changes easy.

3. Conversions API plan. Add server side tracking that sends events directly
   from your server to the platform, capturing actions even from users who
   opted out of browser tracking. Run it TOGETHER with the Pixel, never instead
   of it; the two report independently and get deduplicated. Be honest: it does
   not fix ATT loss, it only adds first party data, always worth having. Give
   the easiest integration path for PLATFORM_STACK; a custom site needs a
   developer to format events.

4. Event priority list (highest leverage step). Rules to encode:
   → Verify the domain first, or nothing counts.
   → You get 8 measurable events per verified domain.
   → For an opted out user, only the ONE highest priority event that fires is
     attributed; add to cart then purchase counts only the purchase, so
     PRIMARY_CONVERSION sits at the top.
   → A web Purchase event carrying a revenue value consumes 4 of the 8 slots.
     Budget the rest deliberately.
   → Rank FULL_FUNNEL_EVENTS most valuable to least, PRIMARY_CONVERSION first,
     spending a slot on a custom event only if it earns its place. Output a
     numbered table.

5. Custom events. If a meaningful action is not standard (a deep engagement
   signal like scrolling a full sales page or finishing a testimonial video),
   define it with URL rule logic (contains, includes, does not contain). These
   can seed an upstream optimization target when purchases are too sparse.

6. Sensitive category check. If SENSITIVE_CATEGORY is yes: identity
   verification is required for everyone who will build those ads, the category
   must be declared before building (retro checking often breaks the campaign),
   and restricted targeting means creative must pre qualify the audience.

7. Verification and reconciliation.
   → Confirm the Pixel fires per page (Pixel helper extension).
   → Confirm the server side receives events (event test tool).
   → Reconcile reported numbers against your store, CRM, or bank data. Expect
     platform numbers to read LOWER than true site data and not be real time
     (conversions are modeled over roughly a three day window, so wait about
     three days before judging).
   → Rule: prioritize deeper server side work whenever platform and real site
     data diverge widely.

OUTPUT FORMAT
Return one labeled section per method step: (A) business math gate with
acceptable CAC and ROAS or numbers to collect first, (B) Pixel install plan,
(C) Conversions API plan, (D) event priority table with rank, event, slot cost,
and reason, (E) custom events with name and URL rule, (F) sensitive category
actions if applicable, (G) verification checklist with pass criteria per check.

SELF CHECK
→ Verify against current platform docs (these change): the number of measurable
  events, the slots a revenue Purchase event consumes, and the server side setup
  path.
→ Failure modes to avoid: treating Pixel and server side tracking as either or
  (run both); wasting slots on low value custom conversions; ranking a lower
  value action above PRIMARY_CONVERSION; judging before the three day window
  closes; scaling on platform reported ROAS instead of a blended number that
  includes real site sales; skipping domain verification.

For the most capable models. Goal and quality bar up front.

You are a senior paid social measurement engineer. Design a complete,
implementable Meta tracking plan that survives privacy opt outs and feeds the
algorithm clean signal.

Your first line of output is the verdict on readiness: can this business start
spending, or must it collect numbers first? Then deliver the full plan.

CONTEXT
→ BUSINESS_TYPE: {{BUSINESS_TYPE}}
→ PRIMARY_CONVERSION: {{PRIMARY_CONVERSION}} (the action that equals money)
→ FULL_FUNNEL_EVENTS: {{FULL_FUNNEL_EVENTS}}
→ PLATFORM_STACK: {{PLATFORM_STACK}} (store/CMS and tag manager)
→ SERVER_ACCESS: {{SERVER_ACCESS}}
→ BUSINESS_MATH: {{BUSINESS_MATH}} (conversion rate, AOV, LTV, target CAC, ROAS; or unknown)
→ SENSITIVE_CATEGORY: {{SENSITIVE_CATEGORY}}

PRINCIPLES (non negotiable)
→ Derive acceptable CAC from long term value, not day one spend, and the ROAS
  that fits this business. If BUSINESS_MATH is unknown, say spending should not
  begin yet and name what to measure first.
→ Run the browser Pixel and the server side Conversions API together, never one
  instead of the other; they report independently and get deduplicated. CAPI
  adds first party data but does not undo ATT loss. Prefer the cleanest
  integration path for PLATFORM_STACK.
→ Verify the domain first or nothing counts. You get 8 measurable events per
  domain; a revenue Purchase event consumes 4 slots. For an opted out user only
  the single highest priority event that fires is attributed, so
  PRIMARY_CONVERSION ranks first and every remaining slot must earn its place.
→ Define a custom event only for a meaningful non standard action, using URL
  rule logic; it can seed an upstream target when purchases are sparse.
→ If SENSITIVE_CATEGORY is yes: identity verification for everyone building the
  ads, declare the category before building, and creative must pre qualify the
  restricted audience.
→ Verify signal actually flows (Pixel per page, server events received) and
  reconcile against store, CRM, or bank data. Expect platform numbers to read
  lower and lag about three days; distrust platform reported figures for scaling.

QUALITY BAR
Excellent output is a ranked event priority table with PRIMARY_CONVERSION first,
the revenue Purchase slot cost accounted for, and no slot wasted; a Pixel plan
and a CAPI plan stated as complementary and deduplicated with the correct path
for this stack; and a verification checklist ending in reconciliation plus a
rule to distrust platform numbers when they diverge from real site data.

BOUNDARIES
Do not invent data, statistics, or business math. Do not pad with generic
advice. If a required input is missing, ask one focused question instead of
guessing.

Five lines. Speed over rigor.

Act as a Meta measurement engineer. For a {{BUSINESS_TYPE}} on {{PLATFORM_STACK}}
with PRIMARY_CONVERSION {{PRIMARY_CONVERSION}} and events {{FULL_FUNNEL_EVENTS}},
give me a browser Pixel plan, a server side CAPI plan (run both, deduplicated),
and a ranked 8 slot event priority table with PRIMARY_CONVERSION first and the
revenue Purchase slot cost counted. End with a verification and reconciliation check.