Honest Growth
← All detections

Detection · capi_missing_or_weak

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:

  1. The account has at least one active sales/leads/conversions campaign
  2. Projected monthly spend is at least $1,500
  3. The account has Purchase events firing on the browser pixel
  4. 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_id to 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

  1. Open Meta Events Manager → your dataset → Settings → Conversions API.
  2. 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.
  3. If you are on a custom backend, implement CAPI via the Conversions API for Events Manager or via a partner like Stape or Segment.
  4. Send the event_id for every server-side event that has a browser-pixel counterpart. Meta uses the ID to deduplicate so conversions are not double-counted.
  5. Use Meta's Test Events view to confirm each CAPI event is arriving and matching browser events correctly.
  6. 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_events filtered to event_name == "Purchase". Each event exposes is_capi and is_browser flags so we can separate the two channels
  • Sum of daily_count across the audit date range for each channel, to compute the CAPI-to-browser ratio
  • Account objective and effective_status on 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.

See it run on a real account.

The sample audit shows this and 14 other detections fired against a synthetic but realistic $30K/month account.