Facebook Ads Pixel & Tracking

What the Pixel does

The Meta Pixel is a snippet of JavaScript placed on every page of a website that fires browser-side events back to Meta — page views by default, plus standard events you implement explicitly (Purchase, AddToCart, Lead, CompleteRegistration, ViewContent). Meta uses this event stream for two purposes at once: attribution (crediting an ad with the conversion it drove, so campaign-level ROAS reporting works) and optimization (the ad algorithm learns which users are likely to convert based on Pixel signal, then biases delivery toward similar users). Without Pixel data, Meta's delivery algorithm is optimizing blind — it can spend budget, but it has no feedback loop telling it whether that spend produced real business outcomes.

pixel_base_code.js

javascript

<!-- Meta Pixel Base Code -->
<script>
!function(f,b,e,v,n,t,s){...}(window, document,'script',
'https://connect.facebook.net/en_US/fbevents.js');
fbq('init', '1234567890123456');
fbq('track', 'PageView');
</script>

<!-- Standard event: Purchase -->
<script>
fbq('track', 'Purchase', {
  value: 149.50,
  currency: 'USD',
  content_ids: ['SKU_001'],
  content_type: 'product',
  eventID: 'order_98765'   // <-- required for CAPI deduplication
});
</script>

Conversions API: augmenting the Pixel, not replacing it

The Conversions API (CAPI) sends the same event types the Pixel sends, but from your own server directly to Meta, bypassing the browser entirely. This is a common point of confusion: CAPI does not replace the Pixel — the documented, recommended setup runs both simultaneously, sending the same real-world event (e.g. one purchase) from two paths: the browser-side Pixel call and a server-side CAPI call, tagged with the same eventID so Meta's deduplication logic merges them into a single counted event instead of double-counting.

The reason both matter together: the Pixel captures rich browser-side context (device, browser fingerprint signals, on-page behavior) that a server often doesn't have, while CAPI captures events the Pixel structurally cannot see — ad blockers stripping the Pixel script, Safari's Intelligent Tracking Prevention truncating cookie lifespan, or purchases completed after a payment redirect where the confirmation page never loads the Pixel reliably. Running both maximizes match rate and event completeness; running CAPI alone forfeits the Pixel's richer browser signal, and running the Pixel alone forfeits everything CAPI recovers.

capi_event_payload.json

json

POST https://graph.facebook.com/v19.0/{pixel-id}/events

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1758556800,
    "event_id": "order_98765",
    "action_source": "website",
    "user_data": {
      "em": ["<sha256-hashed-email>"],
      "client_ip_address": "203.0.113.4",
      "client_user_agent": "Mozilla/5.0...",
      "fbc": "fb.1.1758550000.AbCdEf",
      "fbp": "fb.1.1758400000.123456789"
    },
    "custom_data": {
      "value": 149.50,
      "currency": "USD",
      "content_ids": ["SKU_001"]
    }
  }]
}

Deduplication runs on event_id, not on the event happening twice

Meta doesn't guess which browser-side and server-side events describe the same real-world action — it matches them purely on a shared event_id (or event_name + matching user data as a fallback) sent by both the Pixel and CAPI calls. If your server-side event fires with a different ID than the client-side one for the same order, Meta counts it as two separate conversions, inflating reported conversions and understating true cost-per-result.

Pixel vs Conversions API

Aspect	Meta Pixel (browser-side)	Conversions API (server-side)
Execution point	Visitor's browser via JavaScript	Your own server, direct API call to Meta
Vulnerable to	Ad blockers, ITP/ETP cookie restrictions, JS load failures	Nothing browser-side — but depends on your server capturing the event reliably
Data richness	Rich browser/device context	Whatever your server knows (often less device context)
Recommended setup	Run alongside CAPI, not standalone	Run alongside Pixel, deduplicated via shared event_id
Typical impact of running both	Combined match rate materially higher than either alone	Same

iOS 14.5 and Aggregated Event Measurement

Apple's iOS 14.5 update (April 2021) introduced App Tracking Transparency (ATT), requiring apps to show an explicit opt-in prompt before accessing the IDFA (the device identifier ads had relied on for cross-app tracking and attribution). Adoption of that prompt has been low industry-wide, and the practical effect was a documented, substantial degradation in Meta's ability to track and attribute conversions from iOS users — Meta itself has publicly acknowledged this materially reduced measurable conversion volume and forced changes to how it models attribution and delivery for iOS audiences specifically.

Meta's response was Aggregated Event Measurement (AEM), a protocol built on Apple's SKAdNetwork/privacy constraints that lets advertisers still measure a limited, prioritized set of web conversion events from iOS users in aggregate, privacy-safe form — capped at 8 prioritized events per domain, reported with delay and statistical noise rather than the real-time, user-level granularity the Pixel/CAPI combination gives for non-restricted traffic. Domain verification in Meta Business Manager is a prerequisite for configuring AEM's event priority list at all.

Post-iOS 14.5 reported numbers are structurally undercounted

Since ATT reduced Meta's visibility into iOS conversions, Meta Ads Manager's reported conversion numbers for campaigns reaching significant iOS audiences are understood industry-wide to undercount true conversions to some degree — this is a direct, documented consequence of AEM's modeled/aggregated reporting, not a bug. Cross-check Ads Manager numbers against your own first-party GA4 or warehouse data rather than treating the platform's self-reported number as ground truth.

What's next

The same deduplication and server-side pattern used for Meta CAPI applies broadly to server-side tagging architecture — understanding the full server-side GTM setup shows how this pattern generalizes across multiple ad platforms at once, not just Meta.

Next: Server-Side GTM →