How to Audit GA4 Configuration Limits

Start with a property-level inventory, not an account-wide guess. Record property ID, name, type, business owner, technical owner, environment, data streams, and whether Analytics 360 applies. Then count audiences, saved comparisons, saved segments, key events, custom insights, custom definitions by scope, custom metrics, calculated metrics, explorations, advertising links, and export usage. Google's configuration limits apply per property and differ for some standard and 360 properties.

For each object, capture resource name or ID, display name, definition, creator, created date, last modified date, last verified use, dependent report or campaign, data owner, privacy classification, and retirement rule. Use the Admin surfaces and approved APIs where available. Do not count labels from screenshots when an authoritative resource list exists. Preserve the export time because users can create or archive objects while the audit is running.

Join the observed counts to the current Google limit table. Google's standard-property examples include limits for audiences, key events, saved items, custom definitions, explorations, and Ads links. Treat documentation as time-sensitive and record the page review date. Calculate remaining slots and an internal warning threshold for every object class. A platform maximum is not an operating target; keep a small reserve for urgent compliance, launch, or measurement needs.

Separate hard configuration capacity from query and export constraints. Exploration sampling, data-export row limits, data retention, Data API quotas, and BigQuery delivery behavior require different controls even when they appear in the same documentation. An audience slot problem should not be diagnosed as a reporting quota error. Assign each limit class an owner, monitoring source, escalation threshold, and supported relief path.

For every candidate retirement, identify where the object is consumed. Audiences can be linked to advertising campaigns; key events can feed reports, attribution, and bidding; custom dimensions can appear in explorations, APIs, dashboards, and exports; saved comparisons and segments can support recurring reviews. Search configuration, report definitions, campaign settings, integration code, and owner documentation. Contact a named owner only when evidence leaves a real decision gap.

Classify each object as active, required but dormant, duplicate, expired experiment, superseded, orphaned, test, or unknown. A similar name does not prove duplication. Compare definitions, scope, event names, membership windows, filters, and destinations. Preserve historical labels when reports refer to them. If an object is unknown, quarantine it for a review window rather than immediately deleting a measurement asset that may be expensive to reconstruct.

Export the full definition, resource ID, owner, dependencies, last observed use, approval, and recreation steps before archiving or deleting. Prefer archive when Google supports it and the business may need history or recovery. For custom definitions, Google notes that reaching the limit can require waiting after deletion before another definition can be added. Plan that delay before a launch rather than deleting a slot during an emergency and assuming immediate reuse.

Change a small canary class first when the property has several retirement candidates. Validate affected reports, explorations, audiences, Ads links, API clients, and dashboards after the action. Do not rename an unrelated active object to reuse its slot; this can change the meaning of historical and future reporting under one label. Create a new governed definition when the semantic meaning changes, and document the cutover date.

Publish a monthly or quarterly capacity table with current count, platform limit, internal warning threshold, remaining reserve, oldest unowned object, and next review date. Alert only when a threshold is crossed or an approved project lacks capacity. Route the alert to the property owner with candidate actions and dependency evidence. Avoid nagging teams for every object created inside a healthy reserve.

Maintain a request process for new objects that includes the business question, scope, sample values, expected cardinality, consumer, privacy review, owner, expiry date, and cleanup plan. Reject unique identifiers and unbounded free text as routine custom dimensions. Require experiments to have an end date and named reviewer. This makes capacity governance part of creation rather than a cleanup project after the property is full.

Test one recreation or restoration procedure in a non-consequential context. Confirm the team can find the archived definition, understand its dependencies, restore or recreate it under the approved process, and update consumers. Record the elapsed steps without promising an unsupported recovery time. Close the audit with counts, decisions, deferred unknowns, actions, verification, and remaining reserve. The success measure is known capacity and safe ownership, not simply the smallest number of configured objects. Include the ledger in release planning so measurement work does not discover a full property after implementation is complete. When a launch needs several related definitions, reserve and approve them together, then release unused capacity after the validation window. This keeps temporary experiments from consuming permanent slots and makes emergency cleanup less likely.