HOW DO WE MANAGE THE MONTHLY COSTS FOR OTP SERVICES?
1. Project overview
The login/signup feature. Why the alteration?
When we first launched the Medigo application, our login and registration process was designed to be straightforward. Users only needed to enter their phone number to receive an OTP code via SMS, which would allow them to access the app upon entry of the code.
However, sending OTP codes incurs a fee for our company, and these costs have been steadily increasing each month.
Additionally, it's important to note that not all logged-in users ultimately make purchases.
2. What are the causes?
I use Google Analytics tool to track the number of users and clicks on the OTP code sending button. In addition, I also check the number of logged in/registered users and the number of orders. I found something very interesting based on these figures.
My findings
The way I investigated the root cause of the issue
3. Monitor and check results
After 1 month of changing the user flow and the location of the buttons is not reasonable. I check results from Google Analytics and Microsoft Clarity to track metrics and user engagement after changing user flows
Tracking user behavior ensures that changes to new user flows do not impact the existing user experience and order flow.
Result: In November, our order volume remained stable. While the number of OTP messages sent to users has decreased, the reduction is minimal. There remains a substantial gap between the number of OTPs sent for login/registration and the actual number of orders placed. Additionally, OTP messaging costs have not shown significant change.
Medigo has 2 platforms: app and web/mobile web (the platform that brings our main number of orders is the app). Reducing SMS OTP costs will need to be improved on both platforms but must ensure it does not affect the current number of orders. Therefore, I decided to first improve on the web/mobile web platform because the number of orders here is relatively small but the number of users receiving SMS OTP is relatively large.
Decision 1:
We have decided to look for a new OTP service provider to use alongside our current SMS service at a lower cost. The service we use is the "Zalo" application, a popular messaging app among Vietnamese users.
Some potential risks that may occur:
- However, I must still be cautious about whether switching between applications to receive OTP codes will affect the user experience.
- If the Zalo application cannot be used, alternative options need to be considered.
Decision 2:
Regarding the issue of intrusions by malicious actors, I cannot determine which subscriptions are real and which are fake. Therefore, I have reviewed our system to check for any vulnerabilities and discovered that we are quite lax in our login process, with no regulations in place. I believe I need to establish some rules for this. The regulations are as follows:
- Limit the number of OTP requests per phone number (Maximum of 5 OTPs per day, and there will be a waiting period before the phone number can request another OTP).
- Limit the number of OTP requests per DeviceID (Maximum number of OTPs per device, and there will be a waiting period before the device can request another OTP)
- Limit the number of OTP requests per IP address (Maximum of 7 OTPs per IP address, and we will ban any phone number that requests more than 7 OTPs within a month).
Some possible risks:
A potential risk is that some legitimate users may still use incognito mode to shop on our website and use it to make repeated purchases
(Again due to NDA restrictions, I'm limited in the amount of data i can share here)
Medigo has 2 platforms: app and web/mobile web (the platform that brings our main number of orders is the app). Reducing SMS OTP costs will need to be improved on both platforms but must ensure it does not affect the current number of orders. Therefore, I decided to first improve on the web/mobile web platform because the number of orders here is relatively small but the number of users receiving SMS OTP is relatively large.
Find out what's going on
Our current web interface has too many places that require users to log in in an unnecessary and quite unreasonable way, with the amount of traffic to our site ranging from 450k - 500k per month, we have to pay 1 Approximate amount for this. "Once again, our goal is to optimize the cost of sending SMS OTP"
On the interface product items, there are 2 buttons ''Add to cart" and "Buy now" and when the user clicks on these 2 buttons, they are asked to log in, which is quite reasonable. But when I look at the number of successful orders And the number of users receiving OTP is a terrible difference. The time from user flow redesign to release was 5 days.
Find out what's going on
First, I will solve this problem on the web/mobile web first (You can quickly look at the huge difference between the number of orders and the number of logged in/registered users).
Review the entire user flow and where buttons may not necessarily require users to register/log in.Review the entire user flow and where buttons may not necessarily require users to register/log in.
"The reason is that not every visitor to our website will necessarily make a purchase. They may browse, compare prices with competitors' sites... so I decided to change the traffic flow to allow users to browse the website comfortably, only requiring them to register/login when they decide to make a purchase."
4. New solution for improvement
The results after changing the user flow were not positive, we were forced to find a new direction to reduce costs and based on the data obtained in the previous changes I can make hypotheses as well as some questions
1/ Is the number of users re-logging in the cause of this unusually high login status?
2/ Does the unusual increase in users logging in/registering have anything to do with being infiltrated by bad guys from outside?
3/ Is the cost of the 3rd party SMS OTP sending service too high? Is an alternative method needed?
Questions raised:
Find the answer to the above question
Is the number of users re-logging in the cause of this unusually high login status?
After calculating the total number of users who sent SMS OTP, we found that about 89.8% were new subscribers and 13.2% were subscribers who had accounts and logged in again. Based on the above data, it can be concluded that the number of newly registered subscribers accounts for the majority and this group of subscribers needs to be addressed first.
Does the unusual amount of users logging in/registering have anything to do with being infiltrated by bad actors from outside?
To verify whether we are being intentionally infiltrated by bad external actors, I need to dig deeper into the subscribers who have received OTP, as well as the number of times each subscriber has received OTP.
Result: we are being infiltrated by bad external actors who require us to send OTP codes continuously during the month, with some subscribers we have to send more than 100 OTP codes/month. This is really a big problem
Is the cost of the 3rd party OTP SMS sending service too high? Is an alternative method needed?
We have also considered finding another OTP sending service at a lower cost, this is also a possible direction. But it is also necessary to test and verify so as not to affect the user experience.
Based on the data, make a decision
User Flow
Simple user flow describes the task of the user logging in/registering with a phone number to the task of selecting an expression to receive a code via SMS or Zalo
5. Measuare metrics and check results
Tracking data from January 2024 - March 2024
1/ After releasing the feature, we obtained quite surprising results: over 70% of users switched to using Zalo to receive OTP codes, and this did not affect the user experience as negatively as I had anticipated.
2/ The cost for sending OTPs for login/registration decreased by more than 60% in March and April.
3/ The number of subscribers receiving OTPs more than 40 times a month also significantly decreased: currently, each subscriber only requests OTPs about 4-5 times a month.