Conversion API vs Browser Pixel: What Is the Difference and Why You Need Both

TL;DR

Browser pixels and Conversion APIs are two delivery paths for the same events. The pixel gives ad platforms real-time browser context; the Conversion API delivers purchase data reliably past ad blockers, Safari ITP, and iOS ATT. Running both with a shared event_id gives you one deduplicated conversion per order, not two. WeltPixel Conversion Tracking fires purchases server-side only and reuses Shopify's native event.id, so non-purchase events deduplicate cleanly.

What is a browser pixel?

A browser pixel is JavaScript that executes inside the buyer's browser when they take an action on your store. It reads browser-native signals that your server never sees on its own.

When a shopper views a product page, the pixel fires a view_item event. When they add something to cart, it fires add_to_cart. The browser hands that JavaScript access to the first-party cookie, the document.referrer, the device type, and the session context. Those signals get attached to the event payload before it travels to the ad platform.

Shopify's Web Pixels API [4] is the sanctioned way to deploy browser pixels on Shopify storefronts. It runs inside a sandboxed iframe, which limits direct cookie access but still passes event metadata through the AnalyticsEvent object, including a system-generated event.id you can use as a deduplication key.

The problem is that browser pixel delivery is not guaranteed. Safari's Intelligent Tracking Prevention (ITP) shortens cookie lifetimes. Ad blockers intercept pixel requests outright. The iOS App Tracking Transparency (ATT) framework restricts identifier access. On a typical Shopify store, some percentage of purchase events that actually happen never get reported by the browser pixel alone, and the number varies by audience and device mix.

For page-level events like page_view, view_item, and add_to_cart, the browser pixel is still the right primary source. Those events happen before a transaction completes, so the server does not have the data yet, and the browser context (session, referrer, device) adds real optimization value.

What is a Conversion API?

A Conversion API (CAPI) is a direct server-to-server integration where your backend sends event data to the ad platform's API endpoint. No JavaScript in the buyer's browser, no dependency on the buyer's network settings.

Meta's Conversions API [1] receives events at graph.facebook.com/events. TikTok's Events API [2] has its own endpoint. Google's Measurement Protocol for GA4 [3] works the same way. In each case, your server constructs the event payload and sends it over HTTPS. The buyer's browser never touches it.

For Shopify specifically, the practical trigger for purchase events is the orders/create webhook. When Shopify fires that webhook, your backend receives the confirmed order data and can immediately construct and send the purchase event to Meta, TikTok, Google Ads, and GA4. That webhook fires regardless of whether the buyer's browser is still open, whether they closed the tab before the confirmation page loaded, or whether they had an ad blocker running.

That reliability is the main reason you want server-side for purchase events. The event that matters most to your ad spend, the one that drives ROAS calculations and Smart Bidding signals, is delivered unconditionally.

For a deeper look at how server-side delivery works specifically for GA4, see the GA4 server-side tracking setup for Shopify article.

Why do you need both?

Because each path captures something the other cannot.

The browser pixel captures behavioral events in real time with the session context attached. When someone browses three product pages and adds two items to cart before buying, that sequence of view_item and add_to_cart events happens inside the browser session. The server does not have that data until the buyer sends a request that includes it. Stripping those events from your Meta or TikTok pixel removes the top-of-funnel signals that audience targeting and bidding algorithms use for optimization.

The server-side CAPI captures purchases reliably regardless of browser conditions. A store doing 3,000 orders per month on a typical Shopify demographic, with a reasonable percentage of Safari and iOS users, will see measurable purchase event loss if they rely on the browser pixel alone. The exact drop varies by store, but the mechanism is documented: ITP and ad blockers intercept pixel calls, and closed-tab completions never fire at all.

Running both gives you the full picture. You get the rich behavioral signals from the browser for top-of-funnel events, and you get reliable purchase confirmation from the server. The two do not conflict as long as you handle deduplication correctly.

How does event deduplication work?

Both the browser pixel and the server-side CAPI send the same event_id for a given conversion. The platform matches on that field and counts one event, not two.

If the event_id values do not match between browser and server, or if one side does not send an event_id at all, the platform counts both as separate conversions. That inflates your reported purchases and corrupts your ROAS data. This is not a theoretical problem. It happens on every store where someone has added a CAPI integration on top of an existing browser pixel without verifying that the IDs align.

For a full technical breakdown of how deduplication is implemented and where it breaks, event deduplication for Shopify tracking goes into specifics.

In WCT's architecture, purchase events fire server-side only, from the orders/create webhook. The browser-side purchase dispatch is intentionally disabled, so purchase events fire only from the server. That eliminates the deduplication problem for purchases entirely because only one source fires. For non-purchase events (add_to_cart, page_view), both browser and server-side fire with a shared event_id sourced from Shopify's event.id, so the platform deduplicates correctly.

Verify deduplication on your own store

1. Go to Meta Events Manager. Select your pixel. Open the Test Events tab.
2. Place a test order on your store.
3. In Events Manager, look at the Event Match Quality column for the Purchase event. Check whether you see two Purchase events or one.
4. If you see two, click into one. Check the event_id field on both. If they differ, your deduplication is broken.
5. In Shopify Admin: Settings → Customer events. Check which pixels are active and whether any browser-side purchase events are configured there alongside a server-side CAPI integration.
6. For TikTok, go to TikTok Events Manager → Diagnostics. A "Duplicate Events" warning appears when the platform detects mismatched event_id values across browser and server sources.

Which platforms have Conversion APIs?

Most major ad platforms now have a server-side API. The table below covers the main ones and where Shopify-native support and WCT support currently stand.

Shopify's native channel integrations for Meta and TikTok do handle some server-side forwarding, but their event coverage and deduplication behavior are constrained by the channel's own architecture. For stores where Meta CAPI configuration matters, the Meta CAPI setup paths for Shopify article covers what the native channel does and does not cover.

Google Ads Enhanced Conversions and GA4 Measurement Protocol have no native Shopify channel integration at all. The data has to come from somewhere, and that somewhere is either a custom implementation or an app. For the specifics on Google Ads server-side, the Google Ads conversion tracking for Shopify article covers the Enhanced Conversions setup and what uploadClickConversions actually requires.

The signal quality difference between browser and server

Ad platforms use event data for two things: attribution and optimization. These are related but not the same.

Attribution answers the question "which campaign gets credit for this conversion?" Server-side CAPI data is sufficient for that. You send the purchase event with the click ID (fbclid, ttclid, gclid) and the platform matches it to a campaign.

Optimization answers the question "who should I show this ad to next?" That is where browser context matters. Browser pixels send the user agent, the session cookie, the referrer, and the hashed email/phone if available. That data feeds lookalike audiences, Smart Bidding signals, and bidding calibration. A server-only setup strips those signals from non-purchase events and degrades audience quality over time, especially for top-of-funnel campaigns.

For Meta specifically, Event Match Quality (EMQ) scores reflect how much customer information is attached to an event. A purchase event sent from the server with a hashed email and phone, a fbclid, and a client IP scores higher than one sent with only an order ID. The Meta Event Match Quality article covers how to maximize that score from the server side.

This is why the architecture question is not "browser or server." It is "which events from which source, with what shared identifiers."

Key Takeaways

• A browser pixel fires JavaScript from the buyer's browser and captures in-session events (page_view, view_item, add_to_cart) with session context, cookies, and referrer attached.
• A Conversion API sends events server-to-server from your backend, bypassing ad blockers, Safari ITP, and iOS ATT entirely.
• Purchase events should fire server-side from the orders/create webhook, not from the browser pixel, because that webhook fires unconditionally after a confirmed order.
• Deduplication requires a shared event_id on both browser and server payloads for the same event. Mismatched or missing event_id values cause double-counted conversions and inflated ROAS.
• Firing purchase events from the server side only (as WCT does) eliminates the deduplication problem for that event class because there is only one source.
• Meta, TikTok, Google Ads, and GA4 all have server-side APIs. Pinterest, Snapchat, X, and Microsoft Ads also have CAPIs but WCT does not currently support them.
• Shopify's native Meta and TikTok channel integrations provide partial CAPI coverage but do not cover Google Ads Enhanced Conversions or GA4 Measurement Protocol at all.

FAQ

What is the difference between CAPI and a browser pixel?

A browser pixel fires JavaScript from the buyer's device and reads browser-native data like cookies, referrer, and user agent. A Conversion API (CAPI) sends event data from your server directly to the ad platform's API endpoint, with no browser involvement. Both send the same event types, but through different delivery paths with different reliability and context profiles.

Does using both a pixel and a CAPI double my conversions?

Only if your event_id values do not match between browser and server. When both sides send the same event_id for the same event, the ad platform deduplicates and counts one conversion. If the IDs differ or one side omits the field entirely, the platform counts both as separate conversions. Verify this in Meta Events Manager under the Test Events tab or in TikTok Events Manager under Diagnostics.

Can I drop the browser pixel and use only the Conversion API?

You can, but you lose the in-session behavioral events that feed audience targeting and bidding optimization. Page view, product view, and add-to-cart events happen before your server has enough data to send them on its own, and the browser context attached to those events (session ID, referrer, device signals) improves audience quality. Server-only setups are viable for attribution but tend to degrade top-of-funnel optimization over time.

Which Shopify apps support both browser pixels and server-side CAPI?

Shopify's native channel integrations for Meta and TikTok include partial CAPI support, but they do not cover Google Ads Enhanced Conversions or GA4 Measurement Protocol. WeltPixel Conversion Tracking covers all four: Meta Conversions API, TikTok Events API, Google Ads Enhanced Conversions, and GA4 Measurement Protocol, with shared event_id deduplication handled automatically.

How do I know if my purchase events are being double-counted?

Open Meta Events Manager, go to the Test Events tab, and place a test order. If two Purchase events appear for one order and their event_id values differ, you have double-counting. In GA4, go to Reports → Engagement → Events and filter for purchase. Compare the event count against Shopify's Orders count for the same date range. A ratio significantly above 1:1 (accounting for test orders and returns) indicates duplicate firing.

Start Sending Purchase Events the Right Way

WeltPixel Conversion Tracking fires browser-side events for page_view, view_item, and add_to_cart with shared event_id values, and sends purchase events server-side only via the orders/create webhook for Meta, TikTok, Google Ads, and GA4. Deduplication is handled automatically. You get one conversion per order with full server-side reliability, no manual event_id matching required.

Install WeltPixel Conversion Tracking on Shopify

Sources

1. Meta Conversions API documentation
2. TikTok Events API documentation
3. Google Analytics Measurement Protocol for GA4
4. Shopify Web Pixels API documentation