Keep it alive

First, the knife. With the cut at the mean, "high spend" means above the mean of M in that snapshot. New customers arrive, a few large baskets land, and the mean moves. A customer who spent R$ 160 has not changed, but in one snapshot she is below the line and in the next she is above it. The groups look different and nobody bought anything. The same happens to the frequency mean and to the recency mean, which drifts on its own as the whole base ages against a later snapshot date.

Second, the group sizes. Even with the knife frozen, the shares move because the base moves: a marketplace that acquires 6,000 customers a month adds them almost entirely to General develop and Low value, so the Key groups shrink as a share without losing a single member.

Third, individual customers moving corner to corner. This is the drift that pays for the cadence. The migration crosstab between two snapshots, one row per June group and one column per September group, is built step by step in the retention course's analyst session 4 and is described here in one paragraph rather than rebuilt: join the two tables on the person id, cross-tabulate the old group against the new, and read the off-diagonal cells. The cell that matters most is Key win-back to Low value, because it is the customer who was frequent and big, went quiet, and was not reached before "quiet" became "gone".

There are two defensible policies and they answer different questions. A frozen threshold, the mean of M from the first snapshot written into the spec as a number, keeps the groups comparable across time: a customer only changes group when she changes. That is what you want when the question is "are we moving people up", because then the movement is the signal. A moving knife, the mean recomputed each run, keeps the groups honest to the current base: "high" means high among the customers you have now. That is what you want when the question is "who are the top people to call this month", because a threshold frozen in a year when baskets were smaller will eventually call half the base "high".

The trade-off is real and neither side wins it. What is not defensible is not knowing which one you are running. A team that recomputes the mean each month and then reports "Key win-back grew 20 percent" is reporting knife movement as customer movement. Write the policy into field 6 of the spec, and if it is the moving knife, print the knife's value in every run so a reader can see how much of the change is the line moving.

Each field is a literal value, not a description. 1, person id: the column name, customer_unique_id, and one line on why it is not customer_id. 2, which orders count: order_status == "delivered". 3, spend: the column, payment_value summed per order, and the word total or average. 4, window: all time, or the trailing number of months. 5, snapshot date and the rule that chose it: 2018-09-01, end of the last complete month, found by plotting orders per month. 6, the cut and why: mean split, because the tutorial the team learned from used it, or median split because the spend column is skewed, or Klaviyo's thresholds because the tool decides. The why is what a successor needs when she wants to change it. 7, the taxonomy and the action per group: the eight names from session 1 and the action table from session 5, as a table, not a paragraph. 8, holdout share: the fraction of every audience that is not messaged, so the action can be proved. 9, cadence: monthly, weekly or quarterly, and the day of the run. 10, owner: a name.

Adjectives are the failure mode. "Recent customers with meaningful spend" is a sentence two analysts read two ways. "R below 239.5 days, M above R$ 165.20" is a sentence that produces one table.

Once the spec is a file, it can be put under version control next to the code, and then a change to the model is a change to the file. Someone moves the knife from the mean to the median: that is a one-line diff in field 6, and the reviewer asks "why" before it runs, instead of asking "why did Key win-back double" after the segment counts land in a dashboard. Someone shortens the window to twelve months: a diff in field 4, and the reviewer knows to expect the frequency column to fall. The eight-group taxonomy from session 1 lives in field 7 as a dictionary, so swapping it for Klaviyo's six or Putler's eleven is also a diff, and the reviewer can pull up the finding from sessions 2 and 3 that under those two maps nine in ten "Champions" on a one-time-buyer base bought exactly once.

This is the same discipline any shared dataset gets from a schema: the consumers of the table are protected from silent change because the definition is a reviewable artefact. RFM tables rarely get it because they start life in a notebook, and the spec is how they leave it.

"What is this customer worth over the next year?" is a forecast, and RFM has no time axis in its output. The buy-till-you-die family, BG/NBD for how many purchases and Gamma-Gamma for how much each one is worth, answers it, and it takes recency, frequency and tenure per customer at the snapshot as its inputs. It is built in the retention course's analyst session 6.

"Which customers are about to leave?" is a probability per person, and it needs a label: a definition of "left" that can be checked on past customers. RFM's "quiet" corner is a heuristic for this, not a model of it. The churn model in the retention course's analyst session 7 is the tool, and R, F and M are usually three of its strongest features.

"Are there natural groups I have not drawn?" is the one question the eight corners cannot answer by construction, because the corners were drawn first. Clustering lets the data propose the groups, and the Unsupervised Learning course uses the three-number RFM portrait as exactly those features.

And the one it usually can: "who do I message this month, and with what". For a shop with one channel and a monthly send, three digits and eight actions are the whole model, and reaching for anything heavier is a way of avoiding the holdout question from session 5. Say so plainly in field 6 of the spec: "RFM is enough, revisit when the question changes".

Lifetime value wants three columns per customer measured at the snapshot: recency (in the buy-till-you-die convention, the age of the customer at her last purchase), frequency as repeat purchases, and tenure, the time from first purchase to the snapshot. Tenure is not in the standard RFM table, so the handoff means adding one aggregation, first=("order_purchase_timestamp", "min"), to the session 1 pipeline. Everything else transfers as is, including the frozen snapshot, which the model needs for exactly the same reason RFM does.

Clustering wants the three raw columns, not the scores. The 0 and 1 digits are the answer to a question already asked; feeding them to k-means asks the algorithm to rediscover the corners you drew. Feed it R, F and M scaled, usually log-transformed first because M and F are heavily right-skewed on any retail base, and let it propose groups the taxonomy has no name for. Then compare its clusters against the eight corners with the same crosstab from Part 1.

A churn model wants a label before it wants features. The label is the part RFM cannot provide: "did not buy within N days after the snapshot" is one honest definition, and it requires a later snapshot to exist. The dated files from Part 1 are therefore also the training data for the handoff, which is another reason to save every one of them.