Meta CAPI Deduplication: Event ID Guide for Clinics

Meta deduplicates conversions by matching the event_id and event_name pair sent from the browser against the same pair sent server-side through the Conversions API, discarding the duplicate when both arrive within roughly 48 hours. For healthcare clinics the practical answer is simpler still: if you have removed the Meta Pixel for compliance reasons and send only server-side events, there is nothing to deduplicate, and the whole problem disappears. Curve is the HIPAA-compliant tracking platform that runs this server-side-only path for healthcare advertisers, generating stable event IDs, forwarding clean conversions to Meta CAPI, and including a signed Business Associate Agreement on every plan.

What deduplication actually is

Meta accepts the same conversion from two places. The browser pixel fires when a page loads or a button is clicked. The Conversions API sends the same event from a server. Sending both is a deliberate design: the browser event is fast and rich in context, the server event survives ad blockers and browser tracking prevention, and together they produce better coverage than either alone.

The cost is double counting. If Meta credited both, every conversion would appear twice, cost per acquisition would look half what it is, and the optimization algorithm would learn from inflated signal. Deduplication is the mechanism that prevents this.

Meta matches on two keys together:

• event_name must be identical in both payloads. Lead from the browser does not deduplicate against lead or Lead_Form from the server.
• event_id must be identical in both payloads. This is a value you generate, not one Meta issues.

When both match and both arrive inside the deduplication window, Meta keeps one and drops the other. It generally prefers whichever arrived first, so the practical effect is that the faster path wins and the slower one is discarded.

There is a secondary mechanism using fbp and fbc. The fbp cookie is a browser identifier Meta sets. The fbc value is derived from the fbclid click parameter. If event_id is absent, Meta may attempt to deduplicate on these plus the event name and timestamp, but this is a fallback and it is unreliable. Do not design around it.

Why this matters more in healthcare

Most advertisers treat deduplication as a hygiene detail. For clinics it interacts with a compliance decision, and that changes the shape of the problem.

The reason healthcare advertisers move to server-side tracking is that browser pixels send data directly from the patient's device to Meta, carrying the page URL, referrer, and a persistent identifier. On a clinic site the page URL routinely names a condition or treatment. Meta does not sign BAAs for its advertising products, so those calls are disclosures to a vendor with no BAA in place. That is the mechanism underneath the healthcare pixel litigation that has now produced more than $100 million in settlements.

Which leads to the fork. A general ecommerce advertiser runs pixel and CAPI together and needs deduplication working perfectly. A clinic that has removed the pixel for compliance runs CAPI alone and does not need deduplication at all.

Most clinics should be in the second group. If you are running both because someone told you redundancy improves match quality, you are accepting the compliance exposure the migration was meant to remove. Redundancy is not worth it when one of the two paths is the liability.

The event ID rules that actually break things

If you are running a dual setup, or a hybrid where some events are server-side and some are not, these are the rules that matter.

The ID must be identical, not merely similar

Both payloads must carry the same string. Generating a UUID in the browser and a different UUID on the server produces two events that will never deduplicate, no matter how correct everything else is. The value has to be generated once and passed to both paths.

The ID must be stable across a page reload

A conversion event fired on a thank-you page will fire again if the patient refreshes or navigates back. If the ID is regenerated each time, each refresh becomes a new conversion. Derive the ID from something durable, such as a booking reference or an order ID, rather than from a random value created at page load.

The ID must not contain patient information

This is the healthcare-specific trap. Teams reach for something convenient and unique, and patient email or a medical record number are both convenient and unique. Neither belongs in an event ID. The ID travels to Meta in plain text and appears in the Events Manager. Use an opaque reference with no meaning outside your systems.

The window is about 48 hours

Meta's deduplication window is roughly 48 hours from the first event. Offline conversions uploaded days later will not deduplicate against a browser event from the original session. If you upload booked appointments from your CRM a week after the enquiry, those are separate conversions by design and should use a separate, distinctly named event.

Event names must match exactly

Case-sensitive, character for character. A surprising share of deduplication failures are a capitalization difference between what the browser sends and what a server integration was configured to send.

The hybrid case, and why it is the worst of both

A common intermediate state deserves naming, because a lot of clinics are sitting in it without having chosen it. Someone removes the pixel from the obvious conversion pages, leaves it on the rest of the site, and adds CAPI for the conversions. The result is a partial pixel and a full server-side feed.

This is worse than either clean option. The compliance exposure remains, because the pixel is still firing on treatment pages and those page URLs are the disclosure, whether or not a conversion happens there. Meanwhile deduplication becomes unpredictable, because some events exist on both paths and some on only one, so Events Manager shows a mixture that is difficult to reason about.

If you find yourself here, the fix is to finish the migration rather than to tune the deduplication. Every page a patient can reach is part of the disclosure question, not just the pages where conversions fire.

How to tell whether deduplication is working

Meta Events Manager reports this directly, and it is worth checking rather than assuming.

1. Open Events Manager and select your dataset.
2. Look at an event in the overview. Meta labels events received from multiple sources and shows a deduplication figure.
3. Check the Diagnostics tab, which raises specific warnings for missing event IDs and mismatched names.
4. Compare received event volume against your own record of conversions. Roughly double is the signature of failed deduplication.

The number to distrust is a conversion count that looks unusually good. Deduplication failures inflate performance, so they tend not to get investigated. A clinic reporting a cost per lead that halved after a CAPI migration usually has a deduplication problem rather than a marketing win.

The Curve approach: remove the ambiguity

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, and it takes the position that clinics should not be running browser pixels at all.

The Curve script installs in place of the Meta Pixel. Events go to Curve's US-hosted servers rather than to Meta directly. Curve then forwards clean conversions server-side through Meta CAPI. Because there is one path rather than two, deduplication stops being something you configure and monitor.

What Curve controls on that path:

• Field mapping per destination. Only explicitly mapped fields forward to Meta. Page URLs, referrers, and form content stay behind by default, which is where the condition disclosure would otherwise sit.
• Hashed identifiers. Email, phone, and name are SHA-256 hashed to Meta's CAPI requirements before forwarding.
• Neutral event aliases. The event Meta receives can carry a neutral name rather than one that identifies the service line, so the condition never appears in the Events Manager interface.
• Click ID capture and bridge tokens. The fbclid is captured at landing and preserved, including across a jump to a separate booking or intake tool where attribution normally breaks.
• PHI-pattern detection. Payloads are inspected for PHI-shaped values such as SSNs, MRN-style identifiers, and long numeric sequences, and flagged. This is monitoring rather than the protection itself; the protection is the field mapping.

Curve also supports offline conversion uploads with click ID matching, so appointments that convert in your CRM weeks later can reach Meta as their own event without colliding with the original enquiry. A signed BAA is included on every plan.

For the wider architecture, see our technical overview of conversion API architecture for HIPAA compliance and our guide to Meta Conversions API server-side implementation for healthcare.

Frequently asked questions

Do I need event IDs if I only send server-side events?

Not for deduplication against a browser pixel, because there is no browser pixel. Keep sending a stable event ID anyway. It protects against duplicate server sends caused by retries, and it makes debugging far easier when you need to trace a specific conversion.

Is running pixel plus CAPI better for match quality?

For general advertisers, often yes. For clinics it reintroduces exactly the disclosure that server-side tracking was adopted to eliminate. The marginal match-quality gain is not a good trade against the compliance exposure, and server-side delivery with good identifier hashing usually matches well on its own.

What should I use as an event ID?

An opaque reference that is stable for the conversion and meaningless outside your systems. A booking reference, an internal lead ID, or a hash of an order number all work. Never patient email, phone, name, or a medical record number.

Why do my Meta conversions exceed my actual bookings?

Most commonly failed deduplication from mismatched event names or missing IDs. Next most common is a conversion event firing on a page that can be reloaded or revisited. Check Events Manager diagnostics first, then check whether the event fires on page load rather than on a genuine submission.

Does deduplication work across ad accounts?

Deduplication happens at the dataset level, so events must go to the same dataset. Multi-location clinics sending to separate datasets per location will not deduplicate across them, which is usually the intended behavior.

How long until CAPI events appear?

Usually within minutes, though attribution and reporting can take longer to settle. Do not judge deduplication from the first hour of data.

Can I send appointment outcomes as a separate event?

Yes, and you should. A booked or attended appointment is a different and more valuable conversion than an enquiry. Give it a distinct neutral event name and its own event ID so it never deduplicates against the original lead.

What to do next

If you are a clinic running both a Meta Pixel and CAPI, the deduplication question is a symptom. The underlying issue is that the browser pixel is still sending condition-bearing page data to a platform with no BAA. Removing it solves the compliance problem and the deduplication problem in one move.

Curve is built for that single-path setup: server-side collection, per-destination field mapping, hashed identifiers, neutral event aliases, and bridge-token attribution, with a signed BAA on every plan. Run our free compliance scanner to see what your site is currently sending Meta, or visit curvecompliance.com to review your event setup with us.

Reviewed August 2026. Meta's Conversions API specification and deduplication behavior change periodically. Verify against current Meta developer documentation before implementation.