【Development Diary】On a site with few accesses, how far can you trust a single log entry — Bot detection and handling of n=1
[Key Points]
• For LPs that had been running for more than half a year since opening and had zero requests for logic verification, the first log of "clicking the logic card" was recorded on October 12, 2026
• Three days prior, measures against bot insertion were added to reduce noise, which may have helped detection (not proven)
• One click is not a trend but an observation. Until it is reproduced, do not draw conclusions and continue recording
1. What was recorded
Semura Lab.'s LP includes a tracker for access analytics. It records events such as referral source, scroll depth, dwell time, and clicks to a spreadsheet via GAS, and it was set up to capture presses on the top page's two cards (Logic Verification / Environment & Infrastructure)
The recorded items are limited to date and time, session ID, event name, URL, referrer, scroll depth, dwell time, etc. It is not intended to collect personally identifiable information, but to understand "how one arrived and how far they read" with a minimal configuration.
On October 12, the log first showed an event called card_logic. The flow was as follows: arrive at the top page via an article, scroll to about 70%, click the logic card, and navigate to the verification page.
【Image: fig15_log_flow.png】2. Why the question of whether it is a person first arises
Before celebrating this click, there is something to confirm: is it a human operation?
In fact, in the log from October 8, there were some unnatural entries. About six sessions with different browser-reported details browsed multiple pages in a short time. On the face of the reports, they looked like different visitors, but their movements followed the same pattern.
【Image: fig16_human_vs_crawler.png】On October 9, two items were added to the judgment:
• Treat as a bot movement when a different session rapidly browses multiple pages in succession
• Add points for discrepancies between browser report details and actual behavior
Additionally, the sheet is set to re-evaluate every 15 minutes. Since an initial decision may classify a line as human, it may later align with a crawling pattern and be reclassified as a bot.
3. What can be determined from the log and what cannot
We can determine the path (where it came from), the scroll depth, and which pages were visited.
We cannot determine motive. Why it stopped at 70% and clicked, what drew their interest. Since a bot-detection score has been passed, a human possibility is high, but this is a probability, not a certainty. The log tells us "what was done," but not "why."
Note that bot-detection uses a scoring system. It is difficult to separate human from bot with a single condition. Browser reports can be spoofed, and judging by movement alone might exclude genuinely keen readers who read multiple pages. Therefore, multiple signals are weighted and summed to form a score for judgment. Even so, misclassification cannot be zero, so the criteria are reviewed as they are operated. Bot countermeasures are not a one-and-done thing.
4. How to treat a single instance
Here arises the same issue as backtesting: performance with few transactions is hard to trust. An observation of n=1 cannot be called a trend.
Therefore, the plan for now is to treat it as follows:
• Record the first instance as an "observation" and keep interpretation on hold
• If a similar movement occurs again, consider it as a candidate "pattern"
• Since the final result shows zero requests, track numbers at each prior stage (visit, scroll, click, transition)
In practice, the verification page is reachable, but the report submission (application) has not progressed. At this stage, the hypothesis is that the blockage lies beyond that point. However, this is still a hypothesis and cannot be verified until more data is collected.
The reason for tracking the prior stages is that looking only at the final result provides no actionable improvement insights. A zero-request figure does not reveal where on the LP the problem lies. Is it low traffic, unread content, or unread content that fails to lead to action? By breaking it down stage by stage, we can observe "where people drop off." It is the same concept as analyzing EA results by breaking down entries by conditions, not just by win rate or total profit.
5. Handling changes in search rankings
The same approach applies to search rankings tracked in GRC. The page "EA Verification Report Free" dropped from first to around the 20s, and then rose back to 8th a few days later. This coincided with adding a glossary and an example EA judgment page, but causality cannot be confirmed.
If one continues to attribute daily fluctuations to causes, interpretation may outrun actual changes. It is safer to view rankings over a fixed period.
6. Current status and future
As of now, there are zero requests. The recorded card click count is also only once at the time of writing this article.
Half a year ago, we could not even confirm whether a click occurred. In that sense, having a method of observation is a first step. Going forward, we will continue recording and wait for a second trace to appear. Will it be the same path and depth and pressed again, or will it take another pattern? Only then will the meaning of the first instance become slightly clearer.
We at Semura Lab. will continue observing with our own interpretation even when data is scarce.
If you have any concerns about the log design or verification approach for EA, please feel free to consult at our general inquiries desk.