A working Apple Ads keyword strategy is not a keyword list. It is a routing system: discovery surfaces raw demand, search-term evidence decides what earns exact control, negative keywords stop the wrong intent from spending, and bids are set from what a payer is worth after the install rather than from tap price. Teams that treat keywords as a static upload plateau quickly. Teams that treat search terms as a queue keep finding demand they did not predict.
This guide covers keyword and search-term operations only. Account and campaign architecture — how many campaigns, how ad groups are separated, how budgets and geographies are split — is covered in our Apple Ads campaign structure guide. Structure decides where a keyword can live; this page decides which keywords should exist, what they should cost, and when they should be removed.
What is an Apple Ads keyword strategy?
It is the repeatable process that converts unknown App Store search demand into a small set of controlled, priced, measurable keywords. It has five moving parts: a hypothesis set of terms you believe describe your product, a discovery mechanism that finds terms you did not write, a validation rule that decides which discovered search terms deserve their own bid, negative keywords that route or block intent, and a bid logic anchored to post-install economics rather than install volume.
A note on naming: Apple's advertising product is now branded Apple Ads, while a large share of buyers still search for "Apple Search Ads." Both refer to the same App Store search-results inventory, and Apple's own help and best-practice documentation now sits under the Apple Ads brand. Use whichever your team says internally; the operating model does not change.
How do Apple Ads match types actually behave?
Apple offers broad match, exact match, and Search Match, plus negative keywords as a separate control. Per Apple's documentation on keyword match types, broad match allows your ad to serve on related queries including misspellings, singular and plural forms, and synonyms, while exact match targets a specific term — and Apple notes that exact match may still include close variants such as common misspellings and plurals. Search Match is the automated option that matches your ad to relevant searches using App Store metadata rather than a keyword you supplied.
That last detail is the one teams most often get wrong. "Exact" is not literal. Two keywords that look distinct on a spreadsheet can compete for overlapping queries, which is why search-term evidence, not the keyword label, should drive your reporting decisions.
Which match type does which job?
Control Primary job Evidence it produces Main risk Where it belongs --- --- --- --- --- Search Match Discovery without a keyword list; leans on your product metadata New search terms you never hypothesised Spend on loosely related intent A dedicated discovery ad group with a contained budget Broad match Discovery around a term you believe in — variants, synonyms, misspellings Query variations on a known theme Overlap with your exact terms; muddied read Discovery ad groups, never mixed with exact Exact match Control and pricing of proven demand Clean per-term performance for bidding Ceiling on volume; still admits close variants Your controlled scale ad groups Negative keywords Routing and exclusion Cleaner spend; enforced separation Over-blocking real demand if applied too broadly Applied at campaign or ad group level, deliberately
Apple documents negative keywords as broad or exact and applicable at campaign or ad group level, and warns that overly restrictive negatives can limit your ads from being shown (using negative keywords). Treat every negative as a decision with a cost.
The keyword lifecycle: hypothesis to retirement
A keyword should move through five stages, and it should be possible to say out loud which stage any term is in.
1. Hypothesis
Write the terms a buyer would type when they have the problem your app solves — not the terms your product team uses. Apple's keyword best practices group thinking into categories such as your brand, your category, competitor terms, and generic problem-space terms. Build the list by category, not alphabetically, because each category will behave differently on cost and conversion and you will want to price them separately.
Keep this set deliberately small. A hypothesis list of 40 well-reasoned terms produces readable evidence faster than 400 speculative ones spreading budget too thin to learn from.
2. Discovery
Discovery is where the system earns its value, and it has two engines. Search Match finds queries derived from your App Store metadata; broad match finds variants around terms you already believe in. Run both, but run them in ad groups that exist only for discovery, with their own budget and their own bid level. If discovery and exact control share an ad group, you cannot tell which mechanism produced a result, and you will keep re-buying terms you already control.
Discovery also has a metadata dependency: because Search Match relies on your product page metadata, weak or vague App Store copy narrows what Apple can match you to. That is a product-marketing fix, not a bidding fix.
3. Validation
A discovered search term is a candidate, not a keyword. Validate it against three questions before promoting it:
Is the intent right? Read the query as a human. A term can convert on taps and still describe a different product.
Is there enough evidence? A single install is not a signal. Set a minimum evidence bar — for example, a defined number of taps or a defined spend threshold — before you act. Apple's tips for evaluating performance emphasise giving campaigns enough time and data before judging them.
Does it survive the post-install check? If the term produces installs but no downstream action, it belongs in your negative list, not your scale ad group.
4. Exact control
Promotion means one thing: the validated term gets its own exact keyword in a controlled ad group, with a bid set from its own economics, and it gets added as a negative in the discovery ad group so discovery stops paying to re-find it. Apple's guidance on adding and managing keywords covers the mechanics of managing keywords and bids at the ad group level; the discipline is in the routing rule, not the interface.
5. Scale or retire
A controlled keyword gets more budget only while it holds its cost-per-payer target. It gets retired — paused, bid down, or negated — when it is structurally unprofitable, not when it has one bad week. Write the retirement rule before you need it, because retirement decisions made under pressure are usually made on tap price alone.
Search-term promotion and exclusion rules
The value of this system is that promotion and exclusion are rules, not opinions. Write yours down in this shape and keep them in the same document as your keyword map.
Promote to exact when the search term has cleared your evidence threshold, the intent matches your product, and it has produced at least one meaningful post-install action at a cost you can defend. Add it as a negative in discovery on the same day you promote it.
Add as negative when the term describes a different product or a free-only intent your app cannot serve, when it consistently produces taps without installs, or when it produces installs without any downstream action across a sufficient sample. Prefer the narrowest negative that solves the problem: an exact negative for one bad query, a broad negative only when an entire intent family is wrong.
Leave in discovery when the term is plausibly right but under-evidenced. Most terms live here. Resist the urge to promote early — a keyword promoted on thin evidence takes budget out of discovery and gives you a bid you cannot justify.
How should you set keyword bids?
From payer economics, backwards. Apple's considerations for keyword bids frames your maximum cost-per-tap as what you are willing to pay for a tap, and notes that your bid influences whether your ad enters the auction at all. That framing is only useful if you know what a tap can be worth to you.
A labelled hypothetical
The numbers below are illustrative arithmetic to show the chain, not benchmarks, predictions, or results from any Sharply Labs engagement. Substitute your own.
Suppose your finance-approved allowable cost per paying user is $60. Suppose your first-party data shows that 4% of installs from this keyword family become payers within your chosen window, and that your tap-to-install rate on this keyword is 50%.
Allowable cost per install = $60 × 0.04 = $2.40
Allowable cost per tap = $2.40 × 0.50 = $1.20
So $1.20 is your ceiling max CPT for that keyword family — not a target, a ceiling. Two implications follow. First, a keyword family with a 2% payer rate at the same tap-to-install rate can only carry a $0.60 ceiling, which is why one account-wide bid is always wrong. Second, improving your product page conversion raises the tap-to-install rate and therefore raises what you can afford to bid, which is the operational link to store-page conversion work.
Each input in that chain has an error bar. Your payer rate is a cohort estimate that moves as the cohort matures; your tap-to-install rate moves with your product page and with the query mix behind the keyword. Recompute rather than inherit.
Reading the evidence honestly
Apple's reporting surfaces campaign, ad group, keyword, and search-term views, and its insights and visualisation documentation covers how to explore that data. Two boundaries matter for how far you can push the read.
First, a download reported in Apple Ads is a platform-attributed event on Apple's terms. If you also run a mobile measurement partner, Apple documents both its own ad performance measurement and integration with mobile measurement providers. Platform-reported downloads and MMP first opens are different definitions with different windows; expect a gap and reconcile it deliberately rather than declaring one system broken. Our attribution decision system covers that reconciliation in depth.
Second, search-term reporting is not a complete transcript of demand. Privacy and aggregation constraints mean some queries will not appear as individually actionable rows, so absence of a search term is weak evidence that the demand does not exist. Build your negatives from what you can see and keep discovery running for what you cannot.
Third, and most practically: dashboards default to what is easy to measure. Apple's dashboards and settings overview is a good orientation to the account surface, but the decision-grade view is the one you build — keyword, spend, taps, installs, and your own downstream event, joined to first-party data.
Diagnostic matrix
Symptom Likely cause First action --- --- --- High taps, low installs Query intent mismatch, or product page does not match the promise of the query Read the search terms behind the keyword; fix intent with negatives before touching bids Keyword gets almost no impressions Bid below the level that clears the auction, or budget exhausted early Check bid against your computed CPT ceiling; confirm the ad group is not budget-starved Discovery spend keeps rising, exact spend flat Promoted terms were never negated in discovery Audit the negative list against every promoted exact keyword Installs healthy, payers absent Optimising to install volume on a family with weak downstream value Recompute the payer rate per keyword family; lower the ceiling or retire Two keywords cannibalising each other Close-variant overlap between "distinct" exact terms Consolidate to the better performer and negate the loser in that ad group Apple Ads and MMP disagree Different attribution definitions and windows Reconcile definitions first; do not restructure the account on the gap alone Performance swings weekly Sample too small for the decision cadence Lengthen the observation window; raise the evidence threshold for action
A bounded 30-day workflow
This is a sequence for one app and one market, sized so that each step produces evidence for the next.
Days 1–3. Build the categorised hypothesis list. Compute your CPT ceiling per keyword family from allowable payer cost, payer rate, and tap-to-install rate. Confirm your downstream event is reliably logged in first-party data.
Days 4–7. Launch discovery ad groups — Search Match in one, broad match on your strongest hypothesis terms in another — separated from any exact ad group, each with its own bid and budget. Apple's campaign structure best practices is the reference for keeping these surfaces cleanly separated.
Days 8–14. Do nothing but read. Review search terms twice in the period. Add negatives only for clearly wrong intent. Resist promoting anything yet; you are building the sample that makes promotion defensible.
Days 15–21. First promotion cycle. Promote terms that clear your evidence bar into exact ad groups at their computed ceiling, and negate each one in discovery the same day. Log every promotion with the evidence that justified it.
Days 22–30. Read the cohort, not the dashboard. Join promoted keywords to your downstream event, recompute the payer rate per family, adjust ceilings, and retire what cannot carry its cost. Write down what you learned about demand you had not predicted — that list is the input to your next hypothesis round.
Thirty days will not settle payback questions with long monetisation windows. It will tell you whether your routing system works, which is a different and earlier question.
Common buyer questions
Should I start with Search Match or a keyword list? Both, in separate ad groups. Search Match finds demand your list will miss; your list gives you priced control over demand you already understand. Running only one of them is what produces plateaus.
How many keywords should I run? Fewer than you want. The constraint is evidence per term: enough taps per keyword to make a bid decision within a reasonable window. If your budget cannot deliver that on 200 terms, you do not have 200 terms.
Is exact match really exact? No. Apple states that exact match may include close variants such as misspellings and plurals, so validate with search-term data rather than assuming the label.
Do brand keywords count as strategy? They are a defence decision, not a growth one. Price them separately and judge them on their own logic; blending brand and generic terms in one report inflates every average you look at.
Should I bid on competitor terms? Only if the downstream numbers hold. Competitor intent often converts to install and not to payer, so it is exactly the case where a tap-price read will mislead you.
How does this differ from Google App campaigns? Google's app campaigns move the decision to campaign goals and automated inventory rather than keyword-level control. Our Apple Ads vs. Google App campaigns comparison covers that allocation choice.
When this system does not fit
Be honest about the conditions where keyword-level operation is the wrong investment.
Budget too small to produce evidence. If a term cannot accumulate enough taps to justify a bid change within a month, you are managing noise. Run a narrow Search Match test and spend your effort on the product page instead.
No reliable downstream event. Without a logged, trustworthy post-install action, every promotion rule collapses to install volume — and install volume is the thing that flatters bad keywords.
The App Store is not where your demand starts. Some products are discovered socially and searched by brand name afterwards. In that case search ads capture demand created elsewhere, and your keyword system should stay small while the demand-creation channel gets the work.
Product-page conversion is the actual constraint. If your tap-to-install rate is the binding limit, better keywords buy you traffic you cannot convert.
Automated matching outperforms your control and you cannot explain why. That is a real outcome. If Search Match consistently beats your curated exact set on cost per payer, the responsible answer is to shift budget toward automation and keep a smaller controlled set for the terms you must own.
What good looks like
You can name the stage of every keyword in the account. Every exact keyword exists because a search term earned it, and every promoted term is negated in discovery. Bids trace to a written CPT ceiling built from payer economics. Negatives are the narrowest that solve the problem, and each one is dated and justified. And you can state plainly which of your numbers are platform-attributed, which are MMP-attributed, and which are first-party — without pretending they are the same number.
Talk to us about your keyword system
This conversation is for app teams already running Apple Ads or preparing to launch. We look at your keyword map and category logic, how search terms are routed into exact control, your negative structure, the bid logic behind your current ceilings, and how any of it connects to MMP and first-party payer economics.
You get a prioritised testing plan and a written list of the evidence gaps that currently block confident decisions. We do not promise lower CPT, CPI, or CPA, higher ROAS, better rankings, or a particular scale outcome — those depend on your product, your market, and your monetisation, not on a review.
If you want the wider context, see our mobile app growth work and growth services.