GA4 Parameter Naming Conventions: snake_case vs camelCase (2026)

What naming convention does GA4 use?

Official recommendation: snake_case — all lowercase letters with underscores separating words. item_id, transaction_id, page_title, engagement_time_msec. This is consistent with GA4's automatically collected parameters and all of Google's official documentation examples.

Why this matters: GA4 custom dimension registration is case-sensitive. If you push formId to the dataLayer and register form_id as the custom dimension parameter name, the parameter is never matched and your custom dimension shows (not set) for all values. This is one of the most common implementation bugs in GA4 properties that were migrated from UA (which used camelCase in many GTM templates).

GA4's parameter naming rules

GA4 enforces these rules at collection time:

1. Only alphanumeric characters and underscores — no spaces, hyphens, dots, or special characters
2. Cannot start with a number — 1_item is invalid; item_1 is valid
3. Cannot start with `ga_` — reserved for Google's automatically collected parameters
4. Maximum 40 characters for event names; 40 characters for parameter names
5. Case-sensitive — ItemId, itemId, and item_id are three different parameters
6. Reserved names — these parameter names are reserved and cannot be used for custom events: firebase_conversion, firebase_error, ga_session_id, ga_session_number, page_location, page_title, screen_class, screen_name, session_engaged

Why camelCase appears in legacy implementations

Universal Analytics GTM templates used camelCase extensively:

• transactionId (UA transaction ID)
• productCategory (UA product category)
• pageType (UA custom dimension)
• clientId (UA client ID)

When these properties migrated to GA4, GTM templates were sometimes copied directly, bringing camelCase parameter names with them. If your GA4 property has events with camelCase parameters, this is most likely a migration artefact — it works (GA4 collects the data) but causes problems when trying to register custom dimensions or use parameters in standard reports.

Standardising to snake_case

Step 1 — Audit current parameter names

In BigQuery:

Scan for camelCase patterns (capital letters mid-word).

Step 2 — Update GTM variables

For each camelCase parameter, update the GTM tag to use snake_case:

• transactionId → transaction_id
• formId → form_id
• productCategory → product_category
• pageType → page_type

Step 3 — Update custom dimension registrations

In GA4 Admin → Custom Definitions: if the parameter name in your tag now uses snake_case but the registered dimension uses the old camelCase name, update the dimension's parameter name field to match the new snake_case name.

Step 4 — Note the data break

Changing parameter names is not retroactive. GA4 starts collecting the new snake_case parameter name from the date of the change. The old camelCase parameter stops being collected (it still exists in BigQuery for historical dates). Your custom dimension will have a data gap at the transition date.

Mitigation: If historical continuity is critical, consider running both parameter names temporarily (send both formId and form_id in the same event) during a transition period, then remove the old name after the required historical window has been covered by the new name.

Reference naming convention guide

E-commerce events

Lead generation events

Content engagement events

User property names