How to properly declare events for analytical purposes?

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.

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 https://segment.com/docs/destinations/kochava/#endpoint).

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).

Segment tracking plan

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 Up, Subscribed,…. 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).

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.

Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

You can adjust all of your cookie settings by navigating the tabs on the left hand side.

Strictly Necessary Cookies

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.

disable

If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.

Google Analytics

This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.

Keeping this cookie enabled helps us to improve our website.

disable

Please enable Strictly Necessary Cookies first so that we can save your preferences!

Additional cookies

This website uses the following additional cookies:

FB pixel

Albacross

disable

Please enable Strictly Necessary Cookies first so that we can save your preferences!