マーケティング / 事例

App Store 掲載最適化(ASO)— 小さな実数から、判断基準をつくる

自分で公開している iOS アプリ 4 本の App Store 実数を API で毎週取得し、「広告を出すか」「文言を変えるか」を数字で決める仕組みです。数字は小さいまま、そのまま載せています。

自分のアプリ 4 本数値は App Store Connect API から取得2026-09-19 時点
44件
初回ダウンロード(直近 8 週・4 本合計)
ASC salesReports・7/26〜9/13 週・2026-09-19
1,614回
ストア表示回数(9/7〜9/13 週・4 本合計)
ASC Analytics・2026-09-19
94回
製品ページ閲覧(同週・4 本合計)
ASC Analytics・2026-09-19
¥17.5/週
広告収益の最大週(直近 8 週)
AdMob API・9/13 週・2026-09-19
課題

「なんとなく」で広告費を使わない

個人開発のアプリは、数字を見ずに広告を出すと確実に赤字になります。まず、いま何件ダウンロードされ、何人がストアページを見ているかを把握するところから始めました。

1

数字が手元にない

App Store Connect の画面を毎週開いて転記するのは続かない。週次の実数が自動で貯まる仕組みが必要でした。

2

率だけ見ると誤る

CVR 50% と言っても分母が 6 件なら意味は薄い。率には必ず分母を添えるルールにしました。

3

広告を出す基準がない

「効果を測れる条件」を先に決めないと、出稿しても学びが残らない。判断基準を文章にしました。

実数

週次ダウンロード(4 アプリ・直近 8 週)

初回ダウンロードのみ(再ダウンロード・更新は除く)。9/13 週(9/7〜9/13)は 4 本合計 14 件で、公開直後の将棋にも初めて 2 件付きました。同じ週に掲載文の更新と新版の審査対応を進めていたため、増えた要因はまだ分けられません。

4 アプリの週次 初回ダウンロード数(2026-07-26 週〜09-13 週)Sweepfield合計 12件036Sweepfield 7/26: 0件Sweepfield 8/2: 0件8/2Sweepfield 8/9: 0件Sweepfield 8/16: 0件8/16Sweepfield 8/23: 3件3Sweepfield 8/30: 0件8/30Sweepfield 9/6: 3件3Sweepfield 9/13: 6件69/13Blockwise合計 11件Blockwise 7/26: 5件5Blockwise 8/2: 1件18/2Blockwise 8/9: 0件Blockwise 8/16: 1件18/16Blockwise 8/23: 0件Blockwise 8/30: 2件28/30Blockwise 9/6: 0件Blockwise 9/13: 2件29/13Reversi合計 19件Reversi 7/26: 1件1Reversi 8/2: 2件28/2Reversi 8/9: 5件5Reversi 8/16: 2件28/16Reversi 8/23: 2件2Reversi 8/30: 1件18/30Reversi 9/6: 2件2Reversi 9/13: 4件49/13将棋合計 2件将棋 7/26: 0件将棋 8/2: 0件8/2将棋 8/9: 0件将棋 8/16: 0件8/16将棋 8/23: 0件将棋 8/30: 0件8/30将棋 9/6: 0件将棋 9/13: 2件29/13
4 アプリの週次 初回ダウンロード数(2026-07-26 週〜09-13 週)Sweepfield合計 12件036Sweepfield 7/26: 0件Sweepfield 8/2: 0件8/2Sweepfield 8/9: 0件Sweepfield 8/16: 0件8/16Sweepfield 8/23: 3件3Sweepfield 8/30: 0件8/30Sweepfield 9/6: 3件3Sweepfield 9/13: 6件69/13Blockwise合計 11件Blockwise 7/26: 5件5Blockwise 8/2: 1件18/2Blockwise 8/9: 0件Blockwise 8/16: 1件18/16Blockwise 8/23: 0件Blockwise 8/30: 2件28/30Blockwise 9/6: 0件Blockwise 9/13: 2件29/13Reversi合計 19件036Reversi 7/26: 1件1Reversi 8/2: 2件28/2Reversi 8/9: 5件5Reversi 8/16: 2件28/16Reversi 8/23: 2件2Reversi 8/30: 1件18/30Reversi 9/6: 2件2Reversi 9/13: 4件49/13将棋合計 2件将棋 7/26: 0件将棋 8/2: 0件8/2将棋 8/9: 0件将棋 8/16: 0件8/16将棋 8/23: 0件将棋 8/30: 0件8/30将棋 9/6: 0件将棋 9/13: 2件29/13
初回ダウンロード(件)0 件の週
直近 8 週合計(2026-07-26 週〜09-13 週)と累計(取得できた範囲)・出典 App Store Connect API salesReports・取得 2026-09-19 17:07 JST
アプリ初回 DL日本米国その他累計
Sweepfield1281312(8/23 週〜)
Blockwise1130811(7/26 週〜)
Reversi1985641(3/29 週〜・再 DL 14・更新 9 は別)
将棋22002(9/13 週〜・再 DL 1 は別)

表示回数・製品ページ閲覧・CVR(9/7〜9/13 週)

Apple の Analytics レポート(App Store Discovery and Engagement)を API で取得。CVR は「初回 DL ÷ 製品ページ閲覧」で、分母を必ず併記します。

アプリ表示回数製品ページ閲覧初回 DLCVR(分母)
Sweepfield59345613%(6 ÷ 45)
Blockwise42919211%(2 ÷ 19)
Reversi57225416%(4 ÷ 25)
将棋205240%(2 ÷ 5)
前週(8/31〜9/6 週)の値
アプリ表示回数製品ページ閲覧初回 DLCVR(分母)
Sweepfield2466350%(3 ÷ 6)
Blockwise53200%(0 ÷ 2)
Reversi3045240%(2 ÷ 5)
将棋——0—(9/12 にストア掲載)

4 本合計: 表示回数 603 回・製品ページ閲覧 13 回・初回 DL 5 件。分母が 10 未満のため、率は参考値です。

出典: App Store Connect Analytics Reports API(WEEKLY・2026-09-07〜09-13・Apple 側の処理日 2026-09-18)・取得 2026-09-19 17:07 JST。将棋は分母が 10 未満のため、率は参考値です。

日次の表示回数(9/5〜9/12)

週次に加えて日次も取り、変化の兆しを早く見ます。Sweepfield は 9/5 の 62 回から 9/12 の 102 回へ増えていますが、同時期に新しい版(1.0.1)の審査対応と掲載文の更新を進めていたため、要因はまだ分けられません。

3 アプリの日次 表示回数(2026-09-05〜09-12)Sweepfield合計 607回060120Sweepfield 9/5: 62回629/5Sweepfield 9/6: 49回499/6Sweepfield 9/7: 72回729/7Sweepfield 9/8: 73回739/8Sweepfield 9/9: 86回869/9Sweepfield 9/10: 69回699/10Sweepfield 9/11: 94回949/11Sweepfield 9/12: 102回1029/12Blockwise合計 131回Blockwise 9/5: 4回49/5Blockwise 9/6: 11回119/6Blockwise 9/7: 9回99/7Blockwise 9/8: 27回279/8Blockwise 9/9: 27回279/9Blockwise 9/10: 15回159/10Blockwise 9/11: 22回229/11Blockwise 9/12: 16回169/12Reversi合計 452回Reversi 9/5: 66回669/5Reversi 9/6: 40回409/6Reversi 9/7: 47回479/7Reversi 9/8: 61回619/8Reversi 9/9: 43回439/9Reversi 9/10: 55回559/10Reversi 9/11: 55回559/11Reversi 9/12: 85回859/12
3 アプリの日次 表示回数(2026-09-05〜09-12)Sweepfield合計 607回060120Sweepfield 9/5: 62回629/5Sweepfield 9/6: 49回499/6Sweepfield 9/7: 72回729/7Sweepfield 9/8: 73回739/8Sweepfield 9/9: 86回869/9Sweepfield 9/10: 69回699/10Sweepfield 9/11: 94回949/11Sweepfield 9/12: 102回1029/12Blockwise合計 131回060120Blockwise 9/5: 4回49/5Blockwise 9/6: 11回119/6Blockwise 9/7: 9回99/7Blockwise 9/8: 27回279/8Blockwise 9/9: 27回279/9Blockwise 9/10: 15回159/10Blockwise 9/11: 22回229/11Blockwise 9/12: 16回169/12Reversi合計 452回060120Reversi 9/5: 66回669/5Reversi 9/6: 40回409/6Reversi 9/7: 47回479/7Reversi 9/8: 61回619/8Reversi 9/9: 43回439/9Reversi 9/10: 55回559/10Reversi 9/11: 55回559/11Reversi 9/12: 85回859/12
表示回数(回/日)

出典: 同 Analytics Reports API(DAILY・重複窓は最新を採用)・取得 2026-09-19。表示範囲は 9/5〜9/12 のまま。9/13〜9/17 も取得済みですが、表示回数が前後の 3〜8 倍に跳ねた日(Blockwise 9/13・Reversi 9/13・Sweepfield 9/15)があり、要因を確かめてから次回の更新で載せます。

仕組み

やったこと

ストアの文言づくりと、数字を自動で貯める土台。両方そろって初めて「改善」と言えます。

掲載文を設計し、公開後は API で週次に実数を取得し、判断基準に照らして次の一手を決める流れ 1. 掲載文を設計検索語を含むタイトル・サブタイトル説明文・スクリーンショット日英ほかのローカライズ 2. 審査対応「更新内容」は具体的に書く広告ありは申告項目を正しく却下理由は次の版の基準に 3. 実数を自動取得API で週次 DL・表示・閲覧広告収益も同じ週区切りで火曜に自動で台帳へ記入 4. 基準に照らして決める広告を出す/出さない文言を変える/据え置く実験は 1 つずつ

審査対応の例: 更新内容を「Minor updates.」とだけ書いた版は 2026-09-14 に却下(ガイドライン 2.3.12)→ 具体的な変更点に書き直して同日再提出。広告を表示するアプリは「Advertising」の申告が必須(2.3.6)。出典: App Store Connect の審査履歴(2026-09-14)。

判断基準

広告は「効果を測れる条件」を満たしてから

基準を先に文章にしておくと、数字が出たときに迷いません。2026-09-19 時点の判定も、そのまま載せます。

1
週次の実数が 4 週連続で取れていること

表示回数・製品ページ閲覧・初回 DL の 3 つが、同じ週区切りで自動取得できている。

2
製品ページ閲覧が週 100 回以上あること(アプリ単位)

分母が小さいと CVR の変化を読めない。100 回未満のうちは、広告より先に表示回数を増やす施策を優先。

3
1 ダウンロードあたりの許容コストを、実収益から出せること

広告収益 ÷ 初回 DL で「1 DL の価値」を出し、その範囲内でしか入札しない。値が出せないなら出稿しない。

2026-09-19 時点の判定: 見送り

  • 基準 1: 週次 DL は取得済み。表示・閲覧の週次は 8/31 週・9/7 週の 2 週分(4 週未満)→ 未達
  • 基準 2: 製品ページ閲覧は 9/7 週で最大 45 回(Sweepfield)。前週の 6 回から増えたが 100 回未満 → 未達
  • 基準 3: 広告収益は週 ¥0〜¥17.5。9/13 週で試算すると 1 DL の価値は約 ¥1.3(¥17.5 ÷ 14 件)で、入札に使える水準ではない → 未達

次の見直し: 2026-09-22(日次で 9/14 週までそろう週。週次 4 週分がそろうのは 10 月初旬の見込み)。それまでは無料でできる施策(下の実験 0・1)だけを行います。

流入実験の設計書

変えるのは 1 つずつ。比較期間と母数を先に決める。

「効いた」と言うために、比較期間・同時に変えたもの・母数を必ず併記します。単なる推移と改善効果を区別するためのルールです。

実験変えるもの変えないもの期間指標(分母)判定費用
0. 検索語の見直し
Sweepfield → 他 3 本へ順に
サブタイトルとキーワード欄(1 アプリずつ)アイコン・スクリーンショット・価格変更前 2 週 vs 変更後 2 週表示回数(週)・製品ページ閲覧(週)表示回数が 2 週とも前期間の 1.5 倍以上なら採用。閲覧が減れば戻す¥0
1. 外部からの流入
紹介サイト・SNS
この HP と SNS からのストアリンクに計測パラメータを付けるストアの掲載内容4 週流入元別の製品ページ閲覧・初回 DL(Apple の流入元レポート)流入元別に週 20 閲覧以上あれば、その導線を継続。未満なら投稿内容を変える¥0
2. 製品ページの A/B
Apple の標準機能
スクリーンショット 1 枚目(2 案)文言・アイコン閲覧が各案 100 回に達するまで(上限 6 週)CVR = 初回 DL ÷ 製品ページ閲覧(案ごと)両案の閲覧が 100 回以上で、差が 10 ポイント以上なら勝ち案を採用。母数未達なら判定しない¥0
3. 少額広告
基準 1〜3 を満たした後
Apple の検索広告(1 アプリ・1 か国)掲載内容・他アプリ2 週・上限額は事前に固定広告経由の初回 DL・1 DL あたり費用1 DL あたり費用が「1 DL の価値」以下なら継続。超えれば停止上限固定

計測の約束(共通)

  • 週区切りは月〜日。ダウンロードは初回のみ数える(再 DL・更新は別列)
  • 率には必ず分母を添える。分母 10 未満は参考値
  • 同じ期間に変えたものは全部書く(掲載文の更新・再提出・SNS 投稿)
  • 数値には取得元(ASC / AdMob)と取得日を付ける

この設計書が向いているケース

  • 個人・小規模チームのアプリで、広告費をかける前に「測れる状態」を作りたい
  • ストア文言の変更を、感覚ではなく前後比較で判断したい
  • 自社サイト・SNS からの流入を、流入元ごとに数えたい
出典

数値の出どころ

項目出典取得日(JST)ラベル
週次・累計ダウンロードApp Store Connect API salesReports(WEEKLY / SALES / SUMMARY)。識別子 1・1F=初回 DL、3・3F=再 DL、7F=更新は Apple の公式定義で確認2026-09-19 17:07確認済
表示回数・製品ページ閲覧App Store Connect Analytics Reports API「App Store Discovery and Engagement Standard」(WEEKLY 2 本・DAILY 11 本の重複窓を最新採用)2026-09-19 17:07確認済(週次)/部分週は参考
広告収益AdMob API networkReport(アプリ別・週次・円)2026-09-19 17:07確認済
審査対応の例App Store Connect の審査履歴(却下理由 2.3.12・再提出)2026-09-14確認済
8/30 週以前の表示回数・製品ページ閲覧Analytics のレポート要求を作成した後の週(8/31 週〜)しか生成されない(過去分の遡及なし)—未取得
正直な注記: 4 本とも自分で企画・開発・公開したアプリで、他社の導入実績ではありません。ダウンロード数は週 0〜6 件、広告収益は週 ¥0〜¥17.5 と小さく、この規模だからこそ「測れる状態を先に作る」判断にしています。Apple の週区切りは Apple 側の集計基準で、日本時間の月〜日と厳密には一致しない可能性があります。

同じ計測の仕組みを、あなたのアプリやサイトにも。

ストア文言の設計から、数字が自動で貯まる土台、広告を出す基準づくりまで一緒に作ります。

相談する(無料) 他の制作実績