Retention is one of those settings that gets left at the default until the day somebody asks for a year-on-year comparison and finds the data stops fourteen months ago. Here is how to pick a number deliberately.
Start with the reports you actually run
Not the ones you might run. The ones you opened last quarter.
Most analytics questions are answered inside 90 days: how is this month against last, did the campaign work, which pages get read, where did the traffic come from. If that is genuinely all you do, a short retention is not a compromise.
Three questions need longer, and they are the ones that catch people out:
Year-on-year comparison needs at least thirteen months, and really needs fourteen so that the comparison period is complete before the current one ends. A twelve-month retention cannot answer "how was this December against last December", because last December left the window as this one began.
Seasonality needs two or three full cycles before a pattern is distinguishable from a coincidence. For a retail business that is two to three years.
Long conversion cycles need to cover the cycle. If your buyers take four months to decide, a 90-day window has thrown away the first touch by the time the sale happens, and your attribution silently reassigns it.
Write down which of those three you actually need. If none of them, stop reading and set 12 or 14 months.
What the law requires
Under the GDPR, storage limitation (Article 5(1)(e)) says personal data may be kept no longer than is necessary for the purpose. There is no number in the regulation, because the necessary period depends on the purpose.
The practical consequence is that "we keep everything forever" is not a policy you can defend, and "we keep it for 26 months because that is what the tool defaults to" is not one either. What you need is a period you chose, a reason you can state, and deletion that actually happens.
Some regulators have been specific in guidance about audience measurement. The CNIL's exemption for consent-free audience measurement, for instance, comes with a retention limit as one of its conditions. If you are relying on something like that, the number is not yours to pick.
Two things reduce the problem rather than solving it. Aggregation -- keeping daily totals rather than individual events -- means the long history is no longer personal data at all, so the storage limitation stops applying to it. And a tool that stores no persistent identifier has less to defend in the first place.
What longer retention costs
Money, if the tool prices on it. Some do.
Query speed. A dashboard reading five years of events is slower than one reading three months, unless the tool pre-aggregates -- and if it does, ask what the aggregate keeps and what it throws away. Aggregates are usually built for the questions somebody anticipated.
Risk surface. Data you hold is data that can be breached, subpoenaed, or requested. Five years of visitor-level records is a materially larger liability than one year, for value that decays fast.
That last point deserves the emphasis. The usefulness of a visitor-level record falls off a cliff after a few months. The risk it carries does not fall at all.
A method
- List the reports you ran in the last three months. Note the longest period any of them looked at.
- Add one full year if you compare year-on-year, or two to three cycles if you need seasonality.
- Take the longer of that and your conversion cycle.
- Round up to a whole month and write down the reason next to the number.
- Check whether the tool can keep aggregates for longer than raw events. If it can, set raw events short and aggregates long, which gives you the history without the liability.
- Verify that deletion actually happens. Set a reminder for a month after your first period elapses and go looking for a record that should be gone.
Step 6 is the one people skip, and it is the only one that tests whether any of the rest was real. A retention policy that is configured but not enforced is worse than none, because it is documented.
What to check in the tool you use
- Is retention configurable, or fixed by plan?
- Does it apply to raw events, to aggregates, or to both?
- Is deletion actually deletion, or a flag that hides rows from reports?
- What happens to data already collected when you shorten the period? Some tools apply the change going forward only.
- Can you export before the window closes?
The third one catches people. "Deleted" that means "excluded from the dashboard" is not deletion, and it does not answer a subject access request.
Where Skomi sits
Skomi ties retention to the plan rather than making it a per-site setting, and the periods are published on the pricing page rather than discovered after the fact. That page reads the live plan catalogue, which is why the numbers are there and not repeated here.
Two details worth knowing, because they are the questions above:
Session recordings expire sooner than analytics on every plan -- 30 days where analytics gets 90 or 365. That is deliberate. A recording is the heaviest and most revealing thing Skomi stores, and it is the thing whose usefulness decays fastest; keeping it as long as a page-view count would be carrying the largest risk for the smallest return.
Deletion is deletion, and the rollup goes with it. The pre-aggregated daily totals are purged on the same schedule as the rows they were built from, because a site that kept its totals for months whose page views were gone would be reporting from data it no longer holds. That does mean Skomi will not give you a long aggregate history behind a short raw window -- if that is the arrangement you want, it is a fair reason to look elsewhere.
What is stored is set out in the privacy policy with the actual column list rather than a description of one, and deleting a site purges every store rather than hiding it.
The window itself comes from your plan and applies per product, which the Analytics page lists alongside everything else it keeps; retention is the term as Skomi uses it.