Journal · mobile
Why bounce rate lies about mobile sessions
Bounce rate migrated from websites, where a single page view with no further hit was a reasonable smell test. On phones it is a sloppy import. A “bounce” often means the operating system interrupted you, not that the user rejected the product.
Backgrounding is not rejection
A user opens your app from a push, glances at a status, and switches to LINE. Your SDK may close the session. Analytics calls it a bounce. The job — confirm the parcel is out for delivery — was done. Session quality is high. Bounce rate is ugly.
Deep links make this worse. A bank SMS opens a specific bill. The user pays or decides not to, then leaves. One or two screens. In web terms that looks thin. In app terms it can be a complete visit.
Dialogs and permission sheets
iOS and Android dialogs for notifications, tracking, or camera access sit outside your view hierarchy. Some replay tools capture them; many event streams do not. A user who lands, hits a permission wall, and backgrounds the app to think is not the same as a user who saw a blank home and left.
If your bounce definition starts the clock before the first meaningful paint, you will also punish slow networks. In regional Thailand that is not a rounding error.
What to use instead
Define a “landed” event that fires when the first interactive screen is actually usable. Measure whether the implied job moved. Keep bounce as a diagnostic for landing bugs — blank states, crash-on-launch, wrong deep link — not as a north-star.
In Replay Triage Clinic we tag sessions that look like bounces and sort them into: completed glance, OS interrupt, permission stall, crash, and true reject. The last bucket is usually smaller than the dashboard implied.
If leadership still wants a single bounce number, publish it with a footnote: mobile bounce includes completed glance visits. Then show the split. The footnote is not decoration. It is the analysis.