GA4 parameter size limits ecommerce stores keep hitting

Operators keep showing me the same screenshot. Shopify reports one revenue number for the week. GA4 reports a quieter version of that same number, and when we sort the order list, the orders missing from GA4 are the ones with the longest line-item counts and the longest variant titles. The first instinct is that tracking is broken.

GA4 is doing exactly what its documentation says it does, which is to silently drop anything that exceeds a cap that nobody on the operator's team read.

These are field notes from a month of reconciling Shopify and GA4 numbers across a handful of mid-market DTC brands. None of the mismatches were bugs. They were documented limits, enforced quietly, in a way that makes the data look like a sampling artifact instead of a deterministic cutoff.

The mismatch that is not a bug

Most DTC operators discover GA4 mismatches by accident. The CFO asks why last month's GA4 revenue is 6 percent below Shopify's. The agency runs Tag Assistant, the GTM debugger fires green, and the conclusion drifts toward "GA4 always undercounts a little." That is not what is happening.

GA4 has a list of hard limits on event size, parameter count, parameter value length, and items-array shape. When an event exceeds any of those limits, GA4 stays silent and drops the event, the parameter, or the item depending on which limit got hit. Shopify keeps the full record while GA4 keeps a degraded one, and the two reports diverge by exactly the volume of orders that crossed a limit, all without any UI signal to the operator.

This is a schema problem, not a tracking implementation problem, and the fix lives upstream of GTM.

Field note, day one: the limits GA4 actually enforces

Spent the morning re-reading Google's own documentation on GA4 event and Measurement Protocol limits. Most operators have never read this page. Their tag manager hides it.

A standard GA4 property accepts at most 25 parameters per event. The same cap of 25 applies to the Measurement Protocol when sending events server-side: a single request can carry at most 25 events, each with at most 25 parameters. Names cap at 40 characters for both event names and parameter names. Parameter values cap at 100 characters on a standard property and 500 characters on a GA4 360 property. Three parameters get explicit higher caps: page_title at 300, page_referrer at 420, and page_location at 1,000.

The Measurement Protocol POST body must be smaller than 130KB. Item-level custom parameters are capped at 10 per item via the Measurement Protocol, and the gtag side allows up to 27 item-scoped custom parameters in an ecommerce event beyond the prescribed ones.

The behavior on overflow is the part that catches DTC operators. Google's own wording is that GA4 "doesn't log events, event parameters, and user properties that exceed the following limits." The wording is precise. A 101-character parameter value is not truncated to 100; the parameter is removed entirely from the event. A 26th parameter is dropped. A 26th event in a Measurement Protocol batch is dropped. Nothing surfaces in a warning, an error, or a log line; the drop is silent.

The drop is observable only by exporting raw events to BigQuery and comparing what was sent against what GA4 stored. The DebugView, Tag Assistant, and the browser gtag console all show the upstream payload, not the post-drop record. Most stores never run the export-and-diff comparison, so the silent drop accumulates for months before anyone notices the dashboards have stopped reconciling.

Field note, day two: which DTC store shapes blow these up

Audited five DTC stores this week and pulled the specific shapes that hit the limits. The patterns are consistent enough that I now check for them on every store I touch.

The first pattern is the long line-item purchase. A corporate gifting brand sells gift sets that bundle 18 to 30 SKUs in a single order. Their purchase event was sending an items array with the full set, and most of those orders were larger than 130KB after the per-item parameter expansion. Shopify recorded the full transaction. GA4 stored an empty or partial items array on the high-bundle orders. The cohort the operator most wanted to track, the high-AOV gifting buyer, was the one most missing in GA4.

The second pattern is the over-long variant title. A mid-market apparel brand stuffs size, color, material, fit, and a "limited edition" flag into the variant title. The resulting item_variant parameter ran past 100 characters on roughly 12 percent of products. GA4 dropped that parameter on every event tied to those products. Their Looker Studio dashboard segmented by variant and showed no data for the affected SKUs. The team had been treating it as a Looker Studio configuration bug for months.

The third pattern is the custom-parameter overrun. An operator added a marketing_campaign_id parameter to track first-touch attribution through checkout, and the parameter's value was a concatenation of the campaign name, ad set, and creative variant. On long-named campaigns, the value pushed past 100 characters. The parameter was dropped exactly on the campaigns the operator most wanted attribution data for, because long names correlated with the kind of detailed naming convention that disciplined media teams use.

The fourth pattern is the over-eventing of the order confirmation page. One Shopify theme had been customized to fire view_item, view_item_list, add_to_cart_replay, purchase, and a half-dozen marketing-pixel events on the thank-you page. The GA4 batch on that page exceeded 25 events, and the events that fell off the bottom of the batch were the ones the team did not realize they cared about until the dashboards stopped reconciling.

The fifth pattern is the third-party app rewriting fields it should not. A subscription app on one store overwrote currency with a 4-character internal code. GA4's currency parameter expects ISO 4217 (three characters) and validates the value before processing. Every event from that app's flow had a missing or invalid currency, which downstream broke revenue calculations for the subscription cohort.

Field note, day three: the warehouse-first workaround

Read the warehouse-first analytics rebuild hub for the full sequence. The piece of it that matters here is the schema decision.

When GA4 is the system of record, every limit becomes a hard wall. You either fit your event into 25 parameters, 100-character values, and a 130KB payload, or you accept silent drops. When the warehouse is the system of record, GA4 becomes a downstream consumer. The full event lives in BigQuery in its canonical form. The version that goes to GA4 is a projection: a deliberately smaller payload, with truncated and hashed fields, designed to fit inside GA4's caps.

The shape of the projection matters. On a recent rebuild for a DTC apparel brand, the canonical purchase event in BigQuery carried roughly 60 fields including the full Shopify order JSON, the variant breakdown, attribution metadata, and inferred cohort flags. The GA4 projection carried 22 parameters: ID, currency, value, the standard ecommerce subset, plus a small handful of custom dimensions that the marketing team needed for segmentation. Long fields like full campaign names were hashed into eight-character tokens that we joined back to the full names in the warehouse for reporting.

The reconciliation flow stops being an emergency. When the CFO asks why last month's GA4 revenue is 4 percent below Shopify, the answer is one query in BigQuery. The warehouse holds the canonical record, the GA4 projection holds the degraded copy, and the difference is explainable per-row instead of being treated as a sampling mystery. The detailed BigQuery schema for Shopify ingestion covers the warehouse side; this article is the GA4 side of the same pattern.

For operators who want to confirm the diagnosis before committing to a warehouse migration, the cheaper test is to enable GA4's BigQuery export, send a few weeks of full-fidelity events, and run a query that flags every event where any string parameter is exactly 100 characters or where the items array is exactly at the implicit cap. The exact-match-at-cap is the fingerprint of a silent truncation upstream of GA4.

What this month of audits taught me

DTC operators reach for the wrong fix when GA4 disagrees with Shopify. The usual loop is debugging GTM, running Tag Assistant, calling the tracking agency, and then installing a third-party tag manager wrapper. None of those tools surface the silent drop, because none of them sit at the layer where the limit is enforced.

The fix is upstream. Smaller event payloads, shorter parameter values, fewer items per purchase event, fewer custom dimensions. Or, the more durable fix: warehouse-first capture, with GA4 demoted from system of record to one of several downstream consumers. The full forensic workflow for Shopify, GA4, and Meta reconciliation walks through the diagnostic sequence I run when the three platforms disagree, and the same sequence catches GA4 limit violations as a side effect.

The 25-parameter cap quietly enforces a schema discipline that most stores never get otherwise. If the cap forces you to choose your 25 most useful parameters and demote the rest to a warehouse-only field, the resulting GA4 schema is cleaner than what most stores ship. The cost of paying for GA4 360 just to get 500-character values is rarely the right call. The 360 tier is priced for enterprises with consent-management and BigQuery integration needs that the free tier cannot meet, not for stores trying to avoid a parameter trim.

For stores running a GA4 migration with a Shopify tracking layer, the limits should be designed in at the migration stage. Most stores discover them after, when the dashboards stop reconciling. The retroactive cleanup is harder than the upfront design, because by the time you discover the silent drops, you have months of degraded data that can no longer be replayed at full fidelity. The schema-first event design pattern for DTC is the prevention. This article is the diagnosis.

If you want a faster confirmation that your store is hitting any of these limits in production, the DTC stack audit is the self-serve diagnostic. It scores tracking, analytics, theme performance, and attribution, and one of the checks is exactly the GA4 limit-pattern fingerprint described above. The full pattern catalog from anonymized rebuilds is in the production case study on the tracking gap.

Sources and specifics

• GA4 standard property limits (event parameters per event: 25; parameter value length: 100 characters; parameter and event name length: 40 characters) are published in Google's GA4 event limits documentation. GA4 360 increases parameter value length to 500 characters.
• Measurement Protocol limits (25 events per request, 25 parameters per event, 130KB POST body, 10 item-level custom parameters per item) are published in the GA4 Measurement Protocol reference.
• Page-level parameter exceptions (page_title 300 characters, page_referrer 420, page_location 1,000) are documented per parameter rather than as global limits.
• Field-note observations are from a month of audits across DTC stores in early 2026; specific store types (corporate gifting, mid-market apparel, subscription-app) are anonymized industry categories, not single clients.
• The exact-match-at-cap diagnostic query against BigQuery export is the reliable way to detect silent drops; DebugView and Tag Assistant do not surface them.