Google documented a direct/none attribution spike in May 2024, confirmed across a GA4 support thread with hundreds of affected properties: session_start events were being excluded by the tagging server before consent update events had fired on pages using server-side GTM (sGTM) with Consent Mode v2. Every opted-in session that hit that timing fault was attributed to Direct. Modeled attribution was unavailable for the rest. The fix looked simple in retrospect, a sequencing change, but the practitioners who found it first had to rule out five other plausible causes before landing on the right one.
That sequence matters because sGTM attribution failures rarely announce themselves clearly. They look like rising direct/none traffic, or more unassigned conversions, or a ROAS drop that doesn't match spend changes. The actual failure is usually three or four layers deep, and fixing the most visible symptom rarely fixes the underlying cause.
This piece maps the full failure chain: what breaks, in what order, why each failure makes the next one harder to diagnose, and what a working remediation sequence looks like as of September 21, 2026.
Why sGTM often makes attribution worse before it makes it better
The vendor framing positions server-side GTM as a straightforward attribution improvement: first-party data, ad blocker bypass, better signal fidelity. The actual experience for many teams is the opposite, at least initially. Attribution gets worse after deployment, sometimes significantly.
This is not a knock on the architecture. sGTM, correctly deployed, and maintained, does recover conversion signal. Amplio Data's real-world data from May 2026 puts the realistic recovery at 12 to 18 percent on top of a Consent Mode baseline that already works correctly. But that baseline assumption is where most implementations fail. They ship sGTM on top of a Consent Mode setup that has its own timing problems, a tag firing order that routes hits incorrectly, and a data stream that was never fully consolidated. The sGTM layer compounds every existing gap rather than resolving it.
Three structural misunderstandings drive most of this:
sGTM is not a drop-in replacement for client-side tracking. The architecture requires both containers running in coordination. The client-side container must fire first to read UTM parameters, session context, and attribution data from the URL and local state, then pass that data to the server container. UTM parameters are not available server-side. They live in the browser URL at the moment the page loads. A pure server-side deployment has no mechanism to read them, which means channel attribution for any paid traffic is simply gone. This is a structural requirement, not a configuration preference.
The improvement requires correct baseline configuration. Ad blocker bypass is real but partial. Routing hits through a first-party subdomain avoids most filter lists, but sophisticated blockers inspect URL paths rather than just hostnames. Some percentage of blocked requests will still be blocked. The bypass benefit is real on balance, as of Q2 2025 approximately 29.5% of internet users block ads in some form per Statista, but treating it as absolute will lead to inflated recovery expectations.
sGTM has no built-in alerting. SR Analytics' 2025 analysis found that 73% of GA4 implementations have silent misconfigurations. sGTM sits inside that population. SSL certificate expiry, plugin conflicts, and misconfigured routing rules drop attribution data with no error messages. Tags appear to fire. Reports look plausible. The gap only becomes visible when someone compares backend revenue data against reported conversions and finds the numbers are systematically off.
The five failure modes that compound into unassigned and direct/none traffic
These failures are sequential. Each one degrades the attribution layer that the next one depends on. Fixing failure three without fixing failure one produces confusing results because the upstream context is still corrupted.
1. tag firing order corrupts session context
In a correctly configured sGTM deployment, the GA4 configuration tag must fire before any event tags. If event tags fire first, those hits route to google-analytics.com directly rather than to the server container endpoint. No error is thrown. GA4 receives the data. But it arrives through the wrong path, bypassing the server container entirely, and with it any enrichment, filtering, or identity resolution the server container was supposed to apply.
The diagnostic signal is a mismatch between the volume of events your server container logs and the volume GA4 reports. If GA4 shows more events than your server container processed, tag firing order is the likely cause.
2. missing UTM passthrough loses channel source
When the hybrid architecture is set up correctly (client-side container fires first), the client-side container is responsible for reading UTM parameters from the URL, and passing them explicitly to the server container as part of the event payload. If that passthrough is not configured, the server container receives the event without source, or medium data.
GA4 then attributes the session using whatever fallback is available. If a gclid or dclid is present and consent allows it, the click ID takes precedence. If not, the session falls to Direct. This is not a failure of the server container; it is a missing data layer contract between the client and server containers. The fix is in the client-side configuration, not the server-side one.
3. split data streams inflate unassigned
When some tags route through the sGTM endpoint and others send directly to Google Analytics (a hardcoded gtag in a CMS template is the common culprit), GA4 receives events from two separate client identifiers for the same user. The session context does not merge cleanly. One stream has attribution data; the other does not. The result is inflated unassigned traffic and session fragmentation that makes funnel analysis unreliable.
Analytics Mania's January 2026 analysis identified a related configuration choice that compounds this: the default "Server Managed" cookie identification option in sGTM tends to produce more unassigned traffic than the "JavaScript Managed" setting. This has not been confirmed as an official Google position as of September 21, 2026, but the practical finding is consistent with what the split-stream failure mode predicts. Verify this against your current sGTM release before making it a configuration standard.
4. Consent Mode v2 timing destroys modeled attribution
Advanced Consent Mode is supposed to preserve attribution for non-consenting users through modeled data. GA4 sends cookieless pings for opted-out sessions and uses aggregate patterns to model the conversion paths those users would have taken. The mechanism works, but it depends on session_start events being included in that ping data.
The May 2024 spike documented in the GA4 support thread exposed what happens when the server-side container excludes session_start: the consent ping carries no session context, modeled attribution has nothing to work with, and every opted-in session that was processed before the consent update event fired gets attributed to Direct. Bounteous confirmed in July 2025 that this interplay between Consent Mode v2 enforcement, sGTM transformations, and GA4 modeled data is still a live debugging area. The behavior is not fully predictable across all setups, which means it needs explicit testing rather than assumed correctness.
Since late 2023, a growing pattern across GA4 properties using Advanced Consent Mode has been spikes in "not set" traffic source/medium dimensions, accompanied by drops in first_visit, session_start, and page_view event counts. This is the consent timing failure in its most common form. If you are seeing it, the cause is usually that consent is denied by default on first visit, and session_start is being excluded before the consent update fires.
5. misconfigured identity resolution creates attribution black holes
When the sGTM setup processes events for users whose client identifier has not been resolved consistently, GA4 cannot stitch the session together. Events arrive, but they arrive as orphaned hits with no session context to attach to. These show up as direct/none or (not set) depending on which dimension you are looking at.
This failure mode became more common after sGTM v3.2.0's changes to GA4 client behavior (see the next section). Custom templates that handled identity resolution using pre-v3.2.0 internals may now produce client identifiers that do not match what GA4 expects, creating an attribution black hole that looks exactly like organic direct traffic.
How sGTM v3.2.0 invalidated assumptions in existing implementations
sGTM v3.2.0, released September 2025, made two changes significant enough to silently break existing implementations:
The GA4 client no longer auto-loads gtag.js. Before v3.2.0, the GA4 client in the server container handled loading the Google JavaScript library as part of its normal initialization. After v3.2.0, all Google JS libraries load via the Web Container Client. Any custom template that assumed gtag.js was pre-loaded, or that read internal state set by the auto-load process, now fails silently. The template still executes. The tag still fires. But the data it produces is incorrect because the context it expected to exist is not there.
The base image moved to Node.js 24. This affects custom templates that used Node.js APIs directly or relied on specific runtime behavior from earlier Node versions. The practical impact varies by implementation, but any template that was not retested post-v3.2.0 should be considered untested against current behavior.
The combined effect is that many sGTM deployments that were working correctly before September 2025 began producing degraded attribution data afterward, with no alerts, and no obvious error state. If your unassigned or direct/none traffic increased around October or November 2025, v3.2.0's release is a plausible cause worth investigating before looking elsewhere.
GA4's new attribution waterfall, introduced in early 2025, adds an "Aggregate Identifiers" fallback layer that sits between gclid/dclid, and manual UTM parameters. When click IDs are unavailable (typically because consent was not granted), GA4 now attempts to use aggregated campaign identifiers before falling back to UTMs. This creates a new dependency: if your sGTM setup was passing UTMs as the primary non-consent attribution signal, the waterfall now routes through a layer you may not have accounted for. The upstream architecture may be working correctly but producing unexpected attribution results because the waterfall logic changed around it.
The diagnostic layer: using gA4's 2025 alert tools to locate the break
GA4 rolled out a set of diagnostic alerts in 2025 that surface specific failure signatures. These are the starting points for a structured audit, not the end of one. Each alert identifies a category of failure; the mechanism has to be traced manually.
Missing session_start event. This alert fires when GA4 detects sessions that do not include a session_start event. In a sGTM setup, this is almost always a Consent Mode timing problem: the tagging server processed events before the consent update fired, excluded session_start, and the session context was lost. Start by checking your Consent Mode implementation sequence, then verify that session_start is not being filtered, or excluded at the server container level.
Missing UTM parameter. This alert flags high volumes of "(not set)" for source/medium dimensions. In an sGTM setup, trace this to the client-to-server UTM passthrough first. Check whether the client-side container is explicitly reading UTM parameters and including them in the event payload sent to the server container. Then check whether those parameters survive server-side transformations before being forwarded to GA4.
Spammy user-ID. This alert flags potential overattribution to Direct, which often signals that the identity resolution layer is producing a single, or small set of client identifiers being applied to many users. In a post-v3.2.0 context, verify that your custom templates are producing correctly scoped client identifiers under the new runtime.
Alongside these GA4 alerts, check your server container logs directly. Compare event volume processed by the server container against event volume reported in GA4. A persistent gap where GA4 reports more events than the server container processed means some tags are bypassing the server container entirely (tag firing order problem). A gap where the server container processed more events than GA4 reports means events are being dropped or malformed before GA4 accepts them (likely an identity resolution or schema problem).
For a structured workflow around these diagnostic signals, the GA4 and GTM audit process is the starting point. The alerts surface the entry point; the audit maps the full chain.
The remediation sequence: what to fix, in what order, and what recovery to realistically expect
Order matters here. Fixing issues out of sequence produces confusing results because downstream failures depend on upstream context. Fix in this order:
Step 1: Audit and consolidate the data stream.
Before touching Consent Mode or identity resolution, eliminate the split data stream problem. Find every place that sends data directly to Google Analytics outside the sGTM endpoint: hardcoded gtag snippets, CMS plugins, third-party tools with their own GA4 integrations. Disable or route them through the server container. A split stream means you are analyzing corrupted data throughout the rest of the remediation process.
Step 2: Fix tag firing order.
Confirm the GA4 configuration tag has firing priority over all event tags in the client-side container. In GTM, use tag sequencing, or trigger conditions to enforce this. Verify by checking server container logs immediately after: events should now route through the server container rather than directly to google-analytics.com.
Step 3: Audit the client-to-server UTM passthrough.
With a clean data stream and correct firing order, trace the UTM parameter path. Confirm the client-side container reads UTM parameters on page load, stores them (typically in a first-party cookie, or data layer variable), and includes them explicitly in the event payload sent to the server container. Confirm the server container includes them in the GA4 event it forwards. Use GA4's DebugView to verify source/medium values appear on test sessions from UTM-tagged URLs.
Step 4: Repair Consent Mode v2 sequencing.
Audit the sequence of events on a first-page-load from a new user. The consent update event must fire before session_start is processed by the server container. If your Consent Mode banner fires asynchronously after the initial page load events, session_start may have already been processed. Solutions here depend on your CMP and container setup, but the common fix is either delaying server-side processing of session_start until the consent update is received, or configuring the CMP to fire the consent update synchronously before other tags.
Verify with GA4's "Missing session_start event" alert: it should clear within 24 to 48 hours of a correct fix, given sufficient traffic volume.
Step 5: Retest all custom templates against v3.2.0.
After the foundational fixes above are in place, run each custom template in preview mode against a controlled test environment. Verify that client identifiers are correctly scoped, that gtag.js-dependent functionality has been migrated to the Web Container Client pattern, and that the event payloads produced match what the template documentation describes. This is the step most teams skip, and it is the step that leaves v3.2.0 breakage undetected.
Step 6: Check the "JavaScript Managed" identification setting.
With consolidated data stream, correct firing order, and verified UTM passthrough, compare unassigned traffic volume under "Server Managed" versus "JavaScript Managed" cookie identification. Analytics Mania's January 2026 finding, that "JavaScript Managed" produces less unassigned traffic in practice, is contested but consistent with the architectural reasoning. Test this on your specific setup; do not assume the default is optimal.
Step 7: Run a Meta CAPI event match quality check.
This step is outside GA4 but belongs in the same audit cycle. If you are running Meta CAPI alongside sGTM (the common configuration for paid social attribution), the same data layer contract problems that break GA4 attribution also degrade CAPI event match quality (EMQ). A low EMQ score (below 6.0 in Meta's scoring) means your server-side conversion signals are not being matched to Meta users reliably, which affects campaign optimization, and reported ROAS independently of what GA4 shows. The server-side GTM and CAPI implementation process covers the EMQ diagnostic in detail.
What recovery looks like realistically
Amplio Data's May 2026 data on real-world sGTM installations is the most grounded reference available: 12 to 18 percent conversion recovery on top of a Consent Mode baseline that already works correctly. Tag Specialist's April 2026 analysis puts the combined recovery from a v3.2.0 upgrade, Consent Mode v2 audit, and Meta CAPI EMQ fix at 10 to 25 percent more attributable conversions.
Both ranges are implementation-dependent. The upper end requires a baseline where Consent Mode was previously misconfigured (which is common) and where Meta CAPI EMQ was below 6.0 (also common). If your baseline was already functioning correctly, recovery will be at the lower end.
Numbers above 25 percent, frequently cited in vendor materials, typically reflect fixing pre-existing broken tracking rather than a net-new sGTM benefit. If a vendor is showing you a 40 percent lift, ask what the baseline implementation state was. If the baseline had a split data stream, no UTM passthrough, and a Consent Mode timing fault, the 40 percent is real but not attributable to sGTM alone.
The Measurement Architecture Assessment includes a signal layer diagnostic that maps exactly these failure modes before any implementation work begins. If you are not certain which of the five failure modes are active in your current setup, that is the starting point.
The failure cascade described here, tag firing order corrupting session context, missing UTM passthrough losing channel source, split streams inflating unassigned, Consent Mode timing breaking modeled attribution, and v3.2.0 silently invalidating custom templates, is not a series of independent problems. Each one degrades the attribution context the next layer depends on. Fixing one in isolation produces improvement that is hard to measure and impossible to trust, because the remaining failures are still distorting the numbers you are using to evaluate the fix. The remediation sequence above exists for that reason: fix upstream context first, then verify downstream recovery.