10 Publish
Publish both GTM workspaces and verify the live containers are configured per the staged plan. Publishing pushes your validated configuration to live GTM; cutover happens later in Go Live.
Note: This step content was written for the original dual-run architecture and is being updated for the current setup workflow. The guide overview reflects the current approach.
This step is being finalized. Content is accurate but will be updated and expanded before full release.
Deliverable
Live GTM containers carry every required tag, trigger, and variable per the staged plan.
Validation
Publish the web and server GTM containers deliberately and record the published versions. Your primary GA4 property stays unchanged throughout this step; what publishing turns on is the parallel path that delivers events to the Test GA4 Property via your tagging service.
Use browser network inspection, GA4 Realtime reports, and the tagging service health endpoint together to verify the forwarding path is alive. Confirm primary collect traffic still fires, the new forwarded collect traffic fires to your tagging endpoint, events appear in both the primary and test GA4 properties, client IDs stay aligned, and critical events such as session_start show up in both destinations. Watch Cloud Run logs during the same test window so you can catch hidden runtime errors while the traffic is flowing.
10.1 Publish Both GTM Workspaces
Build queued changes in two GTM workspaces — the web container's staging workspace and the server container's staging workspace. Publish both workspaces, then validate that the live GTM containers carry every required tag, trigger, and variable per the staged plan.
Checks
- API The GSS staging workspaces have no unpublished GTM changes.
- API Web container has the forwarder tag live.
- API Server container has the forwarder tag configured.
Use the app to validate this step automatically.
Request access