← Back to blog

Advertisers: 5 Steps to Stop Double-Counting with CAPI and Pixel via Event ID

October 5, 2026
Advertisers: 5 Steps to Stop Double-Counting with CAPI and Pixel via Event ID

Run both: Pixel plus Conversions API with a shared event ID is the default setup for most advertisers who want reliable Facebook measurement. The combination gives you redundancy against browser blockers and cookie restrictions that no single method covers alone. Before you change anything, confirm your Pixel is firing and check Test Events in Ads Manager to see what is actually arriving today.


TL;DR:

  • Proper implementation requires generating a unique event ID at the moment of action and matching it exactly in both Pixel and server calls with the same event name and Pixel ID.
  • Converting timestamps from milliseconds to seconds is essential; using JavaScript’s Date.now() directly causes silent failures.
  • Use platform connectors or server-side options based on engineering resources, and compare browser and server event counts in Test Events to detect mismatches.
  • Keep personal data minimal, hashing email and phone fields with lowercase and trimming, and obtain explicit user consent before server data transmission.
  • A combined Pixel and Conversions API setup offers the most reliable measurement for ecommerce and high-value campaigns, provided deduplication is correctly configured from the start.

Ahana
Make Your Marketing More Measurable
Ahana combines talent representation, digital production, and verified reporting to help brands turn cultural attention into commercial results.
Visit Ahana Digital

Table of Contents

Why run both and the deduplication rule every team must follow

Running Pixel and CAPI together only works if Meta can tell when both methods reported the same action. Meta's deduplication depends on matching event ID plus event name on the same Pixel ID within the dedup window; get any one of those three wrong and you end up counting the same purchase twice.

Here is the checklist to follow:

  1. Generate one event ID per action, at the moment it happens, such as when an order is created.
  2. Pass that same ID to the browser Pixel call as eventID and to the server call as event_id.
  3. Use the identical event_name string on both the client and server events.
  4. Confirm both events reference the same Pixel ID; a mismatch breaks deduplication even with a matching event ID.
  5. Forward fbp and fbc cookie values from the browser to the server so Meta can match the user, not just the event.

The most common pitfall is a timestamp format error: JavaScript's Date.now() returns milliseconds, a 13-digit number, while Meta's server event expects Unix seconds, 10 digits. Convert with Math.floor(Date.now()/1000) before sending, or your batches will fail silently.

Pro Tip: Check Test Events in Ads Manager and confirm the "Deduplicated" tag appears on paired events before you trust any reporting number.

A server response of "200 OK" only confirms Meta accepted the request, not that deduplication worked. Validate the actual matching keys in Events Manager, not just the HTTP status.

Two event paths merging through deduplication

Practical integration options and a testing checklist

Your implementation path depends on how much engineering support you have. Lighter setups work for smaller teams; server-side control suits anyone running meaningful ad spend.

  1. Platform connectors: Shopify, WooCommerce, and similar platforms often ship built-in or plugin-based CAPI integrations that need configuration, not custom code.
  2. Server-side GTM: a middle ground that lets marketers manage tags through a familiar interface while events route through a server container.
  3. Custom endpoint: a direct integration using Meta's SDKs for your backend language, giving full control over what gets hashed and forwarded.
  4. Browser-to-server handoff: capture fbp, fbc, client IP, and user agent in the browser session and pass them to whichever server method you choose.
  5. Hashing routine: normalize email and phone fields with lowercase, trim whitespace, then apply SHA-256 before the value ever leaves your server.

Once live, compare browser-reported and server-reported rows side by side in Test Events for a few days. Set up an alert for any sustained gap between the two counts, since a growing mismatch usually means a broken dedup key or a dropped field somewhere in the pipeline.

Sending server-side data does not mean sending everything you have. Keep personal fields to the minimum Meta's matching actually uses, and apply the same rule every time: lowercase, trim, then SHA-256.

  • Hash email and phone fields before transmission; never send raw PII to any endpoint.
  • Gate events on consent status: block Pixel firing and send only minimal server signals where local rules require explicit opt-in.
  • Log what you send and for how long, and review that retention schedule on a set cadence.
  • Share a short checklist with legal or privacy teams covering which fields you collect, how they are hashed, and where consent is checked before a server event fires.

Decision guide: when to pick Pixel-only, CAPI-only, or combined

Match the setup to your resources and the stakes of the campaign, not to whichever option sounds more advanced.

  • Pixel-only: fits teams without engineering support who need fast retargeting and basic measurement up and running quickly.
  • CAPI-only: reserved for specialized server-driven flows, like backend-only transactions, where no browser signal exists to forward.
  • Combined setup: the default for ecommerce and high-value campaigns, provided deduplication is configured correctly from day one.
  • Concrete picks: ecommerce and lead gen both benefit from the combined approach given conversion value; publishers with simpler, lower-value events can often stay Pixel-only.

Agency perspective: how teams operationalize Pixel and CAPI

We favor redundant Pixel and CAPI setups with dedup validation built in from the start, followed by a stabilization period before trusting the reporting numbers. A typical engagement runs through audit, configuration, testing, and ongoing monitoring, and we judge success by match rates, deduplication rates, and whether conversion counts hold steady once both pipes are live.

— Zongamele

How we help with Pixel and CAPI implementation

We run measurement audits, build server-side implementations, and deliver reporting so your conversion data reflects what actually happened, not what survived a browser blocker. You get an implementation plan, deduplication testing, and ongoing monitoring once both pipes are live.

Ahana

You getWhat it covers
Measurement auditReview of current Pixel and server-side setup
Implementation planEvent ID strategy and server configuration
Dedup testingValidation across Test Events and Events Manager
Ongoing monitoringAlerts for mismatches between browser and server events

Reach out through our Meta ads service page to get your tracking audited before your next campaign launch.

FAQ

What is the purpose of CAPI?

Conversions API sends conversion events from your server directly to Meta, bypassing the browser entirely. Its purpose is to recover events that ad blockers, cookie restrictions, or browser privacy settings would otherwise prevent the Pixel from reporting.

Is the Facebook Pixel still used?

Yes, the Pixel remains in active use and still provides real-time browser-level signals that a server alone cannot capture, such as exact page URLs and client-side click data. Most advertisers run Pixel alongside CAPI rather than replacing one with the other.

Is Conversions API worth it?

For most advertisers running meaningful ad spend, yes. CAPI improves attribution accuracy and recovers conversions lost to browser blockers, though it requires server-side engineering to set up properly and needs correct deduplication to avoid double-counting.

How much are Facebook ads per 1000 views?

Facebook ad costs vary widely by industry, audience, and region, and no single figure applies across campaigns. Checking current benchmarks inside your own Ads Manager account for your specific targeting gives a more accurate read than any general estimate.

Sources

Primary sources and implementation references

The deduplication guidance and timestamp pitfalls referenced above come from practitioner documentation on event ID matching, and the Pixel versus CAPI trade-offs draw from implementation comparisons covering attribution accuracy and setup complexity. Both sources are linked in the sections where their findings apply.

Written with BabyLoveGrowth's content platform