The most important step before you begin sending data to any analytics platform is to Build a Customer Data Tracking Plan that outlines which user behaviors to track, why they are important, and how they are defined. Each event should be given a unique name that is clear, concise, and consistently applied across your data model.
It’s very common for different teams to track events differently, or to use different formal and informal terms to explain user behaviors. This can lead to a collection of events that are difficult to read and analyze. Over time, inconsistent naming can create confusion among your users and inhibit adoption of analytics tools.
Indicative is not case sensitive and will not rename event names or casings; whatever event name a customer sends will be reflected in Indicative as the “Event Key.” This is why it’s important to Review Your Events and Properties in Settings, especially during the integration and validation phase of onboarding.
When multiple teams rely on the same data, it’s important that everyone understands what the data collected means. We recommend using an object-action framework for event naming.
An object-action naming convention is clear and concise. It begins with an object- that is, the “thing” with which a user interacts.They are typically nouns that refer to the components that make up your digital product or website. "Screen", “page”, “form”, “button”, “email”, and “link” are examples of common objects.
Next, think of the actions that a user can perform when interacting with those objects. “View”, “submit”, “swipe”, “click”, “open”, “install”, and “cancel” are examples of common actions, or verbs, that users perform.
Finally, pair each object with the actions that a user performs on the object. “Page viewed”, “link clicked”, “form submitted”, and “song played” are examples of object-action event names. An object may have multiple actions, too, for example “song played”, “song paused”, and “song skipped”. Some customers prefer to use an action-object framework. For example, “viewed page”, “clicked link”, “submitted form”, and “played song”. What is most important is that whichever system you choose, it’s applied consistently across your data model.
Here are some common sources of errors and problems in event naming conventions.
Case >> choose one casing style. Here are five examples of casing options.
- Proper Case : Account Created
- Sentence case : Account created
- all lowercase : account created
- camelCase : accountCreated
- snake_case : account_created
Tense >> choose present tense or past tense. For example “email open” or “email opened”.
Remember that the most important consideration is to choose a single naming convention and stick with it.
In addition to event names, you should standardize a naming convention for your Event Properties and User Properties as well. Properties describe the context of the event, enabling grouping, filtering, and cohorts. Follow the same considerations outlined above and apply your choices consistently across your data model.
We recommend using ‘Proper Case’ for event names and ‘all lowercase’ for property names. This will create a visual cue for users to differentiate between events and event properties.
Remember, any event property can be enabled as a user property within the User Properties dropdown in Settings. Using the same naming convention for both will make this easier.
Document your chosen naming convention within your tracking plan and make sure to implement it in code with the same formatting. The only thing that really matters is that you keep it clear, concise, and consistent!