When you scan a container with TagManifest, the findings come from 85 individual rules. Each one checks the container JSON for a specific pattern: a consent misconfiguration, a naming inconsistency, a dead tag firing into a property that stopped processing data years ago. The rules are grouped into 10 categories, and the categories aren't evenly sized. Some have 25 rules. Some have 4. That unevenness is deliberate. More rules where more things go wrong.
This is the full overview. What each category checks, what it doesn't, and why the rule set looks the way it does.
Consent and compliance (12 rules)
Consent has the highest stakes of any category in the container. A misconfigured consent setup means tags fire without valid consent for visitors in regulated markets, and unlike a messy tag name, that has legal and data consequences. The 12 rules here check consent type correctness (is an advertising tag gated behind ad_storage or mistakenly behind analytics_storage?), whether tags use Built-In Consent or Additional Consent and whether the choice is appropriate for the tag type, whether Consent Mode v2 signals (ad_user_data and ad_personalization) are present for tags in the Digital Markets Act scope, whether a CMP is detected and how it integrates with GTM's consent infrastructure, and whether consent coverage extends across all tag types that need it, not just the obvious ones.
The depth here reflects the complexity of consent itself. Google's own documentation distinguishes between Built-In Consent and Additional Consent as separate mechanisms with different behaviors, and the interaction between CMP configuration, GTM consent settings, and individual tag consent requirements creates a surface area where subtle misconfigurations are common. The most frequent consent finding in production containers isn't missing consent. It's correct Built-In Consent with an unnecessary Additional Consent check layered on top, which can cause tags to be double-gated and silently suppressed.
GA4 data quality (25 rules)
The largest category, because GA4's event model has the most surface area for configuration errors that quietly degrade data without producing visible failures. Nothing breaks. The data just gets less reliable in ways that only surface weeks later when someone notices the reports don't add up.
The 25 rules cover measurement ID consistency (are all GA4 tags sending to the same property, or are some pointed at a different measurement ID?), event naming conventions (GA4 enforces snake_case, has a 40-character limit, and reserves certain event names that will silently collide with automatic collection), duplicate page_view detection (a config tag fires one, and a separate event tag fires another, doubling your pageview count), enhanced measurement configuration conflicts, whether config tags are properly paired with the event tags that depend on them, and parameter formatting issues that cause data to land in the wrong fields or get truncated.
GA4 is particularly susceptible to configuration drift because the event model is flexible enough to accept almost anything without complaint. A tag that sends event_name: "Purchase Complete" instead of event_name: "purchase" will fire successfully and show up in the Realtime report, but it won't populate any of the standard ecommerce reports, and GA4 won't tell you why. The rules here catch those patterns at the container level, before the data reaches GA4.
Organization (15 rules)
The inheritability category. None of these findings affect whether the container tracks correctly. All of them affect whether the next person who opens this container can figure out what's going on. The 15 rules check naming convention consistency across tags, triggers, and variables, folder usage and whether the folder structure reflects functional grouping or just chronological accumulation, orphaned triggers (connected to no tag) and orphaned variables (referenced by nothing), whether tags have any documentation or notes, and global scope pollution in Custom HTML (variables declared without var, let, or const that leak into the page's global namespace).
Simo Ahava's work on GTM best practices frames organization as a discipline that compounds: containers that start organized tend to stay organized, and containers that don't tend to accumulate debt faster as more contributors touch them. The rules in this category measure the current state of that debt. A container with 60% of its triggers orphaned and three distinct naming patterns from three different contributors isn't broken, but it's going to be slower and riskier to work in than one where those patterns were maintained.
Advertising (9 rules)
Conversion tracking across advertising platforms. The 9 rules check whether conversion tags are present for each detected advertising platform (Google Ads, Meta, LinkedIn, TikTok, Microsoft Ads), whether the Google Ads Conversion Linker is configured (required for conversion measurement to work correctly), remarketing tag coverage, duplicate conversion tracking (the same conversion event firing two tags to the same platform, doubling reported conversions), and cross-platform pixel consolidation opportunities.
The advertising rules sit at the intersection of functional health and money. Duplicate conversion tracking inflates reported ROAS, which distorts ad spend allocation. Missing conversion tags mean entire platforms are running blind. A Conversion Linker misconfiguration silently breaks Google Ads attribution. These findings are typically quick to fix once identified, but difficult to spot manually because the tags fire without errors and the symptoms only appear in the ad platform's reporting, not in GTM.
Naming (8 rules)
Separate from Organization because naming is specific enough to warrant its own analysis. The 8 rules detect the dominant naming convention pattern in the container (separator character, prefix structure, casing), measure consistency against that detected pattern, check GA4 event parameter formatting against GA4's requirements, identify test artifacts that were never cleaned up (test_, copy of, TEMP, v2_final_FINAL), and attempt ownership archaeology: can you tell from the naming patterns who built what and when?
Naming rules are diagnostic rather than prescriptive. TagManifest doesn't enforce a specific convention. It detects whatever convention the container is already using and measures how consistently it's applied. A container that uses Platform - Action - Detail consistently across 90% of its tags is Clean, regardless of whether that's the convention you would have chosen. Consistency matters more than format.
Infrastructure (8 rules)
The structural layer underneath individual tags. The 8 rules check trigger architecture complexity (are triggers deeply nested with multiple conditions that make firing logic hard to trace?), variable nesting depth (variables that reference other variables that reference other variables), duplicate event configurations (multiple tags tracking the same event with slightly different setups), tag sequencing dependencies (tags that depend on other tags firing first, creating invisible ordering requirements), and trigger condition coverage (whether the conditions on a trigger are specific enough to fire only where intended or broad enough to fire on pages where the tag shouldn't run).
Infrastructure findings tend to be the hardest to remediate because they're structural. You can't fix a deeply nested trigger architecture by editing a single tag. These are the findings that land in the "structural work" tier of the work plan.
Security and PII (6 rules)
Small category, high stakes. The 6 rules check for Base64-encoded PII being sent through tag parameters (Base64 is encoding, not hashing, and offers zero privacy protection), eval() and innerHTML usage in Custom HTML tags (both create injection vectors), HTTP resource loading from HTTPS pages (mixed content warnings and potential data exposure), GA4 parameter values that match PII patterns (email addresses, phone numbers flowing into analytics parameters), and plaintext email capture in tag configurations.
PII findings are among the few where the recommendation is unambiguous: stop sending the data. There's no "it depends" for an email address flowing through a GA4 event parameter in plaintext. The fix is either hash it properly or remove it from the parameter entirely.
Ecommerce (5 rules)
Focused on GA4 ecommerce implementation. The 5 rules check whether purchase events include a revenue value (the $0 revenue problem, where transactions record but revenue doesn't), ecommerce funnel coverage from view_item through add_to_cart, begin_checkout, and purchase (gaps in the funnel mean GA4's built-in ecommerce reports show incomplete paths), detection of marketing tools that typically need ecommerce data (Klaviyo, Hotjar), and whether the data layer structure matches GA4's ecommerce specification.
The $0 revenue finding is one of the most common ecommerce issues in production containers. The purchase event fires, the transaction count is accurate, but the value parameter is missing or mapped to the wrong data layer variable, so GA4 reports show revenue as zero. Everything looks correct in GTM Preview Mode because the tag fires. The problem only becomes visible in GA4 reporting, often weeks after implementation.
Performance (4 rules)
Four rules, each targeting a pattern that measurably impacts page load. jQuery dependencies in Custom HTML tags (loading a library for a tracking script), document.write() usage (blocks page rendering and is actively discouraged by Chrome), external script loading from Custom HTML (adding uncontrolled third-party requests to every page load), and overall Custom HTML code volume in the container. These are patterns that add page weight or latency for the tracking layer, not theoretical performance concerns.
The category is deliberately small. Performance in GTM is often discussed in broad terms, but the patterns that genuinely impact page load from within a container are specific and countable. The rules focus on those patterns rather than expanding into speculative performance advice.
Dead code (4 rules)
The smallest category and the most unambiguous. The 4 rules check for Universal Analytics tags still present in the container (UA stopped processing data in July 2023, so these tags fire on every page load and send data to a property that ignores it), tags referencing deprecated APIs, and obsolete tracking methods that no longer function. Every finding in this category is a tag adding page weight and network requests for zero return.
Dead code findings are almost always quick wins. The fix is deletion. The only complexity is confirming the tag is genuinely dead rather than being repurposed in a way that isn't obvious from the tag configuration alone. TagManifest flags the pattern; the five-minute verification step is confirming the destination property is actually decommissioned.
GTM audit finding output format
Every rule that produces a finding returns structured output: rule ID, title, severity (critical, high, medium, or low), effort tier (quick win, focused, structural, or strategic), category, the specific tags affected (with names and IDs), evidence explaining what was detected, and a recommendation. Structured for human reading in the report and dashboard, but also designed to be parseable by AI tools. The markdown export includes the same structured data in a format that works as context for LLM-assisted remediation.
How the rule set was built
The rule set started smaller and grew from real audit work. The initial version had 24 rules covering the most common configuration problems. Each expansion came from patterns that appeared in production containers and were worth checking systematically. Some categories grew faster because that's where the problems concentrated. GA4 data quality went from 8 rules to 25 as the range of event model misconfigurations became apparent. Consent expanded as Consent Mode v2 and DMA requirements added new dimensions to what "correctly configured" actually means.
There are gaps. The rule set doesn't cover every possible GTM misconfiguration, and some categories are shallower than others because fewer distinct patterns have emerged there. Coverage expands as more containers get scanned and new patterns surface. The rules are a living set, and the direction is always toward catching more of the things that matter in production.
Scan your container and the findings you see are these 85 rules applied to your specific configuration. The categories tell you where to look. The effort tiers tell you where to start.