How to Do Keyword Research for Apple Search Ads Without Guessing

Most keyword lists I see from indie devs are built the same way: open a spreadsheet, brainstorm for ten minutes, paste in whatever the suggestions panel offers, set bids to something that "feels right," and hit launch. Then a month later the spend looks weird and nobody can explain which keywords actually moved the needle.

You can do a lot better than guessing without buying expensive tools. The trick is to treat keyword research as a loop with three phases — generate, validate, learn — and to let Apple's own data do most of the heavy lifting once you're live.

Start by writing down what your app actually is

Before touching the ads UI, get specific about what you're selling. Open a doc and answer:

What does the app do in one sentence, in the user's words (not yours)?
What problem are they trying to solve when they search for it?
What are the 3–5 obvious category words? (e.g. "budget tracker," "sleep timer," "running log")
What do competitors call themselves on their App Store screenshots and subtitles?
What do users call the problem in reviews — yours and competitors'?

That last one is gold. Reviews are full of natural-language phrasing you'd never invent at a desk: "app to split rent with roommates," "timer that doesn't lock my screen," "workout app without a subscription." Those are real searches.

The output of this step is a seed list of maybe 30–80 phrases grouped into themes. Don't worry about match types yet.

Mine the App Store itself

The App Store search box is your best free research tool. For each seed term:

Type it into App Store search on a real device.
Note the autocomplete suggestions. These are surfaced because real people type them.
Look at the top 5–10 results. Read their titles, subtitles, and the first screenshot's headline. Those phrases tell you which terms competitors think are worth ranking for.
Tap a couple of competitors and see what "You Might Also Like" surfaces. New theme ideas often appear here.

Do this for every seed. You'll end up with a second layer of phrases — longer, more specific, and often less competitive. A budgeting app might start with "budget" and end up with "budget app for couples," "envelope budgeting," "zero based budget," each pointing at a different intent.

While you're in the Search Ads UI, check the keyword suggestions and the popularity indicator for each candidate. Popularity isn't a search volume number — it's a relative scale — but it does tell you what's at least worth a small bid versus what's a ghost town.

Group keywords by intent, not by topic

This is the step most people skip, and it's the one that saves the most money. Sort your list into rough intent buckets:

Brand — your app name and obvious misspellings.
Competitor — other apps' names.
Category / generic — "podcast app," "to do list."
Feature / problem — "offline podcast downloader," "to do list with reminders."
Long-tail / use case — "podcast app for learning languages."

Each bucket behaves differently. Brand traffic converts at insane rates but volume is capped. Competitor traffic is expensive and conversion is mediocre. Generic is high volume but bids spiral. Feature and long-tail are usually where indies make money — lower CPT, higher intent, better conversion to paying users.

Give each bucket its own ad group, ideally its own campaign. That way you can set different bids and budgets per intent type and read the data cleanly later. Mixing brand and generic in one ad group will make every metric a lie.

Use Search Match as a discovery tool, not a strategy

Apple's Search Match (and broad match) will automatically serve your ad against terms it thinks are relevant. Treat it like an exploration engine:

Run a dedicated ad group with only Search Match enabled and a conservative max CPT.
Add every keyword you're already bidding on as a negative in that ad group, so it can only find new terms.
Check the search terms report regularly. Promote winners to exact match in a proper ad group; add losers as negatives.

The same pattern works with a broad match ad group seeded with your category words. Broad is noisier than exact but cheaper to discover with than guessing what to add manually.

Let the search terms report do your research after launch

Once you've been live for a couple of weeks, the search terms report becomes your actual research tool. For each term that has spent more than a trivial amount, you're looking at:

Did it get taps? (If not, TTR is bad — keyword may be off-intent, or competitors look more relevant.)
Did taps convert to installs at a reasonable rate? (If TTR is fine but conversion is bad, that's usually a product page mismatch, not a keyword problem.)
Did installs convert to revenue? (This is where you need attribution wired up — Apple gives you the install side via AdServices; tools like RevenueCat let you tie that install to actual subscriptions or purchases.)

A keyword isn't "good" because it has a low CPT. It's good if the revenue per tap exceeds the cost per tap over a window you care about (often 30–60 days for subscription apps, because trials and renewals take time).

For every meaningful term, you have three moves:

Promote: add as exact match in its intent-matched ad group, with a bid based on what you've seen it clear at.
Negate: add as a negative if it's off-intent or burning money.
Hold: leave it alone if there isn't enough data yet — usually fewer than ~20 taps for conversion signal, and more for revenue signal.

Resist the urge to act on three taps. Small numbers lie.

Bidding without flying blind

For a brand new keyword you have no data on, a reasonable starting point is somewhere near the suggested bid range Apple shows you, on the low end. You're not trying to win — you're trying to gather data. After a few hundred impressions you'll know whether you need to bid up to get taps, or whether you're already getting them cheap.

Once a keyword has converted installs and revenue:

Estimate revenue per tap = (revenue attributed ÷ taps) over your window.
Your max CPT should sit below that, with margin for the long tail of refunds, churn, and the fact that not every tap-window will look the same.

Again — these numbers come from your data, not from a blog post telling you "the right CPT for a fitness app is $1.42." There is no such number.

Build the loop, not the list

The useful mental model: your keyword list is never finished. Each week you're adding a few terms from the search terms report, negating a few, nudging bids on the ones with enough signal, and leaving the rest alone. That's it. The apps that do well on Apple Search Ads aren't the ones with secret keywords — they're the ones who run this loop consistently and don't override it with feelings.

If staring at the search terms report every morning sounds tedious, that's roughly the gap AdsBuddy tries to fill — it reads your ASA and revenue data and hands you a short list of suggested promotes, negatives, and bid changes each day, with the reasoning attached, so you approve or skip each one yourself. The decisions still belong to you; the grunt work of spotting them doesn't have to.

Takeaway

Good keyword research for Apple Search Ads isn't a one-time brainstorm. It's: write down the real language users use, mine the App Store for variations, group by intent, use Search Match to discover, and then let your own search terms report and revenue data tell you what to keep, kill, and bid up. Do that loop weekly and you'll stop guessing within a month.