Cheap clicks from inside other apps: judge in-app ads by the sales
Photo by Kaboompics.com (opens in a new tab) on Pexels
Ads shown inside other people's apps, through Google's Display Network and AdMob, Meta Audience Network, AppLovin or Unity, produce the cheapest clicks most local businesses ever buy. Some are thumbs that missed a button, some are fraud, and a few are customers. Here is how to tell them apart with the one record that cannot be faked: who paid you.
Contents
- What in-app advertising is, and who sells it
- Why in-app clicks are cheap: the thumb that missed
- Fraud: traffic that was never a person
- Click-to-call from inside an app
- The worked example: cost per lead against cost per sale
- Judge the apps, not the network
- Reporting in-app advertising honestly
- What to do this month
In-app ads buy the cheapest clicks a local business will ever see, partly because some are thumbs that missed a button and some are traffic no person produced. Ignore cost per click and cost per lead. Put the app name on every lead you can, match leads to closed sales, and keep only the apps that produced paying customers.
A heating and cooling company turns on a display campaign in September and leaves the default settings alone. By the end of the quarter the dashboard is delighted with it: 9,000 clicks at fifty cents each and 150 leads at $30 apiece, half the cost of a lead from search. Most of the traffic came from inside mobile apps, which the owner discovers only when somebody opens the placement report and finds a puzzle game, a flashlight app and a weather app at the top of the list.
None of that is a scandal. Ads inside other companies' apps are a legitimate, enormous market, and some of the people who see them need a furnace repaired. But the price of a click there is set by a crowd of advertisers who, mostly, are trying to get an app installed, not a technician booked, and a meaningful share of the clicks were never decisions. This post is about telling those clicks apart from customers, for businesses that close by phone or in person: home services, auto dealers, clinics and real estate.
What in-app advertising is, and who sells it
In-app advertising is ads placed inside other companies' mobile apps, mostly free games and utilities that earn money by showing them. A local advertiser usually buys it without choosing to: through Google's Display Network, which reaches apps that run AdMob, through Meta's Audience Network, or through networks built for games, such as AppLovin and Unity.
The important word is "usually without choosing to". Very few owners of a plumbing company decide to advertise in a solitaire game. They create a display campaign, or a Meta campaign with broad placements, and the auction finds the cheapest attention available, which is very often a banner at the bottom of a game or an interstitial between two levels. The placement report is where the decision shows up, after the money has gone.
That is the direction of the market: networks whose inventory is mobile games are now selling to advertisers who want web visits and sales, with credits to get them started. Some of those advertisers will do well. A local business considering it should start with the question this post keeps asking, which is not how cheap the clicks are but how many of the people behind them paid an invoice.
Why in-app clicks are cheap: the thumb that missed
An accidental click is a tap on an ad by someone trying to tap something else: a game control, a close button, the next article. Every major network writes rules against placements that cause them, which tells you they are common. The ones a network detects are not billed; the ones it misses look exactly like interest.
Read those four together and the shape is clear. The networks know about the problem, they write rules for publishers, they filter what they can detect, and they add friction where a placement keeps misbehaving. What they cannot do is tell you how many of the clicks they billed were real decisions, because they do not know either. Their filters measure clicks against other clicks. Your sales file measures them against money.
There is also an incentive worth naming without accusing anyone of anything. The app's developer is paid when ads are clicked or viewed. The network takes its share of the same payment. The advertiser is the only party in the transaction who benefits from fewer, better clicks, and so it falls to the advertiser to check.
Fraud: traffic that was never a person
Mobile ad fraud is ad traffic generated by software rather than by people: apps that load ads in hidden windows, fake taps, and devices that only pretend to be phones. It is not a small-business problem specifically, but small businesses pay for it the same way, and they are the least likely to have anyone looking.
Notice the detail that matters to an advertiser: the apps behaved normally for researchers and ordinary installs, and only misbehaved on devices the operators had chosen. A scheme built to avoid detection by a professional security team is not going to be caught by an owner glancing at a click-through rate. It will, however, never produce a customer. Fraudulent traffic can fill in a form with a made-up name and a phone number that belongs to nobody; it cannot book an appointment and pay for it.
A network's fraud filter compares clicks with other clicks. A closed sale compares them with money. Only the second one is immune to traffic designed to look like people.
Click-to-call from inside an app
A call button in an in-app ad turns a tap into a phone call, which is valuable for a business that sells by phone and dangerous for its reporting. A thumb that misses a game control can open the dialer and place a call that ends in seconds. Count those calls by duration and by caller, never by tap.
Two things follow for anyone matching calls to sales. First, a very short call may arrive with no usable number at all, so it can never match a customer, which is fine if it was a misdial and a loss if it was a real person who hung up on hold. Second, the conversion count in the ad platform depends on a threshold you set. Set it at one second and every misfire is a lead; set it at 60 and you will miss the brisk caller who booked in 50. Neither is a sale, which is the point.
- Give in-app campaigns their own tracking number. A call log knows which number was dialed, not which app the ad ran in. One number per campaign at least separates in-app calls from search calls.
- Normalize the caller's number before anything else. Trackers, phone systems and CRMs write numbers differently, and phone normalization is what lets a caller match a customer at all.
- Count first-time callers, not calls. A person who rings back three times is one lead. The reasoning is the same as for duplicate leads.
- Split by duration and keep the short calls visible. Under 10 seconds, 10 to 30, over 30. A campaign whose calls cluster under 10 seconds is producing taps, not conversations.
- Keep unanswered calls in the lead file. A real caller who reached voicemail and bought next week belongs to the channel that sent them; our post on missed calls works through why.
The worked example: cost per lead against cost per sale
Cheap clicks make cheap leads, and cheap leads win any report ranked by cost per lead. Ranked by cost per closed sale, the order often reverses. The arithmetic below is illustrative, not a benchmark: one quarter, two campaigns with the same budget, and the same average sale.
| In-app display | Search | |
|---|---|---|
| Spend | $4,500 | $4,500 |
| Clicks | 9,000 | 1,000 |
| Cost per click | $0.50 | $4.50 |
| Leads (calls and forms) | 150 | 75 |
| Cost per lead | $30 | $60 |
| Leads that became paying customers | 6 | 15 |
| Revenue at $900 a sale | $5,400 | $13,500 |
| Cost per sale | $750 | $300 |
| Revenue per dollar of spend | 1.2 | 3.0 |
The arithmetic. In-app: $4,500 ÷ 9,000 = $0.50 a click and $4,500 ÷ 150 = $30 a lead. Six of the 150 leads bought, a close rate of 6 ÷ 150 = 4%, worth 6 × $900 = $5,400, so $4,500 ÷ 6 = $750 a sale and $5,400 ÷ $4,500 = 1.2 dollars back per dollar spent. Search: $4,500 ÷ 1,000 = $4.50 a click and $4,500 ÷ 75 = $60 a lead. Fifteen bought, a close rate of 15 ÷ 75 = 20%, worth $13,500: $300 a sale and 3.0 per dollar.
On cost per lead, in-app is twice as good. On cost per sale, it is two and a half times worse. The same pattern, cheap leads from broad channels and revenue concentrated in expensive ones, is the subject of our post on cost per lead, and in-app inventory is its purest case: the click is so cheap that a campaign can be terrible at producing customers and still look efficient at producing leads.
But stop before turning the campaign off, because "in-app display" is not one thing. It is a few dozen apps, and in most accounts a handful of them take most of the money.
Judge the apps, not the network
The useful unit for in-app advertising is the individual app, because spend concentrates in a few placements and quality varies enormously between them. To judge an app by sales, the app's name has to travel with the lead into your lead file. For web leads that is a URL parameter; for calls it is usually impossible.
| App | Spend | Clicks | Leads | Cost per lead | Sales | Cost per sale |
|---|---|---|---|---|---|---|
| Puzzle game | $2,400 | 6,000 | 70 | $34.29 | 0 | none |
| Weather app | $1,200 | 1,800 | 45 | $26.67 | 4 | $300 |
| Local news app | $900 | 1,200 | 35 | $25.71 | 2 | $450 |
| Total | $4,500 | 9,000 | 150 | $30.00 | 6 | $750 |
The arithmetic. $2,400 + $1,200 + $900 = $4,500, 70 + 45 + 35 = 150 leads and 0 + 4 + 2 = 6 sales, so the rows reconcile with the first table. The puzzle game took 53% of the budget ($2,400 ÷ $4,500) and produced none of the customers. Exclude it, and the remaining $2,100 produced the same six sales: $2,100 ÷ 6 = $350 a sale and $5,400 ÷ $2,100 = 2.6 per dollar, close to search rather than far behind it.
Is zero out of 70 just bad luck? It can be checked. If the puzzle game's leads closed at the campaign's overall 4%, the chance of 70 leads producing no sale is 0.96 raised to the 70th power, about 6%. Against the other two apps' rate, 6 ÷ 80 = 7.5%, it is 0.925 to the 70th, under half of one percent. Either way, the result is unlikely to be chance. What the table cannot do is rank the weather app against the news app: four sales against two is noise, and anyone who moves budget between them on that evidence is reading tea leaves.
So for form leads from a Display campaign, the app can be captured: add {placement} to the tracking template, have the form keep it in a hidden field, and save it with the lead. Then the lead file says not just "Display" but which app. For calls the trail usually ends at the tracking number, and for campaign types that do not support the parameter, such as Performance Max, it ends at the campaign; our post on Performance Max explains why that report is an account of a decision already taken.
Reporting in-app advertising honestly
Report in-app campaigns on matched sales, cost per sale and revenue per dollar, beside the same figures for every other channel. Keep clicks and leads in the report as volume, not as value. Leads that matched no sale stay unmatched, and sales that matched no lead stay in their own bucket rather than being spread across channels.
- Matched sales and revenue, per channel and, where the lead carries it, per app. A sale counts when the buyer's phone or email appears in the lead file.
- Cost per sale and revenue per dollar. Cost per lead stays in the report as a volume measure, labeled as such.
- Call duration buckets for in-app calls. Under 10 seconds, 10 to 30, over 30, so that taps are visible as taps.
- Leads with unusable contact details. Forms with impossible phone numbers or throwaway addresses are a fraud signal in their own right; count them.
- Unmatched sales, stated. Customers who bought without any matching lead belong in Direct / Unknown, and our post on unattributed revenue explains why spreading them across channels makes the whole report less true.
CloseRev does the matching step in this post and nothing upstream of it: it has no ad-platform connection, no fraud detection and no call tracking. You export two CSV files, your closed sales and your leads, and it matches each sale to a lead by normalized phone number or email. A matched sale is credited to the source written in that lead's row. Only high-confidence matches count automatically, weaker ones wait for review, and sales with no match go to Direct / Unknown.
That last point is the honest limit of the whole method. A sale from someone who saw a banner in a game, ignored it, and searched for the company a week later matches the search lead, not the banner. Matching tells you which channel produced the contact detail that became a customer. Whether the banner deserved some of the credit is a question for a holdout test, which our post on incrementality tests covers; it is not a question any click report can answer.
What to do this month
Find out how much of your display and social spend is running inside apps, put the app name on the leads you can, and give it one quarter of matched sales before deciding. Exclude apps on evidence, not on reputation, and check again after excluding, because the auction will find the next cheapest placement.
- Open the placement report for every display campaign and any Meta campaign with broad placements, and add up the share of spend that went to apps.
- Add {placement} to Display tracking templates and a hidden field to your forms, so new web leads carry the app name.
- Give in-app campaigns their own call tracking number, and export calls with duration and the caller's full number.
- At the end of the quarter, match leads to closed sales and build the second table above for your own account.
- Exclude the apps that took real money and produced no customers, with the probability check above, and leave the ones that sold alone.
- Rerun the placement report two weeks later. Expect new apps to appear in place of the old ones, and treat them the same way.
The arguable conclusion is this: for a business that closes by phone or in person, in-app inventory is not a channel to be for or against. It is a pile of separate placements, a few of which find real customers at a fair price and most of which sell thumbs, misfires and software. The network will not sort them for you, because the clicks it bills are its revenue. Your sales file will, if the app's name is on the lead.
Cheap clicks are not cheap customers. Put the app name on every lead you can, match leads to closed sales, exclude the apps that took money and produced nobody, and judge what is left by cost per sale, never by cost per click.
Questions people actually ask
- Are in-app ads worth it for a local business?
- Sometimes, and only your sales records can say which apps. In-app placements usually win on cost per click and cost per lead, because some of those clicks are accidental taps and some are fraud. Match the leads they produced to closed sales, compare cost per sale with your other channels, and keep the specific apps that produced paying customers rather than the network as a whole.
- Do I pay for accidental clicks on mobile app ads?
- Not for the ones the network catches. Google's definition of invalid clicks includes accidental clicks caused by poor ad placement, says advertisers are not charged for them, and credits clicks it detects after billing. Clicks it does not detect are billed as normal, which is why the sales file is the check that matters: a click that never became a customer looks the same whether it was filtered or not.
- How do I stop my Google ads showing in mobile apps?
- Use placement exclusions. Google's help page says you can exclude websites, videos and apps at the campaign, ad group or account level, with app IDs written as mobileapp::1- plus the App Store ID for iPhone apps and mobileapp::2- plus the package name for Android. Excluding every app removes the cheap clicks and any good apps along with them, so exclude by result where you can.
- Why are calls from in-app ads so short?
- Many are not meant to be calls. A tap on a call button opens the dialer, and a thumb that was aiming for a game control can place a call that ends in a few seconds. Count calls from in-app ads by duration and by first-time caller, set a threshold such as 30 seconds before calling it a lead, and keep the short ones visible as their own line.
- Can I see which app a lead came from?
- For web leads, often yes: Google's {placement} ValueTrack parameter can write the site or app where the ad was clicked into your landing-page URL, and your form can save it with the lead. For calls, usually not, because the phone log knows the tracking number, not the app. Give in-app campaigns their own tracking number so at least the channel is clear.