Something shifted over the last couple of years and almost nobody announced it. Server-side data collection—event forwarding, the conversions APIs, moving tags off the page and into the cloud—stopped being the advanced option you graduated to and quietly became the default assumption.
Every major platform now expects a server-side path. The ad networks are measurably better through it. The browsers are actively hostile to the old way.
And yet most stacks I see are still architected, staffed, and mentally modeled as client-side-first, with server-side bolted on where someone had time. That mismatch is the problem I want to talk about, because the gap between where collection is heading and where most teams actually are is wider than people realize.
How the default flipped without anyone deciding
There was no single moment. It happened the way these things always do—a series of individually reasonable changes that added up to a new baseline.
- Browsers kept closing doors. Third-party cookies, ITP, cookie lifespan caps, fingerprinting restrictions. Each one chipped away at what client-side JavaScript could reliably see and remember. The client stopped being a trustworthy place to observe a customer.
- The ad platforms moved their own goalposts. Meta's CAPI, Google's enhanced conversions and server-side tagging—these aren't optional performance tweaks anymore. The match rates and attribution quality through the server-side path are materially better, and the platforms know it, so that's where they're investing.
- Event forwarding matured into real infrastructure. What used to be a niche “send this event to that endpoint” capability became a legitimate collection-and-distribution layer sitting between your edge and everything downstream.
Put those together and the logic inverts. It used to be: collect everything client-side, forward a few things server-side if you're sophisticated. Now it's closer to: collect server-side as the system of record, and treat the client as one input that happens to be increasingly unreliable.
Why “we have CAPI set up” doesn't mean you're ready
Here's where I see teams fool themselves. Somebody stood up a conversions API integration, checked the box, and declared the stack server-side-ready. But having a server-side pipe is not the same as being built for a server-side world. The difference shows up in the parts nobody demos.
- Identity gets harder, not easier, server-side. On the page you had the cookie, the ECID, the whole client context handed to you. Server-side, you have to deliberately carry identity across the boundary—pass the right identifiers, maintain the stitch, keep the server event tied to the same person the client event was. If you don't architect that carefully, you've just created two disconnected views of the same customer and made your fragmentation problem worse.
- Consent has to travel with the event. This is the one that quietly breaks things. When collection moves server-side, the user's consent signal has to move with the data to the server and be enforced there—not assumed because a banner was shown on the page. A server-side event that fires regardless of consent isn't a technical convenience; it's a governance incident waiting to be found. The server doesn't see the banner. You have to send it the answer.
- You lose the free context the browser used to give you. User agent, page context, referrer, timing—client-side handed you all of it. Server-side, every piece of context is something you chose to send, which means every piece of context is something you can forget to send. Debugging shifts from “read the network tab” to “trace it through the pipeline,” and most teams aren't tooled for that.
- The deduplication problem is real. Run client-side and server-side in parallel—which most people do during transition—and the same conversion can arrive twice. Getting the event IDs and dedup keys right is fiddly, unglamorous, and the thing that silently inflates or corrupts your numbers if you get it wrong.
None of that is exotic. It's just work that doesn't exist in the client-side mental model, so it doesn't get planned for, and then it surfaces as “why don't our numbers match” six months later.
The parts of this that are actually architecture decisions
If I were pressure-testing a stack for server-side readiness, I wouldn't ask “do you have event forwarding.” I'd ask a few questions that get at whether the thing was designed for this world:
- When an event is collected server-side, how does identity stay attached to the right person across the client/server boundary?
- Where does consent get enforced—at the edge before forwarding, or are you trusting that it was handled upstream? Can you prove it?
- When client and server both report the same conversion, what dedupes them, and who owns keeping that logic correct?
- What's your system of record—is server-side collection authoritative, or is it a secondary feed you reconcile against client data? Pick one on purpose.
- When something looks wrong downstream, how do you trace an event through forwarding to the destination?
Those aren't integration questions. They're architecture questions, and they decide whether server-side makes your data better or just moves your problems to a place that's harder to see.
So where does FPID fit?
Someone asked me a sharp question about this: if identity surviving the client/server boundary is the hard part, doesn't a first-party ID solve it? My honest answer is—it solves the right piece of it, which is more than most things do, so it's worth being precise about what it does and doesn't fix.
The First-Party ID (FPID) is the identifier you set and control, on your own domain, rather than letting the browser mint and manage it. In the AEP/Web SDK world it becomes the deterministic seed for the Experience Cloud ID—same FPID, same resolved identity, on both sides of the boundary. That matters here for a few specific reasons:
- It can be set server-side, as a first-party cookie. That's the whole point. A cookie your server sets from your own domain isn't subject to the same hostility a JavaScript-written cookie faces—the short lifespans, the script-cookie caps, the general browser distrust the rest of this piece is about. You get a more durable anchor precisely because it's not a client-side artifact.
- It makes the server the identity authority. This is the philosophical fit with everything above. If the server is becoming your system of record, your identifier shouldn't be something the browser owns and can forget. FPID lets identity follow the same logic as collection—you set it, you own its lifetime, you're not at the mercy of what the client decides to drop.
- It gives client and server a shared anchor to agree on. The nightmare in a server-side transition is two disconnected views of the same person. A consistent FPID feeding the same ECID is the thing that keeps the client event and the server event pointed at the same identity instead of fragmenting into two.
So yes—if I were hardening a stack for this world, FPID would be part of my answer, specifically for the durability-and-portability-of-the-identifier problem. It's a genuinely good move.
But I want to be careful not to oversell it, because that's how these things get misunderstood. FPID solves the identifier. It does not, by itself, solve the other three:
- It doesn't make consent travel with your events or get enforced server-side—that's still a deliberate design choice you own.
- It doesn't dedupe your client and server conversions—the event IDs are still your problem.
- And FPID is a pseudonymous browser/device anchor, not a person. The anonymous-to-known stitch—the moment you tie that FPID to an actual authenticated customer—still happens in the identity graph, and that stitch is where the real identity work lives.
So the honest framing is: FPID is the right foundation for identity in a server-side world, not the whole house. It fixes the piece that's hardest to retrofit later, which is exactly why you want it early. Just don't let standing it up become another checked box that lets everyone believe identity is “handled.” It handles the anchor. You still have to build the rest.
The honest bottom line
The pipe is the easy part.
Server-side isn't the future you're preparing for. It's the present you're probably already half-living in, with a stack and a set of habits built for the past.
The ad platforms, the browsers, and the privacy regime have all quietly agreed that the server is where collection belongs now.
The teams that do well here won't be the ones who “turned on CAPI.” They'll be the ones who treated the move server-side as what it actually is—a re-architecture of identity, consent, and the system of record—rather than a new pipe bolted onto old thinking.
The pipe is the easy part. Everything the browser used to do for you, that you now have to do deliberately, is the real work.
If your mental model of data collection still starts at the page, it's worth noticing that the rest of the ecosystem stopped starting there a while ago.