By default, the GA4 client in sGTM listens on /g/collect (and the legacy /collect). Both paths are well-known and increasingly blocked by ad blockers, even on a first-party domain. The fix is to add a custom path that the client also accepts.

In the GA4 client settings

Open your GA4 client and find the "Activation request path" field. Change it from "Default" to "Default + Custom paths." A new field appears asking for the custom path. Set it to something forgettable: /api/m, /_data, /track are reasonable. Avoid anything with the letters ga, analytics, or collect in them.

In the client GTM container

Update your GA4 configuration tag to send to the new path. The setting is "Send to server container" with a path override. Set the path to your chosen value.

For events fired via gtag() directly (not through GTM), set the transport URL on the gtag config call:

gtag('config', 'G-XXXXXXX', {
  transport_url: 'https://data.example.com/api/m'
});

Verify the new path works

curl -X POST 'https://data.example.com/api/m' \
  -H 'X-Gtm-Server-Preview: PASTE_HEADER' \
  -d 'v=2&tid=G-XXXXXXX&en=test'

The event should appear in your preview pane. If it does not, the most likely cause is the client settings did not save (sGTM is fussy about workspace publishes), or the path conflicts with another client's path. Check the activation rules.

Keep the default path enabled

Do not remove the default path entirely. Some Google properties (Optimize, Looker Studio) still send hits to the standard endpoint and ignore your custom transport URL. Keep both active so you do not break those.

If you want to push further on ad-blocker resistance, the custom domain on top of a custom path is the combination that works best.