When you scan a GTM container with TagManifest, the Measurement tab answers the question most people start with: what is this container actually tracking? It's the inventory view — how many GA4 events are firing, which advertising platforms are receiving data, whose account IDs are in the tags, and whether the ecommerce funnel has gaps. If the consent dashboard tells you whether the container is tracking legally, the measurement view tells you whether it's tracking accurately.
This piece walks through each section of the measurement view, what the numbers and indicators mean, and what to look for when you're trying to understand a container's measurement architecture.
What the measurement view tells you
The view is structured around three questions, roughly in order of how people encounter them during a container review.
What's in GA4? How many events, which ones are Google's recommended events versus custom implementations, and whether multiple measurement IDs suggest data routing to different properties. This section gives you the architectural shape of the GA4 setup without opening a single tag.
Who's getting your data? Which advertising platforms have tags in the container, how many tags each platform has, whether they're using native GTM templates or Custom HTML, and the actual account IDs. The account IDs matter for inheritance scenarios — if you just took over a container, this tells you immediately whether data is flowing to the previous agency's accounts or your own.
Is ecommerce tracking your full funnel? The ecommerce section shows which GA4 ecommerce events are present, whether the "Send Ecommerce Data" flag is enabled on each one, and a visual checklist of funnel coverage from view_item through purchase. If your GA4 shows $0 revenue, this section usually points to why.
The GA4 overview cards
The top of the measurement view shows summary cards that orient you before the detail sections.
GA4 Config Tags counts the Google Tag configuration tags in your container — these are the tags that initialize GA4 with a measurement ID and set property-level settings. Most containers have one, and if you see two or three, it means different GA4 configurations are active, which is legitimate when a container serves both a production and staging property but a finding when it's accidental.
GA4 Event Tags counts the tags that send specific events to GA4. A container with 40-60 event tags is typical for a mid-size implementation; significantly more than that suggests either thorough tracking or tag proliferation that could benefit from consolidation.
Measurement IDs lists every unique GA4 measurement ID found across all tags. When all event tags reference the same measurement ID (usually through a shared GTM variable), this shows a single ID, but when tags reference different IDs — either through hardcoded values or different variables — multiple IDs appear. Multiple measurement IDs isn't automatically a problem, but it's worth understanding why they're different; common reasons include a staging property that was never removed after launch, or different teams adding tags that point to their own GA4 properties instead of the shared one.
Total GA4 Tags is the combined count of config and event tags, and this number alongside the event count gives you a sense of the container's GA4 footprint relative to its total tag count.
Reading the event list
Below the overview cards, the measurement view lists every GA4 event name being sent from the container, split into two groups.
Recommended Events are the ones that match Google's predefined event names: purchase, add_to_cart, begin_checkout, sign_up, login, and others. These events populate GA4's built-in reports and integrate with Google Ads automatically, and the count here tells you how much of the implementation uses Google's standard schema versus custom definitions.
Custom Events are everything else — events the implementation team defined for interactions that don't match Google's recommendations. A custom event for pricing_calculator_used or chatbot_opened is entirely appropriate; a custom event for my_purchase instead of the standard purchase means the ecommerce reports won't populate, even though the tracking logic is identical.
What the split tells you. A container with 7 recommended events and 40+ custom events has a GA4 implementation that's been built primarily through custom tracking rather than following Google's schema. That's not wrong, but it means the team doing the implementation either chose to diverge from recommendations for specific reasons, or (more commonly) wasn't aware of Google's recommended event names when building the tracking. For ecommerce events specifically, using the standard names is the difference between GA4's monetization reports working out of the box and needing custom reporting for everything.
Ecommerce Events are called out separately within the event list: the subset of event names that match GA4's ecommerce specification, which maps directly to the funnel coverage section below.
The advertising platforms table
The advertising platforms section shows every ad platform detected in the container, organized as a table with columns that answer different questions.
| What you see | What it tells you |
|---|---|
| Platform name | Which ad networks are active (Google Ads, Microsoft Ads, LinkedIn, Meta, etc.) |
| Tag count | How many tags each platform has (indicates campaign complexity) |
| Native vs HTML | How many tags use GTM's native templates vs Custom HTML (Custom HTML = older implementation) |
| Account IDs | The actual advertiser account numbers from tag parameters |
Account IDs are the ownership archaeology surface. When you inherit a container, the account IDs tell you immediately whose Google Ads account, whose LinkedIn campaign manager, and whose Facebook Business Manager are receiving conversion data. If the account IDs don't match your organization's accounts, data is flowing to someone else's platform — likely the previous agency or consultant.
Native vs Custom HTML is a migration indicator. Native GTM templates for ad platforms (Google Ads Conversion Tracking, Microsoft UET, LinkedIn Insight Tag) integrate with GTM's consent framework and fire in GTM's sandboxed environment, while Custom HTML implementations bypass both. A platform showing 1 native tag and 19 Custom HTML tags (common for LinkedIn in older containers) means the bulk of that platform's tracking runs outside GTM's consent and security controls, and migrating to native templates is usually a focused afternoon of work.
Conversion Linker presence is checked separately — this tag enables Google to stitch click IDs across pages for accurate conversion attribution. Without it, Google Ads conversion tracking still works but loses some attribution accuracy, particularly for cross-domain journeys.
The ecommerce funnel coverage
The ecommerce section starts with a binary indicator: does this container have GA4 ecommerce tracking? If it does, the section expands into the detail that matters.
Ecommerce tag count shows how many GA4 event tags are configured as ecommerce events, alongside how many of those have the "Send Ecommerce Data" flag enabled. This flag tells the GA4 tag to read ecommerce data from the data layer and include it in the event, and if a tag is counted as an ecommerce event but doesn't have this flag enabled, the event fires but ecommerce parameters don't travel with it — this is the single most common cause of $0 revenue in GA4, where the event records, the transaction counts, but the value and currency never make it to the reports because the tag wasn't configured to read them.
Funnel coverage displays a visual checklist against the six standard GA4 ecommerce events:
- View Item (
view_item) - Add to Cart (
add_to_cart) - Begin Checkout (
begin_checkout) - Shipping Info (
add_shipping_info) - Payment Info (
add_payment_info) - Purchase (
purchase)
Checked items have corresponding event tags in the container, and unchecked items don't. The value of this visualization is immediate: you can see at a glance which funnel steps are tracked and which are gaps. A container that tracks add_to_cart, begin_checkout, add_payment_info, and purchase but not view_item or add_shipping_info has a partial funnel that answers some questions (where do people abandon checkout?) but not others (which products attract the most views?).
Most containers skip view_item and add_shipping_info because these require data layer pushes that the ecommerce platform may not provide by default, especially for hosted checkout flows like Paddle or Stripe Checkout. The gap is understandable but worth knowing about, because it determines what level of funnel analysis your GA4 reports can support.
Detected ecommerce tools identifies known ecommerce platforms found in the container (Shopify, WooCommerce, Paddle, BigCommerce), and this context helps you understand why certain funnel steps might be missing — a Paddle-based checkout, for example, handles most of the funnel on Paddle's hosted page, where your GTM container doesn't run.
Findings that appear alongside the measurement view
The measurement view surfaces findings from the GA4 data quality and ecommerce rule categories, which appear as a list below the dashboard sections, each with a description and recommendation.
Common findings you'll see:
Event naming issues. Casing inconsistency (some events use camelCase, others use snake_case), event names exceeding GA4's 40-character limit, or custom events that duplicate enhanced measurement events like form_submit or scroll.
Measurement ID hardcoded in individual tags instead of referencing a shared GTM variable — this is a maintenance risk, because when the measurement ID needs to change, every hardcoded tag needs individual editing instead of updating one variable.
Ecommerce tags missing the Send Ecommerce Data flag. The revenue-breaking finding described above, where the fix is usually checking a single box in the tag configuration.
Incomplete ecommerce funnel. The funnel coverage gaps identified by the visual checklist above also generate an optimization finding with specific guidance on which events to implement.
Each finding links back to the work plan on the Summary panel, organized by the effort required to fix it. Event naming cleanup is a focused session, missing ecommerce parameters are a quick fix, and full funnel implementation is a project that requires developer involvement for data layer changes.
Connecting the measurement view to the rest of the audit
The measurement view is one lens on your container — it tells you what's being tracked and whether the tracking architecture is sound. The consent dashboard tells you whether that tracking respects visitor choices, and the scoring model tells you how the measurement findings contribute to your overall functional health score, where GA4 data quality has the highest deduction cap (16 points) alongside consent, reflecting that these two categories have the most direct impact on whether the data you're collecting is reliable and compliant.
If the measurement view is showing issues, the GA4 data quality audit guide covers each finding type in detail with fix directions and prioritization guidance. Start with the ecommerce findings if revenue is affected, then address event naming and parameter issues that affect reporting accuracy — the configuration findings (hardcoded measurement IDs, debug mode left on) are lower urgency but worth cleaning up as part of any container maintenance session.