Why the Pixel alone undercounts
The Meta Pixel is a script in the visitor's browser. When it loads and fires, Meta learns that someone viewed a page, submitted a form or paid. When it doesn't, because of an ad blocker, a browser's tracking protection, a slow mobile connection or a cookie banner the visitor ignored, the event never arrives. Meta's delivery system then optimises your campaign on the leads it can see, not the ones you got.
The Conversions API sends the same events from your server, where the browser can't block them. Meta's own guidance is to run both: "we recommend that advertisers implement the Conversions API alongside their Meta Pixel".
Pick your setup route
| Your website | Route | Effort | Notes |
|---|---|---|---|
| Shopify | Meta's sales channel app, data sharing set to maximum | 1 hour | Purchases flow automatically |
| WordPress / WooCommerce | Meta's official plugin, or server-side Google Tag Manager | 2–4 hours | Watch for a second pixel plugin firing the same events |
| Wix, Squarespace | Built-in Meta integration in the platform's marketing settings | 1 hour | Limited control over custom events |
| Custom site or landing pages | Direct API calls from your backend, with Meta's Parameter Builder Library | 1–3 days of developer time | Full control; needed for CRM events like "qualified lead" |
| Leads close offline or in WhatsApp | Website API plus CRM events, or Business Messaging API for WhatsApp | Varies | Lets Meta optimise on sales, not form fills |
The effort column is our estimate for a typical small-business site, not a Meta figure.
How deduplication works
When the Pixel and the server both report the same lead, Meta must count it once. It does that by matching event_name and event_id: the browser event and the server event must carry the same name and the same ID, and the second one must arrive within 48 hours of the first.
In practice: when the form is submitted, generate one ID (an order number or a random string), pass it to the Pixel as eventID, and send the same value as event_id from the server. Name the event identically on both sides: Lead and lead are two different events.
What to send with each event
Meta matches server events to people through customer information. Its parameter reference splits them in two:
| Hash with SHA-256 before sending | Send as is |
|---|---|
| Email (em), phone (ph), first and last name, city, country, date of birth | IP address, browser user agent, fbp cookie, fbc click ID |
Meta's best practices make event_source_url and client_user_agent required for website events and ask for external_id and event_id on all events. Normalise and hash once, either in the browser or on the server, never both.
The UAE phone number, worked:
| Customer typed | Normalised | Then |
|---|---|---|
| 050 123 4567 | 971501234567 | SHA-256 hash |
| +971 (50) 123-4567 | 971501234567 | SHA-256 hash |
| 00971501234567 | 971501234567 | SHA-256 hash |
Meta's rule is to remove symbols, letters and leading zeros and always include the country code. Forms in Dubai collect numbers in every one of these formats, so normalise in code, not by hand. Country goes in as ae, also hashed.
Eight checks in Events Manager
- Test Events tab: submit a test lead; you should see one browser and one server event.
- Deduplication: the event's overview shows events as "deduplicated", not doubled.
- Event names match exactly between Pixel and server.
- Event Match Quality: Meta scores matching from 1 to 10 for web events. Note the score, add email and phone, compare.
- Value and currency on purchases: AED, a number, not "AED 250".
- No test code left on the live site after testing.
- One pixel per site. Old agency pixels and plugin pixels double-fire.
- Consent: events stop for visitors who refused marketing cookies.
What nobody tells you
Unmatched events are wasted for optimisation. Meta says only matched events can be used for attribution and delivery optimisation. A server event with no email, phone or browser IDs gets counted but can't teach the algorithm anything.
A form fill is not a customer. If you optimise for Lead, Meta finds people who fill in forms. In Dubai, where many form leads never answer the phone, sending a later QualifiedLead or Purchase event from your CRM is what moves cost per sale. Our guide on tracking WhatsApp leads to the CRM covers the WhatsApp side.
Consent applies to the server too. Moving tracking to the server doesn't remove the PDPL duties to inform and get consent. Send server events only for visitors who accepted; see our guide to cookies and consent on UAE websites.
Vladimir Chernyshev, GM: we don't start a Meta campaign until the test lead shows up twice in Events Manager, once from the browser and once from the server, and is counted once. Half a day of setup decides whether the next six months of budget teaches the algorithm or confuses it. What ads cost once the tracking works is in our guide to Meta ad prices in the UAE.
