Events, parameters, and key events that mean something

Use the simplest event type that fits

Automatically collected events arrive as part of the basic GA4 measurement. Enhanced measurement can add common web interactions from the data stream settings, such as scrolls, outbound clicks, site search, video engagement, and file downloads. Check what is enabled instead of assuming every interaction is covered.

Recommended events are Google’s suggested names and parameters for common actions across industries, such as sign_up, login, add_to_cart, begin_checkout, and purchase. Custom events are names you define when no recommended event fits. Recommended events are a shared language; use them before inventing your own.

• Automatically collected: supplied by the base measurement.
• Enhanced measurement: optional common interactions configured in the stream.
• Recommended: Google-defined naming patterns for common actions.
• Custom: your own event when no suitable recommended event exists.

Parameters make reports worth reading

A button_click event tells you very little on its own. Parameters such as button_name, page_location, and destination can explain which button was clicked, where it appeared, and what happened next. Collect detail that will change an analysis or decision—not every attribute you can find.

For a custom parameter to appear conveniently in standard reports, you may need to register it as a custom dimension or metric. Registration does not rewrite data collected before the parameter was registered. Plan names and types early, and keep a dictionary of what each value means.

gtag('event', 'generate_lead', {
  form_name: 'demo_request',
  form_location: 'pricing_page',
  lead_type: 'sales'
});

A key event should represent value

A key event is an event you mark as especially important to the business. Purchases, qualified leads, and completed sign-ups are common candidates. A scroll or timer might describe attention, but it rarely represents business value by itself.

Marking an event as key does not make its tracking correct. Validate the trigger, parameters, and deduplication first. If you use Google Ads, review how GA4 key events are imported or used as conversions there rather than assuming every advertising setting is inherited automatically.

Build a practical event dictionary

An event dictionary is the authoritative list of what your team collects. For each event, record its business meaning, exact trigger, parameters, expected values, owner, and test cases. Also record whether it should be marked as a key event and where analysts will use it.

Use names that describe completed actions rather than vague interface activity. “generate_lead” after a validated submission is clearer than “form_click.” A click on Submit may be followed by a validation error; treating the click as a lead would inflate performance. Trigger at the point where the business action is actually accepted.

Recommended events help GA4 and third-party tools recognize common behavior. Custom names are appropriate for genuinely distinctive actions, but they need more documentation. Avoid near-duplicates such as signup, sign_up, and SignUp that fragment reporting for no benefit.

Design parameter names, types, and allowed values

Choose stable names and data types before release. If form_name sometimes arrives as “Demo Request” and sometimes as “demo_request,” reports split the same form into separate rows. If price is a string in one release and a number in another, downstream calculations and BigQuery queries become harder.

Use event parameters for details that can change with each interaction. Use user properties sparingly for durable, non-sensitive attributes that GA4 supports in that role. Keep item details inside the ecommerce items structure rather than flattening every product attribute into a long list of unrelated event fields.

Avoid parameters whose values are effectively unique for every user unless you have a clear raw-data use case. Order IDs can be essential for purchase deduplication and BigQuery analysis, but registering every high-cardinality value as a reporting dimension is rarely useful. Group values when a category answers the question better.

// Good: a stable, documented payload
gtag('event', 'generate_lead', {
  form_name: 'demo_request',
  form_location: 'pricing_page',
  lead_type: 'sales'
});

// Avoid: personal data and inconsistent naming
gtag('event', 'LeadSubmit', {
  email: 'person@example.com',
  FormName: 'Demo Request'
});

Separate event collection, key events, and advertising conversions

These ideas are related but not identical. First you collect an event. Then you may mark it as a key event because it matters to the business. Separately, an advertising platform can use a conversion for reporting or bidding. The names and settings should be reviewed in the specific product rather than assumed to be universal.

Suppose generate_lead fires for both newsletter and demo forms. You might mark only a more specific lead event as key, or use separate events if the business meanings differ. The right choice depends on reporting and activation needs. Do not mark every event as key simply because the option exists.

Validate before changing key-event settings. A key event based on an unreliable trigger creates reliable-looking bad metrics. Also consider counting rules and duplicate prevention, especially for purchases and leads that can be submitted again after a page refresh.

Work through a complete lead-tracking implementation

Start with the business definition of a lead. Decide whether a newsletter subscriber, a contact request, and a demo request are equivalent. Then inspect the form behavior. Does success replace the form, display a message, call an API, or navigate to a confirmation page? The trigger should follow the confirmed success signal rather than an unreliable assumption.

Implement generate_lead with the smallest useful context. Test empty submissions, validation failures, successful submissions, double clicks, refreshes, and back-button behavior. Confirm that personal form values never enter the payload or URL. Register necessary custom definitions after the payload is validated.

Finally, document the report interpretation. If one user can submit the same form three times, event count is not the same as unique leads. Explain whether stakeholders are looking at submissions, submitting users, or session key-event rate. For a definitive lead total, reconcile with the system of record rather than expecting GA4 to replace it.

Worked example: measure webinar registration and attendance

A training company offers a webinar. Registering is an on-site business action; attending later happens in a webinar platform. These are different statuses and should not be collapsed into one event. The website can send sign_up or generate_lead according to the approved measurement design, with event_name and webinar_topic as non-personal context.

Attendance may require an approved offline or server-side integration if it must appear in GA4. The team needs a pseudonymous way to relate the outcome, a timestamp reflecting when it happened, and a clear rule for whether registration or attendance is the advertising optimization signal.

Reports should distinguish registrations, registered users, attendance outcomes, and the time basis of each. GA4 can support parts of the journey, but the webinar platform remains the authority for who actually attended.

Event design review questions before release

A good event survives stakeholder questions months later. Its name describes a stable business action, its trigger represents confirmed behavior, and its parameters add context that someone will actually use. Its documentation also states what the event does not mean.

Review the event against failure and duplication scenarios before registering custom definitions or marking it key. Once an event feeds reports and advertising, correcting its meaning becomes more expensive and may create a trend break.