Case study
Why robot traffic in analytics looks like new customers
A burst of sign-ups after an app update looks like growth, and a busy website looks like demand. Here is how we found that almost all of it was machines, and how to tell people from robots in the figures you already record.
Key takeaways
- A jump in app sign-ups on the day you publish an update is usually the app store's own test phones rather than new customers.
- Visits where nobody pressed, scrolled or typed, and that end within seconds, are the clearest sign of a machine.
- Keeping robot visits in their own column lets you check the rule later and keeps those accounts out of your sales list.
- Read each app and each site on its own, with the change against the period before, rather than one total for everything.
- Recording anything new about visitors means your privacy policy has to cover it first.
Robot traffic in analytics is often why a burst of new sign-ups, or a busy week on your website, looks like demand when nothing of the sort has happened. App stores install every new version of an app on their own test phones and let a robot tap through it, while speed tests and uptime monitors open your pages on a timetable, exactly as a browser would. We keep visit figures for our own website, our apps and our blog; within a week of those figures starting they stopped adding up, and the rules that tell people from machines went live the same afternoon we asked for them.
What a burst of new sign-ups really means
People and machines land in the same figure, and only one of them can become a customer. A store's test phones install your app before anyone downloads it, and a robot taps through it, signing up along the way. A speed test opens your site, sees that it answers and leaves. Neither asks you anything or buys anything, and both leave a visit behind.
If those visits sit in the same number as your customers, that number no longer means what you think it means. The answer is not more tracking; it is separating people from machines in what your analytics already records.
How our own figures stopped adding up
We record how people find and use our own website, our apps and our blog, so that we can see which of them brings real interest.
The Android app soon showed a steady trickle of new visits and sign-ups from "business owners" who signed in with a Google account and never named a company. The website counted hundreds of visits on which nobody pressed, scrolled or typed anything. Not one sign-up had been recorded as a goal, and everything sat in one total, people and machines together, every app mixed in with the others.
The detective work: where robot traffic in analytics hides
The Android visits came from the app store's own test phones, and the website's empty visits came from programs doing what a browser does.
We stopped reading totals and looked at the visits one by one. The Android visits that swelled the count shared one kind of device: the same phone model name, the same older Android version, a very small screen, a connection from the United States, and a different time zone each time. They appeared within hours of each new version of the app reaching Google Play.
That is the store's pre-launch report. Google installs every new version on its own test phones, and a robot taps through the app, signs up with a Google account and looks around. We had already marked those robot accounts so that they never counted as clients, but the new visitor figures still counted their visits as clients' visits.
The tell was the phone's model name, which no phone bought in a shop reports. The time zone tells you nothing, because the robots change it.
On the website, the empty visits had signs of their own: a browser window of exactly the size programs use when nobody is watching, a visit that named no browser and no system, or a page opened and left within seconds with nothing touched. Speed tests and site monitors also name themselves in what their browser sends.
One reason the goals stayed at zero was simpler. When somebody signs up in the app, the account exists a moment before the app reports the visit, so the sign-up had no visit to land on and was dropped.
What we changed
Every visit now gets a verdict, person or robot, from what our analytics already records under our privacy policy: the pages opened, presses, scrolling, forms, time and the device. Nothing new is collected about anyone. A finer sign, such as mouse movement, would need a new privacy policy first.
A visit counts as a robot's when it comes from a store's test phone, an emulator, or a browser a program drives, or when a page was opened and left within 30 seconds with nothing pressed, scrolled or filled in. A visit counts as a person's when somebody presses, scrolls or fills something in, stays 30 seconds or more, or is a signed-in client.
Robot visits are kept and can be shown, so the rule can always be checked later, but every report counts people unless robots are asked for. Each source has its own figures with the change against the period before, and one switch shows people, robots or both, on our dashboard and on the screens our staff use.
Every visit recorded since 7 October was judged again by the same rules. A sign-up that arrives before its visit is known now waits up to an hour for it instead of being lost.
What we have now
Live since 13 October 2026. In the week that followed, nearly all of the Android app's visits turned out to be the store's test phones, and about three website visits in four showed no sign of a person: most were opened and left within 30 seconds with nothing touched, and the rest came from browsers driven by programs.
The test phones had been signing up again and again on each day that a new version reached the store. Those sign-ups now go to the robots' column rather than to new customers, and sign-ups made in the app reach the figures as goals. The totals are smaller, and they are now about people.
What you can check yourself
- Put your Android app's new sign-ups beside the days you published an update. A jump on that day, with no company names behind it, is usually the store's test phones.
- Look at the phone models behind your Android visits. The same model again and again, with a small screen and a connection from outside your country, is a test lab.
- Count the website visits where nobody pressed, scrolled or typed, and that ended within seconds, and see what share of your total they are.
- Check whether visits from speed tests and uptime monitors are left out of your visitor figures.
- Sign up in your own app as a test, and see whether that sign-up reaches your goals report.
Before you act on a figure, ask whoever looks after your website and apps how machines are kept out of it. The answer tells you how much the number behind your next decision is worth.
Separating people from robots in figures that already exist, rather than collecting more about visitors, is one of the things our engineers do for clients.
Questions people ask
Why do my app sign-ups jump every time I publish an update?
Because the app store runs every new version of your app on its own test phones before it reaches anyone, and the robot on those phones signs up like a new user. Those sign-ups arrive while your update is being checked, and they carry no company name or real contact behind them. Put your sign-up dates beside your publish dates: if the two line up, that is the store testing, not demand. Keeping those accounts out of your sales list is simpler than trying to stop them.
How can I tell bot visits from real ones without adding new tracking?
Usually from what your analytics already records: pages opened, presses, scrolling, forms, time on the page and the device. Visits where nothing was pressed, scrolled or filled in, and that ended within seconds, are almost always machines, and so are visits from a browser that reports no browser or system at all. A store's test phones share one phone model name, a very small screen and a connection from outside your country. If you decide to record anything new about visitors, your privacy policy has to cover it first, so check with an adviser.
Should I delete robot visits from my analytics?
Better to keep them and set them aside. If you delete them, nobody can check the rule later or see whether the number was wrong before. Keeping them in their own column means your reports count people by default while the robot visits stay available if you want to look. It also lets you show a platform, or whoever looks after the site, what their own checks are doing to your figures.
Why is my sign-up not showing up as a goal in my reports?
It can be a timing problem: the account is created a moment before the app manages to report the visit, so the sign-up arrives with no visit to attach itself to and is dropped. The other common reason is that no goal was ever set up for the app, only for the website. Ask whoever looks after your analytics whether app sign-ups are recorded as a goal, and whether a visit report can wait a short while for a late sign-up rather than losing it.
Do speed tests and uptime monitors count as visitors?
They do unless they are filtered out. A speed test or a monitor opens your pages on a timetable, exactly as a browser would, and these tools name themselves in what they send with the request. If that sign is not used, each check adds a visit that ends within seconds with nothing touched. Ask whether they are excluded; if they are not, they belong in the robots' column rather than in your visitor figures.