How to Validate Success of your Verify Implementation
Time to read: 5 minutes
Sending and checking one-time passcodes (OTPs) is easy with the Twilio Verify API. Whether you're getting started from scratch or migrating from Programmable Messaging, you can build a working Verify proof of concept in under 5 minutes. And with default features including number pool management and compliance, Verify helps you focus on business logic instead of user verification.
Even better – many customers implement Verify in a single sprint. With just two API calls to send and check verifications, the majority of that time will be spent validating the performance of your user verification flow.
This article will walk you through best practices for testing Verify, validating the implementation, and taking Verify into production with confidence.
Designing a good user experience is essential for your verification and authentication flow. From collecting phone numbers to account recovery, reference our developer best practices for verification and two-factor authentication implementation recommendations.
Like any experiment, make sure your sample size is large enough to get a representative result. This is especially true if you're comparing Verify to an existing OTP solution. For most customers we recommend evaluating Verify for at least 4 weeks with production traffic.
Verify performs especially well in scenarios including:
- In countries susceptible to fraud - especially if you want to test the effectiveness of Fraud Guard
- During traffic spikes or high volume
To see representative results we recommend testing Verify in your primary markets, even if it's only a percentage of traffic. Reach out to support if you have any questions about running a proof of concept on Verify.
Follow our guide on Migrating from Programmable Messaging to Verify. If you're moving from another telephony provider this guide will still be useful. Our documentation provides additional details if you're starting from scratch or adding additional features.
Twilio monitors the performance of the telephony network and has intelligent fallback logic to additional providers and networks. Verify may use different telephony routes to improve the odds of delivery on subsequent verification attempts in the same verification. When you're testing Verify, make sure that retries are also sent with Verify to take advantage of this redundant routing retry logic.
While you don't need to pre-register sender IDs for a proof of concept, you can bring your own Sender IDs instead of using the Verify-provided senders.
Reach out to support to start the process of associating your Sender IDs with your Verify Service.
The Verify API has its own rate limits which differ from Twilio's Programmable Messaging rate limits so be sure to update your error handling logic accordingly. Verify error codes can be found in the documentation.
Ensuring that you have success criteria defined up front is critical to measure and monitor the effectiveness of Verify in the context of your application.
Common success criteria include:
- Conversion rate improvement
- SMS pumping cost reduction
- Time to convert improvement
- Support cost reduction
- Account Takeover (ATO) reduction
- Other types of fraud reduction
- Overall cost reduction
Read on for detailed information about how to measure these.
Fraud Guard, Twilio's automatic SMS pumping blocking feature, is included with the Verify API. Whether you've lost thousands to SMS pumping or have yet to be hit with this form of fraud, Fraud Guard is a powerful tool to protect your SMS OTP service moving forward.
There are several ways Fraud Guard can save you money:
2. Lower engineering maintenance costs for fraud prevention. The ongoing effort to ensure fraud is being detected and mitigated while fraudsters constantly change their tactics is challenging. Twilio has dedicated teams of data scientists and fraud operations specialists proactively monitoring the fraud landscape and preventing fraud on your behalf. Many customers have switched to Verify for this lower overhead.
OTPs are only useful if the user actually receives and validates the code in your application. We define verifications and attempts separately in order to calculate conversion rates:
Verification: the verification lifecycle of a given identity (e.g. a phone number) until a verification is approved or expires. Each verification session times out after 10 minutes by default. The API will send the same OTP during a single session. Verification SIDs start with
VE. A verification session can have multiple verification attempts.
Verification attempt: an individual message on a given channel (e.g. SMS, WhatsApp, Call). Verification Attempt SIDs start with
VL. Multiple verification attempts will be grouped into a single session until the session is approved or expires.
Twilio has a couple of ways of thinking about how to measure verification success and conversion.
|approved verifications / verification sessions
|Recommended, more holistic approach for OTP use case.
|approved verifications / verification attempts
|Always less than or equal to success rates.
We typically recommend tracking success rate with Verify to actually demonstrate the value of the network and fallbacks. A conversion rate would be more useful for notification or marketing use cases.
You can track success rates for your Verification Service in the Console or programmatically with Verify Events (real time) or Verify Attempts.
Faster conversion times are also a positive signal of a good verification process. There are two ways to measure timing:
- Using Twilio-provided logging through Verify Events
- Using your own logging service
For tracking API performance in either method, "start" the timer as soon as you call the
/Verifications endpoint (
com.twilio.accountsecurity.verify.verification.pending Verify event string). "Stop" the timer as soon as the
/VerificationChecks endpoint returns an "approved" status (
com.twilio.accountsecurity.verify.verification.approved Verify event string).
To track conversion time from the UI, start the timer as soon as the customer begins entering their phone number and stop when they are redirected to whatever gated content or next step is after verification. This will check both performance of the OTP delivery but also the user experience: how easy is your phone number input? Do you have OTP autofill enabled where applicable?
If you're testing Verify against another OTP solution, track the number of support tickets you receive related to authentication and verification. Not only do we expect this number to decrease when you switch to Verify, if you do need to escalate an issue, Twilio has hundreds of agents around the world for live support.
You may see an uptick in tickets if adding two-factor authentication (2FA) or phone verification for the first time. However this should be offset by the reduction in ATO and other fraud.
We also recommend tracking customer lockout times. A user authentication solution that leaves a customer unable to complete a transaction or access your application can cause significant impacts to your bottom line.
Verify saves you money in many ways, including lowered costs for:
- Phone numbers
- Engineering maintenance
- Customer support
- SMS pumping
Quantify these costs before and after implementing Verify and see if you're one of the many customers who end up saving money by switching to Verify despite the incremental software fee.
Ready to get building? Migrate to the Verify API in a few simple steps. Learn more about how to get the most out of your account security project or visit our documentation for more details. We can't wait to see what you build and secure.
From APIs to SDKs to sample apps
API reference documentation, SDKs, helper libraries, quickstarts, and tutorials for your language and platform.
The latest ebooks, industry reports, and webinars
Learn from customer engagement experts to improve your own communication.
Twilio's developer community hub
Best practices, code samples, and inspiration to build communications and digital engagement experiences.