Cohort windows vs. cookie windows: a measurement mismatch

A cookie window is a storage policy. A cohort window is a claim about when a behaviour still counts as “the same attempt.” Mixing them is how day-7 retention becomes a story about identifier life rather than about whether someone opened the app again.

Where the join usually hides

Teams with a web on-ramp and an Android or iOS app often stitch with a hashed phone or a “anonymousId” that began life as a cookie. The app then inherits the cookie’s expiry as if it were a product truth. When the cookie dies, the cohort dies, even if the person is still using the app under a signed-in account.

The opposite error is just as common: a cookie lives longer than the product relationship, so a returning web session inflates app retention because the warehouse still sees one identifier.

First-party timestamps only

We define cohorts from an event the app itself emitted: first_open, first_meaningful_action, or first_signed_in_session. The window is a number of days from that timestamp, not from a browser file. If consent is withdrawn, the guest cohort ends. A later signed-in account may start a new cohort; it does not revive the guest one.

This almost always lowers the headline retention number. In Retention Without Fingerprints we treat that drop as a correction. Finance may dislike it. The board pack gets more believable.

A practical check

Plot two day-7 curves for the same build: one keyed on your current join, one keyed only on first_open timestamps with no cross-surface stitch. If they diverge by more than you can explain with product changes, you are measuring identifier life. Write down which curve you will publish. Then delete the other from the weekly room.

The lab that drills this is Retention Without Fingerprints. The mismatch also shows up in module 03 of the flagship studio.