Tag manager connections

A tag manager connection lets Monita read a container the way your team does: which tags exist, what triggers them, which variables they read, and how all of that changed from one version to the next. With a container attached to a property, a volume issue on a signal can be traced to the exact tag that sends it, and to the container change that touched that tag.

Detected on the page versus connected

Monita already recognises tag managers from the traffic it observes. When Google Tag Manager, Commanders Act, Tealium or Adobe Launch loads on a page, the property reports it and the piggyback view files vendors under the tag manager that placed them. That needs no setup and works for every tag manager listed.

A connection is different. It gives Monita read access to the container itself, so it can answer questions the page alone cannot: which tag fires a signal, what the container declares that never fired, and what changed between two published versions. Today only Google Tag Manager containers can be connected. Detection of the other tag managers stays automatic; connections for them are not available yet.

Why connect a container

• Trace a signal to its tag. On the property’s Tag managers tab, each container tag that sends a monitored signal is marked with that signal’s vendor, and through the MCP server resolve_signal_source returns the tag, its triggers and the evidence for the match. When a signal drops, you see which tag and which container change to look at, rather than starting from the container’s full tag list.
• Container inventory. A summary of the latest synced version: counts, plus every tag, trigger and variable it declares. Ask it structural questions through your assistant with the MCP server (query_container): tags by type, tags on a trigger, variables reading a dataLayer key, which tags read a variable.
• Container drift. What changed between two synced versions: tags, triggers and variables added, removed, renamed, paused or modified. Pair it with the signal trace to attribute a tag health or volume issue to a concrete change.

Connect a container

1. In Integrations, find the Google Tag Manager card and click Connect Google account. The account you sign in with needs access to the container you want to attach. One Google connection serves the whole organisation; the full sign-in walkthrough is on the Google Tag Manager integration page.

2. Open the property in Properties and go to its Tag managers tab.

3. Under Connect a container, choose the Tag Manager account, then the container. Picking the container attaches it to the property.

4. Monita reads the container’s latest version straight away and re-reads it on a schedule. Press Sync now on the card any time you have published and want the new version reflected immediately.

If the property is new, the same account and container pickers appear in the New property wizard, so you can attach a container while creating the property.

Monita reads, it never publishes

The connection is read-only. Syncing reads the container’s published versions; nothing Monita does through the connection creates, edits or publishes anything in your container.

Edits are a separate path. When your assistant makes a change through the gtm_* tools on the MCP server, it acts as you, through your own Google account, and every edit lands in a workspace. Creating a version and publishing stay in the Tag Manager interface, where you review the change and press publish yourself. See the Google Tag Manager integration for the same principle applied to Monita’s own monitoring tag.

What is not a container

A container has a GTM- id. A page that loads Google’s gtag.js with a DC- Floodlight id (or an AW-, G- or UA- id) is loading Google’s tag directly, not a tag manager container, so there is nothing to attach. Those tags are still monitored as vendor signals and still appear in audits; they are placed by the page, and the piggyback view labels them that way.

Verify it worked

• The property’s Tag managers tab lists the container with its id, when it last synced and the synced version.
• The card lists the container’s tags, and each tag that sends a monitored signal carries that signal’s vendor next to it. Latest changes shows what changed between the two most recent synced versions.
• Through the MCP server, list_tms_connections returns the container, and get_container_inventory returns its tags, triggers and variables.

If the container shows a sync error, check that the connected Google account still has access to it. Re-connecting the Google account from Integrations replaces the organisation’s connection.

Remove a connection

Press Disconnect on the container in the Tag managers tab and confirm. Disconnecting removes the inventory and change history for that property; the container itself is untouched. Disconnecting the Google account from Integrations stops syncing for every attached container in the organisation.