# Naming review checklist

Run this on every proposed event list, rename or new property before it reaches production. Each item names the evidence to look at and what a pass looks like. Record the result in the registry entry or pull request.

## Contents

- Meaning
- Syntax and vocabulary
- Properties
- Destinations
- Renames and history
- Ownership

## Meaning

- One fact per name. Evidence: the trigger in the contract or code. Pass: the name describes the committed state change, not the click or request that precedes it (`report_export_requested` and `report_export_succeeded` are separate when both matter).
- One meaning per name. Evidence: every producer that emits the name (browser, server, iOS, Android, CDP route). Pass: all producers fire at the same moment for the same unit, or only one producer exists.
- A counting unit. Evidence: the registry entry. Pass: it says what one event represents (one export job, one saved report, one person). A batch job and the files it produces are two events with two units.
- Not from UI copy. Evidence: the name against the button label and the translations. Pass: the name comes from the vocabulary, and the interface language is a property (`locale`), so a copy or language change does not create a new event.
- One event per fact, whoever acts. Pass: a keyboard shortcut and a button that commit the same change share one event with `interaction_method`; admin or impersonated actions carry `actor_type` (or a distinct event) and are excluded from customer activation metrics.
- Merged registries. Evidence: both products' definitions of each shared name. Pass: definitions were compared before any product prefix was added, and the product is kept as a namespace in the registry or a property, not as a prefix on identical facts.
- A consumer. Evidence: the metric, report, experiment or workflow named in the registry. Pass: at least one; otherwise the event goes to a backlog.

## Syntax and vocabulary

- Lint result. Evidence: `scripts/lint_event_names.py` output or a manual pass over `linter-rules.md`. Pass: zero unresolved errors; every warning fixed or given a one-line reason.
- Vocabulary. Evidence: the object and action lists in `naming-rules.md`. Pass: every name is one registered object plus one registered action; new terms were added through review, with forbidden synonyms listed.
- Length. Pass: 40 characters or fewer for every name sent to GA4 or likely to be; names over 32 have a recorded reason.
- Reserved names. Evidence: the live GA4 reserved list and the vendor lists in `platform-constraints.md`. Pass: no custom event uses a reserved name or prefix.

## Properties

- Variants are properties. Pass: no format, plan, step, location, date or version inside an event name.
- Types. Evidence: the property list with types across all events. Pass: one type per property name; booleans start with `is_` or `has_`; timestamps end in `_at`; durations and money carry units and `currency`.
- Enumerations. Pass: allowed values listed in lowercase snake_case, with an explicit unknown policy.
- Event-time context. Pass: properties that differ from the current profile value have explicit names (`plan_at_activation`).
- Personal data. Pass: no email, name, phone, address, free text, token or URL with query string in any name or value.

## Destinations

- Final names. Evidence: the destination mapping after every tag and connector transformation (GTM GA4 Event tags and their Event Name field, server-side GTM, the Lowercase Event Name field on each Segment GA4 Custom Event mapping, Protocols transformations). Pass: each destination's received name is recorded and passes M-rules in `linter-rules.md`; no GA4 Event tag forwards `{{Event}}` or another unplanned variable as its Event Name.
- Default and autocaptured events. Evidence: the default events enabled in each destination (GA4 enhanced measurement, vendor autocapture) beside the custom events. Pass: no action is counted by both a default event and a custom one (`form_submit` and `form_submitted`); the one kept is recorded in `decisions.md`.
- Collisions. Pass: no two canonical events reach one destination with the same or case-variant names, unless triggers are equivalent and a dedupe rule is written.
- Standard events. Pass: any mapping to a GA4 recommended event (`sign_up`, `purchase`, `generate_lead`) matches Google's meaning and sends the required parameters.
- Received payload. Evidence: one test event in each destination: GA4 DebugView for gtag.js, GTM and Firebase senders; the Measurement Protocol validation server, then Realtime or the BigQuery export, for Measurement Protocol senders such as Segment's GA4 Cloud destination, which DebugView does not show; Mixpanel or Amplitude live event view; a warehouse row. Pass: name, property names and types arrive as planned.
- Display names. Pass: readable labels are set in Mixpanel Lexicon or Amplitude Data where people read them, and raw names were linted separately.

## Renames and history

- Classification. Pass: the change is labelled label-only, raw rename, duplicates, semantic change or retirement.
- Overlap test. Evidence: one recent full week of daily counts of old, new and their sum against the source-of-truth table, plus an entity-ID join, in the rename plan. Pass: every merge, transformation, PostHog action or warehouse union is over a pair recorded as disjoint; overlapping pairs use the authoritative series or a date split.
- Consumer inventory. Pass: reports, audiences, key events, Ads conversions, experiments, warehouse models and workflows that use the old name are listed with owners.
- Boundary. Pass: deploy time, GTM container version publish time or app version per producer is recorded.
- Late events. Pass: a migration owner decides how events recorded before the cutover and sent late (offline or queued clients) under the old name are read.
- GA4 key events. Pass: the new name copies the old key event's status, counting method and default value, or the difference is recorded with the conversion owner's approval.
- Enforcement first. Pass: the new name is in every blocking schema before release.
- No double counting. Pass: no metric counts both names; any dual emission has its own vendor dedupe keys, a single consumer and an end date.
- Reporting continuity. Pass: Mixpanel merge, Amplitude transformation, PostHog action or warehouse mapping is in place, or the break is annotated.

## Ownership

- Owner. Pass: a named person can explain each event and approve changes.
- Recorded decision. Pass: the naming rules, vocabulary changes and exceptions are in `martech-context/naming-rules.md` and `decisions.md`, approved by the user.