Apple Ads counts installs. Your app's sales close somewhere else

Apple Ads reports taps and installs, and its attribution is built so you never learn who installed. For an app that is a front door to sales closing elsewhere, record the AdServices campaign at first launch, attach it to the phone or email captured at sign-up, and match those sign-ups to closed sales. Judge it on cost per paying customer.

A dealership group launches an app for booking service appointments and requesting trade-in quotes. It buys App Store ads on its own name, on "oil change near me" and on the names of two competitors. The Apple Ads dashboard at the end of the quarter says 1,500 installs at $6.00 each, and the marketing manager is pleased: that is cheaper than a web lead. Then the general manager asks how many cars, service tickets or trade-ins came out of it, and nobody can say, because the dashboard stops at the install and the sales live in the dealer management system.

This post is for that kind of business: one whose app is a way to book, ask for a quote or start a conversation, with the money changing hands later at a counter, on a phone call or in a showroom. Clinics, home-service companies, dealerships, salons, gyms and real-estate teams all have versions of it. Apple's ads can work very well for them. But Apple's reporting answers a question they are not asking, and its privacy design means the answer to the question they are asking has to be built inside the app.

What Apple Ads is, and what changed in 2025 and 2026

Apple Ads is Apple's ad platform for the App Store, formerly Apple Search Ads. It sells placements in App Store search results, on the Search tab, on the Today tab and on product pages. Search results ads are bought on keywords and, for Apple Ads Advanced accounts, charged per tap.

Two pricing models exist, and it matters which one you are on. Apple's invoice help describes cost-per-tap pricing for search results ads as applying to Apple Ads Advanced accounts only, and cost-per-install pricing as applying to Apple Ads Basic accounts only. Either way, the billing unit is an event in the App Store. Nothing Apple charges for is a booking, a quote request or a sale.

The extra search positions are worth noting for one reason: they changed what a tap is worth. An ad halfway down the results reaches a person who has already scrolled past the top result, often your own organic listing. More of your taps can now come from people who were going to find you anyway, which is the same question every paid search buyer faces on branded terms and the reason the pause test later in this post exists.

What Apple reports: taps, installs, and two windows

Apple Ads reports impressions, taps, installs, new downloads and redownloads, cost per tap and cost per install. An install is counted if it follows a tap within 30 days or a view within one day. Redownloads, by people who had your app before, count as installs.

Read the redownload definition with a dealership in mind. A customer who bought a car from you two years ago, gets a new phone and searches your name to reinstall the service app is a redownload, and therefore an install, and therefore part of your cost per acquisition. That customer was acquired two years ago, probably by a different channel. For businesses with a loyal base, redownloads can be a large share of installs, and they are the share least likely to be new revenue.

Every number in the Apple Ads dashboard ends at the install. For an app that sells nothing itself, the install is the first step of the funnel, priced as if it were the last.

Why an install is not revenue

An install becomes revenue only after four more steps that Apple never sees: the person opens the app, creates an account or makes a request, your staff follow up, and the sale closes in a system outside the app. Each step loses people, and the losses differ by campaign and keyword.

The steps are worth naming because each one is a place where a good-looking campaign can quietly fail:

1. Install to first open. Some people install and never launch the app. Apple counts the install; your app never runs, so it never learns anything.
2. First open to sign-up. A booking app that asks for an account before showing availability loses people at the door. This is the step where a phone number or email is captured, and so the step that makes everything after it measurable.
3. Sign-up to request. An account is not an appointment. Some people browse prices and leave.
4. Request to sale. The quote is sent, the appointment is kept or missed, the trade-in offer is accepted or not. This happens at your counter, in your CRM or in your practice-management system.

Keywords make the gap wider. A person who searches the App Store for your business's name is very different from one who searched a competitor's name or a generic phrase. The branded installer probably already had a reason to buy from you; the competitor-name installer is shopping. Apple will happily report a lower cost per install on your own name, and it usually is lower. Whether those installs produce any sale you would not have made is a separate question, and the dashboard cannot answer it. We made the general case for that kind of number in cost per lead.

What Apple's attribution tells your app, and what it never will

Apple offers two privacy-preserving attribution routes. AdServices tells your app, on the device, whether its own install came from an Apple Ads campaign, ad group or keyword. AdAttributionKit, which builds on SKAdNetwork, sends delayed, aggregated postbacks. Neither identifies the person, and neither knows anything about sales outside the App Store.

That is the useful half. Your app, running on the person's phone, can ask Apple once, within a day of first launch, "did an Apple Ads campaign bring me here?" and get back a campaign, ad group and often a keyword. It cannot ask "who is this person?", and Apple's answer is built so that it cannot be used that way. The person becomes known to you only when they choose to give you a phone number or email, which is exactly what a booking or quote app asks for anyway.

AdAttributionKit is the other route, and for this kind of business it is the less useful one. It is designed for measuring installs and re-engagement across registered ad networks, without user-level data.

A postback that arrives a day or two later, with detail that depends on volume, describes a campaign, not a person. That is fine for judging which ad network drove installs. It cannot be joined to an invoice, and it was never meant to be. For a small clinic's app with a few dozen installs a month, Apple itself notes that AdAttributionKit data may be limited, and AdServices is the more useful signal.

The privacy limits, stated plainly

Apple's ad platform is built so that advertisers receive campaign results, not people. Targeting needs more than 5,000 matching people, the attribution payload carries no user or device identifier, some ad groups return no attribution at all, and Apple never sees or receives your sales. These limits are deliberate and are not going away.

Put together, the practical limits for a business trying to reach revenue look like this:

• No list of installers, ever. You will not get names, emails, phone numbers or device IDs from Apple. Anything you know about a person, they told your app.
• One day to ask. The AdServices token lives for 24 hours. An app that only requests it after sign-up, days later, gets nothing. Request it at first launch and hold the answer on the device until the person creates an account.
• Some ad groups are dark. If an ad group uses age or gender settings, your app will be told attribution false even when the ad did its job. Those installs will look like organic ones.
• Search match hides the keyword. The campaign and ad group come back, the keyword does not.
• Installs that never open are invisible to you. Apple counts them; your app never ran.
• Apple never sees the sale. Nothing in the attribution described here carries a showroom sale back to Apple. The join between ad and sale exists only in your own records.

Apple's tracking rules are worth reading in the original rather than in summary. Its definition of tracking is about linking data from your app with data from other companies' apps, websites or offline properties for advertising, or sharing data with data brokers.

The approach in this post keeps everything inside your own business: a sign-up in your app, a sale in your system, matched in your records. It does not send anything back to Apple or to an ad network. How Apple's definition applies to your particular setup, especially if the sale is completed by a separate company such as an independent franchisee, is a question for whoever owns your app's privacy disclosures. Our post on data retention covers how long to keep the files the match produces.

Connecting app sign-ups to closed sales

Record the AdServices answer at first launch, attach it to the account when the person signs up with a phone number or email, and export sign-ups as leads with the campaign as their source. Then match those leads to closed sales on normalized phone and email. The sign-up is the bridge; Apple supplies only the campaign label.

1. At first launch, call AAAttribution.attributionToken(), post it to Apple's attribution endpoint (Apple suggests retrying a 404 every five seconds, up to three times) and store the result on the device: attribution true or false, campaign ID, ad group ID, keyword ID if present.
2. At sign-up, save that result on the account beside the phone number or email the person entered. Translate the IDs into names your team recognizes, such as "Apple Ads / Competitor names", using the campaign report in Apple Ads.
3. If attribution was false or missing, write "App, no ad attribution" rather than leaving the source blank or guessing. That label is honest, and a large share of it is a finding in itself.
4. Export sign-ups as a lead file each month: date, phone, email, source. Treat a booking or quote request with a new phone number the same way.
5. Export closed sales from wherever they really close: the dealer management system, the practice-management system, the CRM, the invoicing tool. Our post on CRM exports covers which fields to take.
6. Normalize, then match. Phone numbers typed into an app, a CRM and an invoice will be written three ways; phone normalization is the step that decides your match rate.

Two rules keep the result honest. First, credit each customer once, by a rule that applies to every channel. A buyer who called you from a Google search in May and installed the app from an Apple ad in June was found by Google; the app made the second visit easier. Our post on duplicate leads explains why one consistent rule matters more than which rule. Second, leave sales that match no lead where they are, in Direct / Unknown, rather than handing a share of them to Apple because the app is popular. We set out why in unattributed revenue.

CloseRev reads two CSV exports, your closed sales and your leads, and has no connection to Apple Ads or to your app. Export your app sign-ups as leads, with the phone or email each person entered and the Apple Ads campaign your app recorded in the source column, and it matches them to closed sales on normalized phone and email. Sales that match no lead go to Direct / Unknown.

A worked quarter: from installs to paying customers

Cost per paying customer from Apple Ads is the quarter's Apple Ads spend divided by the customers whose earliest recorded lead was an Apple Ads sign-up. In the illustrative quarter below it is about 25 times the cost per install, which is roughly what a front-door app should expect.

Here is the dealership group's quarter worked through. The figures are illustrative, built to show the shape of the calculation rather than taken from any account; every step is one a real business can repeat with its own exports.

The arithmetic, step by step:

• Cost per tap: $9,000 ÷ 6,000 = $1.50. Advanced accounts pay this.
• Cost per install: $9,000 ÷ 1,500 = $6.00. This is the number the dashboard leads with.
• Install to sign-up: 520 ÷ 1,500 = 34.7%. Two installs in three never produced a person you could name.
• Cost per sign-up: $9,000 ÷ 520 = $17.31.
• Sign-up to sale: 70 ÷ 520 = 13.5% closed; 9 of the 70 had an earlier lead from another channel, so Apple Ads is credited with 61, or 11.7% of sign-ups.
• Cost per paying customer: $9,000 ÷ 61 = $147.54, which is 24.6 times the cost per install.
• Revenue: 61 customers at an average of $1,200 (service tickets, a few trade-ins) = $73,200, or $8.13 per dollar spent.

The 120 installs your app never recorded as Apple Ads, because they were never opened or came back attribution false, are not zero, and neither are the 860 attributed launches that never signed up. Some of those people booked by phone, walked in, or signed up on the website instead. Their sales land wherever their recorded lead says, or in Direct / Unknown, which is the right place for them until someone records a contact detail. And the match itself is only as good as the share of sales that carry a phone or email; our post on match rates covers what a healthy one looks like.

Now split the same table by campaign. In most accounts the branded campaign, people searching your own name, shows the cheapest install and the highest close rate. The competitor-name campaign shows the most expensive install and a lower close rate but far more first-time customers. The cost per paying customer often ends up closer than the cost per install suggested, and the competitor campaign is often the only one producing customers you did not already have.

$6.00 an install became $147.54 a paying customer. Neither number is wrong; only the second can be compared with what a customer costs from search, social or the phone book.

What a branded install is really worth

Installs from people searching your own business's name are the cheapest Apple Ads buys and the hardest to credit, because many of those people would have found your free App Store listing anyway. The only way to measure what the ads add is to pause them and compare closed sales.

The test is simple. Pause the branded Apple Ads campaign for four to six weeks outside your busiest season, keep the competitor and generic campaigns running, and keep recording app sign-ups and their source exactly as before. Then compare sales from app sign-ups during the pause with the same weeks of the previous period. If app sales barely move, your free listing was doing the work, and the branded spend was buying back customers you already had. If they fall by more than you saved, the ads earn their keep, perhaps because a competitor was bidding on your name. Our post on incrementality tests covers how to read a result like that without fooling yourself.

The same caution applies to view-through installs. Apple credits an install to an ad the person saw but did not tap, if they downloaded within a day. On your own name, in search results where your organic listing sits directly beneath the ad, that is generous. Report tap-through and view-through installs separately, and when you calculate cost per paying customer, check how many of the matched customers came through each.

What Apple's numbers are still good for

Taps, installs and cost per tap are good for running the account: which keywords attract interest, which ads people tap, whether a price change moved volume. They should guide bids, never be presented as revenue, and be read beside the cost per paying customer that only your own records can produce.

Apple's dashboard is a good instrument for what it measures. A sudden fall in taps on a competitor keyword says something changed in that auction. A tap-to-install rate that collapses after an app update says the product page broke something. Those are worth acting on the same day, and no sales export will tell you them.

What the dashboard cannot do is decide the budget. That decision needs the bottom row of the table above, by campaign, for at least two quarters, and the result of a pause test on the branded campaign. Bring those to the next budget meeting and the conversation moves from "installs are up" to "competitor-name installs cost us $160 a customer and branded ones cost nothing we would not have had anyway". That is a conversation about customers. It is also one Apple's account team cannot have with you, because Apple never sees your sales, by design.

Apple tells you that a door opened and which campaign opened it. Your app learns who walked through only when they sign up, and your sales records say whether they bought. Join those two, and Apple Ads can be judged like every other channel.