Why Thai m-commerce funnels stall after OTP
In three consecutive SEA Mobile Conversion Lab cohorts, fashion and QSR delivery exports showed the same kink: traffic looked healthy through install, then fell off a cliff between “OTP requested” and “OTP accepted.” The weekly review kept calling it creative fatigue.
We timed the classroom traces. On AIS during an evening peak, SMS arrived between nine and sixteen seconds. On True the spread was wider. The resend control sat below the fold on two of the five sample apps, which meant the shopper who waited twelve seconds also had to hunt for permission to wait again. That is not a media story.
A second mistake made the chart look worse than the path. Several teams counted “OTP requested” as a micro-conversion in the same row as add-to-cart. When the SMS lagged, the dashboard still celebrated a completed step. The commercial lead saw a healthy funnel until first paid order, then blamed the banner. Drop-off archaeology — the lab’s second module — exists to stop that theatre.
What moved numbers in the Pattaya hotel case on our Reviews page was unglamorous: resend above the code field, email fallback for returning guests, and removing OTP-requested from the conversion column. Install-to-hold-deposit rose without a new campaign. Inventory still capped weekends. The funnel did not invent rooms.
If your own map shows the same kink, do not start with a new partner. Sit with a timer, two carriers, and a small Android. Bring the recording to a lab seat or a Trace Brief if you only need one sitting. Mobile Funnel Analytics, as we use it, begins when the SMS clock is on the page, not when the media plan is.