Make the server the primary record of what happened, with the browser as the backup rather than the system of truth
The behavioral data the stack runs on is captured in the place least able to deliver it reliably: the browser. Ad blockers drop a slice of events outright. Safari's tracking prevention caps cookie lifetimes and severs sessions. Consent rejection removes another slice. Each iOS release and each browser default shift takes a little more, and the loss is not random. It concentrates in privacy-conscious and technical audiences, which skews every downstream model trained on the data that survives.
For most teams the symptom shows up as numbers that no longer reconcile. The warehouse says one thing, the analytics tool says another, the ad platforms say a third, and nobody can say which is closest to true. The underlying cause is usually the same: events are collected client-side as the system of record, and the client is a lossy channel that gets lossier every quarter.
This recipe moves the system of record to the server, where the events the business can observe directly (orders, logins, subscription changes, server-rendered page views) are captured first-hand, and keeps the browser as a fallback for the events only it can see.
Recover the events that browser-side collection silently drops, and stop the slow drift between systems. Realistic effect: ten to thirty percent more events captured for the same real-world activity, with the recovery weighted toward the privacy-restricted segment of the audience that client-side tracking under-counts most. Measure yours by running both paths side by side and comparing server volume with client volume per event type. The exact figure depends on iOS and Safari share, ad-blocker prevalence in the audience, and how much of the meaningful activity happens server-side already. A B2B SaaS product where most events are authenticated server actions recovers more than a content site whose key events are anonymous scroll-depth interactions, because the server can see the former first-hand and only the latter need the browser.
The second outcome matters more over time: a single event schema, captured once, that downstream analytics, activation, and reporting all read from. The reconciliation arguments stop because there is one source to reconcile against.
Two common architectures, and the choice usually follows what the stack already leans on. A server-side tag manager (Google's server-side GTM on Cloud Run or App Engine, or equivalent) suits tag-manager-centric stacks: the application sends events to the server container, which enriches and fans out to destinations. An event-stream platform (Segment, RudderStack, or Snowplow) suits data-platform-centric stacks: the application emits to the stream, which forks to the warehouse and to activation destinations. Both can run the fallback browser SDK alongside. The deciding factor is rarely the feature comparison and more often which layer the team already operates competently, because the collection layer becomes load-bearing infrastructure the moment it becomes the system of record.
Compare the tools on Martech Stack Builder
Data engineering owns the heart of this: the collection endpoint, the deduplication logic, the schema enforcement, and the reliability monitoring that the rest of the stack now depends on. Analytics does the reconciliation work, comparing recovered event volume against the prior client-side baseline and auditing that events conform to the schema rather than arriving in subtly different shapes. Marketing ops maps the events into the destinations activation needs and validates that what fires is what those campaigns actually consume. Infrastructure carries the hosting and scaling posture, which is a real consideration once an outage on the collection endpoint means lost events rather than a degraded dashboard. The recipe ships in weeks because the tooling is mature and the patterns are well-documented. The slip is almost always reliability discipline, not build time. A collection endpoint that drops events under load, or silently fails for an hour during a deploy, is worse than the lossy browser path it replaced, because the team now trusts it.
Work in this order. Each step gates the next one.
Steps 1, 2 and 5 are server-side event collection with client-side fallback, step 3 is consent-scoped signal collection, and steps 4 and 6 are signal quality monitoring.
The most common failure is treating server-side as a replacement for client-side rather than the primary path with the browser as fallback. Anonymous pre-login browsing, in-page interactions, and the click context that ad platforms read from browser cookies still need the client. Teams that rip out the browser SDK "because everything is server-side now" lose exactly the events the server was never able to see, and discover it weeks later when an audience comes back smaller than it should.
The second failure is deduplication that is almost right. If the dedupe key is the timestamp plus user, two genuinely distinct events a second apart can collapse into one, or a single event captured on both paths can survive as two because the keys do not match. The fix is a stable, event-level identifier minted once at the source and carried on both firings. This is the unglamorous detail that decides whether the recovered volume is real.
The third is consent captured but not carried. If consent state is looked up downstream rather than attached at capture, there is a window where events arrive without knowing what they are allowed to be used for, and the safe default (treat as non-consented) quietly drops events the customer did consent to, while the unsafe default (treat as consented) creates the exposure the recipe was supposed to close. Attaching consent at capture is what makes the collection layer trustworthy rather than just larger.
The Workshop works out with your team which of these matter for your stack right now, and what to do first: a 90-minute session with the people who own the decision.
The server-side tag manager versus event stream choice, the deduplication strategy, the schema you standardize on, and the consent model that holds up under audit: those are the decisions that turn "we should collect server-side" into a system the rest of the stack can trust.
Did this recipe match your situation?Anonymous response. Sign up to leave a longer note tied to your account.
Pick an attribution model, lock it, document why, and reconcile its outputs against incrementality, so the channel report becomes one rule the team can defend rather than a debate per meeting
Group users by when they signed up or first acted, then watch each group's engagement curve, so a quiet quarter doesn't disguise a real shift in who is sticking
Watch the conversion events at the resolution that catches a deploy breaking the cart-success fire before reporting starts surprising people, and surface the fix as an operational alert rather than a quarterly investigation