Configure the GTM Server Container

This step configures the GTM server container workspace for the Connect stage. It runs after the web container has been configured (so the test forwarder is sending traffic to the tagging endpoint) and before the optional Preview Test or the Publish stage.

The app page header reads Configure the GTM Server Container. The server container receives the events forwarded by the web container's Test Forwarder tag, processes them, and writes them to the server-only GA4 property. GSS creates or updates a small static set of required GTM items in the selected server workspace: a GA4 client to claim incoming requests, an All Pages trigger that fires on every claimed event, and the GA4 Forwarder tag that sends those events to the server GA4 property. On the first-party loader profile, a Web Container Client is also required. Step 1 picks (or creates) the GSS workspace. Step 2 picks the loader profile. Step 3 manages the workspace items. Step 4 checks the install. Step 5 records what you observe in GTM Preview.

Not covered on this page: web container configuration (GTM Web Container), GA4 property setup (GA Properties), Cloud Run / tagging endpoint (Tagging Endpoint), or selecting which events to mirror (Discover / event selection).

Before you start

• Complete GTM Web Container so traffic is reaching the tagging endpoint.
• Complete GA Properties so the server GA4 property and stream are bound.
• Complete Tagging Endpoint so the Cloud Run tagging service has a public custom domain.
• Have edit access to the selected GTM server workspace (separate from the web container's workspace).
• Selected at least one event in Discover. Without a selection, downstream observation checks have nothing to verify against.

Decision record

The decision record at the top of the app page summarizes what this step is working against and whether the page is ready to hand off to the next Connect step. Its header reads Configure GTM server container. Use it as the page-level status before reading the numbered steps below.

The bottom nav opens Verify wiring in Preview (the optional cross-container probe) once GTM items, Configuration checks, and Preview verification are all green. Preview Test sits between this page and Publish.

1Set up the GSS workspace

GSS writes its client, tag, and trigger changes into a single GTM workspace dedicated to GSS inside the server container. Nothing in your live server container changes until you publish that workspace in GTM. The app surfaces this as the first step on the page so you decide where GSS will write before any GTM item is touched.

The recommended path is to let GSS create its own server workspace. Click Create GSS workspace, accept the suggested name, and Save. A dedicated workspace keeps GSS’s edits separate from anything else in the container and lets you undo the whole setup later by deleting just this workspace.

• Pick an existing workspace instead by clicking Refresh workspaces, choosing a row in the picker, then Save workspace. If that workspace already has draft items, a confirmation modal makes you acknowledge that those drafts will publish alongside GSS’s items.
• Change later — after a workspace is saved, the bound row gets a Delete or Unlink action. Delete removes the workspace in GTM and re-opens the picker. Unlink keeps the workspace in GTM and detaches it from this project.
• Saved workspace deleted in GTM — the status pill flips to "Saved workspace missing" and the picker re-renders so you can pick a replacement.

Steps 2, 3, 4, and 5 below are locked with a grey "Set up the workspace in step 1 first" pill until this step succeeds.

2 How GTM is loaded on your site

This step (visible marker 2 on the app page; anchored as #step-1 here) is where you pick how the GTM web container's loader script (gtm.js) reaches the browser. The two options render as radio rows in a table; the Save profile button at the bottom commits the choice (and stays disabled until you pick something different from the current saved value).

• Standard — browser fetches gtm.js directly from googletagmanager.com. Simplest setup; no extra Cloud Run client needed. Pick this if a server subdomain isn’t an option.
• First-party — browser fetches gtm.js from your tagging domain through the server container. The most resilient setup against ad blockers and browser tracking protections. Adds a Web Container Client item in Step 3 and gates an extra Step-4 check (/gtm.js returns 200).

The chosen profile shows up in the decision record (read-only) and on the row pill ("Selected — Standard" / "First-party"). The four downstream steps re-render when the profile flips because they depend on the profile filter.

3 Server GTM items

This step (visible marker 3 on the app page; anchored as #step-2 here and from app deep-links) is where configuration happens. Each row is a client, tag, or trigger that GSS checks in your saved GTM server workspace. The action verbs are operation-specific — there is no longer a generic "Configure" button. Use:

• Create on a Missing row to author the GSS-managed item.
• Reset on a Changed row to overwrite it with the GSS-managed body.
• Pick a client / Pick a tag / Pick a trigger on a Multiple-matches row to tell GSS which existing item to track.
• Re-check at the top of the step after you edit GTM directly.
• Restore only when you want to roll a tracked item back to a prior saved version.

All changes stay as unpublished GTM workspace edits until you publish the server container at the Publish stage.

3.aWhat this step writes

A single cluster of static items. The GA4 client claims every incoming request and hands it to the All Pages trigger, which fires the GA4 Forwarder tag. The forwarder sends each event to the server GA4 property, mirroring every incoming event regardless of which events were selected for validation.

When a downstream item reports dependency_failed, fix the upstream binding or trigger first — the leaf tag depends on whatever the dependency rows resolved to.

3.bRequired GTM item reference

One block per required GTM item. The header line shows the item name, the GSS-managed name, and the GTM type. The four labeled rows below describe what Create / Reset writes, what the item depends on, what counts as Ready, and how to recover when it needs attention.

Reference note: the deep-dive copy below sometimes uses the noun Configure to describe the GSS-managed authoring step. On the app page itself, the actual buttons are Create (Missing), Reset (Changed), and Pick a {type} (Multiple matches). Read "Configure" as a stand-in for whichever of those applies to the row’s current status.

Detection can classify a matching GTM item as Ready even if the name or exact setup differs from the GSS default. Treat non-behavior changes as optional cleanup; treat behavior-changing differences as something to fix before moving on.

3.cAnatomy of a GTM item card

Each required GTM item renders as a card with a fixed shape. Knowing what each field means makes it faster to decide whether to act on a row.

3.dReference: card states

4 Check GTM items and server-side install

This step (visible marker 4 on the app page; anchored as #step-3) does not write GTM items. The single button is labeled Check. Clicking it re-runs detection against the selected workspace and (on first-party loader) probes your tagging endpoint to verify install details that GTM-item detection cannot prove from the GTM API alone.

Read the structural checks in two groups:

• Loader endpoint check (3.1) — only on First-party loader. GSS fetches your tagging server's /gtm.js endpoint and confirms it serves valid JavaScript. Renders pass with the message N/A — standard loader profile. on Standard, with no fetch made.
• Workspace-API checks (3.2–3.7) — GSS calls the Tag Manager API against the selected workspace draft, not the published container. These pass right after the previous step’s Create / Reset actions run, even if you have not published yet — that is intentional.

Loader endpoint check (3.1)

Workspace-API checks (3.2–3.7)

5 Confirm each runtime check after Tag Assistant

This step (visible marker 5 on the app page; anchored as #step-4) is attestation, not auto-detection. GSS cannot drive your browser or your GA4 DebugView, so you open them yourself, observe each runtime behavior, tick the Confirm checkbox on each row, and click Save at the bottom to commit the full set in one POST. Unchecking a previously-confirmed row before Save surfaces a warning that you will need to re-confirm before this step passes.

Toggling a checkbox is local until you click Save — the persisted label flips to Confirmed at {timestamp} only after the bulk save commits.

Common errors & failure modes

Cross-cutting failures that don't sit on a single GTM item card. If a card shows a specific error message, look at the item's If it needs attention field and Deep dive in Step 2.b first; the symptoms below are the page-level patterns.

Next step

Once the GTM items step is Ready, the configuration checks are verified, AND the runtime attestations are saved, the bottom nav opens Verify wiring in Preview — the optional cross-container probe. Preview Test sits between this page and Publish — Review staged setup.