Get your Meta tracking to 95%+ accuracy guaranteed in writing.
Meta's algorithm rewards data quality. EMQ 5 means half your iOS users never get matched, lookalikes seed off a tiny pool, and your CPMs creep up week after week. EMQ 8+ flips it: more matched conversions, larger seed audiences, lower CPMs, recoverable scale. We rebuild your CAPI with full advanced matching, deterministic dedup and a server-side gateway in 5–7 days.
Free30 minutesNo obligation
Meta · what breaks
Why your Meta CAPI is underperforming
- 01
EMQ stuck at 4–6
Without email, phone, name, address, fbc, and fbp, Meta can't match enough events. Cost-per-result inflates.
- 02
Browser + CAPI but no dedup
Most setups use bad event_id discipline — Meta double-counts or drops events at random. Reported ROAS is unreliable.
- 03
iOS 14.5 throttling kills lookalikes
Browser pixels lose a significant share of iOS users. Lookalike seeds shrink. Costs rise.
- 04
Aggregated Event Measurement priorities wrong
Most accounts have AEM events in the wrong order — Purchase below AddToCart. iOS conversions get filtered out.
Meta · the fix
Outcomes — Meta
EMQ 8+ on Purchase
Verified live in your Events Manager screen.
Deduplicated browser+server
Deterministic event_id, deterministic event_time.
iOS-recovered audiences
Larger custom and lookalike audiences from server-side recovery alone.
AEM properly prioritized
Purchase first, all 8 slots used optimally.
Meta · architecture
How a purchase should reach Meta twice and be counted once
Deduplication is the whole game. Meta needs both the browser and the server event to build a complete picture, and it needs to know they are the same event. Get the second part wrong and you either lose half your data or double your reported revenue.
- 1
The browser generates the event ID
One ID per real event, created in the browser and pushed to the data layer. It has to originate in one place — two systems each generating their own ID is the most common cause of failed deduplication.
- 2
The Pixel fires with fbp, fbc and that ID
The browser event carries _fbp, _fbc, the click ID from fbclid, and the shared event_id. This path is fast and it is the one that gets blocked.
- 3
The server container receives the same event
A GTM server container on your own subdomain receives the event with the same event_id, adds hashed email, phone, name and address from the order, and forwards it to the Conversions API.
- 4
Meta matches on event_id plus event_name
Within the deduplication window Meta keeps the richer of the two and discards the other. One conversion reported, two chances of it arriving.
- 5
Match quality is raised deliberately
EMQ climbs with the number of matched customer parameters. Email, phone, first and last name, city, state, zip and external ID together move most accounts from the low 5s into 8 or better.
Meta · events
The Meta event set we build, and what each parameter is doing
Standard event names, because custom events do not qualify for the same optimization and catalog features. Every event carries the shared event_id whether or not the server path is live yet.
| Event | Fires when | Key parameters | Sent from |
|---|---|---|---|
| PageView | Any page loads | _fbp, _fbc, event_id | Browser + server, deduped |
| ViewContent | Product detail page loads | content_ids, content_type, value, currency, event_id | Browser + server, deduped |
| AddToCart | Item added to cart | content_ids, value, currency, event_id | Browser + server, deduped |
| InitiateCheckout | Checkout begins with a non-empty cart | content_ids, num_items, value, currency, event_id | Browser + server, deduped |
| Purchase | Order confirmed by the store or processor | content_ids, value, currency, em, ph, fn, ln, ct, st, zp, external_id, event_id | Browser + server, deduped — server is authoritative |
| Lead | Qualified lead, not every form fill | em, ph, external_id, value, event_id | Server preferred |
| Subscribe | First successful recurring charge | value, currency, predicted_ltv, event_id | Server |
Meta · normal or broken
Meta will not match your store, and it is not supposed to
Meta reports on an attribution basis. Your store reports on a cash basis. Some of the gap is real and some of it is arithmetic, and the difference matters.
Normal, not a fault
Meta reports more purchases than the store
Default 7-day click and 1-day view attribution credits Meta for orders the customer also reached another way. Two platforms can each claim the same sale. Neither is lying.
Reported revenue exceeds actual revenue
Same cause. If Meta, Google and email are all credited for one order, the sum of their reported revenue exceeds what you banked. Compare each platform to your total, never sum them.
The Events Manager 'Deduplicated' indicator appears on some events but not all
It only shows where both a browser and a server event arrived. Server-only events like a qualified Lead will never show it, and should not.
EMQ below 8 on ViewContent or AddToCart
Those events happen before you know who the visitor is. Purchase is the score that matters, because that is where you have the customer's real details.
Actually broken
Purchase count is close to double the order count
Deduplication is failing. Almost always because the Pixel and a partner integration each generate their own event ID, or because one path sends event_id and the other does not send it at all.
Purchase EMQ stuck at 4 or 5
The server events are arriving with too few customer parameters, or they are being hashed wrong — trailing whitespace, mixed case, or hashing an already-hashed value.
Server events show up as processed but with no fbp or fbc
The click ID was never captured or never made it into the server payload. Attribution falls back to whatever Meta can model, which is far less.
Purchases stop entirely after a checkout change
The thank-you page moved or a payment provider now redirects through its own domain. The browser event dies, and if there is no server path, the account goes blind overnight.
Meta · diagnose
How we find out why Meta's numbers are wrong
- 01
Open Events Manager and check the Deduplicated indicator
Per event, over the last seven days. If Purchase shows both a browser and a server count with no deduplication badge, that is the answer and everything else is downstream of it.
- 02
Compare event IDs across both paths
Use Test Events with a real order and confirm the browser event_id and the server event_id are byte-identical, not merely both present.
- 03
Inspect the CAPI payload directly
Read the actual server request. Look for missing user_data fields, unhashed values, or a value that arrived as a string.
- 04
Count the integrations
Check for a partner integration, an app-installed CAPI, and a GTM server container all sending Purchase. Two live paths plus the Pixel is three events for one order.
- 05
Check the match quality breakdown per parameter
Meta shows which parameters it received and matched. A field present but never matching means it is malformed, not missing.
- 06
Reconcile a closed window against the store
Seven fully closed days, orders from the backend against Meta on a per-order-ID basis. The direction of the gap tells you whether events are lost or duplicated.
Meta · prove
What we hand over as proof — Meta
A screenshot of the Events Manager overview is not proof. These are.
Source of truth
Store or payment processor order records
- Purchase events show the Deduplicated indicator in Events Manager across a full week.
- Purchase EMQ at 8 or above, sustained over seven days rather than measured on the day of handover.
- Server Purchase count within a few percent of backend orders for a fully closed window, matched on order ID.
- No order ID appearing twice in the server event log.
- fbp present on the large majority of events, and fbc present on every event from a Meta click.
- A payload sample from a real order, with the hashed fields shown as sent, saved to your own records.
- The same reconciliation repeated 30 days later.
Meta · free audit
What we check in the free audit
- Open Events Manager and check the Deduplicated indicator
- Compare event IDs across both paths
- Inspect the CAPI payload directly
- Count the integrations
- Check the match quality breakdown per parameter
- Reconcile a closed window against the store
Checked against
Store or payment processor order records
Free30 minutesNo obligation
Meta · when not to buy
When you do not need a CAPI build — Meta
- You spend under roughly $2,000 a month on Meta. Turning on the built-in CAPI integration your platform offers will get you most of the value at no cost.
- Your Purchase EMQ is already 8 or higher and deduplication is confirmed working. Check it before you buy anything — some platform integrations do this correctly out of the box.
- You are running brand awareness or reach campaigns with no conversion objective. There is nothing for the extra signal to optimize.
- Your ads are not working because the creative is not working. Better data will show you that faster, but it will not change it.
Meta · what we deliver
Deliverables — Meta
Server-side gateway
Stape or self-hosted sGTM, your call.
CAPI hybrid with dedup
Browser pixel + server CAPI + deterministic IDs.
Full advanced matching
Email, phone, fn, ln, ct, st, zp, country, fbc, fbp, IP, UA, external_id.
AEM configuration audit
8-slot prioritization based on your funnel.
QA + EMQ screenshots
Live-fire test, before/after EMQ.
Written guarantee
95%+ tracking accuracy
Measured against Store or payment processor order records. Miss it and we keep working at no cost.
Pricing
Pick the package that fits your ad spend
Pixel-only starter
$400one-time setup
Foundation Meta pixel install only. Honest disclosure: this tier is for accounts spending under $1K/month. Above that, 1st-party server-side is the only architecture that survives iOS, ITP, and ad blockers.
- Meta pixel / tag installed
- Clean dataLayer for purchase + lead events
- UTM hygiene + dedup checks
- Consent Mode v2 banner integration
- QA test events + 7-day support
- No server-side CAPI · no iOS recovery
1st-party server-side Meta
Recommended for paid media$800one-time setup · most popular
What every account spending $5K+/month on Meta should run. 1st-party server-side Events API on your subdomain, full identity match, deterministic dedup. iOS users count, ad blockers don't matter, Meta's algorithm finally has the signal it needs.
- Everything in pixel starter
- 1st-party server-side Meta Events API
- Full identity match (email, phone, IP, UA, click_id)
- Deterministic browser ↔ server dedup
- Match-quality / EMQ live verification
- Notion runbook + 30-day support
Full-funnel + offline imports
$1,800one-time + optional retainer
For agencies and brands running multiple Meta accounts or wanting CRM offline conversions feeding back. Every signal — click, lead, MQL, SQL, opportunity, closed-won — pipelined into Meta so the algorithm optimizes for revenue.
- ✓ Everything in 1st-party server-side Meta
- 📥 CRM offline conversion imports
- 🔀 Multi-account routing & per-account QA
- 🎯 Lead-quality / VBO bidding readiness
- Looker Studio attribution dashboard
- 60-day support · retainer optional
FAQ
Meta questions, answered
Yes — it requires hashing and passing email, phone, address, fbc, fbp, IP, UA, and external_id together. Every project we ship hits 9.0+.
Stape is faster to ship, self-hosted is cheaper at scale. We'll recommend based on your traffic.
We typically replace it. Native plugins double-fire and tank EMQ.
More on Meta
- GuideMeta Conversions API Errors Explained: Invalid Parameters, Missing Data, Rejected Events
- GuideMeta's One-Click CAPI Setup: What It Does — and What It Quietly Misses
- GuideMeta Lead Ads Tracking: From Instant Form to CRM to Closed Deal
- Free toolEMQ predictor
- Free toolTracking audit
- Free toolCustomer data hasher
- Healthcare Meta CAPI SetupGoogle Ads for healthcare meta capi setup: the build order
- Meta CAPI deduplication not workingWhy is my Meta CAPI deduplication not working?
- CAPI deduplicationMaking the Pixel and the Conversions API count one sale once
WhatsApp