One container, two copies of the same tag. That is the scene behind a lot of analytics reports that look fine and are quietly wrong. Someone puts the tracking code in the page, someone else adds it again through the tag manager, and each visit gets reported twice.
Should analytics live in the tag manager? Our answer is no. Permanent measurement, meaning analytics and session recording, belongs in the site code, where every build can check it. The tag manager should hold only short-lived ad tags.
The table below shows where each kind of tag belongs. The rest of this post explains why, and how to keep it that way.
| Kind of tag | Where it lives | Why |
|---|---|---|
| Analytics (Google Analytics 4) | Site code | A build can prove it is present |
| Session recording (Microsoft Clarity) | Site code | Same check, same reason |
| Short-lived ad and remarketing tags | Tag manager container | Easy to add, easy to remove, meant to expire |
Why does the tag manager feel like the right home?
The tag manager feels like the right home because it is built to make tag changes easy. Google Tag Manager is a container that loads other tags, so one snippet in the page lets someone add, edit and remove tags without touching the site code. That convenience is real. It is also why permanent tracking drifts there: the easiest place to put a tag becomes the default place.
The pull is strongest for people who do not work in the code. A marketer can publish a change without waiting for a release, and nobody has to open a repository. We understand the appeal. We still think it is the wrong trade for measurement that has to keep running. A tag added in a hurry for a campaign gets forgotten, and a tag nobody remembers is a tag nobody checks.
Permanent measurement has the opposite profile from an ad tag. It should rarely change, and it should survive an unrelated edit. A container is designed for change. That mismatch is the whole problem, and it is the first thing worth checking in any technical review of a site.
How does the myth cause double counting?
Double counting happens when the same measurement tag fires from two places on one page. If the page code sends a pageview and a copy of the tag inside the container sends another, the property receives two for one visit. That is our reasoning about the mechanism, not a statistic, and it is why we keep each tag in exactly one place.
Two copies of one tag
- Analytics tag installed in the page code
- The same analytics tag published in the container
- One visit sends two pageviews
- Reports look busy and nobody questions them
One home per tag
- Analytics tag lives in the page code only
- The container holds ad tags only
- One visit sends one pageview
- A build can prove the tag is there
Google Analytics 4 works through a site tag that sends events from the page to your property, so the page does not care who installed that tag. It sends what it is told. Two installs mean two sends.
The scene is ordinary. A developer installs analytics in the layout while the site is built. Months later a marketer, who cannot see the code and has no reason to suspect it, follows a setup guide that says to add analytics through the tag manager. Both are doing something sensible. Neither knows about the other, and nothing breaks, so nothing alerts anyone.
Here is the turn. The obvious explanation for a jump in visits is a good month, and it is the first one people reach for. The better explanation is two copies of a tag. Reports with doubled numbers look encouraging, so no one goes looking, and the error becomes the baseline for every comparison afterward.
The mirror failure is quieter. Someone tidies a container, deletes a tag that looks old, and the analytics tag that lived only there stops sending. A container edit is quick to make and easy to miss, so the loss shows up as a gap in a chart weeks later. Counting twice and counting nothing share one cause: a permanent tag living where changes are easy and checks are hard. If your reporting feeds SEO decisions, either error misleads every call you make from it.
What can a build check prove that a container cannot?
Our build check proves that the analytics and session recording tags are present in the built pages, carrying the right property IDs. It cannot see inside a tag manager container, which is the one surface a check of the built files misses. That blind spot is why permanent measurement does not belong there.
Keeping the tags in the site code is what makes that claim possible. A missing tag or a wrong property ID shows up in the check rather than in a report weeks later. Microsoft Clarity session recording gets the same treatment, because a recording tool that quietly stops is hard to notice until you need the footage.
A tag inside a container offers no such proof. The container sits outside the built files, so a check that reads them never sees it. We could try to inspect it from outside, but we would rather remove the blind spot than watch it. That is also a reason to settle placement while building the site, not after launch.
The check has limits, and we would rather name them. Presence with the right IDs proves a tag is there. It does not prove the numbers are right, and it says nothing about what a person later adds by hand elsewhere. That is the point of the next section.
How do you keep the container clean?
Run a short check on a schedule, outside the build. Our standing rule is a quarterly out-of-band check that no analytics or session recording tag was ever added inside any tag manager container. It covers the one surface our build check cannot see.
You can run the same check with nothing more than access to the container and a list of the tags that are meant to be there. Put it on the calendar and treat any permanent tag you find as a finding.
The quarterly container check
-
List what belongs
Write down the ad and remarketing tags that are supposed to be in the container right now.
-
Read the container
Open each tag, trigger and variable it holds, including the ones that look switched off.
-
Flag anything permanent
An analytics or session recording tag inside the container is a finding.
-
Fix and record
Confirm the site code carries the tag, remove the container copy, and note the change.
Ad tags are what the container is for. A remarketing tag for a campaign has a start and an end, and the container makes both easy. If you run paid search, ad tags are the right tenants for the container: they are temporary and expected to leave.
When the check turns up a permanent tag, resist the urge to leave both. If the only copy is in the container, move it into the site code first. Then delete the container version and write down the change so the next person knows where each tag lives. A short note beats a long memory.
Look inside the container every quarter, and treat anything permanent you find there as misplaced. Our rule, stated plainly so you can borrow it: permanent measurement lives in the site code, where every build can check it, and the tag manager holds only short-lived ad tags.
Talk to Offer before you decide anything.
You'll talk with Offer, not a sales rep. A short call, no pitch deck.
Talk to OfferThis post was drafted with AI tools from our own project records, anonymized, and checked by us before it published. Read our editorial standards.
