Event naming convention

It's crucial to keep your event naming conventions organized and keep your team aligned on them. If not, many issues can arise, such new team members instrumenting events that have already been instrumented, teammates not being able to find the events they need to make decision etc.

The standard is "Category - Action - Label," which is what I use for any platform. For example, Checkout - Add Payment - Credit Card. Label is oftentimes optional but helps with providing context.

Event & user properties

I'd first think about exactly what you want to learn about the user/event and why you are instrumenting it in the first place. Next I'd think about some of the analysis you'd want to do in the future. Instrument the properties that will be needed to perform the analysis. It's always better to over-do it with event/user meta data. If you discover something is not needed in the future, you can always remove the properties from your tracking calls.

I think there are three components:

1/ Naming convention (as already described by @feifanw)

I personally go for « Item Verb » like « order completed » or « file uploaded ».

2/ Properties

IMHO you’d rather have too much information than not enough. Nothing worse than finding out you’re missing crucial data because you didn’t track it previously.

3/ Dictionary

In order to keep a good data hygiene, I recommend building a database of user properties, events, and events properties.
I built something with AirTable to be able to keep that in check and ensure I don’t make mistakes. It’s super easy to cross reference records with each other and maintain sanity.

Good question! We use Heap Analytics at work and I love it.

Heap Analytics allows you to define events by pointing to elements in the interface. For example, to start tracking clicks on a button, you can just point to the button. Heap will make a note of the button's properties (like the class or ID), and start tracking clicks on it. It's quite simple.

The problem is that divs and classes keep changing all the time, and this is something we realized early on. We now ask engineers to send the event based on a product manager's request, directly using the Heap API. This ensures that our events don't break later when the names or classes or IDs of frontend elements change.

I always ensure I provide enough detail in the event name. Even someone who didn't create a particular event should be able to read the name of the event and understand it instantly. For example, I have event names that go like this:

• 'Clicked on widget banner in the admin section'
• 'Landed on the widget settings page'
• 'Clicked on the button to create a new widget'

This really helps ensure your team never has to talk to you to figure out what event tracks what, when they're doing some research. It is definitely a good idea to establish naming conventions upfront in your team when you start using an analytics tool.

Heap Analytics also provides folders, so it's pretty easy for me to create a funnel or a set of events and organize them into folders, based on the product features I'm tracking.

We serve other businesses, so our user properties contain an account's subscription plan details, the MRR we charge them, the number of members in an account, etc. You need to ensure that the data you send to your analytics tool is devoid of details like email addresses in a lot of situations (to comply with regulations).

Hope this helps!