Due to various reasons - primarily Swiggy offers, but also generally increased business on Pi3 (which is more NU heavy), NU intake is generally high these days.
This Sep 7, we had 6k+ NU which is largest in a more than an year. Following graph shows how monthly NU (across PL and Pi3) have been trending since 2016.
Query for above data is this
SELECT SUBSTR(LEAST(first_pl_txn_timestamp, first_pi3_txn_timestamp), 0, 7) AS mth, COUNT(*) FROM public.user_profile WHERE first_pl_txn_timestamp IS NOT NULL OR first_pi3_txn_timestamp IS NOT NULL GROUP BY 1 HAVING mth < '2025-09' ORDER BY 1
Let's compare MAUs Aug 2025 vs Aug 2024:
| month | pl_users | billbox_users | pi3_users | total_users |
|---|---|---|---|---|
| 2024_08 | 1339141 | 257472 | 19996 | 1388459 |
| 2025_08 | 1379142 (+3%) | 231203 (-10%) | 195791 (~10x) | 1513038 (+9%) |
Now compare TPVs
| month | pl_tpv | billbox_tpv | pi3_tpv | total_tpv |
|---|---|---|---|---|
| 2024_08 | 486.23 | 69.53 | 5.77 | 563 |
| 2025_08 | 548.88 (+13%) | 71.21 (+2.4%) | 60.76 (~10x) | 683 (+21%) |
TPV growth year on year of 21% is not bad keeping in view that focus was consitently on profitability and we had actions like increased late fee and DDD which led to churn. If we keep our focus and don't get lost in other adventures, in 1 year 50-60% growth is gone nowhere and may be better if some new sales / ideas can materialize. There is lot of product and sales momentum currently and we need to continue executing.
Autopay v2 has been ramped up to 100%. Last week we corrected some communication problem in autopay v2.
Autopay seems to be like a giant state machine problem. This state machine is in heads of people. At some point I want to write it formally in some state machine specification. Quick google search does not throw any tools that can help us. Or may be there is.
From the previous update you may remember that Swiggy shows Simpl ad post purchase. So, far that ad was landing ot our play store page, but now it lands on a web page, where we capture user phone number. This is that page
We want to move all "unblock on repayments" to AARR. With this change, I think all blocks except Selmore is on AARR
Talking about AARR, Manish maintains this dashboard to track various metrics regarding AARR. Around 50% of users who are challenged to do AARR do it eventually (Graph below has red line dipping because for recent dates only a few days have elapsed since the users were put on AARR)
Decent number of users pay while on merchant app - which is raison d'être for AARR development
We continued working on several operational improvements and engineering enhancements to support collections. We can now send whatsapp messages where image of the grievance report filed by us is sent. We also trying some AI bots for collection (Weya, Arrowhead). We have collected 2.9 cr in Sep till Sep 13.
Following is canopus collection day wise
Query for above image
WITH base_data AS
(
SELECT DISTINCT user_id
FROM temp.canopus_data_updated
),
user_paid AS
(
SELECT DISTINCT event_id,
event_date,
payload:settlement.amount_in_paise AS amount
FROM vikas.all_events_json
WHERE event_date >= '2025-09-01'
AND event_name = 'UserRepaidEvent'
AND payload:user.id IN (SELECT user_id FROM base_data)
AND DATEDIFF(event_date, payload:repayment_issuer_details[0]:bill_settlement:end_date) >= 300
)
SELECT event_date,
ROUND(SUM(amount)::FLOAT/100) AS amount,
COUNT(amount) AS amount_user
FROM user_paid
GROUP BY event_date
ORDER BY event_date DESC;
Whoever has created the table in temp folder - move it to some proper location.
The long running, often paused, setu integration for billbox is released, and is currently live for 1% of the users in electricity category. Shivanju tells that 30+ external users have paid their bill via this route.
This was the longest running project in central standup.
I spent some time last week convincing Himanshu that observed lower conversion rates in v2 splitpay flow cannot be an artificat of random variations. To generalize the process, I also made an online tool using which we can test - given two rates (conversion rates, churn rates, delinquency rates etc) and the two cohort sizes which exhibit these rates, how confident can we be that one process really yields better rate than the other (rather than the difference being due to random fluctuations)
You can view the tool here.
To everyone - test of significance is the main thing that we study in statisics after measures of central tendency (mean, median etc) and standard deviation.
v2 latency in splitpay will take time to be resolved. This week Akshay/Virinchi did some changes, which (as they expected) did not yield benefits. We will need to figure out our strategy to attack this problem.
Suvakanta gave this talk on the app testing automation that he has been working on. He also shared this video.
Melron is pushing for the following two ideas that I am quite excited about.
Firstly, if someone cannot login via our secure receive sms and send sms flows, can we allow them to login via now deprecated otp flow? For any user logging in via this flow - we will not allow them to do any fraud prone operation, like mswipe or billbox transaction. However, they would be able to pay their Simpl bill. Secondly Melron says that since we do mswipe to enable transactions, Google may allow us to do sim binding. If this can happen this will be a big win for user experience.
Meanwhile, login rates have stayed constant over last few weeks.
We are hiring a few people (2-3) in engineering and few people (1-2) in data science. If you know people who would be a fit, let me know.