Server-side tracking: why Meta and Google don't see every purchase

Why purchases are missing in Meta and Google

A classic pixel runs in the browser. It only reports a purchase if the script loads on the order confirmation page, a cookie may be set and the request leaves the browser. Data is lost at each of these points. Four causes are particularly relevant.

Apple App Tracking Transparency

Since iOS 14.5, apps must ask users for permission via the AppTrackingTransparency framework before tracking them across apps or reading the device's advertising ID. Without permission, the advertising ID consists only of zeros. According to Apple Developer News, Apple has enforced this rule for all apps since 26 April 2021. This mainly affects clicks from within the Facebook and Instagram apps, which is exactly where many stores win their customers.

Intelligent Tracking Prevention in Safari

Safari blocks third-party cookies by default and without exception. In addition, Intelligent Tracking Prevention (ITP) deletes all cookies created via JavaScript and other script-writable storage after seven days without interaction with the website. If Safari detects link decoration, such as appended click IDs, the lifetime of such cookies on the landing page is limited to 24 hours. That is how WebKit itself describes it. Someone who clicks on an ad on Monday and buys the following Monday is then often no longer attributed to the ad.

Ad blockers

Browser ad blockers often suppress requests to known tracking domains. In its help article on Meta data sharing, Shopify explicitly points out that pixel-only tracking can be prevented by ad blockers.

Declined consent

For visitors in the EEA, marketing cookies may only be set with consent. Anyone who declines in the banner does not appear in the pixel. This gap is intended by law and cannot be technically "repaired". More on this below.

What server-side tracking does

With server-side tracking, it is not only the browser that reports the purchase: your server or your store system also reports it directly to the ad platform. The order already exists in the store, with order number, value and customer data. This information is transmitted from server to server and cannot be blocked by the customer's browser.

Meta Conversions API

In its Conversions API best practices, Meta recommends using the API in addition to the pixel. Meta calls this a "redundant setup": pixel and server send the same event, and Meta merges the two. It is important to send events as close to real time as possible, as Meta points out that real-time data can improve campaign results.

Google Enhanced Conversions and server-side tagging

Google takes two approaches. Enhanced Conversions supplement existing conversion tracking with first-party customer data such as email address, name, address or phone number. These are encrypted with the one-way hash algorithm SHA256 before sending. Google matches them with signed-in Google users and can thus attribute conversions that would have been lost without a cookie.

Server-side tagging in Google Tag Manager moves tag processing to a server that you control yourself. According to Google, only you have access to the data until you forward it, and you decide which fields go to which platform. Google explicitly recommends running the server on your own subdomain (first-party context).

Deduplication and Event Match Quality

If you run pixel and server in parallel, you must prevent a purchase from being counted twice. Otherwise your ROAS suddenly looks better than it is.

Deduplication via event_id

In its documentation on deduplication, Meta describes two methods. The recommended one is the combination of event_name and event_id: the pixel sends the purchase with an eventID, the server with the same event_id. Meta then generally keeps the event received first. Deduplication only happens if both events arrive within 48 hours. The order or transaction number is a suitable ID, because it is identical in the browser and in the backend. According to Meta, the alternative via fbp or external_id generally only works if the browser event arrives first.

Event Match Quality

A server event is only useful if Meta can match it to an account. Event Match Quality (EMQ) rates on a scale of up to 10 how well the customer information sent is suited to this. According to Meta, only matched events feed into attribution and delivery optimisation. Additional parameters such as email address, phone number, name and IP address can increase EMQ, as can the cookie values fbp and fbc and an external_id. You should transmit personal contact data in hashed form. EMQ is currently only shown for web events.

Consent Mode v2: what applies in the EEA

In November 2023, Google introduced two additional parameters: ad_user_data (consent to send user data to Google for advertising purposes) and ad_personalization (consent to personalised advertising). According to Google's help article on Consent Mode v2, advertisers who want to continue using measurement, personalisation and remarketing features must obtain consent from users in the EEA and pass the signals to Google. Since March 2024, Google's EU user consent policy has also affected measurement features. This is a Google requirement, not a law. Without correct signals, however, remarketing lists and parts of measurement are lost.

Google distinguishes two variants. With Basic Consent Mode, Google tags only load after an interaction with the banner; without consent, no data flows. With Advanced Consent Mode, the tags load immediately and send cookieless pings if consent is declined. From these, Google can create an advertiser-specific model for missing conversions, provided a minimum data volume is reached. This is set out in the Google Ads help article on Consent Mode.

GDPR and TDDDG: what server-side tracking does not change

Note: this section gives an overview and is not legal advice. Clarify your setup with your data protection officer or a law firm.

Server-side tracking is not a way to bypass consent. § 25 (1) TDDDG (the German Telecommunications Digital Services Data Protection Act) only permits storing information on the end device or accessing it with consent, unless an exception applies. The exception under para. 2 no. 2 only applies to processes that are strictly necessary for a service the user has expressly requested. Advertising cookies such as fbp typically do not fall under it. In addition, transmitting personal data to Meta or Google requires a legal basis under the GDPR.

In practice, this means: the server should only enrich purchase events with customer data if the corresponding consent has been given, and it should send the consent status along with them. Shopify also points out that you should disclose in your privacy policy which data you share with Meta. The gain from a server-side setup lies with users who have consented but whose data was previously lost through ITP, ad blockers or aborted scripts.

Checklist for Shopify stores

• Check data sharing in the Meta app: in Shopify's Facebook & Instagram app, the "Enhanced" and "Maximum" levels use the Conversions API, "Standard" only the pixel. Check which level is active.
• Remove duplicate pixels: a manually installed pixel plus the app integration easily creates double counting without a shared event_id.
• Check event_id in Events Manager: the purchase should arrive from browser and server with an identical ID, ideally the order number.
• Look at EMQ for "Purchase": if email address or phone number are missing from the server events, that is the first lever.
• Activate Enhanced Conversions in Google Ads and check in the diagnostics whether hashed customer data is arriving.
• Test Consent Mode v2: use Tag Assistant to check whether ad_user_data and ad_personalization are set correctly before and after the banner choice.
• Align banner and Shopify settings: the regions in which your banner asks for consent should match the privacy settings in Shopify.
• Check the order confirmation page: after every change to the checkout, use a test order to check whether all purchase tags fire, whether they run via apps or custom pixels, and whether the order value is passed on correctly.
• Reconcile with the backend: compare purchases according to Shopify with the conversions reported in Meta and Google every month. Larger deviations downwards point to measurement gaps, deviations upwards to missing deduplication.

Conclusion

Server-side tracking does not close every gap. Users who decline remain invisible, and that is how it should be. But it ensures that purchases by consenting customers arrive reliably, deduplicated and with high match quality. Meta's and Google's bidding algorithms benefit from this directly. There are several ways to implement it, from the Shopify standard to your own server container to specialised software such as Tracyn. Transparency note: Tracyn is a product of Atmos GmbH, whose managing director Sascha Blum is also the founder of Minotaurus.

Sources

1. Apple Developer News: Upcoming AppTrackingTransparency requirements
2. WebKit: Tracking Prevention in WebKit
3. Meta for Developers: Conversions API Best Practices
4. Meta for Developers: Handling Duplicate Pixel and Conversions API Events
5. Google Ads Help: Enhanced Conversions (German)
6. Google for Developers: An introduction to server-side tagging
7. Tag Manager Help: Updates to consent mode for traffic in the EEA
8. Google Ads Help: Consent Mode (German)
9. § 25 TDDDG (gesetze-im-internet.de, German)
10. Shopify Help: Facebook data sharing (German)