Attach the Tagging Endpoint to Your Custom Domain

This step attaches a custom subdomain (e.g. m.example.com) to your Cloud Run tagging service so first-party event traffic flows through your domain instead of a generic *.run.app URL. Browsers treat events to a first-party subdomain as same-site, which keeps cookies and storage available — that's the whole point of server-side tagging.

Only the tagging service needs a custom domain. The preview service stays on *.run.app because GTM Preview connects to it through GTM's own UI and doesn't need first-party hosting. Activating LOCKS the primary GA4 property and GTM web container for this setup — to use a different GA4 or GTM later, archive this setup and start a new one. After Activate, the tagging endpoint URL is also pushed into the GTM server container's tagging-server URL so the GA4 client knows to expect requests at the new domain.

Not covered on this page: deploying Cloud Run services (Tagging Services), the GTM server container itself (GTM Containers), or DNS provider-specific instructions (consult your provider's docs for adding CNAME records).

Before you start

• Complete Tagging Services — the tagging service must be bound and the Step 3 runtime checks must be green.
• Have access to your domain's DNS settings (Cloudflare, Route 53, Google Domains, your registrar's control panel, etc.).
• The subdomain must share the same registrable root (eTLD+1) as your project's domain. m.brand.com works for project domain brand.com; m.different-brand.com does not.

Decision record

Once a subdomain is saved, the page surfaces a Selected tagging endpoint decision record above the steps with the custom domain, the bound tagging service, the current Cloud Run domain mapping status, DNS state, and the requirement-check rollup.

1 Which Subdomain Should Host First-Party Events?

Step 1 uses a split input: you type the prefix on the left and the page appends .<your-domain> on the right so the assembled subdomain is always on the same root as your project. The prefix pre-fills as m on a fresh project. Common alternatives: m, c, s, sst, stream. Avoid labels that ad blockers commonly filter (collect, tracking, analytics, pixel, stats) — events to those subdomains will be dropped at the browser before they reach Cloud Run.

Type your prefix and click Save. Save stays disabled until the prefix differs from what is already saved. The form posts the assembled custom_domain hidden field; on success the step re-renders with the new value as the selected subdomain.

Constraints (validated server-side):

• Must be a real subdomain (must contain a dot, must not be the root domain itself).
• Must share the same eTLD+1 as your project's domain — m.brand.com works for project brand.com or shop.brand.com, but m.different-brand.com does not.
• No https:// prefix, no spaces, no slashes — just the bare prefix label (because the suffix is added automatically).

2 Point Your Subdomain at Google's Edge

Step 2 stays locked until Step 1 has saved a subdomain. Once unlocked, the page shows the exact DNS record you need to create plus a schematic that highlights which pieces of the path are configured.

Create the DNS record

Add a CNAME record at your DNS provider:

The exact UI varies by provider. A short list of where the CNAME setting lives on the common ones:

• Cloudflare: Websites → your zone → DNS → Records → Add record. Set Type to CNAME. Set Proxy status to "DNS only" (grey cloud, not orange). A proxied record breaks Google's certificate provisioning.
• Route 53: Hosted zones → your zone → Create record. Record type CNAME. Routing policy Simple. TTL 300.
• Google Domains / Cloud Domains: DNS → Custom records → Manage custom records → Create new record. Type CNAME. Name = your prefix. Data = ghs.googlehosted.com.
• GoDaddy: My products → Domain → DNS → Add → CNAME. Host = your prefix. Points to = ghs.googlehosted.com.
• Namecheap: Domain List → Manage → Advanced DNS → Add New Record → CNAME Record. Host = your prefix. Target = ghs.googlehosted.com.
• Other registrars / DNS providers: look for the DNS / Records / Zone Editor screen and add a CNAME for your prefix that points to ghs.googlehosted.com. (mind the trailing dot).

After saving the record, come back to the app and click Test DNS. The result strip next to the button reports pass/fail with the underlying message; the status pill above flips between Pending, Not pointing (DNS doesn't resolve to ghs.googlehosted.com yet), and DNS verified. DNS propagation is usually 1–5 minutes but can take up to 24 hours depending on your provider's TTL.

3 Map the Subdomain to the Tagging Service

Step 3 stays locked until a subdomain is saved in Step 1; the Activate button stays disabled until the GCP project, tagging service, and GTM server container are also bound. The step shows two inline status rows ("Domain mapping" and "GTM Server URL") that double as the "what does Activate do, and how far did the last run get?" surface so you can see at a glance which half is done.

Once DNS is green, click Activate. A confirmation modal explains that activating creates or updates live endpoint resources tied to your current primary GA4 property and GTM web container, and that those primary selections lock for this setup after activation. Click Confirm to run both operations together:

1. Create the Cloud Run domain mapping via the Cloud Run v1 API. The mapping ties your subdomain to the tagging service in the same region. Google starts auto-provisioning a managed SSL certificate at this point — typically 15–60 minutes for the cert to be issued.
2. Set the GTM server container's tagging-server URL to https://<custom-domain>. This tells the GTM container to expect requests at the custom domain. GSS replaces any pre-existing URLs in the list with this single value.

Activate is idempotent: if the mapping already exists and points at the right service, it's left alone (treated as progress, not an error). If the mapping exists but points at a different service, GSS deletes the old one and creates a new one. Same for the GTM URL — if it already equals the expected value, no API write happens.

If exactly one of the two operations succeeds (for example, the domain mapping created but the GTM URL update failed), the step renders a partial-success callout instead of completing. The succeeded half stays applied; click Activate again to retry the failed half. The two status rows (Domain mapping / GTM Server URL) show which half is currently good.

If Activate is disabled, the page surfaces the missing prerequisite: GCP project not bound (complete GCP Project), tagging Cloud Run service not bound (complete Tagging Services), or GTM server container not bound (complete GTM Containers in Build). Resolve the prerequisite, then come back and Activate.

4 Are Domain, DNS, TLS, and GTM All Configured?

Step 4 stays locked until Activate has been attempted in Step 3 (a saved-but-never-activated domain has nothing to check yet). Once unlocked, click Check to run 5 requirement rows. GSS makes 1 HTTP request to /healthy, 1 TLS handshake check, 1 OS DNS lookup, 1 CNAME lookup, and 1 GTM API read.

Common errors & failure modes

Next step

Once all 5 requirement rows pass and TLS is provisioned, the tagging endpoint is ready. From here you continue into Connect — binding the web and server GTM containers, running a preview test, and wiring the saved tagging domain into the GA4 client and the web container's GA4 tag.