Recurring Purchase

Subscription: PRO

The Recurring Purchase module identifies products that individual users buy on a repeating cadence and predicts when each user is due to buy again. It enables timely replenishment reminders and reorder campaigns by learning each customer's personal purchase rhythm from their transaction history — rather than just what they rebuy, it predicts when.

Where Frequently Bought Product answers "which products does this user buy often?", Recurring Purchase answers "when will this user run out and need to reorder?"

‌

Key Requirements

Before setting up the Recurring Purchase module, ensure that:

• The PRO subscription is active.

• Purchase/transaction engagement data is available via web tracking, including quantity per line item (the cadence is quantity-adjusted).

• A product feed is configured with product IDs that match the product IDs in your transaction data. This is essential for linking purchase history to the correct products.

• If your catalog contains product variants (e.g. sizes or colours of the same product), ensure these are identifiable via a variant ID, parent ID, category, or similar attribute so the module can group at the level you want (see Item grouping below).

• For CDP delivery: CDP credentials — for CDP v1 an Event Type ID; for CDP v2 (CXP) a Tenant ID, Definition ID, and Access Token.

‌

How It Works

The module analyses each user's purchase history for a given item group, measures the time between repeat purchases (their cadence), and projects that forward to predict the next purchase date. Users whose predicted date falls inside a configurable delivery window are published to the CDP so campaigns can reach them just before they reorder.

Processing steps:

1. Transaction scoping — Filters purchases to a configurable lookback window (default: 730 days).

2. Purchase aggregation — Groups purchases per user and per item group (default the product itself; can also be category, brand, etc.). Same-day purchases are combined and quantities summed.

3. Interval calculation — For each user–item-group, computes the number of days between consecutive purchases.

4. Sequence cleaning — Ignores one-off abnormal gaps relative to the user's own rhythm: a gap longer than the user's average interval × (1 + tolerance) starts a fresh sequence, and only the latest clean streak is kept. This stops a long holiday break from distorting a steady weekly cadence.

5. Product eligibility — Keeps only item groups that enough distinct customers repurchase (minimum distinct buyers and minimum repeat rate), so one-off or non-replenishable products are excluded.

6. User eligibility — Keeps only users with enough purchase history and recent activity within the lookback window.

7. Cadence calculation — Computes the user's quantity-adjusted average interval (buying more units at once implies a longer gap until the next order).

8. Next-purchase prediction — Predicts the next purchase date and an overdue score indicating how far past due the user is.

9. Delivery window & change detection — Selects users due within the delivery window and, on normal runs, sends only users whose prediction changed since the last run (incremental).

10. Publishing — Delivers results to the CDP as personalization events.

‌

Configuration

General Settings

Transaction Scoping

Item Grouping

Eligibility

Prediction Window

Evaluation (Optional)

The module records every prediction and, weekly, measures how many actually converted within the window plus the mean error in days — visible as accuracy metrics.

CDP Integration

‌

Example

A user buys the same dog food roughly once a month, most recently a 2-pack on 1 September:

The gaps between the single-unit purchases are ~28–30 days, so the quantity-adjusted average interval is about 29 days per unit. Because the last order was a 2-pack, the module expects it to last roughly twice as long:

• Predicted offset ≈ 29 days × 2 units ≈ 58 days

• Predicted next purchase date ≈ 29 October

With a 60-day future horizon, this user enters the delivery window and receives a "time to reorder" event ahead of that date. Had the last order been a single unit, the predicted date would have been ~30 September instead.

‌

Use Cases

• Replenishment campaigns — "Time to restock your dog food!" reminders timed to each customer's individual cadence.

• Personalized reorder suggestions — "Buy your favourites again" in newsletters or on-site, surfaced just before the user runs out.

• Subscription recommendations — Identify products a customer buys on a reliable rhythm as candidates for a subscription offer.

• Timing optimisation — Trigger campaigns at the moment of highest reorder intent (overdue and due-soon users) rather than on a fixed schedule.

‌

Output

The module produces a table with the following information per user and item group:

Results are delivered as personalization events to the CDP, including product details (name, category, image) for use in campaigns and web personalizations. Only users whose predicted purchase date falls within the configured delivery window are published, and normal runs send only the users whose prediction has changed since the last run.