As a junior engineer in 2014, working in Android for QuizUp, I didn’t understand the importance of triple-checking if my event names matched our documentation to the letter. 

I didn’t get why the Analytics team wanted to start building a custom analytics solution in-house to make sure we did the names correctly every time. I mean, if I made a mistake, it took me less than 5 minutes to correct the name and do a new Pull Request right?

Small errors lead to big messes

When I started working with the analytics team, everything changed. I rapidly started to understand the pain they experienced trying to correct data on their dashboards. Especially when event naming errors were made. Sometimes it took a while for them just to find the mistakes in the first place.

They often encountered issues where even slight variations in event names across teams led to fragmented data, making it nearly impossible to build accurate dashboards or derive actionable insights. At least without significant manual effort.

So I slowly started realizing I was wrong, even though it takes me less than 5 minutes to fix the typo in the event name, it’s not that simple. These little data bugs have to fight other priorities to get fixed, against ongoing product features and other bugs. And the data bugs often lost the fight so quickly they piled up and their urgency decreased, as the analysts could not wait—they were forced to work around the (already broken) event.

But now, after almost four years at Avo, I’ve learned this wasn’t just a “junior” mindset; it was a symptom of a disconnect between data producers and consumers. Product teams move fast, implementing and iterating on their new release, while analytics teams often have backlogs that can’t match the same pace. 

For example, a product team might push a new release with updated tracking in a few days. The product team are the data producers, creating the data the analytics teams rely on to be able to do their job. The analytics teams may take weeks to create and adapt their dashboards or queries to the new and often partially broken data, leading to mismatched expectations and delayed insights. Without strict naming conventions and synchronized workflows across disciplines (iOS, Android, Web, Backend), inconsistencies inevitably emerge. And those problems can quickly snowball into bigger data quality issues.

Sometimes we’ve mentioned these issues as symptoms of “Wild West” data culture. In other words, without formal processes to name events consistently, chaos ensures.

The Chaos of Inconsistent Naming

Consider this scenario: An organization needs to track 3 events across three different product teams, iOS, Android and Web, 1) when the user presses the sign up button, which starts the sign up flow, 2) when they receive email verification, and 3) when the sign up is completed.

Each team moves forward with implementing tracking for these events.

Each product team (iOS, Android, Web, and Server) implements tracking for these events, but the results are inconsistent, often due to differing conventions that stem from platform-specific best practices and team preferences:

• Android and Web teams use camelCase:
  
  1. signupStarted
  2. emailVerified
  3. signupCompleted
• iOS team, following PascalCasing, uses:
  
  • Signup Button Clicked
  • EmailVerified
  • SignupCompleted
• Server team, working in Python, uses snake_case:
  
  • signup_started
  • email_verified
  • signup_completed

These differences go unnoticed until analytics engineers start piecing together dashboards. Suddenly, they’re stuck writing complex SQL queries to merge data, performing what we call reactive damage control. Over time, these queries become so convoluted and fragile that even minor tweaks are daunting. Teams procrastinate updates, fearing the hidden repercussions.

Eventually, leadership decides to shift from reactive damage control to proactive data management. To prevent further inconsistencies, the organization adopts a tool like Avo to enforce naming conventions (i.e. Centralized Governance). But the question remains: How do you fix the mess already in production? Sometimes we also refer to this as “inherited data debt”.

Renaming live events is not straightforward—it’s a delicate balance between fixing the past and avoiding future breakage. Fixing historical data often involves rewriting or transforming data in your pipelines, which can introduce errors or inconsistencies if not carefully executed. Some tools also offer ingestion time merging and blocking, but that means the issues remain in other destinations. However, proactive renaming ensures that future data is clean and accessible, reducing long-term maintenance costs and improving the accuracy of insights across destinations. 

Let’s explore three strategies to tackle this challenge.

Three Strategies for Renaming Events

Here are three different approaches, each with its own trade-offs, so you can evaluate for yourself the best approach for your situation. 

1. Rename Events and Accept Breaking Changes

This approach involves directly renaming the event, knowing it will cause temporary disruptions in your data.

• Pros: 
  
  • Future-proof naming consistency across the organization.
  • Easier to maintain and query accurate data moving forward.
• Cons: 
  
  • Historical data becomes fragmented. Queries spanning old and new event names must include both.
  • Old builds (e.g., outdated app versions) may continue sending events with the original names indefinitely.

2. Rename & apply Transformations in the Data Destination

Rename the event at the source and use transformations in downstream systems to map old names to the new ones. Tools like Mixpanel Lexicon or dbt make this possible.

• Pros: 
  
  • Prevents gaps in historical data.
  • Ensures consistent naming in all destinations moving forward.
• Cons: 
  
  • Labor-intensive if multiple destinations exist (e.g., Mixpanel, Snowflake, dashboards, etc.).
  • Forgetting a destination can lead to discrepancies in your data, complicating troubleshooting. (oldEvent.count + newEvent.count) vs (newEvent.count).

3. Duplicate Events Temporarily

Send both the old and new event names for a transition period, while marking the old event as deprecated so it´s not used.

• Pros: 
  
  • Provides a buffer for dashboards and queries to catch up.
  • No breaking change in your existing datasets, and Avo helps you keep track of the name mapping by automatically making sure the event is sent with the mapped name when using Avo Codegen.
  • You start a source of truth for which event should be used going forward, and as time goes on, the history becomes irrelevant and teams rely less and less on the outdated events. 
  • You can configure your setup to send both correct and incorrect events for a while to make sure your data-lake catces up, while explicitly naming the incorrect event as “<eventName> DEPRECATED” to discourage use.
• Cons: 
  
  • It can be an additional cost to be sending 2 events if the volume is large.
  • It can take a long time for the data lake to catch up to the timeframe you use for dashboards.
  • We all know that we are not going to remember to remove the old event in 6-12 months 🤷‍♂️

Choosing the Right Approach

To illustrate these strategies, let’s revisit the signup flow example. The iOS team’s inconsistent naming (e.g., Signup Button Clicked) requires a name map to align with the camelCase standard. Depending on organizational priorities, any of the three strategies could be used. Here’s a simple decision matrix to guide your choice:

• Immediate cleanup needed? Choose Strategy 1: Rename events and accept breaking changes.
• Historical data continuity critical? Choose Strategy 2 and 3: Apply transformations in the data destination and duplicate events temporarily to keep the old events sending for a while
• Flexibility and gradual migration preferred? Choose Strategy 3: Duplicate events temporarily.

Each approach has trade-offs, so weigh up your team’s goals, resources, and existing infrastructure carefully.

Renaming events is undoubtedly harder than naming them from scratch. But with the right strategy, you can migrate to a clean, consistent event taxonomy without compromising your data’s integrity or usability.

Good luck, and don’t hesitate to reach out to us at Avo for help with achieving consistent, trustworthy event data!