From Vision to Implementation: Synergising between Design and Front-End Engineering Teams for Scalable Event Tracking

The Fintech sector is at the forefront of reshaping finance through technological innovations. As user engagement generates data on these platforms, harnessing this information can enhance operations and user experiences, especially in the heavily regulated fintech sector. This entails structured data management and event tracking.

This post explores Cashfree Payments’ journey in developing a robust naming convention, addressing data management challenges encountered during our growth phase. As our design team, product offerings, and user base expanded, the importance of maintaining a coherent user flow mapping became evident, driving us to embrace a structured approach.

Challenges in the Absence of a Naming Convention

In the Cashfree Payments’ Amplitude dashboard, several challenges existed:

Confusion and Non-Uniformity: Different PODs used their own naming conventions, causing confusion and making it difficult to find specific events.

Fig 1: Examples of non-uniform event naming conventions

Repetitive Code for Explicit Event Tracking: We needed to make direct function calls within the relevant event handler. As a result, this leads to the insertion of redundant lines of code.

Event Coverage Gaps: Different teams developed events to address immediate needs, potentially resulting in incomplete event coverage that doesn’t fully meet the requirements of various units within our organisation.

Monitoring and Ownership Void: The decentralised event naming led to no reference docs for new events and limited central guidance. Lack of updates and quality checks worsened, hampering event record accuracy.

Fig 2: Screenshot of trackEvent function called from each onClick event handler

So what did we do in these situations?

Cashfree Payments’ Design team led the effort to standardise event naming conventions. These conventions were:

• Self-Describing 
• Scalable 
• Appendable 
• Sharable 
• Archivable (supported by current and future versions of the software)

To ensure the effectiveness and longevity of this effort, several associated aspects were carefully considered:

• Comprehensive Coverage: All dashboard Call-to-Actions (CTAs) were included under the standardised naming conventions.
• Semi-Automated Tracking: Automation was emphasised for event listening, tracking, and processing, with manual intervention limited to event tagging/triggering.
• Scalable Backend Solution: A scalable backend system was developed to meet evolving organisational needs.
• Internal Resource Utilisation: In-house skills were leveraged to create a tailored solution, with close collaboration between design and front-end engineering teams for a holistic approach.

Naming Convention implementation process

After thorough brainstorming and subsequent review, the design team put forth a recommendation to implement the “Product:page>object>action|attributes Framework” for event naming. 

Where the object consists of two parts – the value of data-track attributes + inner text

e.g. PG:easy-split>filter_row_primary_button:Add Vendor>click

To enact the naming convention, the front-end team created an SDK (Software Development Kit) for seamless integration into any front-end application. This SDK automates event tracking, preventing duplicates and maintaining naming consistency. It monitors trackable events (e.g., clicks and URL changes), processes event data, and sends it to a web worker. The web worker then makes API calls to the backend service for event tracking.

Fig 3: Event Tracking SDK Architecture: Frontend Application Integration Flow

Fig 4: Sequence diagram for User Event Tracking SDK

Four Phases of Naming Convention Implementation

1. Initialisation

We kicked things off by getting the SDK ready using a simple move called the ‘init’ method. To make things organised, we used a special product ID – like a tag – to match what people do in the app or dashboard with a particular product. It’s a bit like putting labels on stuff so we know what belongs where. Or like assigning colour codes to things so we know which one belongs where. This way, we can easily understand what users are doing with different products.

2. Capturing click events 

• Event Listening: The SDK, like a special tool, listens to actions like clicks happening in the app.
• Checking for Tags: When someone clicks, the tool looks like there’s a special tag, like a sign, on what they clicked. (‘data-trackattributes’)
• Identifying Tracked Elements: If that sign is there, it knows that what got clicked needs to be remembered.
• Naming Events: The tool then puts together information about what was clicked, like “what product, what part, what action.”  (like “Product: page>object>action”).
• Passing to the Helper: To do more stuff with this info, the tool sends it to a helper using a special method.

So, the SDK watches for clicks, figures out what’s tagged, remembers what happened, gives it a name, and then hands it over for further work. (‘postMessage’ method)

3. Capturing URL changes

• Tracking URL Changes: The system pays attention to when the website address changes, like when you move from one page to another. (‘window.onpopstate’)
• Sharing Data: It uses a method called ‘postMessage’ to share important information with a helper in the background. So, it’s like watching for changes in the web address and then quietly sending information to a helper behind the scenes. (‘postMessage’)

4. Tracking event 

• Sending Event Data: Once the special tool (SDK) collects important event information, it shares this data with a helper (web worker) using a method called ‘postMessage’.
• Helper Takes Charge: When the helper gets this data, it steps in to handle it.
• Using API: The helper does something similar to making a special phone call (API call) to send the event data.
• Specific Path for Events: It knows to dial a certain number (API endpoint) meant for dealing with events.
• No Token Required: Importantly, this phone call doesn’t need a special password (authentication token) to work.
• Strategic Approach: This was planned because on certain pages, like the login or signup pages, the password wasn’t available
• Why It’s Smart: This was done so that important actions on these pages can still be tracked, even if they’re missing that password
• Seamless Tracking: By making this phone call without needing the password, the whole system ensures that actions on all kinds of pages are tracked smoothly, regardless of whether they have the password or not.

The Benefits of Naming Conventions

• Data Consistency: A clear framework ensured uniform data type and event naming, enhancing analysis and avoiding duplicates. For instance, when defining “Sign Up,” the standardised convention prompts users to recognise the existing identical event, reducing redundancy.
  
• Better discoverability: Our goal with event naming conventions was scalable discoverability and clarity. These conventions enhance dataset understanding and report creation. This clarity enables quick identification of defined product areas, fostering broader analysis opportunities.
  
• Convenience: With a standard naming convention, developers can now easily implement new tracking without having to think about naming conventions. 

• Clarity and facilitates communication: A consistent naming convention boosts mutual understanding across teams, enhancing collaboration. It aids communication among developers, analysts, and database users.
  
• Scalability and portability: The convention’s design prioritises database scalability and portability, enabling seamless migration, integration, and reuse of data across diverse platforms and systems.

The Way Forward

To embed the naming convention deeply within an organisation’s practices, these strategies should be adopted:

1. Review and Refine: Regularly audit and update naming conventions to match evolving needs, maintaining data integrity.
2. Education: Train teams to comprehend and follow standardised naming conventions, minimising errors.
3. Feedback Loop: Foster collaboration for ongoing improvements, accommodating various stakeholder perspectives.
4. Central Ownership: Assign a central team to oversee naming, tracking, and best practices, ensuring consistency.
5. Documentation: Maintain comprehensive documentation, shared across teams, for clarity and reference.

Conclusion

Implementing event tracking is a key aspect of structured data management. Existing frameworks might not perfectly align with each fintech entity’s unique needs, highlighting the balance between off-the-shelf convenience and customisation for optimal data management.

Standardised event naming conventions are crucial for overcoming challenges in the fintech sector, enhancing data integrity, and enabling efficient decision-making. Cashfree Payments’ journey exemplifies the positive impact of such conventions and the strategic implementation of an innovative SDK solution. The Object-Action Framework ensures accurate event tracking, clean data, and innovation. 

Does this sound like an environment where you would thrive? If it is, then we have some exciting opportunities lined up for engineers like you!