Offline Batching Disrupts a Mobile KYC Funnel
Cedar Bank's mobile app has 220,000 monthly active users on iOS and Android. The growth team is examining a four-step onboarding funnel: account created, identity document uploaded, liveness check completed, first deposit. Overall conversion from account created to first deposit is 34%, but iOS shows 41% and Android 27%. The liveness step has a 22% drop on Android and 9% on iOS. Event data is batched and uploaded when the app returns to foreground; Mixpanel's time is set to server receipt time, while the app stores a local client_ts. Support sees users completing liveness but not seeing the success screen. Push opt-in is requested immediately after account creation, and opt-in rate is 18% on iOS versus 44% on Android. The team wants to move the push prompt to after first deposit and compare 30-day retention.
1. The funnel shows some users completing liveness before uploading an ID. What is the most likely cause, and how would you produce a trustworthy ordered funnel?
Read the worked answer
The most likely cause is event ordering by server receipt time. Batched uploads arrive together when the app returns to foreground, so a later step such as liveness can be written before an earlier step such as ID upload. Mixpanel's default time then reflects upload order, not user behavior. To fix the analysis, re-ingest the raw events using client_ts as the event time, but first handle clock skew: compare client_ts to server receipt time, flag events with large or negative offsets, and exclude or correct those records. Deduplicate by an event ID or a composite key because retried batches can duplicate steps. Then rebuild the funnel as a user-level ordered sequence using corrected timestamps, and compare it with a warehouse export to verify counts. Do not simply drop the impossible records; that would bias the funnel toward users with reliable connectivity and hide the Android problem.
2. Should the team move the push prompt based on the current iOS/Android comparison? What would you measure instead?
Read the worked answer
No. The current comparison is observational and badly confounded. iOS opt-in is affected by the App Tracking Transparency context, permission prompts, and different user populations; Android's 44% does not mean Android users are more receptive to notifications in general. The prompt also comes immediately after account creation, so it may affect KYC completion rather than just opt-in. Moving it could change both retention and onboarding conversion. Run an experiment with users randomized at account creation, and keep the prompt timing as the only change. The primary metric should be 30-day retention, with KYC completion, notification opt-out rate, and support contacts as guardrails. Analyze iOS and Android separately as pre-registered subgroups, but do not use the platform difference as the justification for shipping. Wait for a full 30-day window before deciding.