How to properly declare events for analytical purposes?

declare events for analytics purposes xxl

Properly declaring events in your app / website is a crucial step to get the most out of your user-centric analytics solution (Mixpanel, Kissmetrics, Kochava, Amplitude, FB / Google – Firebase Analytics,…). You have to dedicate enough time and resources to create an efficient tracking plan.

As stressed in the intro of this Segment’s piece about events tracking best practices: “Your analytics are only as good as the data you’re tracking”. (note: Segment enables you to declare all your events once to feed multiple analytics platforms).

There will be slight variations depending on the solution you will use but the concept is pretty much the same across all platforms.

I see 3 main dimensions (the third one being a specific application of the second one):

  • the event (= what happens) – also called “action” or “activity”
  • properties (= any relevant attributes) – also called “labels”, “keys”, “parameters” or “metadata”, values can be text strings or numbers
  • the context (= where it happens) – also called the “location”, it’s actually a specific type of property / metadata / key

Example: a user entered the signup process (signup = action/name) on the product page (product_page= location/context), with 2 property values depending on the 2 key states of the process: start vs complete, which enable you to see the dropouts on signups initiated in a certain context (Note: in Kochava’s data model, the context isn’t a type of event property, it’s all the info related to the user’s device for server-to-server calls, see

Examples of funnels:

  • Funnel drilled down to product page: event=signup state=start context=product_page to event=signup state=complete context=product_page. 
  • Overall sign up funnel: event = signup state=start to event=signup state=complete (context agnostic).

The idea is that you’ve got to be able to have both an overall bird’s eye view on a sequence of events AND a detailed view narrowed down to a certain context (giving you the ability to compare different contexts).

tracking plan example xl
Segment tracking plan
mixpanel tracking plan xl

Another example: you could determine which signups are purely organic vs the ones coming from referral campaigns by adding a type to the signup event, which 2 values: organic vs invite.

Segment shares with us via this Google sheet how they structured their own event tracking methods. Actions / event names will be used at the highest level when you create a funnel to display the overall customer’s journey. Context-location + other properties will enable you to drill down and come up with insightful variations of your funnel. Note: in Segment’s example, there’s no state tracking (start – complete) for the signup process, which is fine but doesn’t give them the opportunity to notice dropouts in specific contexts.

What if you can’t filter by properties in your funnel view?

If you don’t track state properties (start, complete) OR if your analytics solution doesn’t allow you to filter results by event properties in a funnel view, you can adopt Segment’s own naming convention = give your events a past tense verb name, e.g. Signed UpSubscribed,…. which only tracks completed events.

If you want to see both the start & complete stages without event properties filtering, you’ll have to declare both a completed START and a completed END. E.g. Started Signup – Completed Signup, using additional properties (such as the “page context” or the type of “registration method” (email, Facebook, Google,…)) for further drill down via direct data queries or via another analytics platform. You can for instance get an event-level view on Kochava + filter all records by event parameters / properties on Facebook Analytics (or Mixpanel, etc.).

Worth reading:

On their developers website, Facebook shows you a few examples of good practices to name events and properties (which they call “parameters” for various verticals).

facebook events

A very good guide about using data for better product decisions:

Tracking plan advice from Mixpanel:

Segment Academy, How to create a tracking plan:

If you want to focus on a Google stack, learn how to connect both GA and Firebase to Big Query for cross-platform analysis:

Good to know:

  • Don’t forget to declare the opening post-install event, which can be open_app / app_start, etc.
  • Most analytics solutions have built-in properties for OS, device, country, city, etc. so you won’t have to create specific properties for these attributes.
  • Make sure you use consistent names for your events across all platforms (ios, Android, web, Messenger,…) otherwise you won’t be able to visualise cross-platform funnels.
  • Don’t forget to add a query property to a search event, to see what people are searching for.
  • If some of your events have a transactional value (purchases), don’t forget to add an amount property to the attributes.
  • Please note that some events will be initiated (and buffered when offline)  on the client side (the app / website on your user’s device) whereas other events will be sent from your server (see here Kochava’s example). A proper signup state=complete event should for instance be sent server-to-server. Otherwise you could register completed signups for aborted attempts due to connectivity issues.

🚀 Subscribe to my weekly newsletter packed with tips & tricks around AI, SEO, coding and smart automations

☕️ If you found this piece helpful, you can buy me coffee