Every click event is a record: a timestamp, a device, a referrer, a hashed IP. Stored forever, those records grow without bound and become a privacy liability. Stored too briefly, reporting loses history. Retention policy is the deliberate answer to how long data lives — this guide covers the trade-offs and the pattern that works.
The data types and their lifecycles
Click data comes in three layers with different costs and values:
| Layer | Content | Cost | Value |
|---|---|---|---|
| Raw events | Every click, full context | Highest | Deep-dive, audit |
| Daily rollups | Clicks per day per link | Low | Trend reporting |
| Totals | Cumulative per link | Negligible | Dashboards, comparisons |
The sensible policy is tiered: raw events live short (weeks to a quarter), rollups live long (years), totals live forever. Each tier has a distinct retention window because each tier has a distinct purpose.
What drives the window
Privacy obligations. Raw events contain personal data by construction: a hashed IP is still a pseudonymous identifier, and referrer URLs can contain account names. GDPR and similar regimes require purpose limitation and storage minimization — retention windows are the engineering expression of that duty.
Storage economics. Raw events at 100M clicks/year grow linearly and get queried rarely after 90 days. Storing them costs real money with zero reporting return.
Operational needs. Quarterly reviews, annual reports, and marketing audits need history — but they need it at the rollup level. Nobody deep-dives raw events from last year.
The tiered pattern
The pattern used in practice:
RAW EVENTS → retained for the current window (e.g. 90 days),
then deleted (or archived encrypted)
DAILY ROLLUPS → retained for years — this is the reporting layer
TOTALS → retained indefinitely — dashboard numbers
The analytics endpoints reflect the tiers: the overview returns daily series and breakdowns from the rollup layer, while per-link recent events come from the raw layer. The analytics explained guide shows which endpoint serves which layer.
Archiving: the middle path
When raw data must outlive its window (audit requirements, dispute evidence), the middle path is encrypted archive: dump the window to encrypted storage, delete from the live database, and restore on demand. This satisfies both privacy minimization (live attack surface shrinks) and legal preservation.
What teams should do
- Know your retention policy — read the privacy policy and the docs; know exactly what lives where and for how long.
- Archive what you need — before any deletion window, export the series and breakdowns you want to keep:
curl -H "Authorization: Bearer yas_live_..." \
"https://yas.sh/api/v1/analytics/overview?days=90" -o analytics-archive.json
- Reconcile cutover dates — when comparing historical reporting across platforms or policies, document the date the data tiers change.
- Design new platforms with tiers — if you're building your own analytics, ship the raw/rollup/total split from day one; retrofitting it later is expensive.
Conclusion
Retention is the lifecycle policy for data: raw events for the near term, rollups for the long term, totals forever. It bounds privacy exposure, controls storage cost, and keeps reporting stable. The analytics API exposes the layers transparently, and the privacy policy documents the windows — the two together tell you exactly what your click data's life looks like.