The only email KPI that compounds, and how to build it
Your list moves every month; most reporting cannot see it. Build the month-over-month migration view from two exports and watch who climbs, who holds, and who slips.
What campaign metrics can't tell you about your base
A strong send month can sit on top of a decaying base.
Rows are last month, columns are this month
Each row is a tier last month. Each column is the same tiers this month, ordered best first, Champions on the left. Every customer lands in exactly one cell. On the diagonal, they held. Left of the diagonal, they climbed toward Champions. Right of it, they slipped. Everything the program needs to know this month starts as one of those three counts.
If you score on ten buckets, keep the ten for targeting and roll them into five tiers for this report. A ten-by-ten matrix has a hundred cells and no readers. Five by five reads in a minute. Choose the roll-up once and keep it stable month to month, so the numbers stay comparable.
The whole build: two exports and a lookup.
-
Snapshot monthly
Score your list (the RFM pillar covers how) and save the export with the date on it. Your ESP overwrites the score the next time you run it, so the dated export is your only record of where each customer stood this month.
-
Keep every snapshot
Never delete an old export. Two months of snapshots show a migration view, six show a trend, and twelve show whether the base is compounding rather than riding one good quarter. Dated CSVs cost nothing to store and get more useful with every month you keep.
-
Join months per customer
Match on email or customer id, whichever is stable in your exports. Put last month's bucket in one column and this month's beside it, one row per customer. A spreadsheet lookup does it. A customer missing from one month was new or gone, and that is data too.
-
Count the moves
For each bucket, count who climbed, who held, who slipped. The percentages summarize the month. The named customers behind them are what you act on. Pull the customers who slipped out of your top buckets: that is this month's save list, the highest-value output of the whole build.
Not scored yet? Start with the RFM teardown, then come back with your first snapshot.
Three numbers, one list of names.
Climb rate
The share of customers who moved up a tier this month. This is the proof the program moves people instead of just sending email. When a welcome flow or a winback works, it shows up here first, as customers crossing into better buckets.
Slip rate
The share who moved down, and from where. Weight matters: one slip out of your top tier costs more than ten at the bottom. Read slip rate tier by tier. Blended into one number, the cheap slips at the bottom bury the expensive ones at the top.
The save list
The named customers who slipped from high value. Lead with a reason to return: the restock of what they buy, the new arrival in their category, the plain check-in. Reach for a discount only after those reasons are used up.
Take your last two exports and run the join. Count how many customers left your top bucket last month. Write the number down. Now ask what fired when they left: which email, which flow, which anything. For most brands the answer is nothing. The best customers on the list slipped, and the program treated them like everyone else. This view closes that gap: a monthly report naming the customers to save while they are still worth saving.
The math has been public since 2000
Pfeifer and Carraway formalized this in "Modeling Customer Relationships as Markov Chains," Journal of Interactive Marketing, 2000: customers modeled as movement between recency states, tracked with a transition-probability matrix. The same table you just built. The paper also relaxed the assumption that a lapsed customer is gone for good, which is the formal case behind the save list. Operators converged on the same practice from the field: transition-triggered automation, and migration rate as the core retention KPI.
Pfeifer and Carraway, Modeling Customer Relationships as Markov Chains, Journal of Interactive Marketing, 2000
The report that proves whether the program compounds
Month one, this view is just a baseline. By month six, it shows whether the program is compounding or only repeating a calendar. This is the report our clients get every month, built in their account, on their data, theirs to keep if we ever part ways. If you would rather see it built than build it, book a fit call.
What operators ask
How often should I rebuild the view?
Monthly, on the same cadence you re-score the list. Migration is a month-over-month read by construction, so rebuilding weekly only adds noise. Pick a day, put it on the calendar, and let twelve identical snapshots do the work.
What tool do I need?
A spreadsheet. The build is two exports and a lookup, and the method survives any tool you move to later. Automation earns its keep once the list is big enough that the manual lookups hurt. Until then, start by hand; you will read the report better for having built it yourself.
What is a good climb rate?
There is no universal benchmark worth quoting. Climb rates depend on category, purchase cycle, and how you drew your buckets, so any figure quoted without that context tells you nothing. The baseline that matters is your own month one, and the trend against it. This page is how you get that number.
Build it yourself, or have it on your desk monthly
Everything on this page is enough to build the view in a spreadsheet today. Or we build it in your Klaviyo, run it, and send you the migration report every month. Yours either way: your account, your data, kept if you leave.
More from this series: the lifecycle playbook the RFM teardown our Klaviyo Composer review
Sources
- Pfeifer and Carraway, "Modeling Customer Relationships as Markov Chains," Journal of Interactive Marketing, 2000
- Datadrew: RFM segmentation operator playbook (migration KPIs, transition-triggered automation)
- Concomitant: the RFM scoring teardown (the snapshot this view is built from)
No benchmark rates appear on this page on purpose: your baseline is month one on your own data.