Book Appointment

Meta event tracking & deduplication

Meta’s event tracking ecosystem helps measure, optimize, and understand actions on websites and apps. This page explains how KMA PolyClinic uses the Meta Pixel (browser) and the Conversions API (server) together — and how event deduplication keeps reporting accurate.

Event setup: guided journey

Meta documents a typical path for website measurement: understand standard and custom events, implement Pixel and/or Conversions API, configure deduplication when both fire the same event, then monitor quality in Meta Events Manager.

  • About standard and custom website events — which actions you can measure
  • About deduplication for Meta Pixel and Conversions API — this topic
  • About Meta Events Manager — testing, debugging, and quality

Why deduplication matters

Deduplication ensures that the same real-world action, when sent from both the browser Pixel and the server Conversions API, is counted only once. That accuracy supports conversion rate, return on ad spend (ROAS), and attribution.

Without deduplication, conversion numbers can look artificially high, which misleads optimization and budget decisions.

Meta Pixel vs Conversions API

Meta Pixel is a browser-based tool that tracks actions on the website (for example page views, content views, or form submissions).

The Conversions API is a server-side method that sends web events from your server to Meta, improving reliability and completeness when browsers block or drop Pixel data.

  • Pixel depends on the browser and can be limited by settings, connectivity, or blockers.
  • Conversions API sends from the server and is more resilient to those browser limits.

When to deduplicate

Deduplication is required when the same event (for example Purchase or Schedule) is shared from both browser and server so lost browser events can be recovered without double counting.

Deduplication is not required when you intentionally send different events from each source (for example AddToCart only in the browser and Purchase only on the server).

Deduplication conditions and logic

For Meta to deduplicate matching browser and server events, these conditions apply:

  • event_name must match (e.g. ViewContent, Schedule).
  • event_id must be identical on Pixel and Conversions API for that action.
  • Alternatively, matching can use event_name with external_id or fbp when applicable.
  • If similar server and Pixel events arrive, Meta prefers the event received first.
  • Deduplication also applies to redundant Pixel-only or server-only duplicates with the same identifiers.

Event sharing strategies

Option 1 — Different events from browser and server: no deduplication needed.

Option 2 — Same events from browser and server (recommended for recovery of blocked Pixel hits): implement deduplication with shared event_name and event_id.

Decision: if you send the same event from both sources, implement deduplication; otherwise it is not required.

Technical setup parameters

Add event_name for every event instance. Add a unique event_id per real user action and pass the same value to Pixel and Conversions API. Optionally include external_id and fbp for additional matching.

Website Conversions API events also require action_source (website), event_source_url, and client_user_agent for quality. Customer information such as hashed email and phone can improve Event Match Quality when lawfully available.

Monitoring in Meta Events Manager

Events Manager shows received events, sources (browser vs server), and deduplication status. Use Test Events to verify which events are received, deduplicated, or dropped.

Common issues include mismatched or missing event_id, delays between browser and server delivery, and incorrect parameter names or values. Pixel Helper and Events Manager tools help diagnose firing and parameters.

Summary checklist

  1. Decide strategy: different events vs same events from Pixel and CAPI
  2. Add event_name and event_id to all dual-sent events
  3. Add external_id and/or fbp when available
  4. Implement via partner integration or manual code
  5. Test with Meta Events Manager Test Events
  6. Monitor deduplication and troubleshoot regularly

How KMA PolyClinic implements this

We use Option 2 for key website actions: the same standard event is sent from the Meta Pixel and the Conversions API with a shared event_id so Meta can deduplicate and keep reporting accurate.

Customer information used for match quality (for example email or phone after an appointment request) is hashed on the server where required by Meta. Facebook Login ID is sent unhashed only when available.

  • PageView — browser Pixel + server CAPI with the same event_id
  • ViewContent — service and department pages (Pixel + CAPI, shared event_id)
  • Schedule / Lead — appointment form (Pixel + server CAPI; Schedule uses the form event_id on both sides)
  • Contact / FindLocation — phone, email, and map interactions when tracked
  • Meta Parameter Builder (client JS + Node) manages fbc/fbp cookies, client IP, and single-pass PII normalize+hash for EMQ
  • fbp / fbc cookies and optional external_id support additional matching
WhatsApp