Should you bid on 'free' keywords in Apple Search Ads?

Every indie running Apple Search Ads eventually stares at the keyword "free" — or some variant like "free games", "free photo editor", "free vpn" — and wonders: is this a goldmine or a trap? The volume is huge. The intent looks high. And yet most people who chase it end up burning cash. This post is a practical walkthrough of when bidding on "free" keywords actually makes sense, how to structure the test, and how to kill it cleanly if it doesn't work.

Why "free" looks tempting

Searches that include the word "free" are common on the App Store because a huge chunk of users default to expecting apps to be free. So you see:

High search popularity on terms like free games, free music, free workout, free vpn, free pdf.
A clear-looking signal: the user is in download mode, not browse mode.
Often, surprisingly affordable max CPT bids compared with brand or category head terms.

If you only look at impressions and taps, "free" keywords often print great numbers. TTR can be solid because your icon and name show up against a query with broad intent. That's exactly where the trap starts.

The hidden cost: who actually taps "free"

The word "free" filters for a specific kind of user: someone whose decision criterion is price, not your app. That has several knock-on effects you'll see in your data:

Lower install-to-paid conversion. Users searching "free" are by definition resistant to paying. If your model is subscription, IAP, or paid unlock, the conversion to revenue is going to be worse than from a category keyword.
Lower retention. Price-shoppers churn faster. You won't see this in Apple Search Ads at all — you'll only see it downstream in your revenue tool.
Higher refund and trial-cancel rates for subscription apps with intro offers.
Misaligned expectations. If your free tier is thin, you'll get one-star reviews about paywalls, which hurts your overall store conversion for every keyword.

Apple Search Ads will happily report a fine CPI on these keywords. The problem only shows up when you divide revenue (from RevenueCat or your own receipts) by spend. ROAS is the only number that matters here, and "free" keywords are where the gap between CPI and ROAS is usually widest.

When "free" keywords can actually work

There are real cases where bidding on "free" pays off. Be honest about whether you're in one of them:

Your app is genuinely free, ad-supported, and you monetize on engagement. Casual games with rewarded video, utilities with banner ads, content apps with display. Here, a price-sensitive user is still a monetizable user, as long as they open the app a few times.
You have a strong free tier that converts later. If 2% of installs eventually upgrade and your LTV math still works at "free"-keyword CPI, it's fine. But you need real cohort data, not a guess.
You're testing a custom product page tuned to free-seekers. A CPP that leads with "100% free, no signup" can dramatically lift conversion from these queries compared with your default page.
You're a defensive play against competitors. If a competitor is showing up on "free [your category]" and stealing brand-adjacent volume, sometimes you bid just to occupy the slot.

If none of those describe you — especially if you're a paid-up-front app or a subscription app with a hard paywall — "free" is probably not your keyword.

How to structure the test

If you want to find out for real, run it as a contained experiment instead of dropping "free" terms into your existing ad group.

Isolate it. Create a dedicated ad group (or campaign) just for "free" variants. Don't let them share an ad group with your good category keywords — you'll never be able to read the data cleanly.
Use exact match first. Start with free [your category], free [core noun], and a few obvious variants as exact match. Skip broad until you know how exact performs. Broad on "free" is a fast way to match into queries you don't want.
Set a bid below your normal category bid. These users are worth less, so they should cost less. If you can't win impressions at a lower bid, that's information — the auction is already pricing in their behavior, or it isn't, and you'll learn which.
Cap the daily budget low. You want enough taps to judge conversion to revenue, not enough to bleed.
Point it at a custom product page if you can. Free-seekers respond to different screenshots than feature-seekers. At minimum, lead with what they get without paying.
Tag the campaign clearly so your attribution tool (RevenueCat or whatever you use) can isolate cohort revenue and retention.

What to measure, and for how long

Apple's attribution resolves within about a day, but revenue takes longer to materialize, especially for subscriptions with trials. Give it real time:

For ad-supported apps: 7–14 days of cohort ad revenue per install is usually enough to judge.
For IAP apps: 14–30 days, depending on how front-loaded your purchases are.
For subscriptions with a 7-day trial: at least one full trial cycle plus a week of renewals before you call it.

Compare three things between your "free" ad group and your normal category ad group:

Conversion rate (tap → install). Usually higher on "free" — fine, expected.
CPI / CPA. Often lower — also expected.
ROAS over a fixed window. This is the verdict. If it's meaningfully below your category keywords, the cheaper installs are not actually cheaper customers.

Clean exit rules

Decide before you start what kills the test. For example:

ROAS at day 14 below X% of your category benchmark → pause.
Trial-to-paid conversion below half your normal rate → pause.
Refund rate noticeably higher than baseline → pause.

Writing the rule down beforehand stops the "but the CPI looks so good" emotional pull when the revenue data comes in soft.

A quick mental model

Think of "free" as a discount channel, not a discovery channel. It's pulling in users who would not have paid your CPI on a category keyword — sometimes because they're genuinely a good fit you couldn't reach otherwise, more often because they self-selected as low-value. Your job is to figure out which of those two it is for your app, using your downstream revenue numbers. There is no universal answer.

Takeaway

Don't bid on "free" because the impressions look juicy. Bid on it only if (a) your monetization tolerates price-sensitive users, and (b) you can prove it with ROAS over a sensible window. Run it in an isolated ad group, on exact match, at a lower bid, ideally against a custom product page, with a pre-written kill rule.

This kind of contained, hypothesis-driven testing is exactly the workflow AdsBuddy is built for — it reads your ASA spend alongside your actual revenue and surfaces a short, prioritized list of changes each day (including "this ad group's ROAS has cratered, consider pausing"), which you approve and apply yourself. The decisions stay yours; the bookkeeping gets easier.