By default, sGTM's GA4 client listens on /g/collect. The path is well-known to ad blockers. Adding a custom path moves your hits onto an endpoint that no blocklist recognises by default. The trade-off is that some Google products will not respect the custom path and will continue hitting the standard endpoint.

When custom paths help

• Your audience uses ad blockers heavily (developer-focused B2B, news/media, EU consumer with strong privacy awareness).
• You have already moved to a custom domain and want the additional layer of resistance.
• You can update your gtag config call to use the custom transport_url.

When custom paths do not help

• Your audience does not use ad blockers (Asian markets, older demographics, certain B2B verticals).
• You rely on Google Optimize, Looker Studio, or Search Console integrations that hardcode the standard endpoint.
• You have a CMP that hardcodes calls to the standard GA4 endpoint and does not support transport_url.

The hybrid pattern

Configure your GA4 client to listen on both the default path AND a custom path. In your client GTM, send hits to the custom path. Anything that bypasses GTM and hits the default endpoint still works. Anything ad-blocked at the standard path is recovered via the custom path.

In the GA4 client config, set "Activation request path" to "Default + Custom paths" and add your custom path in the field below. The exact configuration steps are in a separate post.

Picking a path

Boring is better. /api/m, /_track, /data all blend in with normal API endpoints. Avoid anything containing analytics, collect, ga, or gtm; those are the strings ad blockers scan for.

Measuring the lift

After flipping to a custom path, watch your event volume for two weeks. Most teams see a 5-15 percent lift in event count. The lift is concentrated in the audience segments where ad blocker usage was already high. If you see no lift, your audience was not blocked at the path level (your custom domain was already doing the work).