Why Bangkok teams overcount sessions

I sat the Live Usage Lab after our unique-session chip outran registered users by a factor that made the CEO proud and the data lead nauseous. The default in our mobile kit was simple: new install, new session id, new “user” on the live wall. In Bangkok that default is a fiction with three local authors.

Dual SIMs and the quiet reinstall

Plenty of people here keep a work SIM and a personal SIM, or swap a tourist prepaid after a trip to Isan. When the OS treats the swap as a new device fingerprint, our socket emitted session_start again. The human had not multiplied. The live uniques had. We were not measuring curiosity; we were measuring SIM hygiene.

Grab hand-offs and borrowed phones

A rider finishes a job on one handset, a dispatcher hands another. Family share a tablet at a shophouse. If your live identity is “this advertising id,” you will count evenings as populations. During the film-strip module we paused a single hour from a Sukhumvit cluster and watched the same checkout_paid payment_id appear under three session ids. Finance already knew it was one order. The live board did not.

What we changed without waiting for a CDP fantasy

We stopped showing “uniques” on the live wall. The chip now says “session_start events (not people).” We stitch only where we have a signed-in account id or a payment_id, and we label the stitch. Nalinee would not let us call it identity. That label discipline did more for trust than any probabilistic graph we were quoted.

If your Bangkok board still boasts live uniques, ask what happens when someone swaps a SIM at Mo Chit. If the answer is “a new user,” you do not have Real-Time Usage Analytics. You have a counter. The studio’s Live Atlas is blunt about what a live claim may say. I wish we had read it before the CEO screenshot.