Reading Your Apple Search Ads Search Term Report: How to Turn Raw Queries Into Keyword Decisions
Most indie developers set up Search Results keywords, watch the spend tick up, and then make decisions based on the keyword list they typed in themselves. That list is a guess. The part of your account that tells you what is really happening is the search term report, the list of actual queries people typed (or that Apple matched to your ads) before they saw and tapped your ad. If you read it carefully, it becomes the most useful input for deciding what to bid on next.
This post walks through how to read that report, how to sort what you find, and what to change once you have sorted it. Nothing here requires special tools. You need a few weeks of data, a spreadsheet, and the discipline to act on what the numbers say rather than what you hoped they would say.
What the report is actually telling you
Every row represents a query that triggered an impression for one of your ads. The useful columns are the same ones you already use at the keyword level: impressions, taps, tap-through rate (taps divided by impressions), installs, conversion rate (installs divided by taps), and spend. The difference is that the query is the thing you are looking at, not the keyword you bid on.
That distinction matters because a keyword is a bid, and a query is what a real person wanted. Two people can type different queries that both match your exact keyword, and they can behave very differently. Some queries will be near-perfect fits for your app. Others will be loosely related, or related to a different problem entirely. Your bid is shared across all of them, so you need to see them separately to act on them separately.
Also keep in mind what the report cannot do. Apple does not give you per-keyword revenue. Installs come from Apple's attribution, and revenue has to be joined from your own purchase data or a tool that maps the attribution token to purchases. So when you say a query is "profitable," you are really saying its installs are producing revenue at an acceptable rate, and that claim depends on how well your revenue data is joined. Start with installs and conversion rate. Bring in revenue once you trust the join.
Step one: filter out the noise before you judge
Before you make any decision, remove queries that are too thin to read. A query with two impressions and no taps tells you almost nothing. Set a minimum impression threshold that fits your volume, and do not act on rows below it. The exact number depends on how much you spend, so pick one that gives you a handful of taps per row before you draw conclusions.
Then sort by spend, not by impressions. Impressions tell you what was seen. Spend tells you where your money went. The top twenty rows by spend usually account for most of what you should be thinking about this week.
A common mistake is to read a single bad week as a verdict. Look at at least two to three weeks of data for anything you plan to change, because auction conditions and seasonality can make one period look very different from the next.
Step two: sort every meaningful query into one of three buckets
For each query with enough data, put it in one of three buckets.
Promote
A query belongs here when it has a healthy tap-through rate and an install conversion rate that is competitive with your other keywords. It is doing its job. The action is usually to make sure it has its own keyword entry, with a bid you are comfortable with, so you can control it directly rather than leaving it to whatever broad or Search Match path brought it in.
Promotion is also where you catch queries that you did not expect but that perform well. These are some of the most valuable rows in the report, because they reveal how real users describe your category.
Isolate
A query belongs here when it converts reasonably but the surrounding context is unclear. Perhaps it converts well for a small sample but also brings in taps from a different intent cluster. Isolating means giving it its own ad group or its own bid so you can watch it without contaminating the bids on your core terms.
Isolation is also the right answer when a query matches a keyword you already bid on in another way. The two entries compete with each other in the auction, and you cannot tell which one is actually winning the click. Moving one of them into a separate structure ends that confusion.
Ignore or negate
A query belongs here when it gets taps but installs are consistently poor, or when it is clearly about a different problem than your app solves. Some of these you can simply stop bidding on by lowering or removing the keyword. Others should be added as negative keywords so they stop triggering your ads. Be careful here: a negative keyword blocks a query, and you should only use one when you are confident the query does not fit your app. Negating a query that is merely weak in one week can starve a term that would have improved with a better product page or a bid adjustment.
Step three: decide what kind of problem each weak row is
Not every underperforming query is a relevance problem. Before you negate anything, ask what is going wrong.
If taps are low relative to impressions, the issue is at the ad impression level. The query is seeing your ad but not finding it compelling enough to tap. That points to your ad creative, or to a placement mismatch, not necessarily to the query itself.
If taps are healthy but installs are low, the problem sits between the tap and the install. Check whether the product page is answering the question the query implied. A user who searched for a specific task and landed on a generic page will often bounce.
If installs are healthy but revenue is weak, the issue is downstream. That is a pricing, paywall, or audience-fit question, and changing the keyword will not fix it.
This triage matters because it stops you from using the wrong lever. A query can be a good query with a weak product page, and negating it would be a mistake.
Step four: turn the findings into a short change list
After sorting, write down the changes you intend to make and limit the list. A good week might produce three to five changes: promote a couple of high-performing queries into their own keywords, isolate one that is muddying your data, negate one or two clearly irrelevant terms, and note one product page issue you want to check.
Do not make all of these changes at once if you can avoid it. Changing many bids and structures simultaneously makes it hard to learn which change moved the numbers. Make a few changes, let them run for a meaningful window, and then review.
Keep a simple log with the date, the query, the action, and the reason. In a month you will have a record that tells you what you learned, and you will stop repeating experiments you already ran.
A worked illustration
Suppose a habit tracker developer sees a query related to "daily routine planner" with decent taps and a conversion rate close to their core keywords. The query is not an exact keyword they bid on, so it came in through a broader path. They promote it to its own exact keyword with a modest bid, and keep an eye on it for two weeks. Separately, they see a query about a different type of planner that gets taps but almost no installs. They add it as a negative keyword, since the app does not serve that use case. Neither change required a new campaign or a bid overhaul, and both came directly from reading the report instead of guessing.
The numbers in that example are invented for illustration. The point is the sequence: filter, bucket, diagnose, and change a small number of things.
Takeaway
The search term report is the closest thing Apple Search Ads gives you to hearing what users actually want. Read it regularly, ignore thin data, sort queries into promote, isolate, or ignore, and diagnose whether a weak row is a relevance problem, a product page problem, or a monetization problem before you touch anything. Keep changes small and logged so you can learn from them.
If you find the weekly triage tedious, AdsBuddy is built around this kind of work: it reads your Apple Search Ads and revenue data, ranks the changes worth making each day, and explains why. You still approve and apply every change yourself.