Custom Loader

Updated August 2026 · 7 min read

Serve the Google Tag Manager loader from your own domain at an unguessable path, so requests to it no longer match the patterns content blockers look for.

What Custom Loader does

A regular Google Tag Manager installation loads its script from googletagmanager.com/gtm.js?id=GTM-XXXXXXX. That hostname, that path and that query string are exactly what content blockers match on, so the script never loads for a share of your visitors — and when the loader never loads, nothing downstream of it runs either.

Custom Loader serves the same loader from your own tagging domain, at a randomly generated path, and without the container ID on the URL. A request for https://tags.example.com/a7f3k9x2.js does not match a rule written for googletagmanager.com/gtm.js.

How the first-party loader works

When you enable Custom Loader, TagVolt generates an opaque path segment and configures your container's proxy to serve the loader there. The proxy rewrites the request to your server-side container's /gtm.js endpoint, supplying the container ID itself.

What the browser requests

# before
https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX

# with Custom Loader
https://tags.example.com/a7f3k9x2.js

Two things change. The hostname is yours, so the request is first-party. And the container ID never appears in the browser-facing URL — it is added server-side, so the URL carries no recognisable Google Tag Manager shape at all.

The generated path is stable once created. It does not rotate, and you do not choose it.

Requirements

A container with a serving domain — either its TagVolt subdomain or a custom domain that is already active.
Your web Google Tag Manager container ID, in the form GTM-XXXXXXX.
Permission to edit the container's Power-Ups, and access to edit your site's HTML.

This is your web container ID, not your server container ID. Custom Loader serves the loader that runs in the browser. Entering a server container ID will not produce a working installation.

Select a serving domain

Open your container, go to the Power-Ups tab and choose Custom Loader. Pick a domain from the list. Only domains that already serve this container appear there.

A custom domain is the stronger choice: a subdomain of your own site is first-party in the fullest sense, and it is not a hostname that appears on shared blocklists.

Enter the Web GTM container ID

Enter the ID exactly as Google Tag Manager shows it. It is validated before anything is saved — if the format is wrong you will see:

Validation message

Enter a valid web GTM ID (e.g. GTM-XXXXXXX)

Save the configuration. TagVolt confirms with Custom Loader enabled, and generates your loader path and the two snippets below.

Install the head snippet

The head snippet replaces the script half of your existing Google Tag Manager installation. It belongs as high in <head> as you can put it.

Install the body fallback

The body snippet is the <noscript> half, and belongs immediately after the opening <body> tag. Install both — they are two halves of one installation, exactly as they are in a regular Google Tag Manager setup.

Remove the previous GTM installation

The configuration screen states this directly:

Remove your existing GTM snippet first

Leaving the old snippet in place means the browser loads the container twice — once from the blockable URL and once from yours. That produces duplicate events for visitors without a blocker, which is worse than the problem you started with.

Remove the old snippet and install the new one in the same deployment. A gap in either direction means either duplicated events or no events.

Verify the loader

Press Check now on the Custom Loader panel to probe your live loader URL immediately.

You can also confirm it yourself: load your site with the browser's network panel open and look for a request to your loader path. It should return 200 with a JavaScript content type.

A response only counts as healthy when it is an HTTP 200, carries a JavaScript content type, has a body, and is not larger than the permitted maximum. An HTML error page served at the loader path fails the check even though it returns 200, because it is not JavaScript.

Health Watch

Custom Loader is re-checked automatically. The in-app help describes it as:

We automatically re-check your live loader every few hours and alert you (bell + email) the moment it stops responding — so you never lose data silently. You can also check it right now.

Concretely, the sweep runs about every six hours and re-fetches every enabled loader. Each check makes up to three attempts, spaced a few seconds apart, with a ten-second timeout each, so a momentary blip does not raise an alarm. Only a failure confirmed across those attempts marks the loader unhealthy.

This matters because a broken loader is silent. Your site keeps working, your pages keep loading, and your data simply stops — often after an unrelated site deployment drops the snippet.

Health alerts

When a loader is confirmed down, TagVolt notifies the workspace's owners and administrators in two places: the in-app notifications bell, and email. When a later check succeeds again, the alert state clears and a recovery notification is sent.

Change the configuration safely

Saving a new domain or container ID updates the existing configuration in place and issues fresh snippets — TagVolt confirms with Custom Loader updated. Because the snippets change, treat a reconfiguration exactly like the first install: update your site with the new snippets.

Disable Custom Loader

Disabling turns the Power-Up off and discards the generated snippets.

Restore your regular Google Tag Manager snippet before you disable, or as part of the same change. Once Custom Loader is off, the loader path stops being served — a site still pointing at it loads nothing, and all tag collection stops.

Limitations

This is not immunity from blocking. Custom Loader changes what the loader request looks like. It does not disguise every request your tags make afterwards. Requests that a browser makes later to collection endpoints keep their own recognisable shapes, and can still be matched.
It does not change consent. Custom Loader is a delivery mechanism. Whatever your consent tooling permitted before, it permits now; whatever it blocked, it still blocks. Enabling this Power-Up is not a lawful basis for collecting anything you could not collect already.
Your site must be updated. No configuration change in TagVolt affects a visitor until the new snippets are actually deployed on your site.
One path per container. The generated path is fixed for the life of the configuration.

Troubleshooting

The loader URL returns 404. The Power-Up is disabled, or the domain you selected is no longer serving this container. Re-open the panel and confirm both.

The loader returns 200 but Health Watch says it is unhealthy. The response is reaching your proxy but is not JavaScript — usually an HTML error or interstitial page. Open the URL directly and look at what actually comes back.

Events doubled after installing. The old Google Tag Manager snippet is still on the page. Remove it.

Nothing is collected after installing. Check that both the head and body snippets were installed, and that the old snippet's removal did not also remove something else your site depended on. Then work through Events not showing up.

The domain is not in the dropdown. It is not an active serving domain for this container yet. Finish adding and verifying it first.

FAQ

Does Custom Loader replace my existing GTM snippet?

Yes. The two snippets it generates replace your current Google Tag Manager snippet entirely. Both must be installed, and the old one must be removed.

Should I enter my web or server GTM container ID?

The web container ID — the one in the form GTM-XXXXXXX that loads in the browser. Custom Loader serves the browser-side loader.

Why are there separate head and body snippets?

For the same reason regular Google Tag Manager has two: the head snippet loads the container, and the body snippet is the <noscript> fallback. Custom Loader mirrors that structure so the installation behaves the way your existing setup did.

Can Custom Loader bypass every ad blocker?

No, and nothing can. It removes the specific, widely-matched signature of the default loader URL. Requests made later by your tags still have their own patterns, and blocking tools change constantly. Treat it as removing one large, well-known failure point rather than as a guarantee.

Does Custom Loader override visitor consent?

No. It changes where the loader is served from, not whether tags are permitted to run. Your consent configuration continues to decide that.

How does Health Watch know the loader is broken?

It fetches the live URL on a schedule and checks that the response is an HTTP 200 with a JavaScript content type and a real body. It retries a few times before concluding anything, so a brief outage does not trigger an alert.

What happens when the loader becomes unhealthy?

Owners and administrators get a notification in the bell menu and an email. When a later check passes, the state clears and a recovery notice is sent.

What happens if I disable Custom Loader?

The loader path stops being served immediately. Any site still referencing it will load no container at all, so restore your regular Google Tag Manager snippet as part of the same change.

Was this helpful?