How long should you keep knowledge usage data?
· 1 min read
Keep knowledge view data long enough to learn from it, and not so long that you store personal data without a purpose.
In brief
Teams collect knowledge view data for a good reason: to see what people actually use. Then they either keep it forever, or delete it so fast that the pattern never forms. Keep it forever and you store a quiet record of who looked at what, and when. That is useful for improving articles, but it is also personal data with a shelf life nobody chose. Delete it after a week and you lose the only honest signal you had. You cannot tell which articles still help, which ones died last month, and which ones nobody opened at all. Privacy and compliance pull one way, and learning from usage pulls the other. Neither extreme is a policy. Both are habits that grew while nobody was looking. This article argues for a better question: what decision will this data change? If you keep view counts to improve search, retire dead articles and spot gaps, you need months, not years. If you keep who clicked what, you need a named purpose and a review date. It sets out three plain rules: keep aggregate usage longer than named person-level logs; write down why you keep the data and when you delete it; and review the policy once a year, not when someone asks for an audit. Usage data should make knowledge better for the next person who needs it, not just make a spreadsheet bigger.
Teams collect knowledge view data for a good reason: to see what people actually use. Then they either keep it forever, or delete it so fast that the pattern never forms.
Keep it forever and you store a quiet record of who looked at what, when. That is useful for improving articles. It is also personal data with a shelf life you never chose.
Delete it after a week and you lose the only honest signal you had. You cannot tell which articles still help, which ones died last month, and which ones nobody opened at all.
The tension is real
Privacy and compliance pull one way. Learning from usage pulls the other. Neither extreme is a policy. Both are habits that grew while nobody was looking.
A better question: what decision will this data change?
If you keep view counts to improve search, retire dead articles, and spot gaps, you need months, not years. If you keep who clicked what, you need a named purpose and a review date.
Three plain rules
- Keep aggregate usage longer than named person-level logs.
- Write down why you keep it, and when you delete it.
- Review the policy once a year, not when someone asks for an audit.
Usage data is meant to make knowledge better for the next person who needs it. If it only makes a spreadsheet bigger, you are collecting the wrong thing for the wrong length of time.
Next step
How long do you keep knowledge view data where you work? Join the conversation on ESM's Exchange: https://exchange.esm.institute
Tags: knowledge management, service management, privacy, ESM
Join the Exchange free
Join free to unlock the complete knowledge library.
Founder membership is free for life
More from Esm
How should the service desk handle a Microsoft 365 outage it cannot fix?
4 min read
Deploying AI is the easy part: who runs it once it goes live?
5 min read
How do I compare help desk tool pricing before rolling it out across several departments?
4 min read
Turning 'not helpful' into a fix
1 min read
When the author leaves, who owns the article?
2 min read
Test after every change, or find out from users
1 min read
Related articles
How should the service desk handle a Microsoft 365 outage it cannot fix?
Treat a supplier cloud outage as your own major incident: log it once, tell people early on a channel that still works, update on a rhythm and review your dependency afterwards.

Deploying AI is the easy part: who runs it once it goes live?
Only a third of large enterprises have met the business case for their main AI programme. New research points to a gap in who runs AI after launch, and what leaders can do.
How do I compare help desk tool pricing before rolling it out across several departments?
Compare help desk tools on a full year's cost for your real agents, approvers and requesters in every department, not on the headline monthly price.
Turning 'not helpful' into a fix
'Not helpful' is free, honest feedback, and most of it goes nowhere. Turn that click into a fix.
When the author leaves, who owns the article?
Articles keep being read after their authors move on. Make sure the care for them does not leave too.
Test after every change, or find out from users
Knowledge changes fail quietly. A short, repeatable test after every change finds the problem before your users do.
