I come from an extensive user analytics background. One of my earliest jobs was in a credit risk team in a bank, which involved predicting consumer risk (defaults, delinquency, etc.) based on private transaction data and publicly available information. A more recent role had me working on data and experimentation systems for a product that optimized time spent, retention, and ad revenue by recommending the next 20-second video to watch.
When I started at Ente, my first few days were mostly spent asking questions around metrics - things like sessions per day, daily retention, average time to upload and download photos, etc. These would have been fairly standard metrics in any company building a similar product. To my surprise, the response was: "We don’t track these because we respect user privacy."
That’s fair. But then, how do we improve the product if we don’t know what’s happening?
The next few months were about recalibrating myself to a different way of building products, where I had to start operating in the dark and let my vision adapt to the darkness over time. This post is about that recalibration and the learnings that came from it. The first step was to understand what Ente does not and will not track, so we can at least know the extent of the darkness.
What Ente does not track
Basically, anything that happens inside the app. We do not track:
- App Opens - we can't accurately measure DAU, MAU, sessions information, or any retention metrics.
- Screen Opens - we can’t measure what features are being used more frequently than others, thereby cutting off feedback for any new features we develop.
- Time Measurements - no time measurements in the app, a particular screen, or any specific operation like uploads, downloads, decryption, etc.
- Other User Actions - we don’t know what the user is tapping on, how much they are scrolling, or what the sequence of actions is. So no feedback on user workflows and how inefficient they might be.
Therefore, a lot of feedback on how the app is being used and what we can do better is not available directly through analytics. There is one proxy we do use
- for actions that require a change in our database tables: signups, subscriptions, photos uploaded, albums created, albums shared, etc. This gives us some idea of active users (e.g., users who uploaded at least one photo in a given period), signup-to-subscription conversion, etc. But these are just counts and ratios and don't offer the depth needed to improve the user experience.
On the marketing side, basically, the website, we do have some analytics. We use Simple Analytics and PostHog to get more information about website visitors: the countries they’re from, the pages they visit, the buttons they click, and how much time they spend. We’ve also started experimenting with advertisements and are using UTM parameters to build some understanding of how ads are performing. However, we don’t know the conversion from website visitors to signups or subscriptions (which would require third-party integrations like Appsflyer - something we don’t want to pursue). As a result, a fundamental business metric for us, customer acquisition cost, can only be calculated at an aggregate level, with a very inaccurate view of which channels are working well and which are not, leading to potentially bad decisions.
This is where we’re at, and will stick to this forever: no in-app analytics, some analytics from database changes, and limited insights from website visits. Within this reality, we still need to make the best possible decisions on marketing, product, and engineering.
Analytics is only feedback
User analytics has been a cornerstone of web and mobile product development for about two decades now. While user analytics itself is much older, the post-iPhone world caused an explosion in app developers building products for all sorts of use cases. The path to success included an iterative development process, where you built a basic version of a product or feature, launched it to a small group of users, got feedback, improved the feature, launched to a larger group, got more feedback, and so on.
The feedback part was provided by user analytics services in real time, leading to a faster feedback cycle and, as a result, quicker product improvements compared to competitors. It's no coincidence that Mixpanel launched in 2009, and found massive success, in the midst of this new wave, followed by multiple similar products.
At Ente, if we choose not to rely on user analytics for feedback, it's important to understand exactly what kind of feedback we’re missing, so we can design a suitable alternative.
The main purpose of this kind of feedback is to provide fast input to a product engineering team, helping them make the right decisions about where to focus - whether that's refining a feature, building something new, or fixing a critical bug.
For example, analytics might tell me that the speed of previewing thumbnails on Ente’s home screen is directly proportional to the signup-to-subscription conversion rate. Combined with information about how much effort it would take to improve that speed by 1.5x, and what the potential revenue impact would be, Ente might choose to do that over building a new feature.
While we should replicate this system’s strength, we also need to understand the downsides we don’t want to carry into a new system. A lot of product companies end up over-relying on user analytics, leading to poorly defined or even conflicting goals and metrics. It can also reduce the team’s willingness to take creative risks. For example, a product manager could use data to justify changing the colour of buttons for minor revenue gains instead of pursuing a riskier feature that might help leapfrog competitors. Over time, that’s what leads to the enshittification of a product. But that’s another story.
With this in mind, my takeaways to design an alternative feedback system
- It should surface lots of information about bugs, feature requests, and opportunities for improvement.
- That information should come in as quickly as possible.
- It should leave space for creative risks - even when incoming information suggests otherwise.
Feedback from the Community
Fortunately, lots of information hasn’t been a problem given Ente’s earliest customers came from Hacker News and Reddit. We’ve always received strong feedback from our community. This has been further strengthened over the past couple of years with an incredibly active Discord and GitHub community. Our support desk getting user-submitted reports is another other valuable source.
This feedback has been the primary driver of decision-making for the engineering team. Some good things about it:
- Great at Edge Cases - The diverse set of people in the community, and their willingness to share helps us uncover edge cases we’d never have discovered otherwise. An example is an issue we are facing around slowness on a certain network in Germany. Based out of India, this would have been impossible to catch. Even with customers in Germany, you need a few willing customers to go above and beyond and share their issues. So it’s a testament to a very contributive community that we got multiple reports for this.
- Views from Potential Customers - These channels also enable potential customers to give us feedback on why they feel the product is not ready for them. This is often divergent from the views of existing customers and helps the team balance between solving problems of existing customers while also working on features that will attract new customers.
- First Responders to User Reported Issues - We’ve often seen community members on Reddit, Discord, and GitHub follow up with questions, share resources, and offer counterpoints. This is a massive help for a small team like our, as managing these channels is quite time consuming.
That said, there are also challenges. While this is not intended as criticisms of the community, it is important to bring them up so that we can find ways to improve upon or bypass them.
- Delayed Feedback - Community members will obviously report issues when they encounter them. After a feature launch, they are mostly checking out the happy cases and not really trying to find flaws. Over time, bugs, irritating workflow, missing use cases start surfacing. By then, the engineer has moved on to something else, making it harder to revisit and fix the problem.
- Negative Mental Impact - Tracking multiple channels, replying to messages, summarizing feedback, and detecting duplicate feedback is very time-consuming. However, the emotional toll this work takes on us is significantly worse. Dealing with rude or slanderous posts is very demoralising - an example is a reddit comment slandering Ente in its early days. While we would have lost thousands of customers due to that one comment, it keeps popping up every few months, demoralising us for at least a few hours. Another problem is weeding out distractions. A recent example is the BuyFromEU trend where the team spent weeks agonising over how to handle potential customers rejecting us due to Ente being registered in the US. That time could have been better utilized by thinking about how to improve our product instead.
Basis above, I can update my takeaways from the previous section
- It should surface lots of information about bugs, feature requests, and
opportunities for improvement.
- Volume is not a problem, but can definitely work on increasing it further
- Need to figure out how to manage this information better so that it takes less time and less mental effort.
- That information should come in as quickly as possible.
- Needs to be solved
- It should leave space for creative risks—even when incoming information
suggests otherwise.
- Since this feedback is not numbers based, there is enough room to deviate from it
What we need to do
This post is an attempt to structure my thoughts on how to replace user analytics with community feedback at Ente, while preserving as much value as possible. There are a few things, I think, we, as a team, should do.
- Manage Community Feedback
- Find tools or build them to respond to feedback, and store it for future reference. Also filtering, cleaning, categorising the feedback. Invest into this just like another product team would invest into a user analytics system
- Increase the number of channels from which we can receive feedback. While there is a general negative outlook towards this - more time and effort, solving for tools would help us do this well.
- Get Feedback Faster
- Well designed beta programs can help us get feedback much earlier. Our Figma is already public - so getting design feedback before development can also be useful.
- Documentation on what we have implemented and what use case it solves for will also help customers test the features more extensively, and provide feedback faster.
While this will help us improve our feedback system, it is also important that whatever we build is close to perfect in the first attempt, so that our reliance on a feedback system to iterate can be minimised.
- Use Your Own Product
- Extensively use and test new features, and make our friends and family do the same. This provides directly observable feedback, along with the level of delight or irritation what we have built leads to.
- We already do this, but it is important enough to highlight
- Test All Similar Products
- Test products solving similar problems extensively. Knowing how someone else has approached a similar problem, and thinking about why they have done so can help us make better design decisions.
- This has to be a continuous effort as new ways to solve an existing problem will always keep coming up.
Conclusion
Like I said, this is more an attempt to structure my thoughts. We are still in the learning phase of a different way to build products. Therefore, I would really appreciate suggestions on how to tackle this challenge. Whether it’s suggestions for tools, past experience on similar challenges, potential problems with my approach, or anything else - please comment wherever you discovered this post. The volume and diversity of feedback is really important.
To our community - thank you. Your feedback has shaped Ente in more ways than we can count. And it will continue to shape the direction of both the product and the company. Please continue sharing your thoughts on Reddit, Github, Discord, Mastodon or wherever you’re comfortable. After all, it’s the pillar on which we are building Ente.