Keep analytics event names stable as your product evolves

Choose event names that stay useful in reports, match WhoVisited goals exactly, and change their meaning without breaking your conversion history.

An event name becomes part of your measurement contract

A custom event starts as one line of code, but its name can also be the value of a conversion goal, a filter in a report, and a label in a spreadsheet. If one release sends `demo_request`, another sends `demo_requested`, and a third sends `DemoRequest`, the application may still work while your trend quietly splits across three rows. Treat event names as a small public interface between your product code and your analytics.

This matters most for events that represent a business outcome: a signup completed, a demo request accepted by your server, or a report successfully exported. Name the outcome rather than the UI control. A click can be useful as a separate interaction event, but it does not prove the action succeeded.

Define a small vocabulary before adding more events

Use one predictable style, such as lowercase words joined with underscores: `signup_completed`, `demo_request_submitted`, or `report_exported`.
Describe the thing that happened, in past tense when it marks completion. Keep attempts and completions separate if both help answer a real question, for example `checkout_started` and `purchase_completed`.
Write down the trigger in plain language. For `demo_request_submitted`, say whether the event fires after client validation, after the server accepts the form, or after a human schedules the meeting. These are different outcomes.
Use properties for harmless context that varies while the action stays the same, such as `plan_tier: "starter"`. Do not send email addresses, form contents, payment details, or other personal data as properties.

WhoVisited currently accepts custom event names that start with an ASCII letter and contain only letters, digits, and underscores, up to 64 characters. Names are matched exactly, including letter case, and `page_view` is reserved for page views. Keep a shorter internal rule if it makes review easier, but validate against the product's actual limits rather than assuming every analytics tool has identical rules.

// Send after the server confirms that the request was accepted.
window.whovisited?.track("demo_request_submitted", {
  plan_tier: "starter"
});

The example property is optional context; the event name carries the stable action. Keep properties bounded and non-sensitive. WhoVisited limits each event to 20 properties, property keys to 64 characters, and string values to 256 characters.

Make the goal use the same exact name

When you create a WhoVisited custom-event goal, its match value must be exactly the event name your site sends. `demo_request_submitted` does not match `Demo_Request_Submitted`, and a successful test of the button click does not validate the server-confirmed submission event. After installation, open Settings, create or select the goal, trigger a real test submission, and use the goal's test action to check that the expected event arrived.

WhoVisited counts a session as a goal session when that session contains at least one matching event. Sending the same event several times in one session does not create several goal sessions, but duplicate events still make raw event counts harder to interpret. Add a client-side guard or use an authoritative success callback when an interaction can fire more than once. See the [conversion tracking guide](https://whovisited.net/guides/traffic-source-conversion-tracking) for the difference between a success-page goal and a custom event.

Change an event only when its meaning changes

Do not rename an event just because a button label or component changed. The event should describe the user's outcome, so the interface can be redesigned without changing the measurement. If the business meaning really changes, introduce a new name and update the code and goal deliberately. For example, if `demo_request_submitted` used to mean that a form passed browser validation but now means the server saved a request, the old and new series represent different things and should not be blended as though nothing changed.

Search the codebase and tag manager for every producer of the old name before changing it.
Record the old and new definitions, the release date, and the reason for the change next to your event catalogue.
Update the goal to the new exact name and verify a fresh event. Use a new goal if you need to compare the old and new definitions separately.
Annotate charts or exported reports at the change date; a visible step in the trend may reflect a definition change, not a sudden product change.

Retained historical WhoVisited events keep the names they were originally sent with. A goal created today can match retained events with that exact name, but changing your code does not rewrite old event rows or make two different names equivalent. The report also has a selected date window, so confirm both the goal definition and the reporting period when interpreting a transition.

Review the contract during code review

Is the event tied to a confirmed outcome, and does the name describe that outcome?
Does the name follow the team's spelling and case convention and WhoVisited's allowed format?
Does the matching goal use the exact same value?
Are properties limited to useful, non-sensitive context?
Will this code path fire once for one completed action, or can retries and repeated clicks send duplicates?
If the event changed meaning, have you recorded the definition change so future reports can explain the break?

Google Analytics has its own event naming rules and recommended event catalogue. Those conventions can help a team think about consistent names, but they do not automatically configure a WhoVisited goal or guarantee that the same event definition is portable between products. Keep your own short event dictionary as the source of truth for what each event means.

Keep reports tied to the behavior you actually measure

An analytics event is a signal emitted by your implementation. WhoVisited validates its shape and uses the name you send; it does not independently verify that a signup, payment, or meeting occurred in your business system. Emit outcome events from a success path you trust, keep their meaning stable, and revisit the definition when that path changes.

For comparison, read Google's official [event naming rules](https://support.google.com/analytics/answer/13316687?hl=en) and [recommended event reference](https://developers.google.com/analytics/devguides/collection/ga4/reference/recommended-events). They apply to Google Analytics; WhoVisited uses the limits and exact goal matching described in this article.