Journal · 12 Mar 2026
Why session counts still mislead product teams
Most app analytics stacks still default to sessions as the unit of “engagement.” Product reviews then treat a rise in sessions as proof that people care more. In the Bangkok studio we treat that chart as a warning label, not a win.
A session is an implementation detail: a timeout, a process lifecycle, sometimes a vendor’s guess about foreground time. On Android versions common in Thailand, background services and aggressive battery savers split one human visit into three sessions, or glue two visits into one. iOS is not innocent either — a quick switch to LINE and back can restart the clock depending on how your SDK is configured.
What to count instead
Behavioral segmentation for apps needs events that name a job: first add-to-cart in a session is still a session word. First add-to-cart after install, or first add-to-cart after a failed search, is a behavior. The container dropped away.
When Cohort Signal Lab students insist on keeping session counts, we ask them to overlay the same users’ job events. The overlay almost always shows that “high session” users are a mix of retrying failures, shared-device noise, and a small group actually completing work. Averaging those three into one engagement metric is how a roadmap gets loud and vague at the same time.
A practical check
Pick one week. Plot session count against a single job event you trust. If the correlation is weak, stop using sessions in any segment that will trigger messaging. If the correlation is strong, check whether the job event itself is firing on screen view. Strong correlation with a sloppy event is not comfort.
This is not an argument for deleting session tables. Keep them for quality monitoring. Just do not let them into the language of who the product is for.