A 465-point Hacker News thread centered on a number that Google Ads' install total could not reveal: 33 of 56 billed conversions opened an obsolete Android build, registered zero seconds on every screen, and never came back. The discussion had drawn 245 comments when MrKeyoor's brief captured it. For app developers, the useful warning is narrower than the viral claim about robots. An install can be real enough for an ad dashboard and still be worthless as a customer signal.
Nick Abe, the developer of the Dayzle puzzle app, spent $220 on a two-week Android campaign. He concluded that a bot farm generated most of the suspicious activity. His telemetry makes automation a plausible explanation, but the published post does not identify an operator, an ad placement, or Google's final invalid-traffic decision. Those limits matter because this is one advertiser's small campaign, not a measured fraud rate for Google Ads.
One day exposed the mismatch
Abe began with a CA$40 daily budget and a target cost per install of $1.50. The campaign spent little until he removed that target. It then spent CA$80 in a day and reported 21 installs, while Dayzle's admin panel showed one. That two-times daily spend is allowed under Google's current rules: its Maximize conversions documentation says a campaign may cost up to twice its average daily budget on a given day, subject to the monthly charge limit.
The admin counter was incomplete, rather than proof that the other 20 installs never happened. Older Dayzle builds did not report an install date. Abe checked raw analytics and found 21 new Android devices, including 20 running a version that Google Play had stopped serving days earlier. According to his account, those 20 devices named Google Play as the installer, opened the app once, recorded no time on any screen, and did not return.
Over the full two weeks, Google billed 56 installs. Abe classified 33 as matching that obsolete-build pattern, seven as coming from countries outside his targeting, and 13 as people who completed 92 games. The categories printed in the post add up to 53, leaving three installs unexplained. It also mentions 28 phone models while describing 20 phones without clarifying whether the model count covers the larger sample. The raw export is not attached, so readers cannot resolve either discrepancy.
The careful conclusion from the published evidence is that Abe found a cluster of installs with behavior that made no commercial sense. The old binary, single launch and zero engagement are useful warning signs. They do not by themselves establish who installed the app, how the old package reached the devices, or whether Google had already classified any associated ad traffic as invalid.
An install can arrive without a click
The campaign's attribution path is less intuitive than a click followed by a Play Store download. Google says Android App campaigns can use view-through conversions in bidding. A qualifying view can mean at least half of an ad was visible for one second, or that a video played for two seconds. If Google can match a conversion request to that view within 24 hours, it can count a view-through conversion.
Abe's reconstruction is that the suspicious devices watched the shortest video in his ad group, did not click it, and installed a saved copy of Dayzle. That sequence would explain why an install could receive campaign credit without an ad click. The public evidence does not show the placement logs or attribution rows needed to verify the reconstruction, and the stale app version does not reveal who supplied the package.
Google's reporting model gives advertisers several columns to separate these paths. Its mobile conversion guide tells account owners to inspect all conversions and view-through conversions, then segment results by ad event type to distinguish clicks, engaged views and impressions. That breakdown would be more informative here than the aggregate count of 56, but Abe's post does not publish it.
There is another measurement distinction to keep straight. Google defines an install as the download and a first open as the initial launch after installation, and advises advertisers to count only one of them when measuring new users. Android campaigns can import downloads automatically from Google Play, while other setups may report a first-open event. The conversion-tracking documentation makes those separate data sources explicit. Abe does not state which conversion action produced his billed total.
The optimization target was too shallow
The experiment illustrates a basic property of automated bidding: the system can pursue only the event the advertiser supplies. Google's setup page says Maximize conversions for installs seeks the highest install volume within the budget and does not focus heavily on new-user quality. The same bid-strategy guide offers a separate mode for in-app actions such as sign-ups or purchases.
That distinction explains the feedback loop Abe describes. When he removed the $1.50 target, the campaign had more room to buy whatever it could classify as an install. If low-value devices produced that event cheaply, their conversions became training data for further delivery. The campaign did what its chosen metric asked, while Dayzle's actual goal was to acquire people who play puzzles.
Abe has now changed the target event to winning a puzzle. That is harder to produce accidentally than opening the app, and it matches Google's advice to track an install plus at least one in-app event. Google also tells advertisers to identify the events that carry more value in its App campaign recommendations.
A puzzle win is still a proxy. A script could eventually solve or replay one, and a very deep event may happen too rarely for a small campaign to learn from it. Google's guidance says campaigns need enough event data and warns that major changes during the learning period can hurt performance. A small developer therefore has to balance event quality against event frequency, then judge the result against first-party behavior rather than the Ads total alone.
What developers should log
A useful install audit starts with fields the ad platform cannot summarize for the product team. Record app version, first-open time, session duration, country, device model and the first meaningful action. Preserve campaign identifiers where the measurement stack exposes them. Abe found the anomaly because obsolete builds lacked one admin field but still appeared in the raw analytics. Without build-level data, his 56 installs would have looked like ordinary acquisition.
The next comparison should use independent counters with clearly named events. Google Ads, Play Console, a product analytics service and a backend may count downloads, first opens, account creations or active devices. Those numbers need not match. Google's own documentation says conversion windows and attribution systems can create discrepancies, while its Play measurement guide notes that Google Play measures downloads and in-app purchases rather than every product event.
Segmenting by event type is especially important for video inventory. Google says view-through conversions may enter the Conversions column when an App campaign opts into view-through optimization. A dashboard total can therefore combine users who clicked with devices merely matched to an impression or short view. The official definition uses a default one-day view-to-install window, giving developers a concrete period to inspect when strange installs appear.
No single heuristic should decide that a device is a bot. An old build might come from delayed updates, backups or another distribution path; zero-second sessions may expose analytics failure. Confidence rises when several signals coincide, as they did in Abe's account. Even then, keep the raw rows and label the result suspicious until the ad network completes its investigation.
Google's invalid-traffic process is the next test
Google defines invalid traffic as activity that does not reflect genuine interest, including bots and automated software that mimic human browsing. It says automated filters, machine learning and manual review remove detected activity before billing when possible. Later detections may produce a credit. Advertisers can request an investigation for the previous 60 days through the process described on Google's invalid-traffic help page.
That process asks for dates, campaign and ad-group names, device or browser details, locations, web server logs and Google click identifiers where available. Google says specialists usually respond after several business days, but it will not disclose whether particular clicks were marked valid because that information could help attackers evade detection. Abe says he submitted the form and is waiting for an answer.
The refund decision will clarify only how Google treats this campaign, not whether 60 percent of app-ad installs everywhere are automated. The more useful follow-up would pair Google's ruling with Abe's missing event-type breakdown and a reconciled 56-install table. Until those records appear, the grounded lesson from this test is operational: optimize for an event tied to product value, keep an independent activity trail, and investigate a conversion count before feeding more budget into it.