Building a $10B Super App: Inside Gojek’s Data-Driven Growth Strategy with Crystal Widjaja

When I joined, we had about 20 engineers, 10 business product people, and myself. My initial role was to establish what the real numbers were, as people were getting reports but engineers weren’t concerned about accuracy. From there, I built out the data team, brought in the risk team, and eventually took on marketing and performance marketing. We built internal portals for driver and finance apps, and then I inherited what would become the growth team, transforming it into a technical team focused on experimentation and quantitative decision making. I was constantly looking for ways to get to the truth behind our metrics and understanding why numbers kept shifting.

We started with ETL and Pentaho. We made the transition from a MySQL monolith analytics database to Postgres when our MySQL queries for cohorts became too time-intensive. If I had to tell the team ‘I don’t know what our retention rates were last week because the query is still running and won’t finish until 10am, even though it started at midnight’ – that was clearly too long. We also found that having comprehensive documentation was key to accelerating most data taxonomy transitions. The documentation didn’t need to be complex – it just needed to clearly show what tables existed and if someone was looking for specific information, which table they might find it in. The descriptions needed to be good enough that anyone onboarding to a dataset for the first time could figure out what they needed to query by themselves.

We noticed our driver acceptance rates had declined. We identified all the driver IDs who were consistently ignoring orders, segmented them into control and treatment groups, and implemented a simple SMS campaign. Working with driver operations, we crafted specific SMS messaging. This resulted in an immediate two percentage point lift in conversion rates, which both compounded completed orders daily and remained consistent over time. We validated this with another SMS test on a new group, which performed even better because it included more newly onboarded drivers. In a company doing 10,000 orders per day, that small percentage made a significant impact.

We learned that newly onboarded drivers, particularly those who had joined in the last 40 days, showed the most dramatic difference between before and after treatment. The insight that led to this experiment was  personally calling drivers who had ignored orders to understand why — they would tell me ‘I’m just getting ready for work, just wanting to see where everyone’s going today.’ They were treating it like a social feed, alongside WhatsApp and Facebook. What they didn’t realize was that every ignored order meant a customer waiting an additional 30 seconds for reassignment. We had to actively communicate these platform dynamics that we understood internally but weren’t obvious to our drivers and learned that behavioral interventions had the most impact early on during the onboarding process.

The allocation team eventually built a proper service that would penalize drivers who didn’t accept orders and create countdowns, but that took about a year to develop. In the meantime, we embedded our findings into the operations team’s onboarding program and continued sending periodic reminders through SMS. This exemplified our philosophy that perfect is the enemy of done – we found a way to improve the situation immediately while waiting for the ideal solution. I always advocate for trying to spike solutions: either the fastest version of a solution or the most white-glove version to get early signals about whether a problem is solvable and to what extent.

Product validation was largely driven by intuition, but you could see the success in data immediately with certain products. When we released GoFood, the growth was exponential from day one. We knew GoFood would succeed because we’d already observed users using our logistics product for food delivery. When you called a customer using our logistics product and asked what they were doing, restaurants would answer ‘food delivery services’ or home kitchens. People were already using a suboptimal version of the product to get the job done. So when we built a dedicated food delivery experience, adoption was explosive because we took the design patterns of those using the logistics product for food delivery and built it directly into the GoFood product. When a subset of users are using a suboptimal product through hacks, it’s a sure sign that adoption is being limited. Building GoFood eliminated the first problem, marketing and word of mouth solved the second.

We had cleaning services, massage services, beauty services. In hindsight, it sounds like the right thing to do if you’re a super app, but when you’re on the ground trying to communicate that value proposition to a customer, they have to ask ‘Your driver is going to come give me a massage?’ – and that sounds ridiculous. When you tell people that you also offer cleaning services and massage services, it’s not natural for them to also understand that we have completely different service providers for those services. We ended up shutting these down because they didn’t resonate with users and didn’t leverage our core platform of drivers who could deliver things, people, and money.

We used CleverTap for analytics, Tableau for visualizations, and Metabase for more ad-hoc visualizations. For performance marketing, we really focused on fostering an experimentation mentality within the team. The best App Store optimization experiment we ran was using our competitor’s name – Grab – in our keywords. My head of performance marketing brilliantly used ‘grab our app now‘ just to be found in the keyword search of our competitor. But it was more about creating the mentality of experimentation in the team so they would follow this growth ethos, because most of the performance marketing practices are already well understood.

We would transition when our current solution couldn’t keep up with our scale. For instance, if cohort queries took longer than overnight to process, that was our signal to upgrade. But I wasn’t super in-depth on tools like app performance or ASO. The performance marketing team was a very deep domain with established practices. My role in marketing analytics was more about ensuring we had accurate user data segments, data attribution, and appropriate ad spend tracking. I acted more as a guardian than implementing marketing applications directly.

The goal was to get the company to a place where they respect data and use it to make decisions. We have to be somewhat selfless – the data team is never graded on how much impact they have on revenue or how much better their analysis makes order conversion rates. But I saw this as a way to prove that if you use data, you can make an outsized impact. We focused on building internal tools that would help teams move faster and make better decisions and use data to change the experience our users have. For example, we built a data ‘product’ that would tell drivers when they were matched with a first-time customer so that drivers would have context on the customer’s expectations, or lack thereof.

My views on analytics platforms have shifted significantly. While I previously favored CleverTap, Mixpanel has improved substantially in the past six months. The level of granularity they allow in their analytics reporting is very good. The free plan is generous for startups with less than 10,000 active users per month. I appreciate how deep an analyst can go in Mixpanel to examine things that would typically take 30 minutes to write a query for. The ability to look at frequency bins and analyze different user behaviors is quite well implemented.

My investment in Eppo came from understanding how hard it is to use an experimentation framework across different teams. When you’re just tracking if a feature is released versus not released, that’s one type of experimentation framework. Most products can help you do that basic feature A/B testing – even Amplitude can handle it. But when you start dealing with complex scenarios, everything changes.

Take marketplace matching, for instance. When you’re tracking an allocation algorithm for matching drivers to customers, it becomes incredibly complex. Customer data is sparse – they’re not booking every single day – and driver data depends on geolocation. You have to do switchback tests, turning the model on and off to look at different population groups and their performance. Or consider marketing lift tests where you need to analyze geolift campaigns with both offline and online data. The potential impact from getting these experiments right is massive, but the technical complexity is daunting.

When we built our own internal experimentation platform at Gojek, it became brittle as we scaled. The more successful you are with experimentation, the more teams want to run experiments. Then people start colliding over experiment groups and treatment groups, and the queue gets longer for experiment results. Having a platform where you can just point to a table and say ‘Here’s what’s happening right now and where all the experiments are running’ settles political debates and helps democratize experimentation in a more civilized manner. Eppo simplifies this while maintaining statistical rigor. It lets teams focus on launching great experiences and developing products instead of reading white papers to validate their statistical methodology. This democratization of proper experimentation is what excited me about investing.

The real blocker is typically that no one on a team knows how to implement complex experiments correctly (say, geolift for instance). They have to read ten different PhD white papers to figure out how to do this properly. I’ve had that experience of someone asking if they could run an experiment, and I’ve had to go read statistics manuals to determine the right methodology. That can slow down the team, or you might implement it wrong, or you lose the nuance of what that methodology was trying to capture when you’re doing it for the first time.

Most dashboards are actually lagging indicators – if a dashboard is already built, usually all the insights are gone because someone already built the dashboard, looked at the data, and found a trend or anomaly. Real insights are usually generated by slicing and dicing segments, comparing differences between users who did something versus users who didn’t. That’s why I’m not a huge fan of Amplitude – they have a hard time facilitating that kind of analysis. I think platforms need to enable more flexible, exploratory analysis rather than just presenting pre-built views.

When I was at Gojek, my normal strategy was to say ‘I know what you need, let me just go do that for you and come back with the solution.’ But in advising, you don’t have that luxury. You don’t have access to all the raw material. This forced me to develop more templates and see things from an outside perspective. When I wrote ‘Why Most Analytics Efforts Fail,’ I initially wanted to just publish a template. But Brian (Balfour) helped me realize it’s actually more about the mindset and thought process that I’d unconsciously developed after creating so many instrumentation specs.

Being highly anxious is actually a good way of self-checking yourself. When I joined Gojek, I literally had a call with my future boss and said ‘I don’t know what you’re expecting me to do, and I’m also not sure if I can do whatever that is.’ Most startups don’t know what great looks like – you have to define that for yourself. I have a very strong sense of personal responsibility to the work that I do. What most people don’t do is just basic research – a lot of us are too afraid to simply Google ‘What is the job of a data team?’ or ‘What should a great SQL database structure look like?'”

Search has negative utility. For as long as you are searching for the right answer, that answer-debt compounds. The amount of time you spend looking for the right answer therefore requires that your answer be twice as good, proportional to the time you spent looking for the right nugget of truth. I’m always conscious of that balance – is the time spent proportional to the outcome it’s going to generate? It’s an optimal stopping problem that we don’t really have a great quantitative way of solving.

Nir Eyal told me something transformative when I was struggling to write a long essay. He said ‘The fact that it’s hard is the reason why you do it.’ You have to reframe it as ‘I get to do this because it’s hard,’ not ‘it’s hard so I don’t want to do it.’ Are you the type of person who likes to do hard things? I realized I can’t say no to that question. I do think of myself as someone who doesn’t like to take the easy route! If I’m a person who likes to do hard things, and writing this essay is hard, that makes me want to do it.

I try to do less based on inertia and more on intentional planning. Because waiting for inspiration to strike means nothing gets done for weeks. Instead, I block out three-hour chunks three days a week where I just sit and try to write. Sometimes that means I’m writing garbage, sometimes I’m just editing stuff I’ve already written, but some days I feel inspired by an experience I had with a startup and want to write about it. Being intentional about what I’m trying to do helps, and when inertia happens naturally, that’s great – I try to let that happen on the other two days of the week that I work.

After leaving Gojek, Crystal has focused on advisory roles with companies like Scale AI, Kumu, and Bounce, while also serving on the board of Naked Wines, a public company in London. She continues to share her expertise on Reforge, with an upcoming book on data and growth. For those interested in following Crystal’s work and insights, you can find her on LinkedIn or subscribe to her next cohort at https://www.reforge.com/courses/data-for-product-managers