When two apps share a login and neither team owns the drop-off
A consumer app and a loyalty app used the same sign-in. Retention fell in both. Each weekly pack blamed the other title. Here is how the reading was done.
The two titles lived in different directorates. One was a catalogue; the other held stamps and vouchers. Both used a shared sign-in library maintained by a third group that did not appear in either weekly pack. After a library change in March, day-7 return slipped in both apps. Each pack showed a clean crash-free rate. Each product owner arrived at the findings session ready to defend their release.
We asked for the identity events, not the screen events. The drop-off sat between ‘credential accepted’ and ‘session handed to the title’. That interval was invisible in both product packs because it was owned by the library. Support tickets mentioned ‘keeps sending me back to the stamp card’ and were tagged to the loyalty app, which made the catalogue look innocent.
The heat table put a shared row under both titles. Once the row existed, the argument changed. The library group was invited to the second hour. They had not seen the retention tables; they had only seen crash-free on the library’s own sample. The brief named the interval, the version, and the missing owner. It did not rank one consumer app above the other on a failure neither of them could ship a fix for.
This is the ordinary failure mode of a multi-app portfolio: the worst problems live in the joints. A review that ranks titles without a shared-failure row will keep producing tidy, wrong stories. If your organisation has a login, a payments webview, or a consent screen used by more than one title, put that joint on the table before you argue about whose retention is worse.