Has a conscious decision been made as to when to track events, and how does this map to the companies cookie & privacy policy?
Most commonly we find clients either:
- Track users anonymously until they consent (e.g. sessionisation), following consent they then track them with server side and client side identifiers.
- Do not track users at all until they consent, and then track them with server side and client side identifiers.
The approach affects the way in which you can connect a users behaviour and journey together. For example, if we do not track a user until they consent there will be some restrictions in terms of attribution and understanding landing page behaviour. But, the second provides the greatest level of anonymity for the platforms users.
Should this event come from the back or front end?
More often than not when we think of tracking we think of tracking front end events, this is because in a lot of cases (not all) you can gather the information of back end events via backend databases. A client might lean towards backend events for reliability, but if they rely on backend events, you will miss out on any of this default captured information and anything that happens in the users local environment. The point to go back to, is tracking backend events only makes sense if the data is not available (or we need to send the data somewhere that isn’t the data warehouse), or when we care about the state changes to an entity that isn’t held within the backend data. But be particularly careful in cases where you are sending backend events without a logged in user you are going to come into some user stitching issues, and need to store your own anonymous id’s that you stitch with front end tracking.
What is the coverage of existing events?
Most (if not all) tracking tools will have an out-of-the-box offering that enables tracking of page/screen views. Being out-of-the-box creates a quicker path to value, and therefore is one of the first events to get implemented. Where this falls down, is in single page applications — limiting what the out-of-the-box events can do. One way around this is to model virtual page views: particularly useful when an interaction, and therefore a change, to the page occurs that we would not usually trigger a reload of the page - e.g. when interactions with a map change the filters of a search.
Is each event its own activity?
How many events do you have implemented? Often, we find that companies have way too many! This quickly becomes un-manageable… if you have more than 50-60 truly unique events then you are likely to hit some maintenance issues!
The first way to review these is consider if any events could be collated into a single event with a property that defines them, e.g. the events home_page_button_clicked, summary_page_button_clicked and title_page_button_clicked could be grouped into a single button_clicked event with the page_type as a property. Find the right level of abstraction.
We will come back to this when discussing building a best in class tracking plan next week - but less events is best when it comes to tracking!
Are your events clearly named so that anyone can understand what they are capturing?
We follow the entity_activity naming schema, this follows a noun-verb format, e.g. booking_placed. This gives a clear idea to the data consumer of what this event is describing!
Are your properties across events named consistently?
Each custom event will have a set of defined properties. These give context to what is happening. There should always be enough properties in the event model to enable you to connect it to the main data model.
When setting properties for events, you want to try and share properties across a single entity. Where these properties are shared it’s key to ensure that they have a clear and consistent name! Having different names for the same information (e.g. event_timestamp, event_happened_at) could confuse the data consumer, and lead to the use of the wrong properties. For instance, with Snowplow you could implement these as contexts shared between events. Very neat :)