The product lead sent us a week of charts. Paywall views were steady. Trial starts were steady. The event they called purchase_success sat at zero on Android for eleven days after a store release, while Finance could see Play Billing charges arriving as usual.
We installed the same version they had shipped. On iOS, purchase_success fired after the store sheet dismissed and the entitlement unlocked. On Android, the team had moved the success screen into a new fragment during the paywall redesign. The event was still registered on the old fragment, which the new navigation never opened.
Where the walk differs from the dashboard
A weekly dashboard will not tell you that a fragment died. It will tell you a number went to zero, which is the same shape as a bad campaign, a price test, or a store outage. The only way we trusted the finding was to complete a real purchase on a test account with DebugView open, then search the log for the string the measurement plan still listed.
The string never appeared. A different event, paywall_dismissed, fired when the sheet closed, with no parameter for whether the person had paid. Engineering had kept that event because it was 'good enough for funnel shape.' It was not good enough for Finance.
What we asked them to change
We asked for purchase_success to fire from the entitlement callback, not from a fragment's onResume. The success screen can still exist for the human. The event should not depend on that screen remaining in the graph. We also asked them to stop treating paywall_dismissed as a substitute for revenue.
Eleven days is a long time to read a dead event. The cheaper habit is a pre-release walk of the payment path on both stores, with the debug log saved into the release ticket. That is slower than glancing at a chart. It is faster than explaining a silent fortnight to a board.