広告の要求636回に対して表示0回 — 原因は「時期」ではなく設定漏れだった — 制作日誌 #11

経路アプリを公開して、広告の枠も置いた。数日たっても収益が0円のままだったので、レポートを引いてみた。

要求が636回届いているということは、アプリ側の配線は正しい。広告を読み込もうとして、毎回「出す広告がありません」と返されている。

このとき私が立てた仮説は、こうだった。

• 公開したばかりだから、配信側がまだ様子を見ている
• 広告の在庫が付くまで数日かかる
• そのうち勝手に出るようになる

全部はずれだった。

「実績は見えるが、状態は見えない」という盲点

私は広告の数字を、レポートAPIを叩くスクリプトで見ていた。日々の要求・表示・収益は全部そこから取れる。だから管理画面をブラウザで開く習慣が無かった。

ところがこのAPIで取れるのは実績だけで、アプリが配信可能な状態かどうか（承認状況）は取れない。試しに叩くと 403（権限がない）で弾かれる。つまり、

数字は毎日見ているのに、「配信できない状態です」という一番大事な一言だけが見えていなかった。

4日目にブラウザで管理画面を開いた。アプリ一覧に、こう出ていた。

広告配信を制限しています。ストア情報を追加して、トラフィックの上限を引き上げてください。

何が足りなかったのか

広告の配信サービスは、アプリが実在することをストアの掲載ページで確認する。掲載ページと紐付いていないアプリは、いたずらや水増しと区別が付かないため、配信量を強く絞られる（実質ゼロになる）。

厄介なのは順番だ。

1. 掲載ページは、アプリを公開してからでないと存在しない
2. テスト配信の段階では掲載ページが無いので、紐付けようがない
3. だから「公開前に全部準備しておく」ができない項目になっている

つまり公開直後に必ず1回、手で紐付けに行かないといけない。ここが抜けると、コードは完璧でも収益はゼロのままになる。

紐付けても、すぐには出ない

紐付けたあとも、表示はしばらく「要審査」のままだった。配信側が、アプリの開発元サイトに置いた確認用のファイルを巡回して、初めて「準備完了」になる。案内には最大7日と書いてある。画面の「更新を確認」を押しても即時にはならない。

この確認用ファイルにも、知らないと引っかかる点がある。開発元サイトのURLが全アプリで同じなら、ファイルは1本置けば全部に効く。 私は3本のアプリを同じドメインで出していたので、置くのは1回で済んだ。中身は次の1行だけだ。

google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0

4日を失った本当の理由

技術的な原因は設定漏れだが、4日失った原因は仮説の立て方にある。

私が立てた3つの仮説は、いずれも「時間が経てば直る」という形をしていた。この形の仮説は、外れていても何も起きないので、外れたことに気づけない。 待っている限り「まだ日が浅いから」と言い続けられてしまう。

対して「設定が足りていない」という仮説は、管理画面を1回開けば5分で白黒がつく。先に確かめるべきは、時間の仮説ではなく、5分で潰せる仮説のほうだった。

「公開後にしかできないこと」の棚卸し

この件のあと、公開してからでないと着手できない作業を洗い出して一覧にした。公開日は他の作業で埋まるので、事前に書き出しておかないと必ず抜ける。

3つが「✕」だった。公開は終わりではなく、その日にしかできない作業が始まる日だと考えを改めた。

収益ゼロの切り分け表

広告の収益が0のとき、どこで止まっているかは症状で切り分けられる。同じ場所で迷わないように表にしておく。

私は3か月のあいだに、この表の下3行を順番に全部踏んだ。それぞれ原因はまったく別で、共通していたのは「アプリのコードを何度読み返しても見つからない」という点だけだった。コードの外にある設定は、コードをいくら読んでも出てこない。

同じ状態を疑うときの手順

• 表示が0なら、まず管理画面を人の目で開く。APIの数字だけでは状態が見えないことがある
• アプリ一覧の「承認状況」と「ストア」の列を見る。準備完了＋ストアIDが入っていて初めて正常
• 開発元サイトの確認用ファイルが、そのURLで実際に開けるかを自分で叩いて確かめる
• 紐付け直後は数日かかる。**ここだけは本当に「待ち」**なので、待つ理由が確認できてから待つ

要求が立っているのに表示がゼロ、というのは「アプリは正しく、外側が止めている」というかなり明確な信号だった。信号は出ていたのに、読み方を知らなかった。