Field notes
When client events should move to the server
Signs that a mobile analytics event should be remapped to fire from backend handlers instead of the device.
Not every interaction belongs on the server. Scroll depth, UI experiments, and local preferences often stay on the device. Other moments should migrate once the product depends on them for board-level decisions.
Trust and completeness
If users can complete an action while offline and the client later retries, client-only events may fire twice or not at all. Server confirmation after reconciliation is usually the safer place for the canonical count.
Sensitive fields
Anything that touches account identifiers, payment tokens, or content licensing should be evaluated for server emission under your privacy review. Client SDKs are easier to inspect on rooted devices; server maps give you a narrower surface to control.
Cross-app consistency
Portfolios with iOS, Android, and a light web companion often disagree on naming when each client team instruments alone. A server map owned by one backend team reduces that drift for connected mobile apps sharing the same account system.
How we decide in workshops
We put candidate events on a wall (physical or digital) and ask three questions: Does finance or compliance need this number? Can the backend already know it happened? Would a missing client beacon create a false story? Two “yes” answers usually means the event belongs in the server-side map.