Requested options (any of the following would help)
Aggregation-only mode
Allow showing only anonymized/aggregated metrics (no chat titles, no message excerpts, no user identifiers).

This is already the case if you disabled https://docs.openwebui.com/reference/env-configuration#enable_admin_chat_access (which i assume you did?) - if this is disabled, no chats, no chat titles, no message excerpts, nothing of this is visible.

I have the usecase of a german worker council(Betriebsrat) asking for the option to disable per user analytics data for their approval in corporate usage. They have legal ways in german companies to block usage of tooling and in general oppose any possibilites to track per user data.

Hi, I know about work councils, and I know that it may sometimes be difficult to push things through.

But I am genuinely confused how the current metrics, as they are, could present an issue for "monitoring employees".

As we have already established, you do not see what model an employee used. You do not see what the employee used the model for. You do not see when the employee used which model (though all of these things are technically easily retrievable via simple database queries).

The only thing you see is: how many messages did an employee send and how many tokens exist in their account right now.

And this number isn't even accurate: because if an employee deletes their chats after using the AI, the statistics get cascade deleted. The numbers you see in the admin panel are based on whatever is in the database at the time of viewing. If the employee deletes some or all of their chats, the statistics change accordingly. This is worth emphasizing: no monitoring system gives the monitored party a delete button. The fact that users can unilaterally make these numbers disappear means this is definitionally not a surveillance tool.

It's like viewing the storage an employee consumes in their email inbox. Each employee has a fixed amount of storage. Does the amount of storage consumed equate to productivity or usage? Not at all. If the employee deletes older emails, storage goes down. If they never delete, it goes up. But storage is not a marker of productivity or behaviour, nor is it a meaningful measure of how someone uses the service. Someone consuming 50MB might send hundreds of emails a day.

You don't anonymize the username in the email storage view either. You know exactly that Hans consumes 23 Gigabytes for his email inbox. There's no good reason to anonymize that - and nobody asks for it.

So why anonymize the number of messages and tokens that currently exist in a user's account? Because that's all the analytics show: the current amount of messages and tokens across a user's chats at time of query. It doesn't equate to productivity. It doesn't equate to behavior. And if it would, then you would also have to anonymize the amount of storage consumed by an employee in their email inbox.

The threshold under German labor law (§87(1) Nr. 6 BetrVG) is whether a technical system is designed to monitor employee behavior or performance. A volatile, user-deletable message count is justifyable as not being such a system. The values displayed by the system can change any second and because the employee can actively tinker with the number shown, you cannot infer any behaviour or performance metrics from it (and neither can you from consumed storage in the inbox).

And in terms of GDPR, no additional obligation arises from displaying data that is already collected and processed for the purpose of providing the service (as we have already established).

To add to this: I've verified the code path: when a user deletes a chat, the chat message table (which is what the analytics are based on) gets deleted first, before the chat record itself is even removed. And even if that operation were to fail, the chat has a CASCADE deletion with a foreign key constraint as a fallback. The system is explicitly designed to ensure analytics data does not survive chat deletion.

When a chat is deleted (via Chats.delete_chat_by_id at backend/open_webui/models/chats.py:1494), the code does:

db.query(ChatMessage).filter_by(chat_id=id).delete()  # explicit message deletion
db.query(Chat).filter_by(id=id).delete()               # then delete chat

Even if the explicit deletion were removed, the foreign key constraint on chat_message.chat_id at backend/open_webui/models/chat_messages.py:54-56 is defined with ondelete="CASCADE".

This means the database itself would cascade-delete all chat_message rows when the parent chat row is removed.

If I am missing anything here, since I am from Austria not Germany, which might have slightly different laws (though extremely similar in this area) then please let me know. But I cannot see any reason how this would be legally troublesome. Neither in terms of GDPR nor worker's rights.

Edit: As per legal justification needed for such metrics; if admins need access to per-user storage consumption to plan for storage purchases, backup storage servers and hard drives, being able to adjust the storage quota of individual users (if Hans reaches 90/100GB you might want to increase specifically his storage), which are all equally legitimate administrator tasks which require seeing the total and per-user storage consumption, ... then....

logically, shouldn't the message and token count be too? Sure it is volatile because users delete their chats or use the temporary chats exclusively, or the admins even forcing them to exclusively use the temporary chats feature (which is a feature that exists, you could force them to always use temporary chats) - then why shouldn't an admin be able to see that?
An admin might need to plan ahead in terms of local inference hardware. If more messages get sent, more token processed, he might need to purchase more servers. Or if remote inference providers are used, he might have to look into getting the rate limits increased, purchase additional quota or else.

If you use custom filters to apply rate limits to how many tokens a user can use or how many messages he can send (aka an upper limit, like the email storage upper limit), then it would be needed to see how close specific users are to reaching that limit in order to adjust the rate limits specifically for those power users.

There are many ways admins may justify having access to this data under §87