How Gojek matched customers to the next service they would try
A super app grows when people who order food also start riding, paying and sending parcels with it. In 2020 a Gojek data scientist described how the team matched customers to the service each was most likely to try next, and how a simple recommender beat a pile of separate models. Four years later Gojek asked a sharper question. Here is the path, and how we would build it now.
Gojek started with motorbike rides and grew into a super app for food, payments, parcels and more than 20 services. Every new service raises the same question: which existing customers should hear about it first? In March 2020, Gojek data scientist Gunjan Dewan described how the team built a "matchmaking" algorithm that pairs customers with the services they are most likely to try next. It is a clear example of a problem every business with more than one product has.
The problem: the right voucher for the right person
The post states the business logic plainly: "it makes sense for us as a business if more customers use more of the services we offer". Gojek's lever is the campaign, usually a promo or voucher. Sending it to everyone is expensive and annoying. Targeting, the post argues, "reduces the cost of a marketing campaign" and "helps get better conversion rates", and Gojek wanted campaigns aimed so that "we don't spam our customers with campaigns that are not relevant to them".
The post frames it with two sets. For a campaign that pushes, say, GoFood, the base pool is everyone who uses other Gojek services but has never ordered food. The job is to find the part of that pool most likely to convert.
How they built it
First try: one classifier per product. The team trained a model that split the base pool into people who would and would not start using a service. It worked: Gojek reports "an uplift of ~5x on the natural conversion rate of one of our key services". It did not scale. "We needed to train a different model for every product", the post says, and every product had a different base pool. With 20 services, that is 20 models to build, monitor and retrain.
Second try: one matrix for everything. The team turned the problem around and borrowed the idea behind product recommendations. Customers became rows of a matrix and Gojek's offerings became columns. A column can be a service, a payment method, a combination such as GoFood paid with GoPay, or even a single merchant. Each cell holds how often a customer used that item. The matrix is "very sparse", because most people use only a few services, and cross-selling becomes filling in the empty cells. The top figure shows the idea: user 1 and user 3 behave alike, user 1 orders food and user 3 does not, so recommend food to user 3.
Choosing the method. Nearest-neighbour approaches lost on two counts. Comparing every user with every other user is "computationally very expensive" at Gojek's scale. Comparing products directly made no sense either: "This is absurd. We cannot say if GoCar and GoFood are similar or not." Matrix factorization won. It compresses the matrix into a small set of hidden factors per customer and per item, and their product predicts the empty cells. The team trained it with alternating least squares (ALS), a method suited to implicit feedback such as usage counts that runs well on Spark.
One model, two answers. The same factors serve both directions of matchmaking: "Given a product, we get a list of people who are most likely to cross-sell into that product." And the other way round: "Given a customer, we get the products that a person is most likely to transact with." The pipeline pulled transactions from BigQuery, cleaned them with pandas and trained ALS on PySpark. Moving to Spark, Gojek reports, cut the time to build the engine from about six hours to about one.
What it delivered
Gojek tested the engine in the field. A test group picked by the model and a control group of random customers from the same base pool both received the voucher, and the team compared conversion rates. The diagram in the post shows a base pool of about 3 million and 5,000 customers in each group. Gojek reports "an uplift between 5x to 7x across service types".
Read the result for what it measures. Both groups got the voucher, so the test shows that the model finds people far more likely to convert than a random pick. It does not show how many of them converted because of the voucher, since some would have tried the service anyway. The post gives no absolute conversion rates, voucher costs or significance tests. For a 2020 engineering post, it is an honest design story.
What has changed since
From likely buyers to changed behaviour. In July 2024 Gojek's tech blog described how the company now allocates personalised vouchers at scale (archived copy). The new system predicts, for each customer, the uplift a voucher causes and what it costs, then a knapsack optimiser picks vouchers "while adhering to the budget constraint". The post sorts customers into four types: Persuadables, Sure Things, Lost Causes and Do Not Disturbs, the last being people who transact less when targeted. It uses "thousands of features for each customer (there are hundreds of millions of them)" and allocates vouchers "to millions of customers in minutes". It does not say whether the 2020 matchmaking model was retired. The question has moved on anyway, from who is likely to convert to whose behaviour a voucher changes, and at what price.
AI across the group. GoTo, the group formed when Gojek and Tokopedia merged, launched Dira, a voice assistant in Bahasa Indonesia for the GoPay app, in July 2024, and Sahabat-AI, an open Indonesian language model built with Indosat, that November. With its first-quarter results in April 2026, GoTo said it was introducing a new AI program that "will lower cost to serve and increase engagement and conversion". Conversion is still the target. The tools around it have grown.
Why it matters for your business
You do not need 20 services to have Gojek's problem. A hotel with rooms, a restaurant and a spa has it. So does a clinic with several treatments, a retailer with many categories, or a lender with savings and loans. Most of them answer it with a broadcast to everyone, then wonder why people mute their WhatsApp.
The 2020 recipe is within reach of a small data team. A usage matrix can be built from a point-of-sale or CRM export, matrix factorization for implicit feedback runs on one machine at that scale, and the first test needs only two groups and a voucher. The 2024 lesson matters as soon as vouchers cost real money: measure what the offer changes, not just who takes it.
Indonesia's personal data protection law (UU No. 27 of 2022) shapes how you do this. Its principles require data to be collected in a limited and specific way, lawfully and transparently, and processed according to its purpose. When a consent request also covers other purposes, it must be clearly distinguishable from the rest. And the law lists large-scale processing, systematic scoring and "pencocokan atau penggabungan sekelompok data" (matching or combining datasets) among the high-risk processing that requires a data protection impact assessment (Article 34). Using data from one service to market another touches all three. We are engineers, not lawyers, so treat this as a prompt to ask yours.
How we would build it today
- Build the matrix first. Customers against products, payment methods and branches, counted over the last six to twelve months. The matrix alone shows who already uses what together.
- Beat a simple baseline. Before any model, recommend B to people who use A when most A users also use B. A factorization model has to beat that on held-out first purchases.
- Factorize for implicit feedback. ALS or a similar method ranks candidates for each product. Treat the scores as a ranking, not as probabilities.
- Test three groups, not two. Targeted with a voucher, targeted without one, and random with one. That separates the model's targeting from the voucher's real effect.
- Add a budget. Once those tests have built up data, model the uplift and choose vouchers by expected effect per rupiah, with a cap per customer each month.
- Make consent visible. Name cross-service marketing in your privacy notice, honour opt-outs across every channel, and write the impact assessment before the first campaign.
Gojek's two posts, four years apart, trace the path most teams should follow: first learn who is likely to say yes, then learn who your offer actually moves, and spend only on them.