Where do users come from
An indie developer was billed for 56 installs and 33 were bots; we have eight apps and the same question, so here is what we do instead of buying installs.
On 11 September 2026 the developer of the puzzle app Dayzle wrote that CA$220 of Google app ads over two weeks was billed for 56 installs: 33 behaved like bots (opened once, zero seconds on screen, never returned, running an old build), 7 came from countries the campaign did not target, and 13 were real people; the post passed 500 points on Hacker News. We recognise the problem: eight shipped apps and still few users. So instead of buying installs we are doing two things — making the apps and this site findable (canonical URLs, structured data, RSS, Naver Search Advisor registration, all shipped this week) and putting games where people already are (two are live inside Apps in Toss). A new platform is in preparation; whatever it is, the number we watch there will not be installs.
We read a post about 56 paid installs, 33 of which were bots. We have shipped eight apps and still have few users, and after reading it we are even more hesitant to buy installs. For now we do two things — make people find us, and go where people already are — and we are preparing one new platform.
What the post said
fact It was written on 11 September 2026 by the developer of the puzzle app Dayzle (the original, checked 12 September 2026). He spent CA$220 over two weeks on Google app ads for Android, and the goal was 'installs'. 56 installs were billed. Of those, 33 opened the app once, spent zero seconds on every screen, and never came back. They were running an old build the store no longer distributes. 13 were classified as real people. Another 7 installs came from countries the ad did not target, and the remaining 3 were not classified in the original post.
fact The discovery started with a single number (same post, checked 12 September 2026). Google reported 21 installs in a day, while the app's own dashboard counted 1. Opening the raw data, 20 of the 21 new Android devices showed the pattern above. He wrote that those twenty devices were twenty-eight different models across nineteen states. His explanation is this. Google optimises for the goal the advertiser gives it, and the goal was installs, so the more a bot farm repeated 'install', the better that placement looked, and the more ads went there. He reported the invalid traffic and changed the goal from 'open the app' to 'solve one puzzle'.
fact The post got more than 500 points and more than 260 comments on Hacker News (checked 12 September 2026) and was posted on GeekNews as well. Several commenters pointed at the structure. A bot farm is on the side that shows the ads. The advertiser pays Google, and Google pays the publisher that showed the ad. According to the author's reply, the installs themselves are not what earns the farm money. An install only makes that placement look good so it draws more ads, and what the farm is paid is the price of showing those ads, by the structure above. The advertiser bears the loss alone.
Why this is not someone else's problem
The reason is simple. We have shipped eight apps and we still have few users.
Build it and they will come turned out not to be true for us. So ads that buy installs have always stayed the last option on the list. That post put one more price tag on that option. Not just the money, but the risk of trusting a number a bot made and making the next decision on it.
Three things we take from it
- Do not set the goal to 'installs'. A system hits exactly the goal it is given. Ask for installs and it goes toward whoever manufactures installs. The goal has to be something only a person can do. Dayzle set it at 'solve one puzzle'.
- Compare the ad report with our own screen every day. 21 and 1 was a gap visible in a single day. Zero-second sessions, an old build running, no return visit. Those three are a bot's traces.
- Build a 'real behaviour' metric first. Most of our apps have no login. So before we turn an ad on there have to be events like 'finished a round' or 'solved one cube'. Without that, we too have no choice but to count installs.
Two things we do instead
We go in two directions. We were on this road before we read that post. One is making people find us. fact This week we settled the site's canonical URLs into one, added structured data, RSS and a sitemap, registered with Naver Search Advisor, matched the app descriptions to the store copy, and opened this blog (11 September 2026). Someone looking for a cube app does not search for '한눈 큐브 (Cube at a Glance)'. The work is writing our answer in advance, in the words that person does search. It is slow, but there are no bots in it.
The other is going where the people already are. Sweet Drop has been open inside Apps in Toss since 30 August 2026, and 반장키우기 since 8 September 2026 (inside Apps in Toss they are called 디저트 머지 and 반장 키우기). They open right inside Toss, so there is no install to step over. We are watching how people arrive there and how many stay.
And we are preparing one new platform. What it is, we will write when it is ready. One thing became certain after reading that post. The number we watch there will not be 'installs'.
This post is not an answer, it is a worry. If you are worrying about the same thing, tell us at hi@oddduck.ooo. Everyone is welcome except bots.