Client-side vs server-side tracking: where the event starts

“Server-side tracking” sounds like one setup that you either have or lack. Vendors use the term for at least three different things: a server container that receives requests from your visitors’ browsers, an API that accepts events from your own systems, and a webhook that your store, network or CRM sends when an order changes. The three see different sales.

Whether a setup is client-side or server-side depends on where the event starts, not on the server it passes through. An event that starts in the browser is still a browser event after a server relays it. Server-side Google Tag Manager, a pixel forwarded through your own server and Google tag gateway all move the request. None of them can see a sale that never happens in a browser.

Eight setups, one question

Read from each vendor’s own documentation on 22 October 2026. Every row is in facts above with its source.

Setup	Where the event starts	What triggers it	What it cannot see
GTM server container	The browser	A request from the visitor’s device, sent by gtag.js to the server container URL	Any sale that sends no request from a browser
Google tag gateway	The browser	The Google tag, served from your own domain through your CDN, load balancer or web server	The same sales: it changes the route, not the source
Meta Conversions API	Wherever you send it from	A call from your server, labelled with one of nine action_source values	Any conversion your systems do not record and send
TikTok Events API	Wherever you send it from	A call from your server, with events from websites, apps, stores or CRMs	Any conversion your systems do not record and send
Shopify order webhooks	A server (Shopify)	An order created, paid or refunded, from web, mobile_app or pos	The ad click, unless the order holds the visit
ClickBank Instant Notification Service	A server (ClickBank)	A sale, rebill, refund, chargeback or cancelled rebill	Anything on your pages: it reports ClickBank’s own transactions
HubSpot workflow webhook	A server (HubSpot)	A record that meets a workflow’s criterion reaches the webhook action	The ad click, unless the record holds it
ChatGPT Instant Checkout	A server (ChatGPT, then the merchant’s backend)	The buyer confirms the order in the chat	The conversation: only the data needed for the order reaches the merchant

Two rows start in the browser. Two are pipes that carry whatever you send them. Four start on the server where the sale is recorded, and one of those four is a checkout inside an AI assistant.

The two that start in the browser

Google describes the server container plainly: “The server receives web requests from the user’s device.” Its clients turn those requests into events. The container waits for the browser. A buyer who orders by phone, renews a subscription or pays on a checkout that you do not run sends it nothing.

Google tag gateway goes less far. It serves the Google tag from your own domain, through your CDN, load balancer or web server. Google’s help page says it runs your tags client-side or server-side, which is how one product ends up on both sides of the line. The tag still loads in the visitor’s browser.

Google reports an 11% uplift in signals for advertisers who set up the gateway. The footnote says what that counts: Google tag script loads, with and without the gateway, over one week in April 2025. More browsers loaded the tag. That measures how much the plain browser path was losing. It cannot include a sale that never loaded a page.

None of this makes server-side tagging worthless. It gets more browser events through. A cookie that your own server sets is also outside Safari’s 7-day limit on cookies written in JavaScript, as the cookie behind a click window shows. It makes the browser half better. It does not add the other half.

The two that are pipes

Meta’s Conversions API and TikTok’s Events API start nothing. They deliver what your systems send them. Meta’s action_source field says where a conversion occurred, and it takes nine values. One of them is website. The others are app, email, phone_call, chat, physical_store, business_messaging, system_generated and other. Meta’s example for system_generated is a subscription renewal on auto-pay: a conversion with no visitor and no browser.

So “we use the Conversions API” does not answer the question. If your server forwards the pixel’s purchase event, that event started in the browser. If your billing system sends the renewal, it started on a server. Same API, different sources. TikTok recommends running its Pixel and its Events API together, with deduplication, because a working setup has both kinds.

The four that start where the sale happens

These see the sales that a browser cannot.

• Shopify fires orders/create when an order is created, orders/paid when it is paid and refunds/create when a refund is made. An order’s sourceName can be web, mobile_app or pos, so a till sale reaches the webhook the same way a web sale does.
• ClickBank’s Instant Notification Service posts sales, rebills, refunds, chargebacks and cancelled rebills to a URL that you set. A rebill runs on ClickBank’s billing schedule, with no visitor anywhere.
• HubSpot enrols a record in a workflow when a criterion becomes true, and a webhook action then sends its data to your URL. A lead that a salesperson marks as a customer starts in the CRM.
• ChatGPT Instant Checkout is in the next section.

What these miss is the click. A webhook knows the sale. It knows the ad only if the click ID or the visit was saved with the order. Shopify keeps the online store visits before an order in customerJourneySummary. A till sale has none. A postback is only as attributed as the ID it carries, which is the first thing to test.

What AI changes

OpenAI announced Instant Checkout on 29 September 2025. A ChatGPT user confirms the order and pays without leaving the chat. ChatGPT sends the order details to the merchant’s backend through the Agentic Commerce Protocol, and the merchant takes payment and ships with its existing systems. OpenAI’s commerce documentation still tells merchants to integrate through its Agentic Checkout Spec.

In that purchase the buyer never loads your website. There is no page, no thank-you page and no tag. A server container waits for a request that never comes. The order exists only on the merchant’s server, so only a server-side source, such as the order webhook from the merchant’s own store, can record it. OpenAI also says that only the data needed to complete the order reaches the merchant, so the order arrives with no visit attached. Each sale made this way is one that the browser half of a setup will never count.

How to tell what you have

Ask these questions of any setup called server-side, yours or a vendor’s:

1. Where does the event start? If the answer is a tag on the page, the setup is client-side, whatever route the request takes next.
2. Which of your sales never touch a browser? Renewals, refunds, chargebacks, phone and till sales, deals closed in a CRM, sales on a network’s checkout, assistant checkouts. List them.
3. Which system records each one, and can it send a webhook or postback? That system is your server-side source.
4. Does that record carry the click ID? Without one, the event arrives on time and unattributed.
5. Do the browser and server events share an event ID? When both report the same purchase, the platform needs one key to count it once.

Question 4 is where server-side setups fail quietly. The record has to carry a click ID, and there are two kinds: the one the ad platform created and the one your tracker created. Each one matches only in the system that made it.