SELECT
SUBSTR(bucket_id, 6, 7) AS month,
ROUND(SUM(IF(
product_id = 'a21b31b4-74b8-4a6e-a2a8-28b85d1f8315'
AND merchant_name != 'Billbox'
AND merchant_name != 'Simpl', txn_amount_in_paise, 0)) / (100 * 10000000), 2) AS pl_tpv,
ROUND(SUM(IF(merchant_name = 'Billbox', txn_amount_in_paise, 0)) / (100 * 10000000), 2) AS billbox_tpv,
ROUND(SUM(IF(
product_id = '541eeb1c-8212-40f7-af04-05990ff00961',
txn_amount_in_paise, 0)) / (100 * 10000000), 2) AS pi3_tpv,
ROUND(SUM(txn_amount_in_paise) / (100 * 10000000)) AS total_tpv
FROM
public.transaction_events
WHERE
event_name = 'TransactionChargedEvent'
AND bucket_id >= 'date_2024_01_01'
GROUP BY 1
ORDER BY 1
|
SELECT
SUBSTR(bucket_id, 6, 7) AS month,
COUNT(DISTINCT(IF(
product_id = 'a21b31b4-74b8-4a6e-a2a8-28b85d1f8315'
AND merchant_name != 'Billbox'
AND merchant_name != 'Simpl', user_id, NULL))) AS pl_mau,
COUNT(DISTINCT(IF(merchant_name = 'Billbox', user_id, NULL))) AS billbox_mau,
COUNT(DISTINCT(IF(
product_id = '541eeb1c-8212-40f7-af04-05990ff00961',
user_id, NULL))) AS pi3_mau,
COUNT(DISTINCT(user_id)) AS total_mau
FROM
public.transaction_events
WHERE
event_name = 'TransactionChargedEvent'
AND bucket_id >= 'date_2024_01_01'
GROUP BY 1
ORDER BY 1
|
Pi3 MAU is thriving, PL and Billbox MAU are recovering. Overall MAU is second highest in 14 months.
Cross product linking is now live! It is live for 50% of the users of Myntra. So, there is common linking for PL and Pi3 on Myntra - if you link on one product you are linked on the other. 500bps in conversion is reported in early numbers.
PACE - PAyment Capacity Estimation - is the estimation of user's paying capacity using their SMS data. Around 1800 users daily are being given credit upgrades based on this data.
So far, reminder comms (except for collection calls) were static journeys. In this project we have developed a Deep RL (Reinforcement Learning) framework where we are generating recommendations for users to choose which set of channels we should be using for reminder journey after their bill gets generated. This is currently live for 1% of the users.
WITH verification_attempted
(
( --query to fetch auto-otp read flow data
SELECT
bucket_id,
user_phone_number
FROM
public.verification_events
WHERE
verification_flow = 'LOGIN_FLOW'
and verification_template = 'android_otp_10_alphanumeric'
AND event_name = 'VerificationService::VerificationGeneratedEvent'
AND bucket_id >= 'date_2025_06_01'
)
UNION
(--query to fetch sim binding flow data
SELECT
bucket_id,
mobile_number as user_phone_number
FROM
public.uas_events
WHERE
event_name = 'UserAuthService::SimbindingVerificationInitiatedEvent'
AND bucket_id >= 'date_2025_06_01'
)
),
verification_successful
(--query to successful login data
SELECT
bucket_id,
mobile_number as user_phone_number
FROM
public.uas_events
WHERE
event_name = 'UserAuthService::UserLoggedDeviceSuccessEvent'
AND bucket_id >= 'date_2025_06_01'
)
SELECT
vt.bucket_id,
COUNT(DISTINCT(vt.user_phone_number)) AS num_tried,
COUNT(DISTINCT(vs.user_phone_number)) AS num_succeeded,
ROUND(100 * (1 - COUNT(DISTINCT(vs.user_phone_number)) /
COUNT(DISTINCT(vt.user_phone_number))
), 2) AS pct_failed
FROM
verification_attempted vt
LEFT JOIN verification_successful vs ON vt.user_phone_number = vs.user_phone_number AND vt.bucket_id = vs.bucket_id
GROUP BY 1
ORDER BY 1 ASC
|
Reason of reduction is switching away from the vendor where success rates were low. There are several improvements planned in ongoing sprint. We will see if they result in further improvement of login rates.
Mobile team and DE team have together worked to reduce SMS payload size (data transferred from device to our servers) by around 50%. We were earlier converting the gzipped data to base64 encoded format before compressing it. This was needless as the subsequent compression works with binary data too. Once we remove the base64 encoding step, data transfer reduces by around half. This is good since smaller data transfer means that probability of google assuming that we are doing bulk SMS transfer reduces.
We reached 1000 active mandates on paylist on July 31. As decided earlier, we have now paused paylist user tagging. We will now do user interviews, system monitoring and fastag integration.
Select max offers 30 day cycle to users. There were 177K users in test and 84K users in control. We offered select max to test. Some 7K users chose to sign up for select max. Here is the summary of the experiment
Relevant doc is here.
Delinquency being worse is a slight concern, however, we have the explanation that (i) Two cycles are combined into one so double the userwise delinq is justified (ii) There will be some confusion about cycles leading to additional delinquency (iii) 30 day cycle will naturally attract users who are anyway more prone to delinquency.
We have decided to scale this up for better SSC bands where credit limits are not bloated. As a product, it appears to be a right direction - if CM3 works out for us, we should offer it to users who are ready to pay for it. But there is a nagging concern that users are overspending and then churning away which may hurt our MAUs. On the balance I think those churning away would have churned away anyway.
Analytics team provided an overview of their work. You can view the slides here (slide no. 157 - 167).
I wanted to check what fraction of MAUs face transaction declines. Here is the analysis for PL. Here is the result. Number of users facing declines will now increase since selmore blocks are replaced by transaction declines.
Notably, workload of DE team is increasing significantly.