Blog · Thai Store Readiness
QA-ing Firebase vs Mixpanel before a Thailand store rollout
This is not a bake-off and not a recommendation to switch vendors mid-freeze. It is a release QA pass we run when a team in Thailand is about to ship while running Firebase Analytics, Mixpanel, or both. Analytics QA for App Releases cares about when events land, how identity attaches, and whether locale fields survive the queue.
Offline queues and BTS commutes
Bangkok commutes still produce long offline stretches in underground segments. Firebase and Mixpanel both queue; they flush on different batch sizes and retry policies. If your “activation within 5 minutes” KPI is computed server-side on arrival time, a delayed flush looks like a slow user. Check client timestamp versus server received on a device that airplane-modes for twenty minutes, then reconnects.
Identity timing
Mixpanel alias / identify calls are easy to fire too late if login is a WebView. Firebase user_id has its own race if you set it after the first screen_view. For a Thai OTP-heavy login, we watch the first five events after a successful code: do they carry the same identified user on both vendors? If only one does, your cross-tool dashboard will invent churn.
Calendar and currency payloads
Buddhist calendar dates serialised as strings in one SDK wrapper and ISO numbers in another will break warehouse joins. Baht as integer satang versus decimal baht is the other classic. Neither Firebase nor Mixpanel will save you from an inconsistent property type; they will faithfully store the mess. The QA is on your wrapper.
What we write down
A one-page vendor matrix: queue behaviour, identify timing, debug view availability on iOS/Android, and which tool is source of truth for the gate. Pick one source of truth for ship/hold. Dual-tool “they kind of agree” is how meetings last an hour and still ship a maybe.
Regional instrumentation is taught in Thai Store Readiness Instrumentation and inside our Release QA page.