Why teams reach for a tag manager
The appeal is straightforward. A tag manager lets a marketer add, change or remove a script without a developer, a deployment, or a release window. If your site ships on a two-week cycle and you want chat live on Thursday, that is a real advantage rather than a lazy one.
It also centralises things. When every third-party script lives in one place, you can see what you are actually loading, which is more than most teams can say about a template that has accumulated snippets for six years.
The trade-off is that you have put a layer between your page and your widget, and that layer can fail in ways the widget cannot tell you about. Everything below is about that layer.
What the snippet actually is
It helps to know exactly what you are asking the tag manager to deliver. The MyLiveChat install is one <script> element carrying your account id, marked async and defer, pointed at our host. It is not a bundle, it does not need to run at a particular point in your page lifecycle, and it does not block rendering.
That shape is what makes tag-manager deployment viable at all. A script that had to execute synchronously before the page painted would be a poor fit for a system that injects tags asynchronously after load. Because ours does not, adding it as a custom HTML tag firing on the standard all-pages trigger is genuinely equivalent to pasting it in your template, with the caveats that follow.
The consent question comes first
Most teams that run a tag manager also run a consent banner, and the two are usually wired together so that tags are held back until the visitor chooses. This is where chat deployments most often go quietly wrong.
Support chat is not analytics. A visitor who clicks a chat button is asking to talk to you, and a setup that refuses to load the widget until they have accepted marketing cookies produces the worst of both outcomes: the visitor cannot reach you, and you never find out, because a widget that never loaded generates no events to look at.
Decide deliberately which consent category chat belongs to, write the decision down, and make sure your banner copy matches what actually happens. If your legal position is that chat requires consent, then the page needs to say what a visitor is missing while they withhold it, rather than showing a blank corner. The privacy guide covers the wider question of what you tell people and when.
Where a tag manager quietly breaks chat
Four failure modes account for nearly all of it, and none of them announces itself.
- The tag manager is itself blocked. Content blockers and privacy-focused browsers frequently block tag-manager hosts by name. When that happens every tag inside it disappears, including your chat. Loading chat through the tag manager means your support channel inherits the block list of an analytics tool.
- Content Security Policy stops one half. If your site sends a CSP, it must allow our host on both
script-src and style-src. Allowing scripts but not styles is the nastier version: the widget mounts and behaves oddly rather than failing cleanly. Blocking scripts produces no widget and no visible error at all.
- The snippet is stored with an http URL on an https page. Browsers refuse mixed content silently. The tag looks correct in the tag manager interface and nothing appears on the site.
- Trigger scope is narrower than you think. A trigger built during testing on one page template often does not fire on checkout, on a subdomain, or inside a section rendered by a different system. Chat then works everywhere you looked and nowhere you did not.
If your site is a single-page application, the tag manager's history-change trigger and your widget do not necessarily agree about what a page view is.
The important fact is that our runtime does not re-run its page-load logic when a client-side route changes. Nothing hooks browser history events, so moving from one route to another without a full page load does not re-evaluate anything. In practice the widget you loaded on the first route simply stays there, which is usually what you want.
Where it bites is rules that depend on the current URL. If you have a proactive invitation set to fire on a particular page, or a trigger in the tag manager that fires the chat tag on route change, test the actual behaviour rather than assuming: navigate between routes without refreshing and watch what happens. Do not add a second copy of the snippet on route change in the hope of refreshing state.
Test it the way a visitor experiences it
Preview mode inside the tag manager proves the tag fires. It does not prove a visitor sees a widget, because preview mode runs with consent granted, no content blocker, and usually a logged-in session on a desktop browser.
Test the real thing instead. Open the site in a private window with whatever blocker a normal visitor in your market would have installed. Decline the consent banner and see what happens. Load a page deep in the site rather than the homepage. Try it on a phone. Then check that a chat you start from that session actually arrives in the agent console, because a widget that renders but cannot connect looks identical to a working one until someone tries to talk to you.
When to skip the tag manager
There is a reasonable case for putting the snippet straight in your template even when you have a tag manager, and it comes down to how you classify chat.
If you treat chat as a marketing tag, the tag manager is the right home for it. If you treat it as part of the site's core function, in the same category as your navigation or your contact page, then routing it through a tool designed to be disabled by privacy software is an odd choice. Sites where support is the main reason people get in touch usually end up moving the snippet into the template eventually.
A reasonable middle path is to deploy through the tag manager first, because it is fast and reversible, then move it into the template once you have decided chat is staying.
What to measure
The only number that matters here is whether conversations arrive at the rate you expect, and the only reliable way to notice a deployment problem is to know what normal looks like before you change anything.
Record your typical daily conversation count for a week before moving the snippet, then compare for a week after. A deployment fault rarely produces zero chats; it produces fewer, from a narrower set of pages, which is much easier to miss. If your chat volume drops and no one changed the product, suspect the delivery layer before you suspect demand.