Keyword Categorization for ASO and Apple Ads: My 3D Framework Is Now an Open-Source AI Skill

Back in April I shared a prompt on LinkedIn that cut keyword categorization from 6 hours to 30 minutes. It became my second best performing post ever.

The prompt kept growing. Every account I ran it on taught it a new rule. Every wrong classification became a guardrail. At some point it stopped being a prompt and became a methodology with opinions.

So I did the natural next step: I turned it into a proper AI agent skill and open-sourced it. It’s live now in the ASO/ASA Skill Stack repo, MIT licensed, ready to install in Claude Code or any agent that reads instruction files.

This post walks through what the framework does, the rules it carries from live accounts, and how to run it on your own keyword pool. It’s also the first of three. More on that at the end.

Why keyword lists die in spreadsheets

Every ASO tool will happily export you 500 keywords per market. And that’s where most keyword strategies end: a spreadsheet with volume and rank columns, sorted by volume, treated as one undifferentiated pile.

The problem is that “plant identifier” and “landscaping ideas” are not the same kind of keyword for a plant identification app. One defines what the app is. The other is a tangent. If both sit in the same list with the same treatment, you end up bidding on tangents, stuffing your metadata with words that don’t convert, and reporting on averages that hide the keywords that actually matter.

Categorization is the unglamorous step between keyword research and everything downstream: metadata, Apple Search Ads structure, Custom Product Pages, reporting. Skip it and every downstream decision inherits the mess.

The 3D Framework is the fix, and the whole machine fits in one line: 500 keywords in, three dimensions applied, five groups out. The groups are the point. They tell you exactly what each keyword gets: which metadata slot, whether it gets an ASA campaign, what kind of bid strategy, how often you look at it.

The three dimensions

Type comes first: Brand, Generic, or Competitor. Brand keywords are your app name, branded features, and misspellings. Competitor keywords are other apps’ brand names. Everything else is Generic. Type sets the base treatment: Brand is always Group 1, Competitor is always Group 2, and Generic keywords get sorted by the second dimension.

Relevancy measures how closely a Generic keyword matches what your app actually does, on five levels:

• NorthStar: core value proposition keywords, capped at 10 to 12. These define what the app IS.
• Extremely Relevant: a user searching this would find the app a perfect fit.
• Relevant: strong match to a primary or secondary feature.
• Somewhat Relevant: adjacent use cases.
• Low Relevance: tangential. Tracked, never targeted.

The NorthStar cap is deliberate. Every app team believes they have 30 core keywords. They have 10, maybe 12. The final filter in the skill is blunt: would you actually put this keyword in your Title or Subtitle? If no, it’s not a NorthStar, whatever its volume says. In the worked example that ships with the repo, “garden design” scored higher on volume than “watering tracker” and still failed the filter, because the app doesn’t do garden design and nobody would put it in the Title.

Segment is the dimension most frameworks skip. Segments are app-specific functional categories that reflect how users think about the problem space: for a plant app, things like Plant_ID_Core, Care_Reminders, Disease_Diagnosis, not generic intent labels. Segments earn their keep later: one ASA campaign per segment, shared Custom Product Pages within a segment, segment-level reporting.

One rule took me a while to learn. Modifiers are not segments. A cross-cutting intent like “free” doesn’t create a Free segment. It’s a tag on keywords across segments, used for routing at campaign build time. Dimensions classify, modifiers route.

The 5-Group matrix

Type and Relevancy together map every keyword to exactly one group:

Type	Relevancy	Group
Brand	Any	Group 1
Generic	NorthStar	Group 1
Generic	Extremely Relevant	Group 2
Competitor	Any	Group 2
Generic	Relevant	Group 3
Generic	Somewhat Relevant	Group 4
Generic	Low Relevance	Group 5

And the group determines the treatment:

• Group 1 is strategic priority, and it holds two kinds of keyword with two different goals. Brand keywords are about defense: protect impression share, don’t let a competitor buy your name. Generic NorthStars are about strategic visibility: maximize presence on the terms that define the app, even when short-term ROAS argues for pulling back. Group 1 gets individual strategic attention, custom bid strategies that prioritize impression share, individual Custom Product Pages when warranted, and weekly reporting. A NorthStar with enough volume and independently proven unit economics can graduate into its own single-keyword campaign; the rest live inside their segment campaigns (Act 2 covers that gate in full). Placement-wise, Brand keywords anchor the Title; NorthStars go in the Title or Subtitle.
• Group 2 is performance priority. Individual keyword optimization against LTV and ROAS targets within dedicated segment campaign structures, shared CPPs within segments.
• Group 3 is managed at segment level, not keyword level. Segment campaigns, segment bids, monthly deep dives. This is where efficiency comes from: you stop hand-managing 200 keywords that should be managed as 8 segments.
• Group 4 gets ASO only. No ASA campaigns at all. Keyword Field if space permits.
• Group 5 gets monitoring. Nothing else.

The matrix is why categorization pays for itself. Once a keyword has a group, there are no more per-keyword debates about whether it deserves a campaign or a metadata slot. The group already answered. It’s also what keeps the organic and paid sides of an account speaking the same language. Most teams run ASO and Apple Search Ads from two separate keyword lists that have never met, and that split is where budgets leak. Here, the same groups drive both.

The rules that came from getting it wrong

The skill file carries seven hard rules at the top, and every one exists because skipping it produced a wrong result on a real account. Three examples:

Check the live store before trusting any competitor classification. Substring rules and pure reasoning can’t see intent or whether an app actually exists. On one account, a keyword that read as a plain generic term turned out to be an actual competitor app in that storefront. One live App Store search settled what the classifier got wrong. The skill makes that check mandatory before accepting or overturning any competitor call.

Pull the search-terms report before any singular versus plural decision. Apple silently folds singular and plural variants into whichever keyword you have live, so keyword-level stats are blended. On one account, 87% of a singular keyword’s spend was actually coming from hidden folded queries. The plural was the real demand, and the keyword-level view had no way of showing it.

QA any scripted classification by eye. Substring rules produce silent false positives across word joins. Real cases from one session: a rule for “billin” matched “billing”, “oinvo” matched “pro invoice”, and “freee” matched “free estimate”. Three silent misclassification classes in one pool. The skill requires sampling every rule bucket before accepting the output.

None of this is clever. It’s the residue of running the framework on pools of 900 to 1,000+ tracked keywords per platform and finding out where it breaks. That residue is most of the reason to use a field-tested skill instead of a fresh prompt.

Running it as a skill

A skill is a markdown instruction set your coding agent (Claude Code, Codex, or any agent that reads instruction files) loads when the task matches. No SDK, no API keys, no build step. The methodology is the file. If that sounds unfamiliar, I wrote about where agents fit in app growth work earlier this year. I wrote about this pattern before when I open-sourced an autonomous loop for Google Play descriptions, and the same logic applies here: the agent supplies the labor, the skill supplies the judgment.

Install in Claude Code:

git clone https://github.com/kevserimirogullari-hash/aso-asa-skill-stack.git
cp -r aso-asa-skill-stack/skills/3d-keyword-framework ~/.claude/skills/

Then hand it a keyword export from any tool (AppTweak, Sensor Tower, MobileAction, Astro, AppFollow, 200 to 500 keywords per market is the target) and ask for keyword categorization. The skill triggers on it.

This isn’t Claude-only. If you run Codex, point it at the repo and it picks the skill up the same way: reference skills/3d-keyword-framework/SKILL.md from your AGENTS.md, or paste the file path straight into the conversation. The skill is plain markdown, so any agent that follows instruction files can run it. And if you don’t use an agent at all, the file reads as a complete methodology doc on its own. The agent is optional. The method isn’t.

When you run it, the skill pulls your live App Store listing first, because the listing is the functionality anchor for the relevancy rubric. Assumption-based rubrics miss real product splits that only show up in what the app actually claims to do. Then it assigns Type, sets Relevancy, proposes app-specific segments with rationale, and maps every keyword to its group. It asks for validation at the decision points instead of guessing: segment definitions and NorthStar selection stay human decisions, the skill just makes them fast.

The output is a full analysis: type and relevancy distributions, segment table, the 5-Group summary with treatments, NorthStar candidates, and a preview of the ASA campaign structure the pool implies.

See it on a real (fictional) app

The repo includes a complete worked example on PlantPal, a fictional plant care app, run end to end on a 40-keyword pool. It shows the categorized rows, the segment table with a deliberately thin segment left unmerged (thin segments are information, not problems, and folding them is a campaign-time decision), the NorthStar selection with the root-diversity check applied, and the campaign structure preview.

If you want to know what you’ll get before running your own pool, read that file first. It’s the whole framework at a glance.

This is Act 1 of 3

The repo is called the ASO/ASA Skill Stack because the 3D Framework is the first act of a sequence, and the acts chain:

• Act 1: 3D Keyword Framework (live now). Categorize the pool into segments and groups.
• Act 2: ASA Campaign Creation (live now). Build the Apple Search Ads account structure directly from the categorized pool: segment campaigns, brand and competitor separation, discovery, naming conventions, the single-keyword-campaign gate.
• Act 3: ASA Optimization Loop (coming). The ongoing routine that runs on top of that structure: bids, negatives, keyword graduation from discovery to exact.

Act 1’s output is Act 2’s input. Act 2’s structure is what Act 3 operates. That’s the reason categorization comes first and the reason it’s the first release: everything else in the stack derives from a well-categorized pool.

Each act lands in the same repo with its own walkthrough here on the blog. Star the repo if you want the next acts when they ship, or subscribe to Field Notes on App Growth and the walkthrough will land in your inbox when each one ships.

FAQ

What is keyword categorization in ASO?

Keyword categorization is the step between keyword research and execution: sorting a raw keyword export into priority tiers that determine metadata placement, Apple Search Ads treatment, and reporting cadence. Without it, every keyword in a 500-row export gets the same treatment, which means high-priority terms are underfunded and tangents eat budget.

How many NorthStar keywords should an app have?

Ten to twelve, maximum. NorthStar keywords define the app’s core value proposition and belong in the Title or Subtitle. The practical filter: if you wouldn’t put the keyword in your Title or Subtitle, it isn’t a NorthStar, regardless of its search volume.

Do I need Claude Code to use the framework?

No. The skill file is plain markdown and reads as a complete methodology document. Any agent that follows instruction files can run it, and a human can run it manually. Claude Code just makes the install a one-line copy.