rfm_train_test_split for CLV model evaluation

[TianruiZhang]

Is there an example showing how rfm_train_test_split used in the evaluation of a CLV model like BG/NBD model? I assume model evaluation on unseen data would be necessary for any CLV models like BG/NBD to avoid overfitting, right? Since rfm_train_test_split was just released, there is no code example, anyone please give an example.

[DanteTrb]

Great question and you’re absolutely right to raise this!
When evaluating CLV models like BG/NBD or Pareto/NBD, splitting your data correctly is crucial to avoid data leakage and to properly assess generalization.

What does rfm_train_test_split do?

This function is designed to simulate the real-world temporal structure of customer behavior by splitting the RFM table into:

• Calibration period (train): where the model learns purchase patterns
• Holdout period (test): where model predictions are evaluated

This split is not a classic train/test based on rows, but rather based on time, maintaining customer IDs across both splits. The idea is to respect causality: you should only use past purchases to predict future ones.

Code Example (using lifetimes)

from lifetimes.datasets import load_cdnow_summary
from lifetimes.utils import calibration_and_holdout_data
from lifetimes import BetaGeoFitter

data = load_cdnow_summary(index_col=[0])

# Split into calibration (first 6 months) and holdout (next 6 months)
summary_cal_holdout = calibration_and_holdout_data(
    data, 
    'frequency', 
    'recency', 
    'T', 
    calibration_period_end=6
)

# Fit on calibration data
bgf = BetaGeoFitter()
bgf.fit(
    frequency=summary_cal_holdout['frequency_cal'],
    recency=summary_cal_holdout['recency_cal'],
    T=summary_cal_holdout['T_cal']
)

# Predict number of transactions in holdout period
from lifetimes.plotting import plot_period_transactions
plot_period_transactions(bgf)

Why it's necessary:

Without this temporal split, your model might "cheat" by learning from purchases that occurred after the moment of prediction, which defeats the purpose of evaluating customer lifetime value.

So yes, as you correctly pointed out, unseen data is mandatory to avoid overfitting and to simulate real deployment scenarios.