CDP, server-side GTM and the pixel: who does what
All three send events to Meta, which is why they get confused. But only one of them knows that Tuesday's visit and Sunday's purchase are the same person — and that difference decides which one you need.
If you have asked for server-side tracking quotes recently, you got proposals that look identical at prices that vary tenfold. The confusion is fair: all three categories send events to Meta. What they do before that is completely different.
| Browser pixel | Server-side GTM | CDP | |
|---|---|---|---|
| Role | Collects what happens on the page | Receives and forwards the event | Stores, resolves identity and activates |
| Has memory? | Only the current session | No — every event is isolated | Yes: history per person |
| Knows who the person is? | As long as the cookie lasts | Only what came in the event | Yes, joining sources and devices |
| Sees sales off-site? | No | Only if you send them | Yes: checkout webhook, CRM, email |
| Can you ask it questions? | No | No | Yes — it is a database, not a pipe |
Server-side GTM is transport, and that is not a flaw
A GTM container hosted on a server receives the event, applies rules and forwards it to destinations. It is a very well built router, and it genuinely solves ad blockers and browser restrictions.
What it does not do is remember. Every event goes in and out. If the person visited on Tuesday from a phone and bought on Sunday from a laptop, nothing in the container connects the two — because that is not what it was built for.
Comparing server-side GTM to a CDP is comparing a router to a database. Both are needed at different moments, and neither replaces the other.
The pixel is collection, and you still need it
There is an idea going around that server-side replaces the browser pixel. It does not: the browser is the only place that knows what the person saw, how far they scrolled and when they left. The server knows what was confirmed.
The good implementation uses both with the same event identifier, so Meta counts once. The bad one turns on CAPI, keeps the pixel without deduplication and celebrates revenue that does not exist.
A CDP is memory, identity and activation
A customer data platform does three things the other two do not: it stores history, it decides that different events belong to the same person, and it returns that result to the tools where decisions happen.
The hard part is the middle one. Linking Tuesday's anonymous visit to Wednesday's form and Sunday's purchase — across devices, with different emails — is the work that defines the category. It is also what stops CAPI from sending events with no email: by the time the purchase arrives, the platform already knows who it is.
Which to choose, without the hedging
- 01You need to forward a handful of events from your own site to Meta and Google, and the sale happens on that same site. Server-side GTM hosting solves it, costs less and is the shortest path.
- 02The sale happens off your site — third party checkout, WhatsApp, a sales rep — and you need to tie that sale back to its origin. Server-side GTM cannot reach here, because the memory is missing.
- 03You want to ask the data questions, not just forward it. The moment the question is "who" and not "how many", you are talking about a CDP.
The one question test
If you are unsure what you have today, ask your current tool this: who was the person who bought this morning, and where did they go over the last thirty days?
If the answer is an aggregate number, you have analytics. If it is "the event was delivered", you have transport. If it is a timeline with a name, an email, the originating ad and every visit up to the purchase, you have a CDP — and the CAPI conversation gets much simpler, because the data missing from the send is already stored.