Users and identity
How ErrorDock counts active users, what DAU, WAU and MAU mean here, funnels and retention, and how to choose a user identifier.
Active user counts, session volume and retention are standard product analytics. What is unusual is having them next to your exception data, so the question "is this error affecting real usage" has an answer on one screen instead of across two vendors.
Choosing an identifier
The SDKs keep an anonymous install id on their own, so a device is counted before anyone signs in. To count a person across devices, set your own user id. That identifier is yours, and the choice has consequences that are awkward to reverse.
- Use a stable internal id. An account id keeps working when someone changes their email address. An email address does not.
- Use the least identifying value that works. You are the controller of this data; ErrorDock is the processor. An opaque account id is easier to defend and easier to delete.
- Set it as early as you can. Events before the identifier is known are counted, but they cannot be attributed to the person who produced them.
Without your own identifier, sessions and events are still recorded — they just cannot be joined across devices, so one person on a phone and a laptop counts as two.
User identifiers are hashed on the server. Raw identifiers are stored only if the project turns that on, and it is off by default.
Active user counts
| Metric | Window | Reads as |
|---|---|---|
| DAU | Rolling 24 hours | Habit |
| WAU | Rolling 7 days | Regular use |
| MAU | Rolling 30 days | Reach |
The ratio between them is usually more informative than any of them alone. DAU divided by MAU is how often the average reaching user comes back; a product where that number is 0.05 and one where it is 0.6 are different products regardless of how similar their MAU looks.
All three count distinct identifiers, not sessions and not events.
The Users page shows these aggregates only. There are no per-user profiles and no user search.
Funnels and retention
D1, D7 and D30 retention are always shown. Beyond the headline numbers there are funnels of two to six steps, over a window of up to 30 days, and a retention cohort grid. During the beta, funnels and the retention grid are enabled per organisation.
Affected users on an issue
Because errors and product events share one identity model, every issue reports how many distinct users hit it, not only how many times it fired.
An exception firing ten thousand times for one background job is an annoyance. One firing forty times across forty accounts in checkout is an incident. Event count cannot tell those apart; affected users can.
Deletion
A deletion request for one of your users is a deletion by identifier: one person's data can be erased by the identifier you set. Because the identifier is one you chose and control, you can carry it out without ErrorDock having to guess which rows belong to whom — which is the practical reason to prefer a stable internal id over anything derived from personal data.
See Data and privacy for retention periods, scrubbing and DPA availability.
Related
Last updated October 20, 2026