How to read a retention table without flattening the story

A retention table is not a grade. Each row is a group of people who shared a starting event: a first visit, a first order, a membership start. Each later column is a later window in which some of those people returned and some did not. If you only quote the last column, you have thrown away the weeks where the story actually turned.

Start with the row names. If the names are 'January joiners' and 'February joiners,' ask whether January meant the calendar month or a promotional week that spilled into February. Bundlelogicbase briefings write that definition above the table because operators argue about it later if it lives only in someone’s memory.

Then read across, not down. A group that looks healthy in week two and quiet in week six is a different operational problem from a group that never returned after day three. Averaging those patterns into one 'retention rate' makes both problems harder to staff.

Small rows deserve a mark, not a percentage dressed as confidence. When a cohort has too few people to interpret, the honest cell is a note that the group is too thin. Painting a rate on twelve people invites a meeting about a number that will swing if two families take a vacation.

Finally, keep the operational calendar beside the grid. A price change, a storm closure, or a reminder that stopped going out belongs in the same pack as the table. Without those notes, people will invent causes. Customer behavior analytics is slower when the table pretends to be self-explanatory.

All field notes