Pre-launch keyword research: choose a promise before a keyword list

Start with a task the first release actually completes

A launch shortlist should begin with a product boundary, not the broadest category word. Imagine a home-exercise timer that alternates work and rest, saves routines, and plays audible cues, but cannot create training plans. Interval timing is a credible promise; personalized coaching is misleading.

Describe who uses the app, in what situation, and what they finish. Translate that sentence into candidate searches, preserving the intent beside each phrase. Natural wording is not validated demand: interviews and public search results provide different evidence.

Inspect the result context in one launch storefront

Search candidate phrases in the intended country and inspect the apps that appear. Look for the dominant task: an exercise timer query might return workout tools, while a general timer query may mix cooking, study, and utility apps. That mixture helps you understand ambiguity, not count the people making each search.

Back My Side uses Apple public search and lookup data, with positions sampled in up to 200 results. These are not personalized device rankings or official search-volume figures. If your app is not yet public, research comparable live apps and candidate terms; a public lookup cannot audit an unpublished listing or establish its future position.

Make inclusion a decision, not a score threshold

For the hypothetical timer, keep phrases that describe the working routine builder and reject phrases requiring an absent coaching service. Use relative popularity and difficulty as heuristic comparison aids, never as a reason to override relevance. A less impressive score can still accompany the clearest promise your app can honestly deliver.

Give every shortlisted phrase an owner and a visible proof point. If the team cannot show the promised behavior in a screenshot or a short walkthrough, move the phrase to the product backlog rather than the launch metadata. This prevents future features from quietly becoming present-tense acquisition claims.

• Record the exact phrase, storefront, intended user, and supported task.
• Note competing result types and the date you inspected them.
• Identify the feature or screen that proves the promise.
• Mark uncertain intent for further research instead of inventing demand.

Prepare metadata and the first observation together

Allocate the clearest language across the name, subtitle, and keyword field without repetition. Apple's limits are 30 characters for the name, 30 for the subtitle, and 100 for the keyword field including commas. Avoid duplicates of name, subtitle, or category terms, irrelevant words, competing app names, and unauthorized trademarks. Keep the visible copy readable.

Archive the submitted wording, launch country, release date, and intended audience in your own release notes. After the listing becomes public, collect a baseline and review discovery alongside conversion in App Store Connect. Back My Side does not publish metadata or integrate with App Store Connect; its tracker history begins with collected snapshots, not an invented pre-launch record.

Frequently asked questions