Service
Server-side tracking and event forwarding
I design and configure server-side flows for events, deduplication, first-party identity, and delivery to activation platforms.
What is included
- 01
Client-side and server-side event architecture.
- 02
Configuration with Tealium EventStream, server-side GTM, or Adobe Event Forwarding as scoped.
- 03
Integrations with Meta Conversions API, Google Enhanced Conversions, or Measurement Protocol.
- 04
Deduplication, first-party identity, and payload-control rules.
- 05
Testing, monitoring, and operating documentation.
Related experience and reasoning
-
Built 2021–2024
Server-side tracking and paid media attribution
Paid media pixels deployed client-side and server-side, with routing on Tealium EventStream and server-side GTM. Identifiers left the browser hashed, validated before hashing and only where consent allowed. The platform processed tens of millions of events a month.
- EventStream
- Server-side GTM
- Paid media
- Attribution
-
Built 2018–2021
Analytics SDKs on iOS and Android, and hybrid integrations
Native SDK implementation and resolution of the hybrid integrations between the native layer and the embedded web view. That is where sessions and identities get lost, and nobody looks until the numbers stop matching.
- iOS
- Android
- SDK
- Hybrid app
-
Built 2018–2021
Server-side tagging with custom clients, when sGTM had just shipped
A server-side container with custom clients, not just the stock ones. One for the legacy collection, one for the new one, one for an ad platform, plus outbound requests to an in-house API. The container was exported in March 2021, with the tool barely out.
- Server-side GTM
- Custom clients
- Collection
Frequently asked questions
Does server-side tracking get around blockers?
No, and anyone selling it that way is selling you a problem. It reduces browser dependency and improves the quality of the data reaching destinations, but a user who refuses consent stays out. The goal is control and quality, not recovering coverage through the back door.
Does it make the site load faster?
It can help, but this is not a performance project. Moving tags to the server takes work away from the browser, and how much you notice depends on how many there were and what they did. If speed is the main goal, start by measuring what each tag actually costs.
Which platform do you build it on?
The one you already have: Tealium EventStream, server-side GTM, or Adobe Event Forwarding. The decision comes from your current stack and from where consent lives, not from a preference of mine. Choosing from scratch is platform selection, and that is a separate engagement.
Does it work if we already have consent implemented?
Yes, and that is usually where the problem shows up. Consent resolved in the browser does not travel to the server or to the final destination on its own. Checking that it arrives, and that it arrives meaning the same thing, is part of the work.
Does this fit your problem?
Send me the context and I will tell you whether this scope fits or a different starting point makes more sense.