Open your CRM and look at where your leads say they came from. A large share will read "direct", "none" or simply blank, and in the B2B accounts we audit that bucket runs to roughly one in five inbound leads, most of it paid and organic wearing the wrong label. Almost none of those people fell from the sky. The chain that was supposed to carry the source broke somewhere between the click and the contact record, and every budget decision made on top of that data inherits the lie. Here is where it leaks, why last-click flatters the wrong channels, what moving to the server genuinely recovers, and where the fix pays back.
Your 'direct' bucket is mostly misfiled paid, and here is the mechanism
A lead tagged "direct", "none" or blank rarely means the buyer typed your URL from memory. It means the link between the first click and the conversion has snapped. The failure is rarely one big break; it is a series of small, plausible ones that compound. A paid click arrives with its identifier in the URL, the visitor moves to a second page, and the identifier is gone because nothing persisted it. Consent is handled in a way that blocks measurement entirely rather than recording what it is allowed to. A visitor hops from one of your own pages to another and the system logs it as a fresh referral from your own website. The enquiry form, finally, captures a name and an email and nothing about the journey that led there.
The mechanism underneath is boring and specific. Apple's Intelligent Tracking Prevention caps anything client-side JavaScript writes to the browser, cookies and local storage alike, at seven days, and shorter where link decoration is involved. Moving the click ID from a cookie into local storage does not escape it; the cap is on the browser store, not the format. Firefox blocks third-party cookies by default. If your forms track client-side, and most B2B sites still do, a buyer who clicks a Tuesday ad and returns the following Monday to convert arrives with an expired cookie. The revenue is real. The source is gone. In long B2B cycles, where the gap between first touch and form fill runs to days or weeks, this is not an edge case. It is the median journey.
If the largest channel in your CRM is "direct", that is not a channel. It is a measurement failure wearing one.
Every misfiled lead flatters one channel and starves another
Every misfiled conversion does two things at once: it flatters the channel that inherits the credit and starves the one that earned it. Paid media reads weaker than it is because assisted conversions collapse into "direct". Brand and organic absorb sales they never generated. You then scale the wrong campaigns with confidence, because the dashboard agrees with you.
Last-click attribution makes it worse. Even when a source is captured, most setups record only the last click, which credits whatever was nearest the finish line: brand searches, retargeting, the final email. It systematically starves the channels that created the demand in the first place, the discovery and the first unbranded search weeks earlier. Optimise to last-click and you will defund the top of your own funnel and call it efficiency, right up until the pipeline thins and no one can say why. Honest attribution carries both ends of the journey: first touch, which tells you what created the opportunity, and last touch, which tells you what closed it. Two different questions, both worth answering, neither answered by a single blank field.
Server-side recovers blocked events, not declined consent
The standard advice stops at "move tracking to the server and the problem goes away". That is the part vendors sell, and the part that is wrong. Server-side collection is not a loophole around ITP.
Here is what it does fix. Instead of the browser firing events straight to Google or Meta, where ad blockers and privacy settings can drop or truncate them, your site sends events to a container on your own domain, which forwards clean data to each platform. That recovers the leads lost to script blocking, ad-platform payload limits, and the reconciliation gaps between analytics, ad platforms and CRM. Google's enhanced conversions, which hash first-party data such as the email a buyer types on your form and match it against logged-in accounts, run more reliably through this path than through the browser alone.
Now the limit a specialist will hold you to. A server-side Google Tag Manager container still reads a first-party cookie, and if that cookie was written client-side with document.cookie, ITP still caps it at seven days. Server-side is only a genuine extension of the window when the cookie is set server-side as an HTTP-only cookie in the response header, which Safari does not truncate the same way. This is the distinction that separates a working rebuild from an expensive one that changes nothing.
Consent is the harder wall. Moving collection to the server does not move the legal basis. If a user declines, you still cannot lawfully track them, wherever the tag fires. Google's Consent Mode does not change this. It reads the consent-state signals, analytics_storage and ad_storage, and where consent is denied it stops setting cookies and sends cookieless pings that feed modelled conversions. Those are estimates, not observed events: useful for aggregate trend, useless for attributing a specific named lead in your CRM.
Measure the ceiling before you spend
Start by measuring, not building. Pull the share of CRM leads tagged "direct", "none" or blank across the last two quarters. Sit it next to your consent decline rate, and read that rate from your consent management platform's own logs, not from GA4. Consent Mode models the denied traffic, so GA4 hands you a smoothed estimate; your CMP records the raw accept and decline events before any modelling touches them. That log is your true floor of unattributable leads, the part no architecture recovers. The first number is your problem, the second is the part server-side can never reach, and the gap between them is what you are actually buying.
Then build in order. Stand up a server-side Google Tag Manager container, self-hosted or managed through a provider such as Stape, and route your highest-value form events through it first. The config step that actually moves the cookie off document.cookie: in the GA4 client of your server container, enable first-party identification. That writes an FPID cookie through the Set-Cookie response header with the HttpOnly attribute, rather than through browser JavaScript. Miss this toggle and you inherit the seven-day cap you paid to escape. One caveat undoes all of it: the HttpOnly escape only holds on a genuine first-party origin, a container served from your own infrastructure on a real subdomain. If your container sits on a subdomain CNAME'd to a Google or vendor host, Safari's CNAME-cloaking defence treats those Set-Cookie headers as third-party and caps them at seven days too, HttpOnly or not. Serve the container from first-party infrastructure, or you rebuild the ceiling in a place you can no longer see it.
What the fix actually looks like
None of the server-side work replaces the on-page capture that reads the click journey and writes it onto the form the buyer submits. That is the step that lands a permanent, attributed record in your CRM the moment someone converts, beyond the reach of any cookie expiry, because once first and last touch are hidden fields on a Zoho or HubSpot record they are yours for good. Server-side does not compete with that layer; it keeps the browser remembering the first touch long enough to reach the form fill, so the record that lands is complete. The capture layer and the server-side window are one system, not a choice between them.
So the remedy is a deliberate, consent-first data layer, built once and properly. It captures the click identifiers and the campaign parameters into durable storage that survives navigation, derives first touch, last touch and channel, and injects all of it into your forms as hidden fields so it lands in the CRM with the lead rather than in a report nobody reconciles. It is hardened for the awkward realities too: platforms with no way to pass an identifier through the URL, back-forward cache, sister domains, the slow disappearance of third-party cookies. This is the substance of a data and automation engagement, and it can be delivered on its own, even where the media is run elsewhere. It is exactly the work behind one of the practice's case studies: rebuilding click-to-CRM attribution across a multi-domain group so that "direct" stopped being the biggest line in the report.
The payoff is a number you can trust
The payoff is narrow and real. You will not recover the leads that declined consent, and you should stop pretending you can. You will recover enough of the consented, long-cycle journeys to see which campaigns and keywords actually produce paid leads, and to stop funding channels that only look strong because they inherited credit they never earned. Every enquiry then reaches the CRM carrying its full journey, and the next budget decision rests on numbers the business can trust rather than the channel that happened to be standing nearest the door. Until you move the job to the server, and set the cookie correctly when you do, your CRM will keep telling you a comfortable story and your budget will keep following it.
