Server-side tracking
Server-side tracking is sending a "someone viewed a page" or "someone bought" message from your own server (the computers that run your website) to Google or Meta, instead of only from the visitor's browser. The browser can block those messages with ad blockers or privacy settings. Your server is harder to block. It is more reliable, and more work to set up.
Theodor Lindfors, Founding Marketer ·
How server-side tracking works
A lightweight client sends one event to an endpoint you control. That endpoint enriches the event and distributes it to each destination through their APIs (application programming interfaces: a way for one computer to send data to another), such as Meta Conversions API or Google's server-side endpoints.
Let's take a drink brand as an example. They sell a low-sugar sports drink for active women over 50, mostly from their own website. The drink brand advertises on Meta, TikTok, and YouTube.
Let's take a drink brand as an example. They sell a low-sugar sports drink for active women over 50, mostly from their own website. A customer buys a $36 six-pack. Instead of eight different tags racing in the customer's browser, the drink brand's website tells the drink brand's own server: purchase, $36, order 4812. That server forwards a copy to Meta, a copy to Google, and a copy to analytics. If the customer's ad blocker would have killed the browser tags, the server still has the $36 six-pack order.
Lemonado does not run this pipeline for you. Lemonado is not a tag manager or a server container. Lemonado reads the ad accounts and analytics you connect, and writes changes to campaigns. MCP connections (Model Context Protocol: a way to plug ChatGPT, Claude, Cursor, or n8n into your marketing data) stay read-only.
Why server-side tracking matters
Browser tracking keeps getting less reliable, and every lost event is both a reporting gap and a worse signal for automated bidding. Server-side collection recovers a meaningful share of that loss. A drink brand's Meta column looks closer to the shop's actual 400 orders.
Server-side tracking also gives you one place to decide what data leaves your systems, which is easier to govern than a dozen tags a dozen people added over three years.
How to read a server-side migration
Conversions will usually go up in the reports. That is recovery, not growth. Mark the migration date and compare against your own orders, or you will spend a quarter congratulating yourself for a plumbing change. If Meta jumps from 280 reported purchases to 360 reported purchases and the shop still processed 400 orders, you closed a gap. You did not sell 80 extra six-packs.
Deduplication is the thing that bites. Run client and server in parallel with shared event IDs, verify the counts, then retire the duplicates. An event ID is a shared label, like order 4812, so Meta knows both copies are the same $36 six-pack.
Common server-side tracking mistakes
- Double counting because client (browser) events and server events are not deduplicated.
- Sending more customer data than the visitor agreed to.
- Treating server-side tracking as a privacy workaround rather than a reliability upgrade.
- Nobody owning server-side tracking, so it silently breaks and nobody notices for weeks.
Lemonado
How Lemonado helps around server-side tracking
A server-side rollout changes what each platform sees. Lemonado keeps platform-reported conversions next to your own revenue, so the jump in reported results does not get read as growth.