Customer data glossary

Replay (event replay)

By Art Kukharenko · Published 2026-10-17 · Updated 2026-10-18

Event replay re-processes previously recorded events from a stored log, so a platform can rebuild profiles, fix errors or feed a new destination without asking sources to resend.

Part of the Learn hub and the customer data glossary.

What it means in practice

Replay depends on retention: events must sit in a durable log or archive. A stateless pipeline that forwards events and forgets them cannot replay; a Hacker News discussion comparing RudderStack with Segment raised exactly that gap 1. Replay is used to rebuild profiles after a bug in identity resolution, to backfill a new destination with history, to recover from an outage, and to reconstruct what the platform knew at a point in time.

Replay is risky if done naively. Events may relate to people who have since withdrawn consent or asked for deletion, so a replay must apply the current consent state and deletion records or it will resurrect them. Replay into live destinations can resend messages or double-count conversions, so replays should write to profile stores and analytics first, use idempotent keys, and be flagged so journeys do not fire.

Retention is itself a governance decision. The longer you keep events, the more you can replay and the more personal data you hold, so set retention by purpose and delete or pseudonymise on schedule.

Example (retail banking): a bug mis-merged some profiles for two weeks. The bank corrects the matching rule, replays the 14 days of events into a staging store, compares results and then promotes the corrected profiles, applying the suppression list throughout and keeping journeys switched off.

Event stream: the retained log replay reads.
Event contract: old events need versioned schemas.
Identity resolution: a common reason to replay.
Audit ledger: records what was replayed.
Suppression list: must be applied during replay.

Where it matters

Customer data platform architecture: where replay sits.
Migrating off a SaaS customer data platform: a 90-day plan: replaying history into a new platform.

Back to the customer data glossary or the Learn hub.

Frequently asked questions

How is replay different from a backup?

A backup restores stored state. Replay re-runs events through current logic, so it can produce new, corrected state.

Does replay conflict with deletion?

It can. Replay must apply deletion and suppression records and consent state as of replay time, and archives should be purged or pseudonymised when deletion applies.

How far back can you replay?

As far back as you retain events. Set retention by purpose and cost, and keep schema versions so old events stay readable.

Sources

Hacker News discussion, RudderStack versus Segment (practitioner comments, not vendor statements) Open source