Is Custom Loader necessary for server-side GTM?

Not always. If you mainly need payload control and multi-platform forwarding, a standard server-side setup can be enough. If you want to reduce the impact of blocking in the browser part, Custom Loader is often important.

Will Custom Loader increase data by 40%?

The specific result depends on the website, audience, ad blockers, consent, and implementation. Treat it as a hypothesis to measure, not as a guaranteed number.

Can Custom Loader violate consent?

Technically, it can send requests where it should not. That is why it must be connected to consent logic. More resilient measurement does not mean measurement without consent.

BlogMeasurement and Analytics4 min read

Custom Loader for GTM and GA4: what exactly it changes and why server-side is often not enough without it

Short answer

Server-side GTM by itself does not mean measurement avoids blocking. If the website still loads standard gtm.js from googletagmanager.com and sends the first request to a recognizable tracking endpoint, part of browser blocking can intervene before the event reaches the server. Custom Loader changes the GTM/gtag loading paths and routes them through a first-party domain or a custom path, so some blockers lose a simple pattern. It is not magic, but it is an important building block for robust hybrid measurement.

Where the standard server-side setup falls short

In a typical hybrid setup, the browser loads web GTM, GTM creates a GA4/Data event and sends it to the server-side GTM container. The server container then forwards the data. But the browser still has to load the original script and create the first event. If an extension blocks GTM right at the start, the server receives nothing.

That is why some server-side tracking implementations look nice in a diagram but improve measurement only to a limited extent in reality. They added a server container but did not change the most vulnerable part: loading and the first browser request.

What Custom Loader does

Custom Loader changes the URL through which the GTM or gtag library is loaded and often routes it through your own domain or custom path. Instead of an obvious request to a known tracking domain, the website can call a first-party endpoint that then serves the loader. From an implementation perspective, script src, server URL, and often the paths for collect requests change.

Stape describes Custom GTM/GA4 Loader as a solution that changes loading paths for gtm.js and gtag.js and helps with ad blockers and ITP. The practical benefit depends on the website, extensions, CSP, consent, DNS configuration, and whether events are truly sent through the server endpoint.

What Custom Loader does not solve

It does not solve a bad dataLayer. It does not solve a click trigger instead of a successful form submission. It does not solve duplicate purchase events. It does not solve a missing event_id for Meta CAPI. It does not solve legal consent. It does not solve the backend truth of whether an order actually happened.

It also does not bypass every ad blocker. Some tools block by domain, others by path, others by script behavior. Custom Loader reduces the risk of simple blocking, but it is not a guarantee of 100% measurement.

Implementation checklist

Prepare the server-side GTM endpoint on your own subdomain, for example metrics.example.cz. 2. Configure DNS and SSL. 3. Set the server container URL in the GTM/gtag configuration. 4. Implement Custom Loader according to the selected provider. 5. Verify that gtm.js/gtag.js and collect requests are not going through the old path. 6. Test consent. 7. Test ad blocker scenarios.

The Network panel must make it clear what is loaded from where. It is not enough to see that a GA4 event arrived. You have to know whether it went through the standard browser endpoint, the server endpoint, or the Custom Loader path.

How to measure the benefit

Before and after deployment, compare the number of server requests, GA4 events, Meta Test Events, Google Ads conversions, the share of cookieless/denied signals, the difference versus backend orders or CRM, and behavior in browsers with ad blockers. Do not evaluate only that "the number of events increased." Additional events can be duplicates.

A good test is based on a controlled set of scenarios: clean browser, Chrome with an ad blocker, Safari, mobile, first visit without a consent cookie, acceptance, rejection, purchase/lead. Without a test matrix, you do not know what Custom Loader actually improved.

FAQ

Frequently Asked Questions

server-side measurement architecture sGTM webhooks

Three server-side measurement architectures: browser to sGTM, Data Client, and backend webhooks

Server-side measurement is not a single implementation. The three most common architectures are hybrid browser to sGTM through GA4 or Data Client, direct server events from backend or CRM, and a combination of both.

Read ArticleRead Article