Can Phloz publish GTM tags?

No, by design. Phloz documents each GTM container and never writes to GTM — its Google connection is read-only. The publishing flow stays in GTM where the version-control + preview-mode safety net lives. Phloz shows the state your team recorded for each container; you publish from GTM after review.

How does Phloz handle server-side GTM containers?

Server-side GTM containers are tracked as a separate node type (`gtm_server_container`) linked to the parent web container. The graph shows web → server → ad platform/analytics destination. For agencies running CAPI through server-side GTM, this becomes the canonical map of "where is the conversion sent?"

What about Tealium, Tag Inspector, ObservePoint, etc.?

Phloz V1 doesn't natively integrate with non-Google tag managers. Tealium and similar tools can be modelled as `custom` typed nodes with metadata if your client uses them. V2 will add typed Tealium support if customer demand surfaces it.

Tag management

Google Tag Manager integration for digital marketing agencies

Google Tag Manager is the connective tissue of every digital marketing agency's tracking stack. A misfiring GTM tag silently breaks conversion tracking, retargeting audience builds, and analytics attribution — usually only discovered when ROAS reporting comes back wrong. Modeling GTM containers as typed objects — with what each one sends events to, and when someone last verified it — means "which container feeds this client's GA4?" has a documented answer.

How Phloz models Google Tag Manager

What Phloz records about Google Tag Manager on each client's tracking map, and what it doesn't. Only GA4, Google Tag Manager and Google Ads connect to Phloz (read-only, through a connected Google account); everything else is recorded by your team. Health states are set by the person who checks, the structural audit re-runs weekly, and graph relationships show what each node connects to — so a node marked broken or overdue for verification shows up in the cross-client tracking-health view.

GTM container as a typed node with container ID, account ID, workspace name, environment (live / staging), and link status
Tags, triggers, and variables stay in GTM — Phloz doesn't read them; note anything worth keeping on the container node
Health status per container: working / broken / missing / unverified, set by your team — and the audit flags a live container that sends events nowhere
Linkage to GA4, Meta, Google Ads, TikTok, Microsoft Ads nodes — the GTM container shows what platforms it fires events to

Common Google Tag Manager configuration gotchas

The configuration mistakes agencies most often make with Google Tag Manager, surfaced here as a checklist agencies can run at every client onboarding. Honest, useful, not gated behind a sales pitch — these are real and you should audit for them regardless of whether you use Phloz.

Workspace drift: agencies leave half-finished workspaces unpublished for weeks, then a different team member publishes a workspace that doesn't include the latest tags. Check the version history in GTM at every takeover, and mark the container verified afterwards so the date shows on the map.
Trigger firing scope: tags configured to fire on "All Pages" when they should fire on "Page Path equals /thank-you" inflate conversion counts. Spot these by checking each conversion tag's trigger in GTM Preview at onboarding.
Custom variables fragmentation: agencies create five variables for the same value across five tags. Standardise + audit at onboarding; revisit quarterly.

Guides on Google Tag Manager

At launch (V1)

Connect Google and import GTM containers straight onto the tracking map with their real container IDs and names — an imported container auto-wires to the client's GA4 property when the map has exactly one. Tags, triggers, and variables aren't read or modelled; the container node records its ID, workspace, environment, and link status.

Not built yet

Read-only GTM Admin API sync: container version, active tags, last publish timestamp.

Why we built the integration this way

Most agency CRMs treat third-party tools as text fields: "GA4 Property ID" goes in a custom column on the client record. That works at one or two clients and breaks at five. With Google Tag Manager recorded on each client's tracking map — as its own typed node where Phloz has one, as fields and notes where it doesn't — the agency can answer "is this client's Google Tag Manager setup documented, and when was it last verified?" per client, and see every client ranked by tracking health.

Most of it is entered by hand at onboarding: only GA4 properties, GTM containers and Google Ads accounts can be imported from a connected Google account, and nothing syncs afterwards. The manual pass forces explicit verification at the exact moment the agency takes over the client's tracking — the cheapest moment to catch the gotchas listed above, before they become production issues.

When to use this in your client onboarding flow

The pattern we recommend: at every new client onboarding (see the client onboarding audit use case), spend 30 minutes documenting the client's Google Tag Manager configuration on the tracking map — IDs, tracking-code installations, conversion setup, the relationships to other systems. Verify each one fires by triggering a test event, then mark the node verified so the date is recorded. Add a recurring task (monthly, say) for the re-check, assigned to whoever owns tracking — the audit flags anything unverified for 30+ days either way.

Thirty minutes at onboarding costs far less than finding the same tracking issues during the first month of campaign optimisation — when finding them would mean a refund conversation. See the broader tracking infrastructure map use case for the agency-wide pattern.

Frequently asked questions

The three questions agencies ask most often about Phloz's Google Tag Manager integration. Honest answers — same data we'd give a friend evaluating the integration.

Can Phloz publish GTM tags?: No, by design. Phloz documents each GTM container and never writes to GTM — its Google connection is read-only. The publishing flow stays in GTM where the version-control + preview-mode safety net lives. Phloz shows the state your team recorded for each container; you publish from GTM after review.
How does Phloz handle server-side GTM containers?: Server-side GTM containers are tracked as a separate node type (`gtm_server_container`) linked to the parent web container. The graph shows web → server → ad platform/analytics destination. For agencies running CAPI through server-side GTM, this becomes the canonical map of "where is the conversion sent?"
What about Tealium, Tag Inspector, ObservePoint, etc.?: Phloz V1 doesn't natively integrate with non-Google tag managers. Tealium and similar tools can be modelled as `custom` typed nodes with metadata if your client uses them. V2 will add typed Tealium support if customer demand surfaces it.

Other tag management and adjacent tools, and how Phloz handles each.

Start your free trial

14 days free for new workspaces · No credit card · Starter tier free forever