Event naming conventions for Mixpanel, Amplitude, PostHog and GA4

Last updated: 21 September 2026.

Report Created, report_created and reportCreated may look equivalent to a person. A destination can treat them as different events. Worse, two developers can send the same name for different moments: one when the customer clicks a button and another when the report finishes successfully.

The first problem fragments your charts. The second makes a clean-looking chart answer the wrong question. Naming rules need to address both.

Name the business fact before choosing the casing

Start with the object and the completed action. For a reporting product, report_created should represent an agreed creation outcome. If the system needs several minutes to generate the report, use separate names such as report_generation_requested, report_generation_succeeded and report_generation_failed when those distinctions support a real decision.

Do not call all three report_created and hope that a success property will make every analyst select the right rows. It can be better to use one event with an explicit outcome when the analysis consistently needs all attempts, but make that design choice deliberate.

Define the trigger, non-trigger and counting unit beside the name. An event could mean one completed job, one saved object or one user's interaction. Those units produce different totals.

Twilio's collection best practices recommend an object-and-action structure, consistent casing and properties for variable context. The convention works because a person can infer the general meaning, while the event definition supplies the details a name cannot carry.

Use a canonical name and a separate display label

For a new multi-tool implementation, a reasonable custom-event policy is:

• Use lowercase snake_case, starting with a letter.
• Choose a domain object followed by a specific action or outcome.
• Keep names short enough for the most restrictive destination you intend to use.
• Put identifiers, plan names, dates and UI locations in properties.
• Keep a readable display label and full description in the tracking plan.
• Reserve tool-specific names and fields for their documented functions.

Examples include workspace_created, member_invitation_accepted, report_export_succeeded and subscription_cancellation_requested.

This is an implementation recommendation, not a universal requirement from Mixpanel, Amplitude or PostHog. An established, consistently implemented Title Case taxonomy can be perfectly usable. Do not migrate it merely to make the raw names match someone else's preference.

Mixpanel's Lexicon distinguishes an ingested name from its display name. Amplitude's display-name documentation similarly says that changing a display label does not change raw data. Use these facilities when the problem is readability rather than event meaning.

For example, the raw name report_export_succeeded can display as “Report Export Succeeded” without requiring every producer, warehouse query and integration to change.

Account for GA4's rules explicitly

Google's event naming rules require event names to start with a letter and use letters, numbers and underscores rather than spaces. Names are case sensitive. Google also maintains reserved names and prefixes, with differences between web and app contexts.

The collection limits set a 40-character event-name limit for tag and SDK collection. A conservative internal rule is to keep custom names below that limit, leaving room for future clarity without relying on the boundary.

Check event names, parameter names and user-property names separately. Their limits and reserved fields are not interchangeable. A parameter being accepted in an event does not necessarily mean you can register the same name as a new custom dimension.

Do not reuse automatically collected names for unrelated business facts. For instance, calling a completed application report page_view makes its meaning conflict with page measurement. Also avoid inventing custom fields that shadow a destination's identity or timestamp fields.

Maintain the relevant reserved-name checks from the current documentation. A short copied list in an old spreadsheet will eventually become incomplete.

A Segment Title Case event does not automatically break GA4

Segment recommends Title Case in its general collection guidance, while GA4 does not accept spaces in raw event names. That does not mean every Segment-to-GA4 integration fails.

The current GA4 Cloud destination documentation says Segment replaces spaces with underscores and offers a Lowercase Event Name option for custom events. It also supports explicit action mappings.

The practical problem is knowing which transformation your configured path performs. Report Created could become Report_Created or report_created, depending on that configuration. A separately instrumented browser event might use a third spelling.

Record the final destination name rather than relying on a connector's default. Check whether two source names collapse into the same output after lowercasing or replacing spaces. Plan Selected and plan_selected should not accidentally become two producers for one apparently clean destination event.

A successful transformation also does not prove that properties, identity or timestamps mapped correctly. Inspect a received event in the destination.

Map standard destination events by meaning

Some destination event names carry documented semantics and parameters. Google publishes a recommended event reference, including events for sign-up, login and purchases.

Map your canonical event to one of those only when the meaning matches. user_registered can represent a completed sign-up if that is its trigger. A click on “Create account” does not establish the same fact.

Similarly, a GA4 purchase mapping needs a real purchase definition and the relevant transaction and item data. Renaming a billing-page visit to purchase will make a conversion number move without improving measurement.

An illustrative registry can keep these mappings visible:

events:
  user_registered:
    display_name: User Registered
    trigger: persisted_user_registration
    unit: newly_registered_person
    destinations:
      mixpanel: user_registered
      amplitude: user_registered
      posthog: user_registered
      ga4: sign_up
  report_export_succeeded:
    display_name: Report Export Succeeded
    trigger: export_job_completed_successfully
    unit: export_job
    destinations:
      mixpanel: report_export_succeeded
      amplitude: report_export_succeeded
      posthog: report_export_succeeded
      ga4: report_export_succeeded

This is a planning format, not vendor configuration. The real adapter also needs approved property mappings, identity, timestamps and event-delivery rules. You do not have to send every event to every destination; list only the routes that support a defined use.

Open full diagram

Put context in properties without creating another taxonomy problem

Prefer report_export_succeeded with export_format: pdf over separate event names for every file format. Prefer plan_selected with a stable plan code over names that embed a changing commercial plan label.

Keep property names and types consistent. A boolean should not alternate between true, "true", 1 and "yes". A duration needs a documented unit such as milliseconds. A money amount needs a currency and a clear representation.

Use enumerated values when a property supports a limited set of choices. For example, export_format might allow pdf and csv. Introduce a new value through the same review process as a new event if it changes reporting or downstream behaviour.

Avoid putting arbitrary user text, email addresses, tokens or full URLs with sensitive query parameters into event names. Review property contents too. Moving a value from the name into a property does not make it appropriate for every destination.

Separate properties recorded at event time from a person's current profile. If you need to know which plan the account had when the export occurred, record that context with the event or join to reliable historical state. A current profile value can answer a different question.

The tracking plan guide provides the wider contract for triggers, fields, ownership and allowed destinations.

Validate syntax and mapping collisions before release

A basic syntax check can catch spaces, unexpected casing and overlong names. It cannot tell you whether the event represents the right fact.

The following Python example implements the conservative custom-name policy above and rejects duplicate destination names. It is intentionally stricter than some vendor APIs, and it is not a complete GA4 reserved-name validator.

import re

def validate_custom_mapping(mapping, reserved_names):
    seen = {}
    for canonical, destination in mapping.items():
        for name in (canonical, destination):
            if not re.fullmatch(r"[a-z][a-z0-9_]{0,38}", name):
                raise ValueError(f"Invalid custom event name: {name}")
        if destination in reserved_names:
            raise ValueError(f"Reserved destination name: {destination}")
        if destination in seen:
            raise ValueError(
                f"Collision: {canonical} and {seen[destination]}"
            )
        seen[destination] = canonical
    return True

custom_events = {
    "report_export_succeeded": "report_export_succeeded",
    "workspace_created": "workspace_created",
}

validate_custom_mapping(custom_events, {"page_view", "session_start"})

The two names in the example denylist are illustrative, not Google's full list. Keep standard-event mappings in a separately reviewed registry so an intentional sign_up or purchase mapping is not confused with an arbitrary custom event.

If two producers intentionally map to the same event, require equivalent triggers and an agreed deduplication rule. Do not bypass a collision check merely because both teams prefer the same dashboard label.

Rename without manufacturing a growth spike

First determine what is changing.

If only the label is unclear, a display-name update may be enough. If the trigger or counting unit changes, treat it as a semantic change. A historical click and a future completed operation should not be presented as one unchanged measure.

Before changing a raw event name:

1. Inventory its producers, destination mappings, saved reports, audiences, experiments and warehouse models.
2. Record the old and new definitions, the reason for the change and the release boundary.
3. Update consumers to understand the transition where appropriate.
4. Test the new producer in a separate environment or controlled release.
5. Compare known actions against received events and published metrics.
6. Remove obsolete production emissions after the agreed migration period.

Avoid dual-emitting old and new events into a metric that counts both. Ten real exports can become twenty events without one extra customer action. If a migration requires overlap, preserve an operation identifier and define how each report avoids double counting.

PostHog's Actions documentation describes combining related events for analysis and giving them a useful name. That is an analytical definition over events, not proof that historical raw records have been rewritten. Document equivalent distinctions in each destination.

For an incompatible definition change, use a new event or a versioned metric and annotate the reporting break. Keeping a continuous line is less valuable than keeping a truthful one.

Give the convention an owner and a practical review rule

Store the registry near the implementation or in a controlled tracking-plan tool. Each event should have an owner, purpose, definition, properties, destinations and the reports that depend on it.

A proposed event earns its place when someone can name the decision or debugging question it supports. “We might need it later” is a weak reason to collect a new stream of detailed customer behaviour.

Review changes at the same time as the product change. The engineer knows where success is actually committed; the product or growth owner knows which outcome matters. Agree before a name becomes part of production history.

For the wider implementation, use the SaaS product analytics setup guide. If the existing taxonomy is already fragmenting decisions across tools, our product analytics service can help map the definitions and migrate the events without disguising changes in meaning.