Event mapping – one of the most essential, but boring tasks in a devs life. It’s not as fun as developing a cool new UI, and nor is it as exciting as dabbling with some cutting edge architecture, but anything being built isn’t going to be worth much without it.
Monotonous and clerical as it may be, it is nevertheless crucial for any firm’s machinery, functioning as a critical bridge between engineering and product.
In the context of a developer's daily tasks, event mapping is most definitely not what they look forward to (and according to many, even sometimes neglected!)
Still, when a feature is pushed, it’s integral-at the end of the day, the enjoyment of the building aside, it’s needed to know if feature updates are even moving the needle overall.
Why does this happen? Why does event mapping, a critical function, get overshadowed by its more 'creative' counterparts? We sought answers from those in the trenches - the developers themselves.
So, at its core, event mapping serves as a recognition mechanism for user data.
Imagine you're a user navigating a website, which involves various events and actions:
Clearly, this is crucial for product managers so that they can help guide product and engineering decisions.
This is where the fundamental problem lies: Event Mapping is primarily under the purview of product, but the onus to do it lies on developers, because they are the only ones that can enable it. Since they are the ones who built out a product, it is their vocabulary and labeling that needs to be translated for their non-technical colleagues to be able to parse through the data.
This is because, in a nutshell, for someone to be able to make data interpretable, they need to understand it in the first place.
For instance, an event might not be as simple as a user clicking on the 'checkout' page. It could be more nuanced, like a user merely clicking the checkout button but not confirming the order, or clicking on a new ‘1 click buy’ button. All these specific scenarios need to be painstakingly labeled and inputted by devs.
From the devs we’ve spoken to, Event Mapping is one of those things thats not the favourite part of anyone’s day, but so essential and so expected that it’s not really something which even frustrates them anymore-it’s just what you do.
Nevertheless, common consensus seems to be that event mapping takes a 5 person dev team 5 hours a week.
Even just saving time aside, they’d all just be happier and more satisfied with their work if there was some way they didn’t have to to do it. After all, pretty much no one likes mundane, repetitive, and basically brainless labeling work; work which one dev described as ‘intern’ work.
It really just boils down to the fact that data entry is menial work, and the more talented the engineer, the less likely they are to enjoy it-in addition to their time just being more valuable.
Let’s cut to the chase -the problem here is the fact that data needs to be manually made into actionable insights that can be used by product teams.
Conventionally, this responsibility lies upon devs, and takes up a lot of their bandwidth. There is a solution for this-one that exists! Autotrack.
As we’ve spoken about earlier, autotrack would solve a lot of issues in this regard. This is because by default, each piece of data would be tracked, rather than developers having to manually sift through and select the relevant data for product.
Even something as crucial as A/B testing would be made easier; each change wouldn’t require corresponding event mapping.
Going back to the fundamental issue described above, someone would still need to sift through the data at some point. In this scenario, it’d be the marketers or salespeople themselves. Moreover, because devs use their expertise, they know which data to include. With autotrack (as it currently exists), however, a one size fits all approach is employed. Autotrack doesn’t just mean that tracking is automated, it also means that everything is tracked.
Ultimately, someone still needs to make sense of this. If, for example, a PM goes through the data by themselves without the help of a dev, they may miss out on relevant data points. For example, if a user clicks on a gear icon, it’s difficult to say that they also clicked on settings. Clearly, this hides important information about the user flow. Furthermore, this is relatively easy on non-autotrack tools like Mixpanel, which would then again require developer intervention.
So we’re back to square one, with developers having to spend bandwidth on making data digestible.
To sum it up, there’s three problems with autotrack right now.
1: Too much data: As I said before, autotrack functions by tracking everything by default. This can be quite hard to manage and sift through.
2: Paradoxically, because there’s too much data, autotrack leaves PMs vulnerable to missing out on relevant data.
3: Context Setting: Knowing what event to measure when is crucial, and the one size fits all approach currently available autotrack employs is not capable of enabling this.
Basically, all we need here is someone or something that takes data and makes it interpretable. For this, of course, the someone or something needs understand the data in the first place as well.
That’s where Crunch comes in.
Given how good recent transformer models are in understanding data of all sorts and then making it interpretable, it’s clear that they can do the ‘intern’ work required here of processing data and making it interpretable.
Using our model trained on the interfaces of various apps, Crunch would be able to label specific buttons or events automatically-removing the need for the painstaking work that devs need to do right now.
There’s other issues such models would solve as well. For example, currently, analytics tools aren’t able to decipher, by themselves, the function of a particular icon if it is also not textually labeled. The multi-modality shown by models like GPT4 solves this issue as well (I highly recommend you watch the demo if you haven’t already.
This is just the tip of the iceberg though, in the future, in addition to the immediate possibilities of automation using these models, there are tons of eventual possibilities which have to do with augmenting product development:
Our model's deep understanding of user interactions across different apps enables it to anticipate the most valuable events to track, even before a feature is fully deployed. This predictive capability can help product teams design more effective strategies and user experience improvements from the get-go. For example, it is likely that it will eventually be possible to simulate user responses to new features based off of old ones.
By understanding how users interact with different interfaces, Crunch can provide insights for optimizing the user interface and user experience. For instance, it could suggest changes in the placement of certain buttons or navigation elements to enhance user engagement or conversion rates.
Crunch also could enable dynamic feature deployment based on user interactions. This capability would make it possible to roll out or adjust features for specific user segments in real-time, delivering a truly personalized user experience.
Our model could also help identify anomalous user behavior or unexpected interactions with the app, which could be signs of bugs, usability issues, or even security threats. This unlocks a powerful tool for proactive problem solving.
With Crunch, documentation itself could be automated as well. The tool could generate and update documentation automatically, making it easier for team members (especially non-technical ones) to understand the data being collected.
As we step into the future, we're reshaping the landscape of development, creating more room for innovation and less for mundane tasks.
We’ve seen how magical AI enhanced recommendations can be in everyday consumer apps we all use. Such functionality, when baked into the very process product development shows great promise.
To that end, at Crunch, we're doing exactly that for an essential component of building: analytics.
Want to see what it's like?
Signup for our waitlist here!
