DJ's Portfolio - Event Tracking Framework

Home ▶ Tools & Processes ▶ Event Tracking Framework

PROCESS • ORG: Delivery Hero

Transforming Event Tracking
Streamlining Efficiency & Standardization

June 2022

Project Overview

Currently, event-tracking documentation resides in Google Sheets, a process that lacks efficiency and standardization. Our goal is to optimize event tracking from design to data & analytics. We capture the Remote Procedure Call (RPC) in Figma, initiated by Dev/PM comments on specific screens, with the Design team manually transferring this information to the Figma canvas.

Problem Statement

The existing process is cumbersome, prone to errors, and lacks consistency. It hampers collaboration between design and development teams, leading to delays and inaccuracies in event tracking.

Objectives

Our primary objective is to enhance efficiency and standardisation in event tracking. Specifically, we aim to:

Reduce Errors: Decrease the likelihood of errors in event tracking data.
Improve Efficiency: Streamline the process from design to data & analytics.
Enhance Collaboration: Facilitate seamless communication between Dev/PMs and Design teams.

Strategic Value

Achieving these objectives aligns with the broader project's strategic value by:

Accelerating Development: Reducing errors and improving efficiency ensures that development proceeds smoothly, saving time and resources.
Enhancing UX: More accurate event tracking improves user experience.
Supporting Data-Driven Decisions: Standardization empowers data & analytics teams to make informed decisions based on reliable data.

Team

Shyam Sundar, Head of Data Science
Dhananjay Garg, Senior Product Designer
Lakshmi, Hazel Teng, Pierre-Philippe, Jingwen Ng, Product Management Team

Final Event Tracking Flow (in Figma) + Common Component Events

Naming Convention for component_name

<component_type(acronym)>_<screen_type>_*<screen_type_child_branches>

Examples

scr_wallet
scr_wallet_monthly_limit
scr_p2p_choose_recipient

Event Tracking Process (for Designers)

Base UI Event flow for user behavior

- Designer designs the screens & UI components
- Every screen to have a unique name
- Each component within the screen to have three letters acronyms that act as prefixes to component name, e.g., btn_<screen_type>_XXXX
- Each component to be named after text displayed in Figma, e.g., btn_airtime_buy_load_now
Data Analyst to verify events
- Call out additional event payloads where required
- Log events into a common database/spreadsheet

Frontend UI developers to implement where required

Implementation to be validated QAs in Google Analytics

Backend Event flow

The need for backend flow could be by process design or/and by the sensitivity of information sent to the tracker. For example, we might want to avoid sending a rejection reason to the app when we want that to be tracked in GA.

PMs to detail backend flow along with UI / user behavior flow
Data Analyst to verify events
- Call out additional event payloads where required
- Log events into a common database/spreadsheet
Backend developers to implement where required
Implementation to be validated QAs in Google Analytics

Tracking Options Compared

Google Sheets

✅ Team members can compile to see the end-to-end journey in one place
✅ Event names can be referred to in Figma, which is already being done
❌ Need to update manually when there's a new design
❌ Can become too big to maintain when we track many events
❌ Adds to another source of truth that needs to be maintained

Figma

✅ Team members can visually see the screen and Event information in one place
✅ It has worked on how we capture RPC calls
✅ Aids in complete automation of the process
❌ We have multiple files, so there may be difficulties when the data team wants to search for something
❌ Additional work for the design team
❌ Only the design team will have the edit rights, so the dev/PM needs to inform us when there's an update

Why choose Figma over Google Analytics (GA)?

Dealing with too many events

Too many events in Google Analytics to filter through
- We can rely on Figma to locate the event generator
- User can go to Figma and refer to the flow to construct the funnel
Increase in cost of data storage and querying
- We were not yet at that scale, but it is a good problem to solve
- Problem deferred for consideration until we get a large enough bill

Event Tracking Process (for Devs)

Developer goes into the Figma file

Developer wants to implement an event label for the transfer button
Dev searches for the component name by selecting the button
The name of the button will be found on the layout panel on the left

The name of the component is found as "btn_transfer".
Developer implements event label as indicated in Figma for every component developed. For any customizations, Devs will refer to this sheet ( ).
- If possible, the variable name in the UI code corresponding to that instance can be maintained to be the same as the event label
  Eg: btn_transfer = Button(event_label="btn_transfer")
- This allows seamless search/discoverability of components across Design, Product, and Data
During testing, the important events are verified if they appear on the analytics layer.

Event Tracking Process

1. Instrumenting event tracking from Figma

2. How can anyone explore & perform analytics

Source of Truth: Why do we need this

Why do we need this?
Analysts or PMs should know which event is coming from where so that they can construct funnels. With a clear indication, this can become relatively smooth.
Who would own the task of setting event names?
Few options exist

Designers owning element names (for every element)

Through the Figma naming convention
- Screen Name specified as per convention
- Component Name for each component (instead of "Button") in the layout panel
- Developers and Analysts can refer Figma file

Screenshots with labels (could be in Figma with element names as labels)
- Designers specify names in a screenshot representing a master screen
- Developers to refer to the labels during implementation

Developers via Google spreadsheet (for every element)

Developers would populate the Google Sheets with details of elements & screens during implementation

PMs or Analysts (for required events)

Work through KPIs, metrics, and conversion funnels
Mark and list events for those funnels
Runs a risk of creating parallel work streams and governance issues for managing events at scale.

Learnings

Adoption Challenges: Initially, there was hesitance among team members to embrace Figma as the central repository for event tracking, as some believed it could overly complicate the design process.
Consistent Tracking: Developers diligently followed naming conventions and continued tracking events in Google Sheets before introducing the new Figma-based system.
PM Preferences: Project Managers (PMs) maintain event tracking records. They prefer Google Sheets over Figma for this task due to their comfort with the existing process.
Cross-Platform Reference: To facilitate alignment between PMs managing event tracking in Google Sheets and developers working in Figma, screen names from Google Sheets can be mirrored in Figma, providing a helpful cross-reference point.

Short-term & long-term suggestions

Short-term:

- Use Google Sheets and standardize the events.
- Meanwhile, designers work with devs, analysts, and PMs to arrive at joint management of events across design, software, and data analytics (warehouse & Google Analytics)

Long-term: