Event names are generally ignored by analysts and developers alike, and PMs don’t even care to ignore them, but they have a huge impact on data quality and analytics output.
Seems unlikely, right? We get used to whatever events are named and memorize them over time – incorrect spellings, odd capitals included. But getting used to something does not mean it can’t be better.
I understood this purely by chance when I had a bit too much time in 2020 to plan events for a new app. So, i listed down all the issues i had faced due to event names in the past many years of query-writing. Then I came up with a set of rules to fix those issues.
Months later, when the new app was live with new events, we immediately felt the difference.
We were writing queries twice as fast, developers were making less errors in implementing the events and new hires were able to write queries by looking at the documentation.
In the last 2 years, I have worked on multiple event tracking setups for Shopify clients.
In such companies, events are setup through the Google Tag Manager and does not require developer time. In short – I was able to add new events myself. This freed me up to go deeper into event naming and further refine my ideas.
The first thing to decide is how much information do we want to store in a name.
Generic vs Specific names
Broadly, there are two extremes when it comes to naming events –
- Generic names: We stick with few event names and store a lot of parameters to get the information we want. For example, we trigger ‘product_card_click’ for all click events on product card on the site.
- Specific names: We create a lot of events with different names, so we don’t need to check the parameters for context. For example – click_pdp_recommended_product_add_to_cart – tells us everything we want to know.
Generic events take less time to setup in Google Tag Manager. Specific events lead to fast and more accurate querying. Implementation is a one time task, querying is a repeat task. It’s easy to see the better choice here.
However, having too many specific events can make it harder to write queries over time. So the best approach is to find a middle ground based on your data instict:
- specific names for actions that are important and will often be part of queries
- generic names for rarely analysed pages like About or Blogs.
- generic names for are rarely analysed actions – like ‘share’ or login flow.
Whatever you choose, if you don’t document each event cleanly, you will end up confused.
Although we are giving specific names instead of generic ones, we are still referring to a small set of user actions like click, scroll, impression, etc. In the next section, let’s look at the various event types for Shopify stores.
Name structure
This is the really important bit.
All event names should follow this structure – [event_type]_[page]_[optional section name]_[optional position identifier]_[action and or target]
- Event_Type : The type of event, as explained in the section below.
- Page: Page type. Example – product, cart, checkout, home, collection.
- Section name: Name of the section, like ‘recommended’ or ‘recent’ or ‘upsell’. I am using full names for clarity, but i often shorten this while implementing the event.
- Position identifier: Position identifier for sections that are repeated on a page. For Example – websites often have multiple add to carts so we can identify them with – sticky, top, bottom.
- Action: This is the action triggered by the button. Example – login, checkout.
- Target: If this button takes user to another page, this is the name of the page. Example – product, collection, etc.
For example, a click on ‘recommended products’ product card on a PDP:
- Event type – click
- page – product
- part – recommended
- optional position identifier – not needed.
- action – view product page
- target – another product page
So the event name could be – click_product_recommended_show_product. Yes, it’s a bit messy and long. In the past, i would have called it – reco_item_click_pdp – shorter and nicer, but makes for poor querying.
For a sticky add to cart, this could be –
- Event type – click
- page – product
- part – not needed.
- optional position identifier – sticky.
- action – add_to_cart
By fixing this structure for giving names, we are standardizing the process of coming up with event names. This means anyone in the team can create names and they will be consistent. This also means that you can easily check for incorrect names by running a well written query.
Page, Part and position are straightforward. In the next 2 sections, I provide a list of event types and action/target values.
Event Types
The first part of a name is the event type. This tells us what the event represents. In this section, we will list out all the event types for Shopify stores.
Now, Shopify stores have simple websites. Users can only perform one type of action – click. We can use ‘click’ for all these event types, but I prefer to have 3 event types – click, select, toggle.
I use them for the following cases:
- click – for all important actions, and all actions that trigger a page change.
- select – For less important actions, mainly related to engagement on product pages.
- toggle – Specifically for toggles, although ‘select’ works as well.
Additionally, we get Form Submit event from GA4 for forms. But it doesn’t add much value for D2C stores.
In response to user actions, the website can do a few things – load a new page, show a popup, trigger a checkout. We get events from GA4 for these and they are enough.
The other part of user experience is what they are seeing because a lot of interactions don’t involve any clicking. We can measure this with the below events:
- scroll, impression events to track visibility
- popup events for popups
Since these are information heavy websites, we want to track if user is looking at something for a few seconds.
for these cases, we use ‘impression’ events.
I prefer ‘impression’ over ‘view’ because GA4 has multiple automatic events starting with ‘view’ which can cause confusion (view_cart, view_item, etc.).
Action/Target
All user actions have one of the below functions. To keep names short, most of these are just the name of the target. For actions without a clear target, you can use the action name as the text, like ‘initiate_checkout’, ‘initiate_login’, etc.
| Action | Text for event |
|---|---|
| Product Card click to open another page | product |
| Add to Cart from anywhere | atc |
| click on a collection link from menu, or from a banner | collection |
| click on a blog link | blog |
| Remove an item from cart | remove |
| Add/Subtract the quantity of an item | plus, minus |
| Click on product or review image or video | image |
| Click on product or review image or video | video |
| Toggle a FAQ | faq |
| Toggle or click on a information tab | info_tab |
| initiation checkout or continue shopping | checkout, continue_shopping |
| For all other actions | action name |
Exceptions
It’s important to remember that these rules and conventions are only guidelines for better and easier querying.
The goal is to have great events to work with. A key part of this is making exceptions. As i mentioned above, if there are some common actions which are not very important, you can ignore the convention.
Here are some examples:
- share buttons on product cards. It’s not a common action for most D2Cs. So just create a generic event called ‘share’ and be done with it
- +/- buttons on product cards – again, users don’t use these buttons as much. So i name all + buttons as – click_product_card_plus, click_product_card_minus
Leave a Reply