Detection: Conversions API missing or weak for Purchase
Key: capi_missing_or_weak
Severity: Medium–High
Confidence: 75–90%
What this detection looks for
We flag an account as missing or weak on Conversions API (CAPI) for the Purchase event when all of these are true:
- The account has at least one active sales/leads/conversions campaign
- Projected monthly spend is at least $1,500
- The account has Purchase events firing on the browser pixel
- One of:
- No Purchase events have come through CAPI (missing case), or
- CAPI Purchase volume is less than 50% of the browser-pixel Purchase volume (weak case)
Why this matters
Apple's App Tracking Transparency (ATT) and similar browser-level privacy restrictions break a meaningful share of pixel events. The Conversions API is Meta's server-side replacement: your backend sends conversion data directly to Meta, bypassing the browser. Without CAPI, Meta sees fewer conversions, attribution under-reports performance, and the optimization model loses signal.
The cost shows up two ways:
- Optimization cost. Meta cannot target audiences toward conversions it never saw. The campaigns under-deliver against the business goal, particularly on iOS, which is the highest-AOV traffic for most DTC.
- Reporting cost. Reported ROAS understates actual ROAS, often by 10–30%. Budget decisions get made on a number that is wrong in a predictable direction.
CAPI implementation is mature in 2026 — Shopify, WooCommerce, and most ecommerce platforms have first-party integrations. The remaining work is usually mapping events and confirming deduplication with the browser pixel.
How we calculate confidence
| Condition | Confidence |
|---|---|
| No CAPI Purchase events firing while browser pixel is firing | 90% |
| CAPI Purchase events firing but at < 50% of browser volume | 75% |
| CAPI Purchase volume ≥ 50% of browser volume | We don't surface the finding |
How we calculate the estimated monthly cost
We surface a share of account spend as the cost of the visibility/optimization gap.
- Missing case (90% confidence): 10% of monthly spend
- Weak case (75% confidence): 5% of monthly spend
monthly_recoverable = (account_spend × share) × (30 / days_in_range)
These are conservative versus the 10–30% published lift figures because the actual gain depends on the share of your traffic that is ATT-affected (typically 30–50%) and the mix of iOS vs. Android vs. desktop in your audience.
What would change our mind
This finding can be a false positive in a small number of cases:
- Browser pixel records and CAPI records are not deduplicated
correctly. If you implemented CAPI and forgot to send the
event_idto deduplicate, Meta may be reporting CAPI events separately and our ratio looks wrong. Confirm in Events Manager → Deduplication. - You sell through a platform where browser pixel does not fire. Mobile-app-only checkouts or off-platform marketplaces will not produce browser-pixel Purchases. In that case the lack of browser events is correct and this detection should not fire — we check that the browser pixel has events before flagging, which prevents most of this case.
- You are in the middle of a CAPI rollout. If you implemented CAPI in the last 7 days, the ratio will look weak while server traffic catches up. Wait 14 days post-implementation before acting on the finding.
How to fix it
- Open Meta Events Manager → your dataset → Settings → Conversions API.
- If you are on Shopify, WooCommerce, or another supported platform, use the first-party integration. It implements server-side Purchase, AddToCart, InitiateCheckout, and ViewContent events with correct deduplication.
- If you are on a custom backend, implement CAPI via the Conversions API for Events Manager or via a partner like Stape or Segment.
- Send the
event_idfor every server-side event that has a browser-pixel counterpart. Meta uses the ID to deduplicate so conversions are not double-counted. - Use Meta's Test Events view to confirm each CAPI event is arriving and matching browser events correctly.
- Wait 14 days after implementation for the optimization model to incorporate the new signal. Expect modest reported-ROAS improvements followed by gradual optimization improvements over 30–60 days.
What we look at to make this detection
pixel_eventsfiltered toevent_name == "Purchase". Each event exposesis_capiandis_browserflags so we can separate the two channels- Sum of
daily_countacross the audit date range for each channel, to compute the CAPI-to-browser ratio - Account
objectiveandeffective_statuson each campaign to confirm purchase-style optimization - Total spend, projected to monthly, to ensure the finding only fires for accounts where the dollar value matters
Source
This methodology page is generated from
apps/api/app/services/detections/capi_missing_or_weak.py. The
detection code is open for inspection. We do not have hidden rules.