Read the table
Rows are sorted by flagged events, then by counted page views, largest first. Every website is listed, including those with nothing flagged. The Range picker covers the last 24 hours, 7 days (the default) or 30 days.
- Reasons can add up to more than the flagged events. One event can fail several checks, and each failed check is counted in Why.
- The share mixes two kinds of event. Its counted side is page views only, while flagged events include custom events. A website whose flagged traffic is mostly custom events shows a slightly higher share than its page views alone would give.
- “Flagged traffic is unavailable (Umami unreachable)” means the flagged summary could not be loaded. The counted page views may still show.
Inspect a website
Below the table, Inspect a site links to up to 12 websites that have flagged events in the range. Selecting one addssite=<website id> to the URL and shows Latest flagged events for that website: the 50 most recent in the range.
Flagged events keep the path, referrer domain, country and coarse device only. IP addresses and query strings are never stored.
While a website is selected, the table counts flagged events for that website only, and every other website shows zero. Changing the range keeps the selection. To see all websites again, select Traffic quality in the navigation.
What to do about a project with a lot of flagged traffic
1
Find it and size it
The website is near the top of the table. Compare its flagged share with projects of similar size, and switch between Last 24 hours and Last 30 days to tell a one-off burst from a steady pattern.
2
Inspect its latest flagged events
Select the website under Inspect a site and read the 50 latest events. Look at the timing (regular bursts or spread through the day), the paths (one URL over and over, or real pages), and the client column (one identical client string, or a normal mix).
3
Match the reasons to a cause
The combination of reasons usually points to the cause:
4
Check the counted numbers
Open the project from All projects and look at Overview and Website for the same range. Flagged events are not in those numbers. If counted traffic also jumped at the same moment, with an unusual shape, that traffic passed every check, and the checks alone cannot settle it. Put the project next to similar ones in Compare.
5
Act on what you found
- A configuration problem: contact the project. For a project that signed up itself, the contact email is on Enrollment: in its queue entry, or under Recent decisions for the latest 50. Typical fixes are
data-domains, HTTPS, the pinned Lumenstat tracker and a missing domain. Framework recipes has the exact tag. - A deliberate attempt: nothing is needed to protect the numbers, because flagged events are already excluded. Note the range, the reasons and the share if you need to refer to it later.
Limits
- Requests rejected before the checks are not shown. Umami’s own bot check, by user agent, and its IP block list drop requests before the four layers run. Those are not stored.
- Fake traffic that passes every check is counted and does not appear here. A real browser running the tracker from a home or mobile network passes all four layers. An anomaly view for sudden changes in traffic or flagged share is planned for Milestone 2.
- The screen calls Umami once per project and once per website on each load. It slows down as enrollment grows. Aggregated queries and CSV export for the operator view are planned for Milestone 2.