App Store ランキングを改善するための計画が「もっと大きなキーワードを追加する」だとしたら、おそらくそのリリースを無駄にしようとしています。
少しきつい言い方かもしれませんが、これは小規模な iOS アプリで私が常に目にするパターンです。開発者が便利なプロダクトをリリースし、キーワードリストを開き、人気度順に並べ替え、そのカテゴリで最も大きな用語を中心にアプリ名、サブタイトル、キーワードフィールドを書き換えるのです。
その理屈は理解できます。大きなキーワードほど大きなオーディエンス、というわけです。しかし App Store は野心そのものを評価してくれるわけではありません。評価されるのは、関連性、コンバージョン、ユーザーシグナル、評価、そして競争上の強さです。あるキーワードの上位結果が何年も積み上げたシグナルを持つ確立されたアプリばかりなら、あなたの小さなアプリに必要なのは正面突破ではなく、そのカテゴリへ入り込む経路です。
実践的な答えがキーワードラダーです。
キーワードラダーとは、あなたのアプリが狭い関連性から広い需要へと登っていける用語の連なりのことです。完璧なキーワードリストを一つ選ぶのではありません。プルーフ用語から積み上げてブリッジ用語へ、そしてアプリがより強い裏付けを得たあとにアンビション(野心)用語へと進んでいくのです。
まずはプルーフ用語から始める
プルーフ用語とは、なぜそのアプリがふさわしいのかを Apple がすでに理解しているはずのキーワードです。
Pi Digits の場合、「brain games」や「brain training」といった広範な米国向け用語は、人気度スコアが高いため魅力的に見えます。しかしこれらは競争が非常に激しく、最新の Marteso のデータ取得では、このアプリに目に見える現在のランクはありません。
ところがより狭い用語になると、話は違ってきます。「pi digits trainer」と「pi digit trainer」はどちらも難易度がはるかに低く、ランク #2 を示しています。これらは見栄えのためのキーワードではありません。Apple がこのアプリを「円周率の桁を練習したい人を助ける」という具体的なジョブに結びつけられることを証明しているのです。
小規模なアプリが始めるべきはここです。その用語が最も大きいからではなく、その用語が証拠を生み出すからです。
シグナルを得てからブリッジ用語を追加する
ブリッジ用語は、狭いジョブをより広いカテゴリへとつなぎます。
CalcBlitz の場合、「math games」は人気度 93、難易度 100 を示しています。これは小規模なアプリにとって、最初の目標としては手強すぎます。しかし同じキーワードセットには、もっと有用な踏み石も含まれています。「mental math practice」は人気度 61 / 難易度 54、「arithmetic quiz」は人気度 48 / 難易度 40、そして「quick math challenge」は人気度 42 / 難易度 35 です。
これらの用語は同じではありません。それぞれ異なるユーザーの意図を含んでいます。math games のユーザーは娯楽を求めています。mental math practice のユーザーはスキルアップを求めています。quick math challenge のユーザーは、素早く競い合えるトレーニングを求めています。
この違いは重要です。あなたのアプリがそれらのジョブのいずれかに最も優れているなら、まずそのジョブを中心にメタデータを組み立てましょう。そこでランキングとコンバージョンが改善したら、隣接するブリッジ用語へと移っていきます。
広範なキーワードは後回しの賭けとして扱う
広範なキーワードは悪いものではありません。ただ、コストが高いだけです。
RowTally も同じパターンを示しています。「hiit interval timer」や「interval training timer」のようなフィットネス寄りの用語は需要が高いものの、アプリを混み合ったカテゴリへ引きずり込みます。一方で「row counter」「free row counter app」「knitting row counter app」「row counter app for knitting」といったユーティリティ系の用語は、アプリの実際の機能にずっと近いものです。ブランド用語の「rowtally - row counter」は現在ランク #1 で、これは Apple がコアとなるポジショニングを理解していることを裏付けています。
とはいえ、RowTally がより広範なフィットネスやローイング系の用語を決してテストすべきでない、という意味ではありません。次のメタデータの賭けはラダーを尊重すべきだ、という意味です。つまり、コアとなるユーティリティを守り、隣接するユーティリティ検索へと広げ、アプリが十分なシグナルを得てから、より広いカテゴリの言葉をテストするのです。
ランキングラダーのワークフロー
次のメタデータ更新の前に、これを使ってください。
- 現在のキーワードセットを、人気度・難易度・ランクとともにエクスポートします。
- すべてのキーワードをプルーフ、ブリッジ、アンビションのいずれかに分類します。
- そのリリースに向けて、プライマリとなるプルーフ用語またはブリッジ用語を一つ選びます。
- その一つの賭けを中心に、タイトル、サブタイトル、キーワードフィールドを書き換えます。
- 学びが得られるだけの十分な期間、テストにはそのまま手を付けずにおきます。明らかなインデックスの問題がない限り、私は 21 日間のレビュー期間を使っています。
- 勝者を上へと昇格させます。プルーフ用語が改善したら、次は最も近いブリッジ用語をテストします。ブリッジ用語が改善したら、より広いカテゴリ用語を検討します。
鍵となるのは順序です。すべてのキーワードで一度にランクインしようとするのではありません。次の、より難しいキーワードが現実味を帯びるだけのランキングの証拠を作り出そうとしているのです。
避けるべきこと
すべてのメタデータフィールドを 5 つのテーマで一度に書き換えてはいけません。何が効いたのか分からなくなります。
キーワードを人気度だけで判断してはいけません。人気度 99・難易度 99 で現在のランクがない用語は、たいていインディーアプリにとっては気を散らす存在です。
小さく見えても強くコンバージョンする用語を無視してはいけません。目に見えるランクを持つ狭いキーワードは、これから 2 か月の ASO 作業の土台になり得ます。
そして ASO をコピーライティングだけのものとして扱ってはいけません。より良い言葉選びは助けになりますが、App Store ランキングが改善するのは、キーワード、プロダクトの約束、スクリーンショット、コンバージョンの挙動、そしてユーザーシグナルが同じ方向を指しているときです。