Apple Search Ads Campaign Structure: My Build Method Is Now an Open-Source AI Skill

Three weeks ago I open-sourced my keyword categorization framework as an AI agent skill and called it Act 1 of a series. This is Act 2: the method that takes the categorized pool and builds the Apple Search Ads account from it. It’s live now in the ASO/ASA Skill Stack repo, MIT licensed, same install as before.

Act 1 ended with a promise: once every keyword has a group and a segment, the campaign structure follows. This post is about what “follows” actually means, because the distance between a categorized spreadsheet and a launch-ready account is where most structures go wrong.

Match type shouldn’t be your account’s primary taxonomy

Open a typical Apple Search Ads account and you’ll find campaigns named things like “Generic Broad”, “Generic Exact”, “Competitor”, maybe “Brand”. The organizing principle is match type, sometimes seasoned with a vague intent label.

Match type matters. It’s just the wrong thing to build the account around. Match type determines how a keyword serves; segment determines what that spend means. When “Generic Exact” drifts over target, which product story is failing? Which keywords deserve the budget that the failing ones are eating? You can’t tell, because the campaign mixes every theme the app has into one bucket. Match type is a delivery mechanic, and when it’s also the account’s business taxonomy, optimization becomes keyword whack-a-mole instead of strategy.

My structures are organized by segment, the third dimension from Act 1. One campaign per proven keyword segment. When the plant-identification campaign drifts and the care-reminders campaign carries, that’s not a bid problem, that’s information about the product and the market. The structure itself becomes a reporting layer.

But segment campaigns are only half of the method. The other half is deciding how many boxes a market actually deserves.

The only reason to create another campaign

One rule sits under everything the skill builds: a campaign exists to give something independent spend control. Everything else only needs an ad group. If you want to cap it, fence it, or fund it separately, it’s a campaign. If you only want to read it separately, it’s an ad group. If neither, don’t create another box. That one sentence deletes about a third of the campaigns in most accounts I audit.

Everything else in the structure is that rule playing out at different market sizes. The most expensive structural habit I see is shape-copying: the flagship market has twelve campaigns, so every market gets twelve campaigns. I’ve watched this produce accounts where half the campaigns spend pocket change, which means every one of them is unreadable at review time and none of them will ever collect enough data to justify a decision.

So the skill carries two validated shapes, both derived from the spend-control rule.

The full structure (9 to 12 campaigns) is for markets that carry the account: single-keyword campaigns for proven NorthStars, a campaign per segment, a free-intent fence, a low-volume farm, competitor, discovery. Each campaign exists because something in it needs independent budget control.

The small-market template is for everything else, and it works by folding. At most one single-keyword campaign, and only for a head term with proven economics. NorthStar runners-up become named ad groups inside the main generic campaign instead of getting their own campaigns. Thin segments fold into the workhorse campaign as ad groups. Speculative angles become probe ad groups at one flat bid, so the question “is this angle real?” costs one readable line instead of a campaign’s worth of overhead. In practice mine often lands around six campaigns, but six isn’t the template. Folding is the template.

And the rule that governs both sizes: campaign count follows each market’s own pool and economics, never another market’s shape. Model the logic, not the layout.

Fences and headroom

Every budget cap in the structure is one of two kinds, and mixing them up is how “budget management” becomes theater.

A binding cap is a fence: spend you have decided to limit. Free-intent keywords get fenced because free searchers convert to paid at a fraction of the rate. Competitor campaigns get fenced because conquest is a bet, not a baseline. Discovery gets fenced because expansion should earn its budget. Fences are set at the number you mean, and the redistribution is the strategy: the spend you fence off is what funds the keywords that deserve more.

A headroom cap exists so a campaign never chokes. It sits comfortably above expected spend and it isn’t a decision, it’s plumbing.

One mechanical detail that will bite you exactly once: Apple rejects any bid above the campaign’s daily cap. Check it when you draft budgets, not when the upload fails.

The rules that came from getting it wrong

Like Act 1, the skill leads with hard rules, and every one of them is a scar. Three stories that earn their place:

56 keywords disappeared. Apple’s older bulk keyword endpoint returned success while silently dropping any row whose bid exceeded the campaign cap. On one build, 56 of 480 keywords simply never got created, and nothing in the response said so. The current API fails loudly, but the discipline stays: after any build, re-fetch what exists and diff it against the plan, keyword by keyword, never by row counts. A matching count can hide substitutions. A diff can’t.

The zombie campaign followed us through five markets. Pull every campaign and its status from the API before any cutover, not from memory or from the console view you think you know. During a series of market restructures, a forgotten enabled-but-dormant campaign turned up in five consecutive markets. Five. Legacy campaigns you don’t know about keep serving next to your new structure and quietly poison the clean-data window you’re about to start.

Exact isn’t as exact as you think. Apple’s exact match folds singular and plural into one keyword: bidding “invoice” also serves on “invoices” searches. Usually harmless, until the two forms have different economics and you target them in separate places. Then both serve on both queries and every read you take is blended. So whenever the structure splits a singular/plural pair, each side gets the other as an exact negative at build time, and then you confirm the isolation actually holds in the search-terms report. Apple treats plurals as close variants even under exact targeting, so never assume two exact keywords produce independent traffic until the query data says so.

There are eleven of these rules in the skill file, including why everything gets created paused and why Search Match ad groups start paused. That last one is my operating prior, not platform physics: across the accounts I’ve operated, broad-match keyword discovery has given me cleaner expansion with more control, so Search Match waits as the fallback for when a market needs reach at any cost.

One more rule deserves its own paragraph, because it isn’t really an ASA rule at all: live keywords carry their current bids into a restructure verbatim. A restructure is already an intervention. If I change bids at the same time, I lose the ability to attribute what happens next, and the first two weeks of the new structure tell me nothing. So first the architecture changes, alone. Then, once the new structure has produced a clean window, the economics start changing. That second part is Act 3’s job.

From build to Day 1

The skill doesn’t stop at a structure diagram. It seeds initial bids (carryovers verbatim; for never-bid keywords, a formula: target cost per action times the segment’s event-per-tap rate), builds the negative sets before launch, and drafts the budget table with expected spend grounded in actual recent dailies rather than guesses. One thing the formula is not: a prediction of what the auction will clear at. It’s a starting bid ceiling derived from the event economics, and the auction, data thinness, and organic overlap all get their say afterward. That’s what the rebalances are for.

Then it runs the launch sequence: build everything paused, verify by diff, human review in the console, enable new and pause legacy the same day, re-census the account, and start the clean-data clock. At day 3, a serving check: every campaign showing impressions above zero, because created-and-active is not the same as serving. A bid below the auction floor sits at zero impressions forever and looks perfectly healthy in every status column.

The sequence ends with the first rebalance scheduled at two weeks, with its agenda written in advance: fence phase-downs, probe reads, hold-slot promotions. Everything after that is Act 3.

One more thing the skill insists on, and it’s the part I’d defend hardest: the structure is presented as a decision list, not a fait accompli. Which fences at which caps, which competitors got gated out, which NorthStars earned their own campaigns and which go to hold slots. Each decision with its evidence and with what would reverse it. Structure decisions are strategy decisions wearing operational clothes, and whoever owns the account should get to veto them while they’re still cheap to change.

Running it

Install next to Act 1:

git clone https://github.com/kevserimirogullari-hash/aso-asa-skill-stack.git
cp -r aso-asa-skill-stack/skills/asa-campaign-creation ~/.claude/skills/

Then hand your agent the categorized pool from Act 1 and ask for the ASA structure. The first thing the skill does is interview you, because the answers can’t be read from a keyword pool: restructure or cold start, which market and what it spends, your target cost per action, your daily budget, and the one most people skip: what post-install event you optimize toward. Trial start, registration, purchase, tutorial completed. Every bid and every verdict in the structure prices against that event. And if you answer “installs”, the skill pushes back the way I would: possible, but installs are a proxy, and two keywords with identical cost per install routinely have completely different costs per trial. If you don’t have an MMP giving you that event per keyword, connecting one matters more than any structure sophistication.

Same as before, this isn’t Claude-only: the skill is plain markdown, so Codex or any agent that reads instruction files runs it the same way, and it reads as a complete methodology doc if you’d rather run it by hand.

The repo’s worked example continues the PlantPal story from Act 1: the same 40-keyword pool taken through the full US build (including the single-keyword-campaign gate deciding that exactly one NorthStar earns its own campaign), and then the same app compressed through the small-market template for a cold-start storefront. If you want to see what the output looks like before running your own pool, start there.

Act 3 is the loop

The stack so far: Act 1 categorizes the pool, Act 2 builds the account from it. Act 3 is the part that never ends: the optimization loop that runs on top of the structure. Bids, negatives, graduating discovery terms into exact, promoting hold slots, phasing fences down. The structure you build in Act 2 is designed to be operated, and Act 3 is the operating manual.

Star the repo if you want it when it ships, or subscribe to Field Notes on App Growth and the walkthrough will land in your inbox.

FAQ

How many campaigns should an Apple Search Ads account have?

As many as need independent budget control, and no more. A campaign exists to cap, fence, or fund something separately; anything you only want to read separately should be an ad group. In practice that means 9 to 12 campaigns for a flagship market and roughly 6 for smaller ones.

Should every keyword get its own campaign?

No. A keyword earns a single-keyword campaign only when all three hold: it’s a core (NorthStar) keyword, it has the volume to spend meaningfully alone, and its economics are proven on its own data rather than inferred from its segment. Everything else is better served inside a segment campaign.

Do I need Act 1 before using Act 2?

Yes, and the skill will tell you the same. Campaigns derive from segments, and segments come out of categorization. Building structure from a raw keyword export just moves the mess into the account, where it’s much more expensive to fix.