Google Tag Manager
Review imported GTM versions and optionally observe tag execution in the browser.
Trace offers two independent views of Tag Manager: imported container configuration and observed execution callbacks. Use either or combine them, keeping their evidence distinct.
Connect a container
Choose an authorized Google connection and the intended GTM account/container for the selected environment. Wait for the first successful import and inspect its timestamp.
The connection reads container configuration through Google. It does not install tags, publish a GTM workspace or require the Trace observer. Recurring Live checks look for changes approximately every 15 minutes.
Review tags and version changes
Open Tag Manager in the Trace sidebar, or Explorer’s Tag reviews, to inspect saved tags, triggers, variables and version comparisons. Removed tags remain in history so a later publication does not erase the evidence of removal.
Changes lists each GTM publication of the last 30 days with Compare versions, next to Trace collection publications, and counts the issues first found within 6 hours of each. An issue sheet shows the same changes under Changed around the same time. Timing points where to look; it does not prove that a change caused the issue.
A first import may compare Live with the nearest earlier saved version. That is a historical comparison, not proof that Trace watched the change happen. Detection time also is not necessarily the time someone edited Google’s configuration.
Removed tags and failed or stale checks can appear in Issues. If a change was intentional, mark that exact change expected. A later change needs its own review. This records a configuration decision; it does not establish that the website’s tags ran successfully.
See tags on the service map
Services joins each live tag with the service it loads, next to real traffic and consent status. Every row says how Trace knows the service. Trace first uses what you told SiteOS: a name you gave the tag in Trace, or a SiteOS Cookie custom service whose discovery sources name the tag or the script address it loads. On the SiteOS Cookie banner, Cookie’s identification wins. Then Trace uses the tag's built-in template type (for example a GA4 event, Google Ads conversion, Hotjar or LinkedIn Insight tag) or the hosts its Custom HTML or Custom Image loads, resolved through the SiteOS vendor registry. It never guesses a service from a tag name.
Hosting and CDN addresses, such as Amazon S3, CloudFront or jsDelivr, can serve any service, so Trace never names a service after them. A tag that loads only from them appears as an unidentified tag, such as Tag “RB2B Script”. With the SiteOS Cookie banner, use Identify in Cookie to link it to the service it belongs to or describe a new one; with another consent source, use Name this tag. Paused tags are labelled Paused and never need attention. Gallery templates and inline code without a script address are counted without a service.
A tag in GTM does not prove that the service runs, and a service seen in traffic may not have a tag. The map shows both facts with their own dates, so a mismatch is visible. With the SiteOS Cookie banner, each row has one next step: Add to Cookie when the banner does not declare it, Publish in Cookie when it is only in the draft, or Identify in Cookie. With iubenda or another CMP, the map shows a consent column instead; see Consent and privacy. Open a service to reach its tag in the container view.
Name a service in Trace
Outside the SiteOS Cookie banner, an unidentified tag shows Name this tag and an unrecognized domain shows Name this service. Choose the vendor from the SiteOS registry; hosting and CDN vendors are not offered. The tag or domain then joins that vendor’s row, and its traffic counts under the vendor.
A name changes only how Trace groups the service. It never changes Cookie or stored observations, and you can remove it from the service’s sheet. If you later move to the SiteOS Cookie banner, Add to Cookie uses the same vendor.
Add execution evidence when useful
For callback evidence, install the normal Trace observer once and use the separate GTM execution monitor provided in Installation.
- Download the returned monitor template and import it as a private GTM Tag Template.
- Create one monitor tag.
- Add a Custom Event trigger matching
.*, with regular expressions enabled and all custom events. - Set the monitor to fire once per event.
- Preview the workspace and publish only after review.
The monitor listens for tag callback metadata. It does not load Trace itself or send the website’s business events. A tag that never fires may produce no callback, so absence alone is not an execution-failure verdict.
Investigate failures
Inspect the exact container, tag, callback result and page context. A callback can report failure, exception or timeout without providing the underlying error message. Use the website, GTM preview and adjacent evidence to investigate the cause.
A configuration change, execution callback and destination request are separate stages. GTM success does not prove that GA4 or another destination counted an event.
Read the summary through the CLI
MCP exposes the bounded GTM summary, the service map (siteos_trace_get_services) and saved observations. Full private configuration and container review actions remain in the authorized application interface. See Issues and rules for follow-up and recovery.