Product · 11 min
Funnels that span two runtimes
If step three is a native screen and step four is an HTML sheet, you do not have a funnel until you have a join key that survives process death.
Product teams love a five-step chart. Hybrid apps punish that love. Native onboarding ends. A WebView payment sheet opens. The user backgrounds the app to find a card. The shell is killed. HTML starts a new visitor id. Your funnel now shows a miraculous drop-off at payment that is mostly identity loss.
Name the steps by runtime
In class we label every step with its runtime: native.onboarding_complete, webview.checkout_start, native.purchase (if native owns purchase). Blended names like activation are banned until the ownership table exists. The chart looks uglier. The argument gets shorter.
The join key
A first-party user id is the only join we trust across a kill. Session ids and advertising ids are extras. If the user is not logged in before payment, say so: that funnel is unscoreable past checkout start, and you will not invent a probabilistic stitch for the board pack.
When login happens inside the WebView, native must learn the user id through a signed payload, not by scraping a cookie. Scraping is how you accidentally persist a previous customer’s id on a shared device.
Reading drop-off honestly
A real drop between onboarding and checkout start is a product problem. A fake drop caused by a new visitor id is a measurement problem. If you “fix” the chart by unioning anonymous HTML visitors with native users, you have trained the organisation to ignore both.
Week six of the flagship is a funnel QA lab. Students must present two charts: the honest one and the blended one, and explain which number they would allow into finance.