Meta Pixel and CAPI: Event Collection Architecture

For the surrounding account decisions, compare Meta Pixel and CAPI: Event Deduplication Diagnostic and use Ecommerce Meta Pixel and CAPI: Implementation Checklist as the next diagnostic.

In short

This guide owns one decision artifact: the filled, auditable structure below. Reader-supplied thresholds stay explicit; missing evidence stays missing.

Browser, server, and combined source-of-record decision table

Use event_name + event_id below as the operator’s join contract for one logical occurrence. Meta describes matching browser and server events for deduplication in its current Conversions API documentation; accessed 2026-08-27, re-check before implementation.

Key event	Collection method	Source of record	Consent gate	Dedup key	When to use
PageView	Browser	Page data layer after the page renders	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 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/order	Same name plus checkout ID	Recover a backend-confirmed checkout while retaining browser context
Purchase	Combined	Commerce ledger owns authorized/recognized order state	Suppress or minimize fields where consent does not permit advertising use	Same Purchase name plus immutable order-event ID	Send only the declared qualifying order transition; retries reuse the ID
Refund	Server	Commerce/refund ledger	Follow the recorded purpose and deletion policy	Refund plus immutable refund-event ID	Represent the reversal separately; never overwrite the purchase occurrence

Recognized-order event coverage = (recognized orders joined to one valid logical Purchase occurrence) ÷ (recognized orders eligible for measurement). Source/window: commerce ledger and raw browser/server event log for the same order cohort. Limitation: coverage does not establish attribution or incrementality.

Interpretation boundary

Use the browser/server source-of-record contract only for its stated decision. Let the browser own observed interactions and the commerce service own accepted state transitions; combined twins reuse event_name plus event_id. Do not combine paths when consent differs, occurrence semantics conflict, or a stable shared event ID cannot be issued. Reader-supplied thresholds remain inputs, not universal standards.

Where implementation depends on Meta behavior, re-check Meta’s current Business Tools Terms and linked product documentation before release; accessed 2026-08-27. The tables below are operator contracts unless a primary Meta source is linked.

Can software help?

Bach.ai audits your connected Meta account against 100+ checks, ranks what it finds by estimated impact, and proposes specific fixes. It stays read-only until you approve a change, then executes the approved change on Meta; connected Google Ads data is used for intelligence only. Think of it as an automated audit layer that surfaces issues and proposed fixes for your review — not a replacement for your team’s judgment, and it does not generate your creative.

FAQ

Should the browser or the server be the source of record for each event?

Let the browser own observed interactions and the commerce service own accepted state transitions; combined twins reuse event_name plus event_id.

When should you not combine a browser event with a server event?

Do not combine paths when consent differs, occurrence semantics conflict, or a stable shared event ID cannot be issued.

Does higher event coverage prove attribution or incremental impact?

It supports the bounded operating choice encoded by the browser/server source-of-record contract. It cannot replace missing source records or turn platform credit and observed association into incremental impact.