You have been told your site needs server-side tracking. Possibly more than once, by more than one supplier, with a diagram.
The diagram was persuasive because diagrams with more boxes always are. What is usually missing from it is the sentence that would let you decide: here is the specific thing that is broken for you right now, and here is the smaller thing we should try first.
So this is that sentence, written out at length. It is written for the person who signs off on the spend, not for the person who does the implementation.
Two things worth saying before the argument starts.
Nobody at your company got this wrong. There is no default state of a marketing website in which this is already handled. It decays quietly, there is no alert, and at most B2B SaaS companies between roughly 70 and 200 people there is no role that owns it.
And I inherit, repair and operate these systems for a living. I have not designed one from nothing, and that is exactly why the recommendation below is often “not yet.”
What Server-Side Tracking Actually Changes
Today, when somebody lands on your website, the messages that tell Google, LinkedIn or Meta what happened are sent by the visitor’s own browser. That browser belongs to the visitor, not to you. It can refuse, and nothing on your side gets told when it does.
Server-side tracking moves those messages onto a server you control. Your website talks to your server. Your server talks to the ad platforms.
That is the whole architectural change. Everything else people say about it is a consequence of that one move.
Three consequences matter commercially.
The first is that a browser can no longer silently discard the message. Ad blockers, tracking prevention and shortened cookie lifetimes all operate on the browser. A message sent from a server is not subject to them in the same way.
The second is visibility. Every message now leaves from one place you own. When a customer’s security reviewer asks what data your website sends to third parties, you can answer with a list rather than an investigation.
The third is time. A browser only knows what happened in the tab it is in, while it is open. A server can hold on to something and report it back weeks later, which is the only way a deal that closes in month four ever gets credited to the ad that started it in month one.
Read against the three tracking architectures, this is the third one. It is not a replacement for the other two. It sits alongside them.
The Three Situations Where It Is Genuinely Worth Buying
Here is the short list, and you need at least one of these to be true before the spend makes sense. Your ad reporting is materially behind your CRM. A privacy requirement has landed with a date attached. Your sales cycle outlives the window your ad platforms will still accept a conversion in.
One: your ad reporting is materially behind your CRM
Your ad platform says it produced 90 conversions. Your CRM has 140 records for the same period, from the same campaigns.
If that gap is real and consistent, some of it is browser blocking, and server-side tracking recovers part of it.
The important caveat is that this test only works if you have already ruled out the cheaper causes, and the cheaper causes are more common. More on that below.
Two: a privacy requirement has landed with a date attached
This is the situation that produces the most urgency and the least warning. A prospect’s security review asks a question your team cannot answer. Legal reads something. A deal is blocked pending a written response.
Server-side tracking helps here in a way that has nothing to do with recovering conversions. It gives you a single place where you can inspect and document what leaves your website, which is exactly the artifact those reviews ask for.
To be direct about a claim you may hear elsewhere: this is not a way around consent law. Consent governs what you are permitted to collect no matter where the code runs. Anybody selling server-side as a workaround is selling you a problem. What it genuinely gives you is control and evidence, and both are legitimately valuable when a deal is waiting on them. The broader picture is in consent and cookie loss.
Three: your sales cycle outlives your ad platforms’ memory
This is the one nobody explains to marketing leaders, and it is the most quietly expensive of the three.
When somebody clicks a paid ad, the platform attaches a small identifier to your page address. That identifier is what allows a conversion to be credited back to that specific click. It does not last forever.
LinkedIn’s is valid for 30 days from the click and resets each time the person clicks again[2]. Google will not import a conversion uploaded more than 90 days after the associated click[3]. Microsoft suggests a 90-day retention window and states directly that storing the identifier is the advertiser’s job, not theirs[1].
In B2B SaaS, a deal routinely takes longer than 90 days to close.
So the sequence is this. The ad works. The person signs up. Four months later the deal closes. And by then the proof of which ad started it has expired, or was never saved in the first place.
That is not a reporting inconvenience. It is your paid budget being optimised against the subset of deals that happen to close quickly, which are not the same deals as the ones that matter most.
The Cheaper Fixes That Come First
Here is the part most proposals leave out, and it is the reason this article exists. Four cheaper problems account for a meaningful share of what looks like tracking loss: links that drop the campaign, forms that never pass it, two systems counting at different points, and consent set to lose more than it has to.
A meaningful share of the conversion loss I find on B2B SaaS marketing sites is not a browser problem at all. Server-side tracking would not fix it, and buying server-side tracking without fixing it first means paying for infrastructure that faithfully transmits incomplete data.
Four things, in the order they usually turn up.
Your own links are erasing the campaign. A visitor clicks the ad, lands on the page, then clicks through to the demo form. Somewhere in that second click the campaign information gets dropped, because a link on your own site was written without it. The form works. The lead arrives. The story is gone. This is a link fix.
The form never passes the campaign along. A custom form built by a developer who was not told this mattered will happily create a contact with no source attached. Nothing errors. Nobody is notified.
The two systems count at different points. Your analytics counts a page view on the thank-you screen. Your CRM counts a contact record after deduplication. They will never agree, and the difference is a definition problem rather than a data problem. The Analytics Trust Gap covers this in full.
Consent is configured to lose more than it has to. A privacy banner can be perfectly compliant and still be quietly deleting a large share of your visibility, because it was configured for the legal question and nobody checked the reporting one. These are two separate settings.
None of these requires new infrastructure. All of them are cheaper. And if you fix them and the gap between your ad platform and your CRM closes, you have just saved yourself a project.
What It Costs, Honestly
Server-side tracking carries two costs, and the second is the one that sinks projects. Hosting the server container is modest and predictable. Ownership is not: somebody has to maintain it, keep it aligned as the ad platforms change what they accept, and be able to explain it to a security reviewer.
The first is running the thing. There is a server container to host. That cost is modest, predictable and not the reason anyone regrets this decision.
There are two ways to host it, and they move that cost rather than remove it. A managed provider runs the container for you and bills you monthly, which is really a way of buying somebody else’s maintenance. Running it on your own cloud account removes the monthly fee and hands the patching, the platform changes and the quiet failures to your team instead. One version lands on an invoice. The other lands on somebody’s calendar, where it is easier to ignore and more expensive when you do.
The second is ownership. Somebody has to maintain it, keep it working as the ad platforms change what they accept, and be able to explain to a security reviewer what it does. Ad platform requirements do move: Google’s own developer documentation notes that from June 15, 2026, offline conversion uploads fail for developer tokens that have not previously used them, pushing new integrations toward a newer interface[6]. Somebody has to notice changes like that.
A server container nobody owns is worse than no server container. Before you had a gap you knew about. Now you have reporting that depends on infrastructure quietly rotting, and it will fail without telling you.
So the real question in the buying decision is not “should we do this.” It is “who owns this in nine months, by name.” If there is no answer to the second question, the honest recommendation is to wait until there is.
What Good Looks Like Afterwards
If this is done properly, three things become true, and none of them is a dashboard. The evidence a security review asks for exists in writing before anyone asks. Long-cycle deals stay attached to the campaign that started them. And the ad platforms start learning from customers rather than from form fills.
You can answer the security questionnaire without a two-week investigation, because the list of what leaves your site exists in writing.
A deal that closes in month four gets credited to the campaign that started it in month one, because the identifier was saved against the account record at signup and handed back when the deal closed. Google, Meta and Microsoft all support that pattern, and they all describe the same shape of it: keep the identifier, report the real conversion back later[5][4].
And your ad platforms start optimising toward customers rather than toward signups, because the thing you report back is the thing that actually mattered. That is the same discipline behind which events earn a place in your analytics at all.
One boundary worth being explicit about, because this category overclaims constantly. None of this will tell you what your conversion rate should be, and nobody who has not seen your traffic can tell you that either. What it does is make the number you report defensible. Whether the number is good enough is your marketing lead’s call, and it should be.
The One Question to Take Into the Next Vendor Conversation
If a supplier is proposing this to you, ask one thing before anything else, and make it about your situation rather than their technology. Which of the three situations you are in, and what they checked to conclude it. A good answer names one and describes the check. A weak answer talks about browsers in general.
Which of the three situations are we in, and what did you check to conclude that?
A good answer names one of them specifically and describes the check. A weak answer talks about browsers and privacy in general terms and moves to the diagram.
You do not need to understand the implementation to ask that question. That is the point. Not knowing which of the three you are in is the normal condition, not a gap in your competence, and it is the whole reason it is reasonable to ask somebody to find out for you.
Sources
- Microsoft Advertising (Microsoft Learn), UET and Conversion API Integration – Official documentation, dated 2026-08-04; states directly that advertisers not using the UET JavaScript are responsible for capturing and storing the click ID themselves, with a suggested 90-day retention window ↩
- LinkedIn Marketing Solutions (Microsoft Learn), Enabling Click IDs – Official documentation; the li_fat_id first-party click-ID cookie persists for 30 days from the most recent ad click ↩
- Google Ads Help, Offline Conversion Import FAQs – Official documentation stating offline conversions uploaded more than 90 days after the associated ad click will not be imported ↩
- Meta for Developers, Conversions API Get Started – Official setup documentation confirming Conversions API events use the same Pixel ID as the browser-side Pixel ↩
- Google Ads Help, About Enhanced Conversions – Official documentation describing the mechanism: first-party customer data is hashed with SHA-256 client-side or server-side before Google matches the hash against signed-in Google accounts ↩
- Google Ads API, Manage Offline Conversions – Developer documentation confirming that from June 15, 2026, UploadClickConversion API requests fail for any developer token that has not previously used offline or enhanced-conversion uploads ↩
Seeing these patterns at your company?
Book a free WebOps Diagnostic. I'll review your site before the call and share specific observations.
Book a Free Call →Frequently Asked Questions
Three tests, and you need at least one to come back yes. Is your ad platform reporting materially fewer conversions than your CRM records for the same period. Has a customer security review or your own legal team asked what data leaves your website and where it goes. Does your average deal take longer to close than the 30 to 90 day window in which the ad platforms will still accept a conversion. If all three are no, spend the money elsewhere first.
Partly, and not on its own. Some of that gap is browser blocking, which server-side addresses. A lot of it is simpler: forms that never pass the campaign along, links on your own site that drop it, and deduplication rules that count the same person differently in each system. Those are cheaper to fix and are usually the bigger share. Diagnose before you buy infrastructure.
No, and any vendor implying it is should end the conversation. Consent still governs what you are allowed to collect regardless of where the code runs. What server-side genuinely gives you is visibility and control: one place where you can see exactly what leaves your site, which is what a security reviewer or a privacy counsel actually asks for.
Two costs, and the second is the one that gets underestimated. There is hosting for the server container, which is modest. Then there is ownership: somebody has to maintain it, keep it aligned with the ad platforms' changes, and be able to explain it. A server container nobody owns is worse than no server container, because now your reporting depends on infrastructure that is silently rotting.
Mostly yes, and that is a large part of the appeal. The container itself runs separately from your product and does not touch your application code. The one place engineering usually is needed is storing the ad receipt against the account record at signup, which is a small change inside your product.
