Meta Pixel and CAPI: Event Collection Architecture
Should events come from the browser or the server?
Both, for the events that matter. Meta recommends a redundant setup: send key events from the pixel and the Conversions API with the same event_name and event_id, so Meta keeps one copy within 48 hours. Give each event one source of record, and aim for the 75% server-to-pixel coverage ratio Meta recommends.
Send your important events from both the browser and your server, and decide in advance which system is the truth for each one. Meta recommends running the Conversions API alongside the pixel, a setup it calls redundant, and it collapses the two copies into one only when they share a key. The table below gives every ecommerce event an owner, a consent gate and that key.
Once the contract is set, How do I diagnose duplicate events between pixel and CAPI? shows how to test it, and What should I check when setting up Meta Pixel and CAPI? gives the order to validate it in.
What does Meta recommend for browser and server events?
Meta’s deduplication guide says: “For optimal ad performance, we recommend that advertisers implement the Conversions API alongside their Meta Pixel. We call this a ‘redundant setup.’” Its Business Help Center article gives you two ways to share:
- Different events from each source, for example AddToCart from the browser and Purchase from the server. No deduplication is needed.
- The same events from both, for example Purchase from both to recover events the browser loses. Deduplication is required, or Meta double counts.
Why bother with the server at all: the pixel relies on the browser, which settings, connectivity and ad blockers can interrupt, while the Conversions API sends from your server and is more resilient to them. In Events Manager, Meta says server events should match or exceed pixel events, and that advertisers “should aim for a 75% event coverage ratio of Conversions API to Meta pixel events” (View server event details).
Which system should own each event?
Use event_name + event_id as the join key for one logical occurrence. Meta’s recommended method discards a browser and server copy when both fields match within 48 hours, and prefers the browser copy when the two arrive within 5 minutes of each other (server event parameters).
| Key event | Collection method | Source of record | Consent gate | Dedup key | When to use |
|---|---|---|---|---|---|
| PageView | Browser | Page data layer; the pixel base code fires PageView on every load | Fire only when the recorded consent state permits this purpose | Browser-only occurrence ID; no server twin expected | Diagnose reachable pages and landing sessions |
| ViewContent | Browser, or combined when a backend view exists | Browser product-view payload; backend log only if it represents the same view | Apply the visitor’s stored consent state to both paths | Same ViewContent name and stable event ID on both paths |
Measure product-detail viewing without inventing a server view |
| AddToCart | Browser or combined | Cart service owns the accepted cart mutation; browser owns the click | Do not send either path outside the declared consent rule | Same AddToCart name plus cart-mutation ID |
Use combined only when both records refer to one accepted mutation |
| InitiateCheckout | Combined | Checkout service owns successful checkout creation | Carry the consent state attached to the session or order | Same name plus checkout ID | Recover a backend-confirmed checkout while keeping browser context |
| Purchase | Combined | Commerce ledger owns the authorized order; currency and value are required |
Suppress or minimise fields where consent does not permit advertising use | Same Purchase name plus the order number |
Send only the declared qualifying order transition; retries reuse the ID |
| Refund | Your ledger only | Commerce or refund ledger | Follow the recorded purpose and deletion policy | Your own refund ID | Meta has no standard refund event; keep the reversal in your ledger and never overwrite the purchase |
Two rows rest on Meta’s standard events reference: Purchase requires currency and value, and the list of 17 standard events has no refund or cancellation event. The pixel fires PageView automatically each time it loads (conversion tracking).
Recognized-order event coverage = (recognized orders joined to one valid logical Purchase occurrence) ÷ (recognized orders eligible for measurement). This is our working definition, measured against your order ledger; Meta’s own “event coverage” compares server events with unique pixel events. Source and window: commerce ledger and raw browser and server event log for the same order cohort. Limitation: coverage does not establish attribution or incrementality.
When should you not combine browser and server events?
Do not combine the two paths when consent differs between them, when the occurrences mean different things (a click is not an accepted cart mutation), or when you cannot issue one stable shared ID. Each of those produces either a double count or a silent gap.
Three requirements from Meta sit underneath the consent column:
- Consent where the law requires it. Meta’s Business Tools Terms (effective 3 November 2025) say that where informed consent is required for cookies or similar storage, the European Union among them, you must ensure “in a verifiable manner” that people consent before you use Meta Business Tools.
- Hashing. The JavaScript pixel hashes contact information before sending it; for other tools, including the Conversions API, you must hash it as Meta specifies. Email and phone must be hashed; IP address, user agent,
fbcandfbpmust not be (parameters). - Required fields. Website events sent through the Conversions API need
client_user_agent,action_sourceandevent_source_url.
Whether your consent wording is lawful where you sell is a question for your counsel, not for this table.
Can software help?
Bach.ai connects to your Meta ad account, audits it, and ranks the revenue leaks it finds by estimated dollar impact, each with a proposed fix. It applies a fix on Meta only after you approve it. The event contract above is still an engineering decision for your team.
For the account-wide checks around it, see the Meta ads audit checklist.
FAQ
Should the browser or the server be the source of record for each event?
Let the browser own what only the browser sees, such as a page view or a click, and let your commerce systems own accepted state changes, such as a placed order. When you send the same event from both, both copies must carry the same event_name and event_id so Meta can keep one.
When should you not combine a browser event with a server event?
When consent differs between the two paths, when the two records describe different moments, or when you cannot issue one stable ID for both. Combining in any of those cases either double counts the event or hides a gap, and Meta’s deduplication cannot repair either.
Do I need the Conversions API if I already have the pixel?
Meta recommends it: its guide calls the pixel plus the Conversions API a redundant setup and recommends it for optimal ad performance. The server path keeps sending when browsers or ad blockers interrupt the pixel. Meta’s target is a 75% coverage ratio of server events to pixel events.
Does Meta have a refund event?
No. Meta’s list of 17 standard events includes Purchase but no refund or cancellation event, so a standard setup never tells Meta about an order you refund later. Keep reversals in your own ledger, and reconcile reported purchases against net orders rather than overwriting the purchase.
Does higher event coverage prove attribution or incremental impact?
No. Coverage tells you how many recognized orders reached Meta as one valid Purchase. It cannot fill in missing source records, and it cannot turn platform credit into proof that the ads caused the sale. Incremental impact needs a test with a holdout group.
Sources: Meta, Handling Duplicate Pixel and Conversions API Events, Server Event Parameters, Conversions API parameters, Meta Pixel reference, Conversion tracking; Meta Business Help Center, About deduplication, View server event details; Meta Business Tools Terms (all checked 1 Oct 2026).