GA4 Parameters: Design, Send, Register, and Validate Custom Data

July 1, 2026

Author: Shusaku Yosa

GA4 event parameters add context to a measured action. They are not interchangeable with user properties or item-level data. A useful implementation begins with a question, then separates sending the data, registering reporting definitions, and validating the result. This guide turns those decisions into a measurement plan, practical examples, and checks that can be reviewed before a tag is published.

Separate events, parameters, and user properties

An event name describes what happened. Its parameters describe the details: page_view can carry page_location for the viewed URL and page_referrer for the preceding page. Page referrer is not necessarily the acquisition source shown in a traffic report.

User properties describe a user, such as membership_tier. They are not permanently static: a tier can change, so define its update and reset conditions. Selecting User scope in a custom definition does not transform an event parameter into a user property. Ecommerce data inside items needs an item-level design. Google’s user-property guidance explains the separate collection mechanism.

Check predefined data before creating custom fields

Review the predefined parameter and reporting catalog before inventing a field. A predefined dimension such as page location should not be duplicated as a custom dimension with the same meaning. Enhanced measurement depends on the feature settings and site implementation; enabling it is not a promise to capture every interaction.

For purchases, start with the recommended event and its expected value, currency, transaction_id, and items structure. Reserve custom fields for questions the existing schema does not answer. For editorial analysis, a controlled article category may be useful; a unique identifier for every view can create many distinct values without helping the decision.

Design event, user, and item data with a measurement plan

This table is an illustrative measurement plan, not a production configuration. Define the source of each value, when it is available, the relevant events, and who maintains the contract. A membership tier belongs to the user-property mechanism; the category of a viewed article belongs to that event.

Question	Event or value	Reporting scope	Design check
Views by category	article_view; article_category=analytics	Event custom dimension	Controlled taxonomy without personal information
Behavior by membership tier	User property membership_tier=free	User custom dimension	Update on account changes and reset when appropriate
Product performance by color	item_color=blue inside items	Item custom dimension	Correct value for each item
Reading depth	Numeric reading_depth=75 on a defined event	Custom metric if suitable	Specify units and meaningful aggregation

user_id is a reserved field for the dedicated User-ID feature. Follow the instruction not to register User-ID as a custom dimension rather than adding a generic member-ID reporting field.

Send values with the Google tag or GTM and verify collection

Choose direct Google-tag implementation or GTM according to the existing architecture and responsible team. In GTM, inspect the GA4 event name, parameter names, value variables, trigger conditions, and intended Google-tag destination. Previewing a trigger and verifying that Analytics receives its data are related but separate tests.

Reproduce one illustrative article_view and check article_category=analytics.
Check whether direct implementation and GTM both send the same action.
Record the production hostname, property, consent state, and timing of value availability.
Inspect the event and parameter in DebugView; collection can be checked before creating a custom definition.

Use the event-parameter setup documentation and DebugView guidance to validate the sending mechanism. Do not use personal information as test data.

Register custom dimensions and metrics where needed

Use a custom dimension for a classification and consider a custom metric for a quantity. In Admin’s custom definitions, match the display name, scope, and exact event-parameter or user-property name. Display labels and collected names serve different purposes; capitalization in collected names must agree.

article_category belongs to Event scope, membership_tier to User scope, and a custom item_color inside items to Item scope. Before using reading_depth as a metric, decide what 75 means and whether a sum or average answers the question. Custom-definition documentation describes a usual 24–48-hour reporting delay after setup and collection. Waiting cannot fix an unsent parameter or a name mismatch.

Check collection limits, definition quotas, and reserved names

These standard-property limits were checked on October 12, 2026. Collection limits and reporting-definition quotas are different constraints. Verify the applicable property type and current documentation before implementation.

Constraint	Standard-property example	Practical response
Collection	25 parameters per event	Remove unnecessary fields and review the event design
User custom dimensions	25	Keep genuine user attributes
Event custom dimensions	50	Avoid duplicating predefined fields
Item custom dimensions	10	Use for item-level questions
Custom metrics	50	Specify quantities and units

See event collection limits and definition quotas. Do not automatically split one action into multiple events to accommodate excess parameters: that can inflate event or key-event counts. Check reserved names and prefixes separately.

Avoid PII, high cardinality, and duplicate sends

Exclude names, email addresses, phone numbers, and other prohibited personally identifiable information from collection. Inspect URLs, page titles, UTMs, search terms, and free-text form values as well as custom parameters. Consent management and the requirement not to send PII are separate checks.

Data redaction is a supporting feature, not comprehensive protection for every collection route. Minimize data at its origin. Avoid high-cardinality reporting dimensions such as an identifier that changes on every view. Validate duplicate success-event sends and counting methods; event totals are not a count of registered people.

Troubleshoot reporting and maintain the data contract

If DebugView contains the value but a processed report shows (not set), check the registered name, scope, registration timing, processing, and event filter. A category sent only on article_view will legitimately be absent on other events. Changing a definition is not a promise to backfill every historical value.

Write the analysis question and intended event and metric.
Record name, type, units, allowed values, source, applicable events, and owner.
Test collection, DebugView, definition, and the later report in that order.
Review values and duplicate sending after site or consent changes.

A maintainable parameter plan needs explicit acceptance criteria for both collection and reporting. Choose only the fields that support a decision, then keep those criteria with the implementation.