How to Tell if Astrina Is Tracking Bot Traffic Correctly
You do not need a grand audit to answer one question: is Astrina classifying bot-like visits the way you expect in this property, on this campaign, right now? That is a narrower test than judging traffic quality across the whole account, and it saves time. Start there.
The cleanest way to work is to pick one property, one landing page, and one small window. Ten minutes can be enough. You are checking the tracking logic, not the health of your entire acquisition mix.
1. Define the exact bot-checking scenario
Write down the scenario before you open the dashboard. Name the property, the campaign, the page path, and the behavior you expect to see. If a crawler hits /pricing three times in 90 seconds, that is a specific case. If a QA tool loads the same page with the same user agent from one IP, that is another.
This matters because bot traffic can mean different things in different places. A newsletter campaign can attract link scanners. A public docs page can draw scrapers. An ad landing page can get preview bots from ad platforms. Do not mix those cases in one test set. One test, one target.
If you are validating a setup after a change, note the exact change. Did someone add a filter? Did the agent get installed on a second subdomain? Did a new alert rule go live? Those details decide whether the result is a product issue or a configuration issue.
2. Pick a small test window with known bot signals
Choose a short time window where you expect bot-like activity to be visible. A 30-minute slice works better than a full week when you are trying to confirm classification. If you already know a source, use it. If you know a landing page, use that. If you know a crawl-heavy hour, even better.
Look for a baseline you can explain in one sentence. For example: “This page was shared in a bot-heavy forum at 14:00,” or “This campaign was hit by a monitoring check every 5 minutes.” The cleaner the baseline, the easier it is to tell whether Astrina is tagging the visits correctly.
One practical move: compare the test window to a quiet window of the same length. If the bot signals appear only in the expected window, and Astrina treats them differently from the quiet window, you have a useful starting point. If the two windows look identical, pause. Something in the setup may be hiding the signal.
3. Reproduce the visit pattern you want to test
Use a repeatable pattern. Hit the same path from the same browser profile, or from the same test host, or with the same user agent string. Do it in the same order each time. Three visits, one minute apart, is easier to review than a messy burst of random clicks.
A simple pattern can look like this: page A, then page B, then page A again. Or homepage, then product page, then checkout page without pausing. Some bots do exactly that. Some humans do too, which is why the repeat count matters. Two hits are weak evidence. Five or more can tell a clearer story.
Keep the test narrow. Do not flood the property with hundreds of requests unless you are trying to test scale behavior, and that is a different job. A small set of known visits is enough for most checks. You want readable traces, not noise.
If you need a clean installation first, the agent setup page is here: * and the normalized visible-text size. Install once, confirm the property is receiving data, then run the bot test. A failed test is meaningless if the tracker was never active.
4. Check whether Astrina records the event chain consistently
Open the individual visit or session view and inspect the sequence. Pageviews should appear in the order you generated them. Referrers should match the source you used. Timestamps should line up with the minutes, not drift into another hour. A bot test is supposed to be boring here.
Watch for gaps. A bot may fire pageview events without a matching session start. A reload loop may create duplicate hits with the same path. A crawler may arrive with no referrer, then bounce through two internal pages. These patterns are not proof by themselves, but they tell you whether Astrina is seeing the chain as a single bot-like sequence or as unrelated traffic.
One useful check is the interval between hits. If you triggered requests every 20 seconds, the recorded gaps should stay close to that rhythm. If they are collapsed, stretched, or reordered, the problem may be in timestamp handling rather than bot classification.
That small detail matters. A bot label that sits on the wrong visit is a bad label. So is a good label attached to the wrong path. Check the chain first, then the label.
5. Compare classification outcomes across filters and views
Do not trust a single dashboard tile. Check the same test set in the main view, any saved segment, any export, and any property-level filter you rely on. The result should stay consistent. If a visit is labeled as bot in one place and human in another, that is a reporting problem worth chasing.
Use at least two views if you can. One view may hide filtered traffic. Another may expose the raw events. That difference is useful, not annoying. It tells you whether the classification exists at the event level, the session level, or only in a derived report.
If you keep a measurement map for the property, cross-check the bot test against the events you expect to measure: pageview, session start, referrer, and any custom event tied to the campaign. The article on what to measure in website analytics can help when you need to name those fields clearly.
Do not skip exports. A CSV can reveal a mismatch that the dashboard hides behind grouping. Look for the same session ID, the same page path, and the same bot flag across all three places. If the flag vanishes in export, that is a concrete failure.
6. Look for false negatives and false positives in the test set
Now audit a small sample by hand. Pick 5 obvious bot hits and 5 obviously human visits. You do not need a huge sample. You need obvious cases. If a known crawler was missed, that is a false negative. If a normal human visit was flagged, that is a false positive.
Use the simplest evidence you have. A bot test from a monitoring service, a synthetic browser run, or a known QA IP can provide the bot side. A test from your office Wi‑Fi or a staff account can provide the human side. Keep the distinction clean. Mixed samples waste time.
Watch for edge cases. A browser extension can make a human visit look odd. A privacy tool can strip referrers. A corporate proxy can group multiple people behind one IP. None of those alone proves Astrina is wrong, but they explain why one hit may land in the wrong bucket.
If you want to compare the bot label against a product flow, session replay can help. The post on astrina session replay for checking checkout shows how to use replay in a narrower journey. That is useful when the bot test touches form fills, cart actions, or checkout steps.
7. Verify downstream reporting and exclusions
Correct classification is only half the job. You also need to confirm that the bot traffic is excluded, routed, or counted the way your reports expect. Check alerts, exports, and any integration that reads from Astrina. If bot traffic should be excluded from a metric, verify that exclusion in the place where the metric is consumed, not only inside Astrina.
Look at one downstream example. If your weekly report pulls only non-bot sessions, does the test traffic disappear there? If your alert watches for suspicious spikes, does the bot test trigger the alert or stay below the threshold? If a downstream dashboard uses a saved filter, does the filter still work after the bot label is applied? Three separate checks. Three different failure points.
This is also the point to review product or stack changes that alter analytics behavior. If browser rules changed recently, the post on what changed in website analytics after can give useful context for a report shift that is not caused by bot detection at all.
Some teams also send bot-handled traffic into a separate process, especially when an alert or support workflow depends on it. If your setup includes a withdrawn or gated path, confirm the routing rules still behave as expected after the bot label lands. One missing exclusion can flood a report within hours.
8. Document the result and what to retest next
Write down the test before you forget it. Record the property, the test window, the source, the path, the number of hits, and the outcome. Five lines are enough. If the label matched expectations, say so. If it did not, note exactly where it failed: missing label, wrong session, wrong export, or broken exclusion.
Keep the next test specific. If the first check used one IP, retest from a second IP. If the first check used one page path, retest on a different page. If the first check used pageviews only, retest with a referrer change or a repeated click pattern. One change at a time. That is how you isolate the problem.
Use a short checklist after any configuration change, agent reinstall, or new release. The setup page can help if you need to reinstall the agent from scratch: * and the normalized visible-text size. If your team works from a staging property, mirror the same validation there first. Staging failures are cheaper.
If you want a cleaner view of how a tracked visit should move through the property, review the baseline article on how to set up astrina uptime. Uptime is not bot detection, but it teaches the same discipline: one known event, one known result, one checkable path.
After that, keep the notes visible. A single sentence like “10 repeated hits from one IP were labeled bot in dashboard, export, and alert filter on Tuesday at 14:20” is worth more than a vague pass/fail note. Write the date. Write the path. Write the exact failure if there was one. Then retest that exact case next time.
