GA4 & server-side tracking
We audit your tracking, set up GA4 and server-side tracking, and configure marketing consent with Consent Mode.
We clean up your tracking so one report shows sales that match what’s actually in your order database. That way, you base your Google and Meta ad budgets on solid numbers.
Overview
We reconcile GA4 and your ad platforms with your order database, so your ad budget rests on solid numbers.
Often your store’s admin panel shows one order count, GA4 another and the ad platform a third. When that happens, it’s hard to know which one to treat as the baseline, and budget decisions come down to gut feeling. In most cases, cleaning up how events are collected and sent is enough to make all 3 numbers line up again.
We build tracking into your system, so the data comes straight from the source of each sale. We send purchase events along 2 paths, from the browser and from the server, with a shared event ID, so each purchase counts only once. We protect personal data before it’s sent by hashing it into an irreversible string, and the whole setup follows the consent each user has given.
The result is a figure you can put next to your sales report without having to explain where the difference came from. When you discuss campaign profitability and which channel actually drives orders, the conversation rests on data you trust.
Order count and value in your reports match your store system.
The event fires when the order is saved to the database, so every purchase counts.
A shared event ID ensures the same purchase is counted once.
Tracking follows the consent each user has given.
Everything from a review of your current setup and server-side tracking to reports that actually support your budget decisions.
We check which tags (snippets of code that collect data) actually fire, which events are duplicated and which are missing. We compare order count and value in your analytics tools with the data in your database and trace the source of every discrepancy, so you know which numbers you can trust.
We set up the full purchase funnel—from product view through add to cart and checkout to the completed order—with correct product IDs, variants, currency and post-discount value. We keep the configuration consistent across markets and languages, so you can compare data from each of them side by side.
We track along 2 paths, from the browser and from the server (Conversions API sends purchase data straight from your backend to Meta), with a shared event ID, so each purchase counts once. We hash personal data before it’s sent, handle returns and adjustments, and keep tracking running even when customers block scripts in their browser.
We pass the consent state to your tracking tools and respect it on the server side as well, so tracking follows each user’s choice. On top of that, we add an on-site option to change consent at any time and a privacy policy with an accurate cookie table, so you can be confident about GDPR compliance.
We build product feeds (your catalog in a format that ad systems can read) for Google Merchant Center and marketing automation tools: we group variants, fill in required attributes and validate the file before publishing. Rejected items go into a report with the specific reason, so your complete catalog shows up in your ads.
We prepare recurring reports straight from your database and analytics tools, delivered by email or in a dashboard, so you get one consistent view of sales. We also monitor the event stream continuously, so if tracking stops working, you find out the same day and the data gap stays short.
Basics
This single distinction explains most discrepancies in your analytics. It’s worth understanding before you decide on another tool, because it usually points straight to the fix.
Traditional tracking is a script that runs in the customer’s browser. For a purchase to count, the whole chain has to work: the script must load, and the customer must return from the bank’s payment page to the thank-you page and stay there long enough for the data to go out. If any link breaks—an extension that blocks scripts, a closed tab, a dropped mobile connection—the order stays in your database but may be missing from your analytics.
Server-side tracking closes that gap. The event fires the moment the order is saved to the database or its status changes to paid, so the data comes straight from the source of the sale. This matters most when the payment gateway confirms payment with a server-to-server notification (a webhook from the payment provider), because an order can be paid well after the customer has left the store.
Browser tracking still plays a role, because it provides context the server lacks: where the traffic came from and what the user viewed along the way. A well-configured setup combines both sources with a shared event ID, so the same purchase counts only once and you get complete data with a single result.
| Scenario | Browser tracking | Server-side tracking |
|---|---|---|
| Script-blocking extension | The event never fires | Fires regardless of the customer’s browser |
| Customer closes the tab right after paying | Data may not leave the browser in time | Sent after the order is saved to the database |
| Payment confirmed by a gateway notification | Status is still unknown at page view | Event fires after the notification is verified, with the real status |
| Order value with a discount | Often calculated from list prices in the template | Taken from the amount stored in the order |
| Data used to match the conversion | Sent in plain text or skipped | Hashed on the server before sending |
| Identifier lifetime limits | Cut short by the browser, breaking the user journey | Identifier controlled by the application |
| Order return or cancellation | Sales value can be overstated | Adjustment sent after the status change |
GA4 and ad platforms measure exactly what their configuration allows. On default settings, they measure less than they could—and that’s the part we fix, so your data is complete.
Takeaway from the tracking audits that start every project
Audit
These 10 issues come up in most of the setups we take over, so we know where to look and get your data back in order fast.
In detail
Event deduplication
Sending each purchase from both the browser and the server in parallel makes tracking resilient to blockers, and a shared event ID ensures the same order counts only once. We assign the ID when the order is created, store it with the order and use it on both paths, so the ad platform pairs both signals and keeps a single purchase—and your report shows a number that matches your database.
We take the same care with the data that lets a platform attribute a purchase to a user. We secure email addresses and mobile numbers before sending by converting them into an irreversible string (hashing), so matching works without passing on any human-readable data. When marketing consent is missing, neither the browser nor the server sends the event, so tracking stays compliant with privacy law.
We also keep the data clean: a repeated notification from the payment gateway never creates a second purchase, a return triggers a value adjustment, and product IDs stay consistent across your store, product feed and events. That way, your GA4 and ad platform numbers stay reliable month after month.
Performance
Page speed affects your results twice over: when content loads slowly, some users leave early, and tracking scripts have less time to send events. That’s why we run the tracking audit together with a performance audit—we test Core Web Vitals, Google’s metrics for page speed and visual stability, on real devices and at real connection speeds, so a faster site translates into more completed purchases and more complete data.
We check how many third-party scripts really need to load and in what order, whether images use the right formats and dimensions, and whether each visit fetches more data than it needs. We also verify rendering in Chrome, Safari and Chromium, which can handle the same layout differently, and behavior on narrow screens from 320 pixels up, so your store looks the same on every smartphone.
The result is a list ranked by impact versus effort: what to fix first, what can wait and what requires backend changes—so you know where to start to see a difference fastest.
How we work
We inventory the tags and events that are firing, then compare the data in your analytics tools with order count and value in your database. For every discrepancy, we identify the cause, so you know where it comes from and how to close it.
We define the list of events, their parameters and a reliable source for every value, so each number has a clear origin. We document what is sent from the browser, what is sent from the server, how we make sure each purchase counts once, and which events depend on marketing consent.
We build the tracking layer—in-app events, server-side sending, consent handling, data protection and status adjustments—on a separate copy of your store, so we can test every change without affecting live sales. We then roll it out to the live store in stages, with the option to revert each change, so the rollout stays safe.
Over an agreed period, we compare events with orders in your database, channel by channel, and close the gaps until the numbers line up. Finally, we leave continuous event-stream monitoring and alerts in place, so you know right away if tracking starts to drift.
Each of the 3 recurs in many online stores. Below each one are the steps we take to bring the numbers back in line, so you can rely on your data when you set your budget.
Server-side tracking
Your store’s admin panel shows more orders than GA4 and Meta Ads Manager. The gap widens in paid campaigns and narrows in direct traffic.
The browser sends the purchase event from the thank-you page. If the script is blocked, the tab is closed, or the payment is confirmed after the customer has left the store, the event may never fire.
We move purchase tracking to the server and tie it to the order status change in the database, so every purchase counts. Browser-side events stay in place for context, and a shared event ID ensures each purchase counts once. We hash personal data, and marketing events follow each user’s consent.
Tracking audit
The report shows revenue that never appears in your accounting. It’s hard to switch anything off when no one knows what else will stop being tracked.
The purchase event can be wired into 3 places at once: the theme template, Google Tag Manager and a plugin. Each new implementation adds its own source, and the old ones stay in place. On top of that, every reload of the thank-you page counts the same purchase again.
We list every event source and match it against order numbers from the database, day by day. We switch sources off one at a time and measure the impact of each step, so every tag you need keeps working. Each purchase gets a key based on the order number, so a repeated event no longer counts.
Consent
Overnight, the event count drops by an order of magnitude. Store sales stay at the same level, so the gap is on the tracking side.
Tracking scripts wait for a signal that the consent decision has been made. For some user choices, that signal never arrives, so the tools stay silent even when consent has been given.
We set the consent state before any tool loads and update it whenever the user changes their decision, server-side events included, so tracking always follows the user’s choice. Events that fire before the user decides wait in a queue. Continuous stream monitoring catches any similar drop on the same day it happens.
FAQ
No. Consent applies to the purpose for which data is processed, so it holds whether the event leaves the browser or the server—if a user declines marketing consent, the server sends no event either. Server-side tracking helps with a different case: it covers situations where consent was given, yet the event never arrived because the browser blocked it or the customer closed the tab before it was sent. That way, you get complete data while respecting every user’s choice.
Having GA4 installed doesn’t guarantee the data is correct. In the audit, we compare order count and value in your analytics tools with what’s in your database and check the most common sources of discrepancies: missing events in the purchase funnel, values calculated before discounts, duplicate tags from previous setups and internal traffic counted as sales. You get a list of discrepancies with the cause and a proposed fix for each, so you know which numbers you can trust.
A match down to every single order is hard to promise honestly. Analytics tools such as GA4 and Meta Ads Manager use their own attribution models, time windows and session-counting methods, so small discrepancies are natural. We aim for a gap that is small, stable and explained—then you can compare reports month to month and treat them as a solid basis for budget decisions.
In most cases, no. We connect the tracking layer to your existing application—on MedusaJS, Shopify, WooCommerce, WordPress or a custom backend in Node.js, PHP or Python—so your store keeps running without a rebuild. We need access to the point where an order is created or changes status, and to the payment gateway notifications. If those hooks are missing, we add them along the way, so the rollout stays smooth for live sales.
Through an automated alert. We continuously monitor the flow of key events and compare it with the order count in your database. If the stream stops or the gap exceeds an agreed threshold, we send a notification by email or to your team channel, so you can react the same day. This matters because tracking outages most often appear when a new version of the store is deployed, and continuous monitoring lets you fix them right away, before the data gap grows.
On the technical side, yes. We prepare a privacy policy with an accurate table of the cookies in use, a list of data recipients and information on transfers outside the EEA, plus an on-site option to change consent at any time. We compare what the document says with what the code actually does and list each discrepancy with the script name, so you can be sure the policy matches how the site behaves. Legal opinions come from a lawyer, and we provide the technical documentation they can rely on.
Email us a list of your tracking tools and where your numbers diverge. We reply within one business day. The first step is an audit that shows where the gap comes from and what it costs to close, so you make budget decisions based on solid data.