Home / Blog / Elevar Purchase Events Duplicated in Meta
Elevar · Meta CAPI · Deduplication
Elevar Purchase Events Duplicated in Meta: What to Check
If Meta shows more purchases than Shopify after Elevar is installed, don’t assume Meta is simply “over-attributing.” You may have duplicate Purchase events, broken Pixel/CAPI deduplication, or two tracking tools sending separate purchase streams into the same Pixel.
The fix is not to randomly add an event_id. First, find every Purchase event source. Then confirm the browser Pixel event and server-side CAPI event are actually describing the same Shopify order.
eventID and server-side CAPI event_id do not match. Meta deduplicates overlapping Pixel and CAPI events only when the event IDs and event names line up. The fix is to identify every Purchase source, confirm the IDs match, remove conflicting tags/apps, and validate the result against Shopify order IDs.Key takeaways
- Meta deduplication depends on matching Pixel
eventIDand CAPIevent_id. - Elevar is designed to keep event IDs consistent across browser and server events, but duplicate sources can still break reporting.
- Do not start by manually adding a random event ID.
- First list every Purchase source in Shopify, Elevar, GTM, Meta, and third-party apps.
- Validate against Shopify order IDs, not Meta totals alone.
The symptom: Meta purchases are higher than Shopify orders
This issue usually shows up in one of five ways:
| What you see | What it usually means |
|---|---|
| Meta reports more purchases than Shopify | Meta may be counting duplicate Purchase events, or Ads Manager attribution is wider than Shopify reporting. |
| ROAS looks unusually high | Purchase volume or purchase value may be inflated. |
| Events Manager shows browser + server Purchase events but they don’t deduplicate | Pixel eventID and CAPI event_id may be missing or mismatched. |
| Purchase events fire from more than one source | Shopify native Meta app, Elevar, GTM, Customer Events, or another tracking app may overlap. |
| The same order appears to trigger multiple Purchase events | A duplicate pixel, legacy script, thank-you page reload, or parallel tracking tool may be firing. |
The first mistake is comparing Meta Ads Manager directly to Shopify and calling the difference “duplicate tracking.” Ads Manager uses attribution windows. Shopify is your order source of truth.
So the better first question is: did Meta receive more Purchase events than the real number of Shopify orders, or is Ads Manager simply attributing more purchases to ads?
How Meta deduplicates Pixel and CAPI events
When a Shopify store uses both the Meta Pixel and the Conversions API, Meta may receive two versions of the same action: a browser event from the Meta Pixel and a server event from Conversions API.
That is normal. Meta recommends using Pixel and CAPI together in many setups. But if both sources send the same Purchase event, Meta needs a way to know they describe the same order.
Meta’s recommended method is event ID deduplication. For a browser Pixel event, the parameter is eventID. For a server-side Conversions API event, the parameter is event_id.
For Meta to deduplicate the two events, the corresponding Pixel eventID and CAPI event_id need to match, and the event names also need to correspond. Meta’s documentation explains that the Pixel eventID must match the Conversions API event_id, and the Pixel event name must match the server event_name for events to be deduplicated. Meta’s server event parameter docs also describe event_id as the parameter used for deduplication between browser/app events and Conversions API events.
How Elevar is supposed to handle Meta deduplication
Elevar’s server-side tracking setup is designed to avoid double-counting by keeping a consistent event ID across client-side Pixel events and server-side CAPI events. Elevar’s documentation says it maintains a consistent event ID across both sides, allowing Meta to deduplicate and avoid counting the same event twice.
So if Elevar is the only intended owner of the Meta Purchase event, and the setup is clean, the browser and server versions should deduplicate.
But that assumption breaks when another source also sends Purchase.
- Shopify’s native Facebook & Instagram channel
- A Meta Pixel hardcoded in
theme.liquid - A GTM Meta Pixel Purchase tag
- Shopify Customer Events custom pixel
- Meta Conversions API Gateway
- Stape, Analyzify, TrackBee, Trackify, Aimerce, WeltPixel, or another app
That is why “Elevar is installed” does not automatically mean “Meta purchases cannot be duplicated.” Elevar can be configured correctly and still coexist with another Purchase source that sends its own event.
What to check first:
- Is Meta reporting more purchases than Shopify orders for the same date range?
- Are there multiple Purchase sources in Meta Events Manager?
- Do browser Pixel
eventIDand server CAPIevent_idmatch? - Is Shopify native Meta, Elevar, GTM, Stape, Analyzify, Trackify, or another app also sending Purchase?
- Does a test order produce one deduplicated Purchase event or multiple independent purchases?
Diagnostic table: cause, where to check, validation
| Symptom | Likely cause | Where to check | How to validate |
|---|---|---|---|
| Meta purchases are higher than Shopify orders | Duplicate Purchase events or attribution-window difference | Shopify orders + Meta Events Manager + Ads Manager | Compare Shopify order count to Meta Purchase event receipt for the same date range. |
| Browser and server Purchase both appear but don’t deduplicate | Pixel eventID and CAPI event_id mismatch | Meta Test Events, payload details, Elevar/GTM setup | Confirm browser and server event IDs match for the same test order. |
| Two Purchase events fire at the same time and URL | Duplicate Pixel or old script | Meta Recent Activity, Pixel Helper, Shopify theme code | Remove the extra Pixel source and retest. |
| Purchase fires from Elevar and another app | Parallel tracking tools | Shopify apps, Customer Events, GTM, Elevar destinations | Decide which system owns Purchase and retest. |
| Dedupe worked before migration, then broke | Parallel run without shared IDs | Elevar / Stape / Aimerce / other migration settings | Confirm both systems are not sending independent Purchase streams. |
| Meta still differs after dedupe is fixed | Attribution settings or reporting lag | Meta Ads Manager attribution settings | Compare Events Manager receipt separately from Ads Manager attribution. |
Common causes of duplicate Meta purchases after Elevar
1. Elevar and Shopify native Meta app both send Purchase
Shopify’s Facebook & Instagram channel can send Meta Pixel and CAPI events. Elevar can also send Meta events.
That combination is not automatically wrong, but it must be intentional. If both send Purchase independently, Meta may receive two purchase streams.
Check Shopify’s Facebook & Instagram channel, Elevar’s Meta destination settings, Meta Events Manager Purchase sources, and whether both tools are sending the same event to the same Pixel.
2. Old Meta Pixel still exists in theme.liquid
This is one of the most common Shopify causes. A store may install Meta Pixel manually in the theme, later connect the Facebook & Instagram channel, and later install Elevar. The old script remains in the theme and continues firing.
Shopify’s help docs warn that if you edited theme code to add a Meta Pixel, you need to remove that pixel code before adding a Meta Pixel through the Facebook & Instagram channel. Otherwise, the store can have more than one pixel, resulting in duplicate or incorrect data. Meta’s Shopify duplication help page also tells users to check theme.liquid for Meta Pixel scripts and remove the extra location if duplication comes from both the Facebook/Instagram channel and another Shopify location.
Search your theme, header snippets, app embeds, and custom pixels for fbq(, facebook.com/tr, or old Meta Pixel scripts.
3. GTM still fires a Meta Purchase tag
If the store used GTM before Elevar, there may still be a Meta Pixel Purchase tag firing on checkout completion.
Check your GTM web container for custom HTML tags, Meta Pixel templates, purchase/thank-you triggers, and old tags left live after Elevar launch.
4. Shopify Customer Events custom pixel also sends Purchase
Shopify Customer Events can run app pixels and custom pixels. If a custom pixel sends Meta Purchase and Elevar also sends Purchase, you may have another duplicate source.
Check Shopify Admin → Settings → Customer Events, then review custom pixels, app pixels, and any code that sends fbq('track', 'Purchase').
5. Another tracking app sends Purchase
Elevar is not the only tool that can send Shopify purchase events to Meta. Other tools may include Stape, Analyzify, Littledata, TrackBee, Aimerce, TAGGRS, WeltPixel, Trackify, Nabu, and Shopify native Meta.
These tools are not “bad.” The issue is overlap. The better question is: is another tool sending the same Purchase event as Elevar, Shopify, or GTM — and if yes, are those events meant to deduplicate or are they separate streams?
6. Browser and server IDs differ
This is the classic deduplication failure.
| Source | Event | ID |
|---|---|---|
| Meta Pixel | Purchase | abc123 |
| CAPI | Purchase | xyz789 |
To Meta, those may look like two separate purchases. This can happen when the browser ID and server ID are generated separately, when GTM tag sequencing creates IDs multiple times, when two apps use different IDs, or when one source uses order ID while another uses a generated UUID.
7. Thank-you page reload fires another browser Purchase
Some older Shopify setups fire Purchase from the thank-you page or order status page. If the page reloads, or the customer revisits the order status page, the browser Purchase can fire again.
This still appears in stores with legacy scripts, custom thank-you page logic, old GTM triggers, post-purchase apps, and checkout customizations.
Elevar vs Stape vs Analyzify vs Littledata vs TrackBee: what changes?
This is not about declaring one tool “best.” It is about understanding how each setup may send Purchase events.
| Tool/setup | Deduplication pattern | What to check |
|---|---|---|
| Elevar | Designed to maintain consistent event IDs across Pixel + CAPI | Confirm no other source sends independent Purchase events. |
| Shopify native Meta app | Often handles Pixel/CAPI automatically | Check old theme pixel, GTM, or another app is not also sending Purchase. |
| Stape CAPI Gateway | Stape says dedupe is automatic | Confirm Gateway is not running alongside Elevar or another CAPI source. |
| Stape GTM/sGTM | Requires correct shared event ID handling | Check Unique Event ID variable and duplicate browser sources. |
| Analyzify | Uses Pixel + CAPI dedupe via shared event ID | Confirm no overlapping Purchase event from another tool. |
| Littledata | Sends Shopify server-side events with specific event definitions | Check whether event definitions overlap with Elevar or native Meta. |
| TrackBee | Says dedupe is automatic via event IDs | Confirm it is not layered on top of another Purchase owner. |
| Aimerce | Warns about double-counting during migrations | Avoid parallel systems without confirmed shared dedupe key. |
| TAGGRS | GTM/server setup requires matching event IDs | Check client and server event ID configuration. |
The takeaway: any tool can create duplicate Purchase events if it overlaps with another Purchase owner and the events do not share a deduplication key.
What most people miss
Most teams jump straight to: “We need to add event_id.” That can be the wrong first move.
If the store has two independent Purchase streams — for example Elevar plus Shopify native Meta, GTM, or a leftover hardcoded Pixel — each stream may be internally valid but still create duplicate Meta purchases.
In that case, adding an event ID to one stream does not solve the core issue. You still have two systems claiming ownership of the same Shopify purchase.
- Find every source sending Purchase.
- Decide which source should own Purchase.
- Confirm browser and server versions of the same event share the same ID.
- Remove or disable overlapping legacy sources.
- Validate against Shopify order IDs.
In TrackingAudit audits, this is where the issue usually becomes obvious: the platform totals are not the source of truth. Shopify orders are.
How to validate the fix
1. Pick a controlled date range
Use a short range first: today, yesterday, or the last three days. Avoid starting with 30-day Ads Manager numbers because attribution windows can confuse the diagnosis.
2. Pull Shopify source-of-truth orders
Record order ID, order number, order time, order value, currency, payment status, test vs real order, and subscription vs one-time if relevant.
3. Check Meta Events Manager, not Ads Manager first
Ads Manager answers: what did Meta attribute to ads? Events Manager answers: what events did Meta receive? For duplicate Purchase troubleshooting, start with Events Manager.
4. Inspect Purchase event sources
Check whether Purchase is coming from browser, server, partner integration, Shopify, GTM, Elevar, or another app/source.
5. Run a controlled test purchase
Use Meta Test Events and Elevar’s Meta CAPI testing process where appropriate. For the test order, confirm the browser Purchase fires, the server Purchase fires, IDs match, event names correspond, and no old Pixel/GTM/app fires a separate Purchase.
6. Compare one Shopify order to Meta activity
| Check | Pass condition |
|---|---|
| Shopify order exists | One real order ID |
| Browser Purchase exists | Yes, if browser tracking is expected |
| Server Purchase exists | Yes, if CAPI is expected |
| IDs match | Pixel eventID = CAPI event_id |
| Event name matches | Purchase = Purchase |
| Extra source exists | No unexpected Purchase source |
| Meta count | One deduplicated Purchase, not multiple independent purchases |
7. Watch after the fix
After removing duplicate sources or fixing IDs, monitor Meta Events Manager Purchase volume, deduplication diagnostics, Shopify order count, Meta Ads Manager purchase attribution, and ROAS changes.
Do not panic if Ads Manager drops after removing inflated duplicate purchases. That may mean the old tracking was overstating results. The goal is not higher reported ROAS. The goal is cleaner conversion data.
Still seeing more Meta purchases than Shopify?
TrackingAudit can compare Shopify order truth against Elevar, GTM, Meta Pixel, CAPI, Shopify Customer Events, and app-level event sources to show exactly where the duplicate Purchase path starts.
Get your free audit →Frequently asked questions
Why does Meta show more purchases than Shopify?
Meta can show more purchases than Shopify for several reasons: duplicate Purchase events, wider attribution windows, view-through attribution, reporting lag, or multiple tracking sources sending the same order. Start by checking Meta Events Manager against Shopify order IDs before using Ads Manager totals as proof of duplication.
What is the difference between eventID and event_id?
eventID is the browser Pixel parameter. event_id is the server-side Conversions API parameter. For Meta deduplication, the browser and server versions of the same event need matching IDs and corresponding event names.
Does Elevar automatically deduplicate Meta Pixel and CAPI events?
Elevar says it maintains a consistent event ID across client-side Pixel and server-side CAPI events so Meta can deduplicate them. But duplicates can still happen if another app, GTM tag, native Meta channel, custom pixel, or hardcoded script also sends Purchase.
Can Shopify’s native Meta app duplicate Elevar events?
Yes, if both Shopify’s native Meta integration and Elevar send overlapping Purchase events to the same Pixel without a clear ownership and deduplication setup. Check Meta Events Manager sources before disabling anything.
Should I manually add event_id to Shopify?
Not as the first move. If you use Shopify’s native Meta integration or Elevar, event IDs may already be generated. Manual changes can make things worse if you do not know which system owns the Purchase event.
Can Stape and Elevar run together?
They can exist in the same broader stack, but be careful if both send Purchase events to Meta. Stape CAPI Gateway says deduplication is automatic, while GTM/server-side GTM setups require correct event ID handling. If Elevar and Stape both send independent Purchase streams, validate deduplication before trusting Meta numbers.
How do I test if Meta deduplication works?
Use Meta Events Manager Test Events and inspect whether browser/server events for the same test order share the same ID and appear as one deduplicated Purchase. Then compare that event against the Shopify order ID.
Why does Ads Manager still not match Shopify after deduplication is fixed?
Ads Manager uses attribution windows and ad-touch logic. Shopify is the order source of truth. Fixing duplicate events should clean event receipt, but Ads Manager will still not equal Shopify one-to-one.
Can duplicate Meta purchases hurt ad optimization?
Yes. If Meta receives inflated purchase signals, campaigns can optimize toward false conversion data. It can make ROAS look better than reality and distort budget decisions.
Is this only an Elevar problem?
No. Duplicate Meta purchases can happen with Elevar, Shopify native Meta, Stape, Analyzify, TrackBee, Aimerce, Littledata, TAGGRS, WeltPixel, GTM, custom pixels, or manual scripts. The issue is usually overlapping event sources or mismatched deduplication IDs, not the brand name of the tool.
Sources
- Meta: Handling Duplicate Pixel and Conversions API Events
- Meta: Conversions API server event parameters
- Elevar: Event coverage in Facebook and how Elevar improves it
- Elevar: How to test Facebook Conversions API integration
- Shopify: Meta pixel help
- Meta Business Help: Fix Meta Pixel duplication when using Shopify
- Stape: Event deduplication with Meta CAPI Gateway
- Stape: Facebook event deduplication in GTM
- Analyzify: Meta Pixel + CAPI deduplication
- WeltPixel: Event deduplication on Shopify