Webclat / Tealium Practice
Webclat / Tealium Practice  /  capability guide

Tealium's profile retention policy: how long visitor data actually lives, and who controls it

"How long do you keep this?" is a real question from legal, from a data subject request, and from whoever is watching AudienceStream's storage cost grow. Profile retention policy is where that question gets an actual, enforced answer.

What profile retention policy governs

Retention policy controls how long AudienceStream keeps visitor-level data - events, attributes, and identifiers - before it ages out of the profile. It is a compliance control and a cost control at the same time, not merely a technical setting buried in an admin screen.

When it actually matters

  • Any GDPR or CCPA-adjacent program where "how long is this kept" is a real, answerable question from legal or a data subject request
  • Any AudienceStream implementation large enough that stale, unretired profiles are inflating cost without adding measurement value

How to approach it properly

Set retention deliberately per data sensitivity rather than accepting one blanket default across every attribute - a loyalty ID and a low-value browsing event do not need the same retention window. Document the policy alongside the actual privacy notice it needs to match; a retention setting that is technically correct but never reconciled with the public privacy policy is still a compliance gap when someone checks. Coordinate the setting with whoever owns the privacy policy language, not just with whoever has admin access to change it.

How to verify it worked

After changing a retention setting, confirm on a test profile that data actually ages out at the configured interval - not just that the setting saved without error. Administrative permissions and the exact retention mechanics for this setting vary by tier and Tealium release; confirm both against current documentation and your own admin role before treating a change as live.

The gap this closes: a retention window that is technically correct in the platform but was never told to whoever wrote the public privacy policy is still, functionally, undocumented - and undocumented compliance controls do not hold up under scrutiny.

Common questions

Is retention policy the same across every AudienceStream attribute?

It doesn't have to be - retention can and often should be set per data sensitivity rather than as one blanket rule. Confirm what granularity your tier actually supports.

Who should be able to change retention settings?

This is an administrative, governance-relevant control - access should be limited and coordinated with whoever owns the organization's actual privacy policy commitments, not left to general admin access.

Make retention policy match what your privacy notice actually says.

A review of current AudienceStream retention settings against your documented privacy commitments, with a verification test that data actually ages out on schedule.

Audit My Retention Policy