Overview

Schema retention settings control how long data is kept for specific fields or tables in your schema. Retention policies help you manage data lifecycle, comply with privacy regulations, and keep profiles clean by automatically expiring stale data.

Retention applies to the data on profiles, not to the audiences built from it. Audiences are live filters that re-evaluate as profile data changes — they have no lifespan of their own. The optional per-audience Expires After setting is unrelated to retention: it deletes the audience definition and leaves every profile untouched. See Audiences.

📘

Schema retention is opt in; some account settings are not

The schema-level controls on this page — field keep_days and capacity, and table retention — apply only once you configure them. Nothing expires by default.

Two account-level settings are different: depending on your package, event archive retention (archive_retention_duration, between 1 and 12 months) and the anonymous profile cull (cull_anonymous, commonly 60 days) may already be active without anyone having configured them. Both are ordinary account settings, so a per-account value overrides the package default, and where no value is set the data has no age limit.

To confirm what applies to you, check your package and whether an account-level override is in place. Your account team can confirm both.

Configuring Retention

Retention settings can be applied at the table level to control how long profile data is retained.

API Reference

Get Retention Settings

GET /v2/schema/{table}/retention

Returns the current retention configuration for a table.

Update Retention Settings

POST /v2/schema/{table}/retention

Updates the retention configuration for a table.

Field-Level Retention

Individual fields can have keep_days configured to control how long their values are retained on profiles. When keep_days is set, field values older than the specified number of days are automatically cleared during profile maintenance.

📘

See Fields & Mappings for details on configuring keep_days when creating or updating fields.

Use Cases

• Cookie expiration: Set retention on cookie-based identity fields to automatically expire inactive anonymous profiles.
• GDPR compliance: Configure retention limits on PII fields to ensure data is not kept beyond required periods.
• Data freshness: Expire behavioral signals that become stale after a defined period (e.g., recent purchase flags).

Other Data Lifecycle Controls

Schema retention is one of several independent controls. Each operates at a different level, and they can be combined.

Audience expiration is deliberately absent from this table. Setting Expires After on an audience deletes that audience's definition and nothing else — no profile, field value, or event is removed. It is an organizational convenience for retiring unused audiences, not a data lifecycle control, and it does not contribute to any retention or minimization requirement.

🚧

Culling is not deletion

Culling removes profiles from the profile store and search index but does not delete the underlying event data. If new events later arrive for a culled identifier, the profile is rebuilt with its prior history. To permanently remove a person, use Identity Deletion.

For how these controls map to privacy obligations and data subject requests, see Privacy and Data Protection and Compliance. For modeling consent — which Lytics does not track natively and you define in your own schema — see Consent & Privacy.