Item Array Integrity: What Stops Items Reporting in GA4

What stops items appearing in GA4 reports?

Items fail to appear in GA4 e-commerce reports when the items array is missing, malformed, or inconsistent across the funnel. Eight common bugs: (1) missing `item_id` (the only required field, items without it are dropped), (2) item_id mismatched between view_item and purchase (same product reports as different items), (3) currency code drifting between events (collapses to property default), (4) item_category exceeding cardinality limits ((other) at scale), (5) item_variant inconsistent between view and purchase, (6) missing items array entirely on purchase events (revenue tracked but no product attribution), (7) dynamic items with random IDs (each session creates new "products"), and (8) Merchant Center item_id mismatch (blocks Performance Max product-level optimisation).

The single biggest fix is item_id consistency across all events.

The required vs recommended fields

GA4 e-commerce items have one required field and many optional ones:

The pragmatic minimum: item_id, item_name, price, quantity plus event-level currency. Without these four, your reports lose key dimensions.

The eight common bugs

Bug 1, Missing item_id

The only required field. Items missing item_id are silently dropped from GA4's items reports, the purchase event still appears with revenue, but no product is associated.

Detection: Run this BigQuery query:

Any row with events_with_missing_item_id > 0 is a problem. Fix: ensure every item-array entry has a non-empty item_id at the dataLayer push.

Bug 2, item_id mismatched between view_item and purchase

A product viewed as item_id: "PROD-123" and purchased as item_id: "123" reports as two different items in GA4. Funnel reports break, view_to_purchase rates collapse because the items don't link.

Detection: Compare the unique item_ids across your top events:

If the same logical product appears with different item_id formats across events, that's the bug. Fix: standardise item_id format at source. Pick one, usually the platform's internal product ID, and use it everywhere.

Bug 3, Currency code drifting between events

A view_item event with currency: "GBP" followed by a purchase with currency missing causes the purchase to fall back to the property's default currency (usually USD). Revenue numbers convert at incorrect rates.

Detection: Check GA4 Monetisation report → revenue by currency. If you see revenue in unexpected currencies (especially the property default when you don't operate in that currency), it's bug 3.

Fix: Set currency on every e-commerce event explicitly. ISO 4217 format (GBP, EUR, USD). Don't rely on it being inherited from session or property.

Bug 4, item_category cardinality blowups

If item_category includes dynamic data (timestamps, user IDs, freeform text), it can exceed GA4's 50,000-value cardinality limit. Once over, item_category collapses to (other) for the day.

Detection: Check GA4 Monetisation → Items report. If item_category shows (other) with high event counts, cardinality is the cause.

Fix: Use stable category names, not dynamic ones. "Men > Shirts > Casual" not "men-shirts-casual-2026-04-15-uid12345". Keep cardinality under a few thousand unique categories.

Bug 5, item_variant inconsistent between view and purchase

A user views "T-Shirt" with item_variant: "Blue, Large" and purchases with item_variant: "blue-large" or item_variant: "". The variant-level reports show different products.

Detection: Same query as Bug 2 but filter on item_variant.

Fix: Standardise variant format. The cleanest pattern: use the SKU as item_variant if you have SKUs, or a stable concatenation like "Blue|L".

Bug 6. Missing items array entirely on purchase

The most damaging: purchase events fire with revenue and transaction_id but no items array. GA4 records the revenue but can't attribute to products. Items report shows zero rows for affected purchases; revenue numbers don't match items revenue totals.

Detection:

Any percentage > 0% indicates the bug. Fix: ensure your purchase event dataLayer push includes the items array. Common cause: server-rendered thank-you pages where the items data isn't accessible to the front-end JavaScript.

Bug 7, Dynamic items with random IDs

Each session generates new item_ids, item_id: "VIEW_${timestamp}_${userId}". Every page load creates a "new product" in GA4. Items reports become useless, cardinality limits hit immediately.

Detection: Run a query counting unique item_ids per day. If your site has 1,000 products but GA4 shows 50,000+ unique item_ids per day, you have this bug.

Fix: item_id must be stable across sessions and users for the same product. Use the platform's product ID (Shopify product_id, Magento entity_id, custom store SKU). Never generate dynamically.

Bug 8, Merchant Center item_id mismatch

For Google Ads Performance Max with Merchant Center integration, item_id in GA4 must match the id field in your Merchant Center feed. When they don't match, Performance Max can't optimise at the product level, campaigns silently lose efficiency.

Detection: In Google Ads → Conversions → check Performance Max product-level reporting. If product reporting is empty or "unattributed", the item_id linkage is broken.

Fix: Audit your Merchant Center feed. The id field there must match exactly what GA4 receives as item_id (case-sensitive). Common breakage: Merchant Center uses SKU; GA4 sends product_id (or vice versa). Standardise.

The cross-event consistency check

The single most valuable item-array audit is checking consistency across the funnel. For your top 10 products, verify item_id, item_name, currency, and price are identical across:

• view_item
• add_to_cart
• begin_checkout
• purchase

Any item appearing in fewer than all 4 events is suspicious, either the funnel isn't tracked properly or item_id is inconsistent across events. The result is your remediation list.

How to use this in a GA4 audit

Use this topic to support a ecommerce tracking audit and data-layer review. This article covers ecommerce measurement quality, with emphasis on validating transaction integrity before teams trust revenue or merchandising reports. Where possible, separate API-verified findings, browser-verified findings, and findings that depend on access to linked platforms.

What to verify

• Validate purchase, refund, and item-level payloads against the platform or backend order record.
• Check whether currency, value, quantity, and transaction identifiers are populated consistently.
• Confirm attribution and checkout continuity separately from order-system truth.
• Document whether the issue is browser-verified, platform-specific, or dependent on backend access.

Known limitations

• GA4 is useful for attribution and behavioral analysis, but storefront or finance systems may remain the source of order truth.
• Deduplication and refund handling should be tested against the implementation in use, not assumed from a generic pattern.

Before acting on the result

Use the visible evidence behind the finding before changing reporting, bidding, privacy controls, or executive dashboards. GA4 Audits findings should be reviewed by a qualified analyst before major business decisions are made.