What Bangkok hardware teams actually put in the measurement stack

People ask us for “the stack.” We do not sell one. After eighteen cohorts we can describe a pattern that keeps showing up in IoT App Analytics work from Thailand product teams — usually two or three people sharing a spreadsheet before anyone admits they need a warehouse.

The shape, not the logos

Devices speak MQTT or HTTP to a broker or API the firmware team already trusts. A thin ingestion job writes raw payloads to object storage before they are cleaned. A contract snapshot — often just JSON in git — describes expected fields. A warehouse or even a well-kept Postgres then holds parsed events with device_id, firmware_semver, and event_time. Ops looks at uptime in Grafana or a vendor cloud. Product looks at funnels in a notebook or a lightweight BI tool. The failure mode is when those two desks stop sharing identifiers.

Mobile analytics kits sit beside this, not on top of it. They are fine for companion-app screens. They are a poor source of truth for valve state.

Why Bangkok specifics matter

Installer schedules, holiday weeks, and coverage gaps on certain routes change cohort windows. A stack copied from a European SaaS post will still “work” technically and still lie about retention. Several alumni on the Eastern Seaboard keep a local timezone calendar table because “ISO week” without Thai public holidays wrecked a Q1 comparison.

What we push back on

Buying a customer-data platform before the telemetry contract exists. Streaming every topic into a real-time feature store when the device sleeps for six hours. Hiring a visualisation contractor to hide missing firmware dimensions behind colour. The studio’s bias is unfashionable: freeze the promise, then pick tools that can keep it.

If you want help naming the gaps in your own stack, start with the IoT App Analytics page or a scoping call. We will not arrive with a partner logo sheet.