I am very happy about engineering improvements - codepush, network lag down, identity service deprecation!
Two new credit lines have been launched: RETENTION_V1_EQ1_GCL and RETENTION_V1_EQ2_GCL.
Let's understand what is happening here.
For the longest time, our approval model was purely delinquency based: our models computed the probability of default, PD, and used PD as a threshold for the approvals. Sometimes there have been heuristics, but all heuristics used PD as a central measure. In the last several months, we have developed a new measure - PC - probability of churn. This is because acquiring users with low first cycle delinquency is important, acquiring users who retain with us is also important.
So, now we have two models - one model predicts PD and the other predicts PC. We then combine PD and PC into a single measure and approve based on that measure.
More precisely, we do the following. We already give lines to the some users. We continue doing that. Separately PD+PC model also evaluates all the users and it too gives line to the user it finds fit. A lot of the users will have overlap with the PD only model, and some users be new. So, there will be 3 different types of users - having the PD line only, having PD+PC line only, and having both PD and PD+PC line. We will see how the incremental users do in terms of delinquency and performance.
Let's see how this new development unfolds!
A bit of background first. There is a split pay service which is used to handle Pi3 transactions. Since it was a hack and hard to work with, we built a Pi3 orchestrator to replace it. When we built cross product linking (For a given merchant, if you link when doing pi3 txn, you will then not be asked to link when doing pl txn and vice versa), we could only build it in orchestrator, becuase split pay service was a mess.
When we routed 25% of myntra traffic to orchestrator (to take advantage of cross product linking present in orchestrator), we expected that for non linked users, conversion should stay constant and for linked users it should go up.
Our best data so far suggests that for non linked users, conversion rate goes down, while for linked users it goes up. Our theory is that there is something wrong with orchestrator flow which is pulling down conversion rate everyone - linked and non linked. For linked users though, absence of linking step on orchestrator pulls them up.
We resolved two bugs over the last week - back button was leading to a never finishing loader, and the rule engine timeouts were leading to inconsistent eligibility responses. However, they have not led us get parity in conversion rates. Our current culprit is latency - we have seen that latency from otp confirmation to payment page landing is higher for orchestrator - on all measures like p50 or p90. We are figuring out the root cause of latency. Current hypothesis is that redirection from one domain to other causes latency, though there are arguments against this hypothesis since latency gap between split pay and orchestrator seems to be too large to be explained by redirection.
Using codepush, we can deliver react native bundle upgrades to the devices on the fly. When an app launches, then it asks our server - "my version is a.b.c, what is the latest bundle for this version". If the server responds with a version number which is larger than what the app has, then app downloads the latest bundle. If the bundle is optional, then the app will use this bundle in the next app launch. If the bundle is mandatory then the app will interrupt the user and ask them to restart the app right then.
Using code push, if an app update requires only react native changes, then we can deliver the update to the app at a much faster rate compared to the rate at which people update their apps.
AFS team is now merging update queries to neptune DB, resulting in lower CPU utilisation, and reduced network consumer lags. Network consumer is the kafka consumer which consumes various events and updates our graph DB which is Neptune. Shubham reports the following lag graph.
Network consumer lag has plagued us for a very long time. Will it be solved for next several months with this? We will see.
Last 2 weeks of new experimentations in late (D300+) collection have yielded following three avenues of collectionss.
Engineering (Shivam) will be supporting these efforts in a dedicated manner for the coming week. Indications are that it could lead to several crores (even tens of crores) of incremental collection.
We celebrate lower delinquencies as a triumph of our risk management. A lot of it is the hard work of our collection team!
Note that this is shown irrespective of the payment mode (Simpl or otherwise). Awesome! Here is Vikas Goyal presumably ordering some sweets from Om Sweets and Snacks.
Identity service db is not updated anymore, and replica db for identity service RDS has been lowered in instance type. Primary RDS I think will stay as it is. $250 monthly saving. Final step will be to delete the DB. Identity service served us well! It is what drove now long defunct CTUF. Time to move on!
Raksha and Shoan are trying to root cause some apparent OTP confirmation rate problems on some merchants before they rollout sveltekit migration further.
Myntra Pi3 alerts, Realtime pi3 funnel, Zepto Pi3 real time funnel, Realtime payin3 funnel were deprecated. Saving $70 per day.
Thanks Neha Tayade for concluding this. Now, for PL, adding address to database is not done in critical charge call flow, it is done as in goroutine in async manner.
Someone (we know who you are!) partititioned the data on timestamp rather than date, and caused a blow up on s3 costs! Folks please understand that you should not create more than a few thousand partitions, since creating partition is costly. (But you should create suitable number of partitions since suitable partitions speed up the queries). If you partition on user id, or on timestamp, you are creating millions of parititons. On inspection we found several tables with such partitions. If you do that again I will ask HR to deliver your next salary in 1 Re coins and then as you collect your salary you will realize how computers feel when you create a large number of partitions.
If a user has not given us SMS permission, we nudge them to give it to us on each app launch. Should increase coverage of PaCE.
GraphShield selmore ensemble is now live. What is the impact on precision, I don't know. This was done by Akhil Mahajan. Congratulate Akhil for his new born too!
Looking forward to evolving TS components to next level. My dream is - super lean and super fast TS. Super lean means don't do everything.
Don't help Pi3 authenticate gateways. Don't help appex authenticate users. Don't help repayments collect money. Deprecate v1, deprecate v3. Don't have the word issuer_id
anywhere in your codebase.
Super fast means average response times comes down from 60ms to 10ms.
Dead code of cashback campaigns, unused models, deprecation of high volume kafka worker service.