Networks · 12 min
Why add-to-cart rates stall on Thai mobile networks
During a live drop, product teams stare at a falling add-to-cart line and rewrite the button. The warehouse already knows something else happened: phones fell back to a slower radio, images froze, and thumbs left.
In Live Basket Intelligence we ask students to plot add-to-cart not only against clock time but against a crude “network weather” flag: was the device on a fast cell, on Wi-Fi, or in a fallback state when the tap failed or never came. Thai live commerce is dense enough, especially after 21:00 in Bangkok condos and in provincial towns sharing a tower with a festival crowd, that this flag often moves in the same minute the host mentions a SKU.
That coincidence is not proof. It is a reason to stop treating the stall as a copy problem. A 2.4-second image retry on a 3G fallback is long enough for a shopper to swipe back to Line. Your analytics tool may still count a session. It will not count the humiliation of a frozen size swatch.
What to log, practically
You do not need a carrier partnership. You need client-side timing around image complete, variant fetch, and add-to-cart request, plus a coarse connection type when the OS will give it. Join that to the live host’s SKU call timestamps. If add-to-cart dies in the same thirty-second window that image complete time doubles, write that in the merchandiser memo. Do not write “users bounced.”
We have seen desks spend a quarter polishing a gold button while the CDN origin sat in a region that hated Thai evening traffic. The button was innocent. The network was not a footnote.
A limitation of this note
We are not radio engineers. This essay will not help you negotiate with a telco. It will help you stop hiding latency inside a conversion rate. If your catalogue is mostly desktop, this problem is quieter and our flagship will feel like overkill — which is a fair reason to skip it.