How does event_id deduplication work between pixel and CAPI?

When the browser pixel and CAPI send the same purchase, Meta receives two events. To count only one, both channels must send a STRICTLY identical event_id. Meta compares the event_name + event_id combination: if it receives two events with the same pair within a 48-hour window, it discards the duplicate. The value can be any unique string — a UUID or the order ID — but it must be generated once and read identically by both channels. The classic error is that the browser and the server each generate their own ID: even a different separator or case breaks the matching, and Meta double-counts everything. Best practice: generate the event_id once client-side, then pass it to the server.

What is Event Match Quality and how do I improve it?

Event Match Quality (EMQ) is a 0-to-10 score Meta assigns to each event, measuring its ability to link your events — especially those sent by CAPI — to real Meta user profiles. An EMQ above 7 markedly improves delivery, targeting, and campaign optimization; below 5, the algorithm works almost blind. To improve it, send as many hashed matching parameters as possible: email and phone first, then the fbp cookie (Meta browser identifier) and fbc (click identifier). These four parameters are usually enough to reach 7–8/10. Adding first name, last name, city, postal code, and IP address pushes the score toward 9+. The score is viewed and tracked in Events Manager.

How do I verify that my Meta Pixel and CAPI are working?

Verification is done in Meta Events Manager, via the Test Events tool. Enter your site URL, trigger a real test purchase, and watch: each key event must appear with TWO indicators for the same event_id, "Browser" (the pixel) and "Server" (CAPI). Seeing both confirms the dual send and deduplication work. If you only see "Browser," your CAPI sends nothing; if you only see "Server," your pixel is blocked. Next, check Event Match Quality (aim for above 7/10) and the deduplication rate in the dataset overview: 40 to 70% is healthy for a Purchase event. Allow 2 to 3 weeks for the scores to stabilize after a deployment.

Can I install CAPI without GTM Server-Side?

Yes, there are three methods. The first is native integration: Shopify, WooCommerce, and other platforms offer CAPI connectors in a few clicks — the simplest, but with limited control over matching parameters and deduplication. The second is the direct API, coded into your backend: full control, but requires a developer. The third, GTM Server-Side, is the reference when you manage several event sources or several destinations (Meta, GA4, TikTok): a server container centralizes all the logic. For a small site with a modest ad budget, a native integration or the direct pixel API is enough as a first step. Once the budget exceeds 5,000 MAD/month or the tag plan grows complex, GTM Server-Side becomes the most reliable and scalable option.

How much does a Meta Pixel + CAPI installation cost in Morocco?

At Webotic, the full setup — browser pixel installation, CAPI wiring, event_id deduplication configuration, and verification in Events Manager — is billed between 800 and 2,500 MAD as a one-off, depending on the complexity of the site and the existing tag plan. A site with a custom checkout and many events takes longer than a clean installation. On top of that, if you go through GTM Server-Side, add the server container hosting: 10 to 25 USD/month on Google Cloud Run for most Moroccan sites. The timeline is 2 to 3 business days. ROI is positive from 5,000 MAD/month of ad budget, because recovering 25 to 35% of lost conversions directly improves campaign optimization and lowers cost per acquisition.

Back to blog

/ 66 · meta-pixel-capi-setup-marocTrackingPublished on10 min

META PIXEL · CAPI · TRACKING · MOROCCO 2026

Install Meta Pixel + CAPI in Morocco: browser pixel vs server— the reliable setup guide

In 2026, a browser-only Meta Pixel loses 25 to 45% of conversions to iOS, Safari ITP, and ad blockers. The reliable solution combines the client-side pixel AND the server-side Conversions API (CAPI), deduplicated via an identical event_id, ideally through GTM Server-Side. Configured correctly, this dual send recovers +25 to +35% of conversions and pushes Event Match Quality above 7/10 — the threshold where Meta's bidding algorithm optimizes properly. This guide covers installation, deduplication, verification in Events Manager, and the errors that break tracking.

By Marouane MohachtouFounder & CEO

+25–35%conversions recoveredpixel + CAPI vs pixel only

7–9 / 10Event Match Qualitywith email, phone, fbp, fbc

40–70%deduplication ratehealthy for a Purchase event

2–3 daysfull setuppixel + CAPI + verification

Browser pixel vs CAPI: why you need both in 2026

Many Moroccan advertisers assume installing the Meta Pixel in the browser is enough. In 2026 that is wrong — and the mistake wastes real ad budget. The browser (client-side) pixel is a JavaScript snippet that loads in the visitor's browser and sends events to Meta. The problem: this script depends entirely on the client's device and browser. Safari ITP caps cookie lifespan at 7 days or even 24 hours, iOS 14+ requires ATT consent that most users decline, Firefox ETP blocks cross-site tracking, and ad blockers (uBlock Origin, AdGuard) intercept requests to facebook.com outright. Measured on Moroccan e-commerce sites: 25 to 45% of conversions never reach Meta. The Conversions API (CAPI) solves this by sending events from your server directly to Meta's servers via a server-to-server HTTPS request. No blockers, no browser cookie limits, no dependency on the client's device. The purchase event leaves your backend or your GTM Server-Side container, not the browser. But CAPI does NOT replace the pixel — the two work together. The pixel captures rich behavioral signals (journeys, microconversions, data for lookalike audiences) while CAPI guarantees that key conversions always arrive. The combination of both, correctly deduplicated, is the reference architecture in 2026.

Pixel alone = 25–45% of conversions lost to iOS ATT, Safari ITP and ad blockers
CAPI sends events server-to-server — immune to blockers and cookie limits
The pixel remains essential for microconversions and lookalike audiences
The reference 2026 architecture = browser pixel + CAPI, never one without the other

Installing the Meta Pixel: prerequisites and the basic steps

Before CAPI, you need a clean browser pixel. It is the foundation everything else rests on. Prerequisites: admin access to the Meta Business portfolio and Events Manager, a Google Tag Manager account with a web container, and a clear tag plan (which events, on which pages, with which parameters). Never skip this planning step: most tracking problems trace back to a vague tag plan from the outset. Step 1 — create the dataset (formerly pixel) in Events Manager and grab the 15–16 digit ID. Step 2 — install the base code. We recommend going through Google Tag Manager rather than hard-coding the snippet into the theme: a "Meta Pixel base" tag firing on all pages (All Pages trigger), initialized BEFORE any event tag. The classic error: a custom HTML tag that sends an event before the base pixel is initialized — the event is lost. Step 3 — map the standard events. Meta recognizes 17 standard events; the most useful for advertising are PageView, ViewContent, AddToCart, InitiateCheckout, AddPaymentInfo, Purchase, Lead and CompleteRegistration. Each event must fire at the right moment, via the dataLayer rather than via a fragile CSS click that breaks on the first theme redesign. Step 4 — enable advanced matching. Send hashed email and phone from the browser: this sets the stage for a good Event Match Quality once CAPI is wired in.

Go through GTM, not hard-coded snippets: the base tag must initialize before any event
Fire events via the dataLayer, not via CSS clicks that break on redesign
17 standard events exist; focus on the 8 that matter for advertising
Enable advanced matching (hashed email, phone) from pixel installation

Wiring CAPI through GTM Server-Side: the reliable architecture

There are three ways to implement CAPI: native integration (Shopify, WooCommerce via plugin), the direct API coded into the backend, and GTM Server-Side. For an advertiser managing several event sources who wants full control, GTM Server-Side is the reference. The principle: a GTM container runs on a server (Google Cloud Run or Stape), receives hits from the site, enriches them, then forwards them to Meta CAPI, GA4, and TikTok Events API from a single central point. This avoids multiplying integrations and centralizes the deduplication logic. Setup: your web container sends events to the server container (via the GA4 tag or a dedicated client). In the server container, a "Meta Conversions API" tag reads the event, rebuilds the payload, and sends it to Meta with the CAPI access token generated in Events Manager. That token is the server authentication key — it must never be exposed in the browser. Critical point: the matching parameters. CAPI can only match an event to a Meta profile if you supply identifiers. Send, as a priority, email and phone (hashed in SHA-256), plus the fbp cookie (Meta browser identifier) and fbc (ad click identifier). These four parameters are usually enough to reach an EMQ of 7 to 8. Adding first name, last name, city, postal code, and IP address pushes the score toward 9+. Deploying the server container takes 2 to 4 hours; the CAPI configuration and deduplication take the rest of the day.

GTM Server-Side centralizes CAPI, GA4 and TikTok from a single server container
The CAPI access token stays server-side — never expose it in the browser
email + phone (SHA-256) + fbp + fbc = the base for an Event Match Quality of 7–8/10
Add first name, last name, city, postal code, IP to push EMQ toward 9+

event_id deduplication: the step that breaks everything if done wrong

This is the most misunderstood and most frequently botched step. When the browser pixel AND CAPI send the same purchase, Meta receives two events. Without deduplication, your Purchase is counted twice — your ROAS becomes false and the algorithm optimizes on inflated data. The deduplication mechanism relies on a single parameter: the event_id. The pixel and CAPI must send a STRICTLY identical event_id for the same event. Meta compares the event_name + event_id combination: if it receives two events with the same pair within a 48-hour window, it keeps only one. The event_id value can be any unique string: a UUID, the order ID, or a concatenation of identifier + timestamp. What matters is that it is generated ONCE and read identically by both channels. The most common error: the browser generates one ID and the server generates another — even a different separator, a space, or a different case breaks the matching. Deduplication drops to zero and Meta double-counts everything. How to verify it is correct: a healthy dual-source setup shows a deduplication rate of 40 to 70% for the Purchase event — meaning roughly half the events received are identified as duplicates and discarded. A rate near 0% means the event_id is not matching. A rate near 100% is also abnormal. The rule: generate the event_id once, client-side, and pass it to the server.

STRICTLY identical event_id on pixel and CAPI — a space or different case breaks everything
Meta deduplicates on event_name + event_id within a 48-hour window
Healthy Purchase deduplication rate: 40–70%; near 0% = event_id not matching
Generate the event_id once client-side and pass it unchanged to the server

Verifying in Events Manager: Test Events, EMQ and coverage

Unverified tracking is broken tracking until proven otherwise. Verification in Meta Events Manager is non-negotiable and happens in three stages. First, the Test Events tool. In Events Manager > your dataset > Test Events, enter your site URL and trigger a real test purchase. You should see each event appear in real time with TWO indicators for the same event_id: "Browser" (the pixel) and "Server" (CAPI). Seeing both confirms the dual send works. If you only see "Browser," your CAPI sends nothing; if you only see "Server," your pixel is blocked. Second, Event Match Quality (EMQ). It is a 0-to-10 score Meta assigns to each event, measuring its ability to match your server events to user profiles. An EMQ above 7 markedly improves delivery and optimization. Below 5, the algorithm works blind. You raise the score by sending more matching parameters (email, phone, fbp, fbc, first name, last name). Third, coverage and deduplication. In the dataset overview, verify that each key event receives data from BOTH sources and that the deduplication rate is within the healthy 40–70% range. Allow 2 to 3 weeks for the EMQ to stabilize and campaign optimization to improve.

Test Events must show "Browser" AND "Server" for the same event_id
Aim for an Event Match Quality above 7/10; below 5, the algorithm is blind
Check dual-source coverage and deduplication rate in the dataset overview
Allow 2–3 weeks for EMQ to stabilize and optimization to improve

Common errors that sabotage a Meta Pixel + CAPI setup

Most broken tracking is not obviously broken — it half-works, which is more dangerous because nobody notices. Here are the errors we fix most often at Webotic. Purchase without value or currency. If the Purchase event fires without the value or currency parameter, Meta can only optimize on purchase count, not value — you lose all ROAS optimization. It is the most costly and most common error. Double counting from failed deduplication. Described above: a different event_id between pixel and server, or a plugin that sends the event on top of your setup. Result: inflated conversions, misleading ROAS. Events firing at the wrong time. AddToCart depending on a CSS class that disappeared in a theme redesign; Purchase waiting for a dataLayer event name changed during a checkout customization; a plugin duplicating PageView across the whole site. Missing matching parameters. Sending CAPI without email, phone, or fbp/fbc yields an EMQ of 2–3: the event technically goes through, but Meta can barely match it, so attribution is weak. Exposed or expired CAPI token. An access token badly stored in the browser is a security hole; a revoked token silently cuts off the server send. Monitor the logs. The Webotic rule: after every site, theme, or checkout change, we run the tracking back through Test Events. Tracking is re-verified, never assumed.

Purchase without value/currency = no ROAS optimization possible — the costliest error
Non-identical event_id or a duplicate plugin = double counting and false ROAS
Events tied to fragile CSS classes: they break on the first theme redesign
CAPI without email/phone/fbp/fbc = an EMQ of 2–3 and near-zero attribution

FAQ

Do I need to install CAPI in addition to the Meta Pixel?: Yes, in 2026 it is essential. The browser-only Meta Pixel loses 25 to 45% of conversions to iOS ATT, Safari ITP, Firefox ETP, and ad blockers that intercept requests to Meta. The Conversions API (CAPI) sends events from your server directly to Meta's servers, bypassing these blocks. But CAPI does not replace the pixel: the two work together. The pixel captures behavioral signals and data for lookalike audiences, while CAPI guarantees that key conversions always arrive. The correct architecture combines both, deduplicated by an identical event_id, for full coverage without double counting. At Webotic, we never deploy one without the other.
How does event_id deduplication work between pixel and CAPI?: When the browser pixel and CAPI send the same purchase, Meta receives two events. To count only one, both channels must send a STRICTLY identical event_id. Meta compares the event_name + event_id combination: if it receives two events with the same pair within a 48-hour window, it discards the duplicate. The value can be any unique string — a UUID or the order ID — but it must be generated once and read identically by both channels. The classic error is that the browser and the server each generate their own ID: even a different separator or case breaks the matching, and Meta double-counts everything. Best practice: generate the event_id once client-side, then pass it to the server.
What is Event Match Quality and how do I improve it?: Event Match Quality (EMQ) is a 0-to-10 score Meta assigns to each event, measuring its ability to link your events — especially those sent by CAPI — to real Meta user profiles. An EMQ above 7 markedly improves delivery, targeting, and campaign optimization; below 5, the algorithm works almost blind. To improve it, send as many hashed matching parameters as possible: email and phone first, then the fbp cookie (Meta browser identifier) and fbc (click identifier). These four parameters are usually enough to reach 7–8/10. Adding first name, last name, city, postal code, and IP address pushes the score toward 9+. The score is viewed and tracked in Events Manager.
How do I verify that my Meta Pixel and CAPI are working?: Verification is done in Meta Events Manager, via the Test Events tool. Enter your site URL, trigger a real test purchase, and watch: each key event must appear with TWO indicators for the same event_id, "Browser" (the pixel) and "Server" (CAPI). Seeing both confirms the dual send and deduplication work. If you only see "Browser," your CAPI sends nothing; if you only see "Server," your pixel is blocked. Next, check Event Match Quality (aim for above 7/10) and the deduplication rate in the dataset overview: 40 to 70% is healthy for a Purchase event. Allow 2 to 3 weeks for the scores to stabilize after a deployment.
Can I install CAPI without GTM Server-Side?: Yes, there are three methods. The first is native integration: Shopify, WooCommerce, and other platforms offer CAPI connectors in a few clicks — the simplest, but with limited control over matching parameters and deduplication. The second is the direct API, coded into your backend: full control, but requires a developer. The third, GTM Server-Side, is the reference when you manage several event sources or several destinations (Meta, GA4, TikTok): a server container centralizes all the logic. For a small site with a modest ad budget, a native integration or the direct pixel API is enough as a first step. Once the budget exceeds 5,000 MAD/month or the tag plan grows complex, GTM Server-Side becomes the most reliable and scalable option.
How much does a Meta Pixel + CAPI installation cost in Morocco?: At Webotic, the full setup — browser pixel installation, CAPI wiring, event_id deduplication configuration, and verification in Events Manager — is billed between 800 and 2,500 MAD as a one-off, depending on the complexity of the site and the existing tag plan. A site with a custom checkout and many events takes longer than a clean installation. On top of that, if you go through GTM Server-Side, add the server container hosting: 10 to 25 USD/month on Google Cloud Run for most Moroccan sites. The timeline is 2 to 3 business days. ROI is positive from 5,000 MAD/month of ad budget, because recovering 25 to 35% of lost conversions directly improves campaign optimization and lowers cost per acquisition.