Skip to main content

​
CDP retention windows

GDPR storage limitation (Article 5(1)(e)) asks you to keep personal data no longer than needed — and most privacy programs answer that with a written policy saying “we retain analytics events for N days.” Orbit’s CDP makes that policy something you can enforce in-product: the Retention tab on the CDP page (/integrations/cdp) exposes a per-data-class time-to-live window for every prune-able CDP surface, and the API contract behind it — GET/PUT/DELETE /api/v1/cdp/retention-policy — lets you script the same posture. A tenant with no overrides behaves exactly as the platform ships; nothing changes until you set a window.

​
Section 1 — What data classes retention governs

Three prune-able classes, each with a documented platform default: Profiles, identifier graph entries, and computed traits are not retention targets — they persist until a contact erasure removes them. Retention governs the rolling event/delivery/violation stores; identity is governed by erasure propagation.

​
Section 2 — Available windows and guard rails

Each class carries a [min_days, max_days] range burned into the product. The server clamps any override into that range, so a tenant can never set an unsafe window at either end:
  • Minimum ≥ 1 day — a 0-day “delete on write” policy would race the ingest path and destroy in-flight analytics. The floor makes that impossible.
  • Maximum per class — raw events cap at 730 days, deliveries and violations at 365 days. The cap keeps the hot-table index and SLA-query assumptions each surface was sized for intact.
The catalog endpoint returns each class’s live range; the dashboard dialog renders the range inline (“Allowed range 1–730 days”) and re-checks the value client-side before it enables save.

​
Section 3 — What is preserved vs deleted per class

The reaper prunes a class on the class window, and the resolution order decides which window applies to any given row:
  1. A per-event-name override (raw track events only) — exact match on the event name.
  2. The class-level override, if you set one.
  3. The platform default, otherwise.
Deleted: any row in the class older than its resolved window. Preserved: everything younger, plus all non-retention data (profiles, identifier graph, accounts, segments) — a tight retention window never collapses a profile; erasure does that.

​
Section 4 — API contract

All routes are owner/admin/developer + contacts:read for reads and contacts:write for writes.
Each response includes source — default, target_override, or event_override — so an auditor can see exactly which layer resolved the window in force today. Response envelope per class:

​
Section 5 — Preview before save

Don’t PUT blind. The single-target GET returns the class’s effective window before you write, with the guard-rail spec attached — build the row the operator sees from that response:
Response:
The dashboard dialog shows the same preview (“Platform default is 90 days”); out-of-range values are clamped on save, never silently truncated.

​
Section 6 — Sample PUT: several classes in one policy

Send one PUT per class — the registry is per-key. Here raw events tighten to 45 days with two per-event carve-outs, deliveries stay extended to a year, and violations tighten to 14 days:
event_overrides is rejected with EVENT_OVERRIDES_UNSUPPORTED (400) on a class that doesn’t support it — only raw_track_events accepts the map. The notes field (max 500 chars) rides along as audit context in the registry.

​
Section 7 — Rollback semantics

Removing an override is DELETE /retention-policy/:target — the class reverts to the platform default on the next reaper pass, and the DELETE response returns the now-effective window (source: "default"). The guard-rail clamp means an accidentally-requested 99999 becomes max_days, and the accidental 0 becomes min_days — never the dangerous extreme either direction. Retained data is not affected retroactively when you reset; rollback only changes the boundary the next prune uses.

​
Section 8 — Tenant-safety warning

Retention is tenant-scoped: the registry lives on your organization’s own settings row, so one tenant can never see or shorten another tenant’s window, and there is no global gate. The warning is about blast radius inside your tenant: a shortened window is how downstream erasure and clean-room requests propagate the same way — when an Article-17 erasure runs, destinations replay against the current effective envelope, so a tightened retention policy shrinks what an erasure can fan out to (nothing outside the window exists to propagate). Review retention changes alongside your erasure-propagation policy before tightening a window for an active DSAR posture, and treat retention edits the same way compliance treats erasure-policy edits: an audited, reasoned change.