クラッシュでセッションが終了したとき、失うのはユーザーの信頼だけではありません。そのセッションの残り時間に表示されるはずだった広告インプレッションも、終了時に送信されるはずだったポストバックも失われ、翌日継続率も大きく低下します。数字にすると、見過ごせない損失です。
損失の連鎖
正常に動作するモバイルアプリの平均セッション時間は6〜9分。表示回数制限を適用した後の、1セッションあたりの平均インプレッション数は2.4回です。開始から2分でクラッシュしたセッションでは、平均で約1.6回分のインプレッションが失われます。取り戻すことはできません。
クラッシュ率1%、DAUが500万の規模では、1日あたり8万回のインプレッション損失になります。eCPMが7ドルなら、毎日560ドルの収益損失です。安定性のわずか1パーセントポイントの差が、これだけの金額に直結します。
広告収益損失の計算モデル
計算式はシンプルです。1日あたりの収益損失 = DAU × クラッシュ率 ×（1セッションあたりのインプレッション数 − クラッシュ前のインプレッション数）× eCPM ÷ 1,000。実際にあり得る数字を当てはめると、損失の大きさが実感できます。
- DAU 100万 × クラッシュ率1.5% × 損失インプレッション数1.6回 × eCPM 6ドル ≈ 1日144ドル、年間5万2,000ドル
- DAU 500万 × クラッシュ率1.0% × 損失インプレッション数1.6回 × eCPM 7ドル ≈ 1日560ドル、年間20万4,000ドル
- DAU 2,500万 × クラッシュ率0.6% × 損失インプレッション数1.6回 × eCPM 8ドル ≈ 1日1,920ドル、年間70万ドル
- しかも、これらは失われたインプレッションだけの数字です。通常、それ以上に大きな損失を生む継続率の低下は含まれていません
ANRはクラッシュ以上に収益化を妨げる
AndroidのANR（Application Not Responding：アプリケーションが応答しない状態）は、見えにくい収益損失の原因です。ユーザーはフリーズしたUIを見てアプリを強制終了し、そのままアンインストールします。しかし、クラッシュレポートが送信されないため、Crashlyticsを監視するチームは気づきません。広告SDKをメインスレッドで初期化するアプリでは、ANR率が0.5%を超えることも珍しくありません。
iOSでこれに相当するのが、終了コード0x8badf00dを伴うwatchdogによる強制終了です。多くの場合、根本原因は同じで、起動時にメインスレッドで同期処理を実行していることにあります。どちらもクラッシュと同じように扱いましょう。アラートを設定し、同じモデルで収益損失を算出し、毎回のリリース可否の判断基準に組み込んでください。
プラットフォーム別の予防実装パターン
以下は、Apps Kit SDKを組み込む際に、私たちが標準で適用している実装パターンです。特別な工夫はありません。しかし、私たちが監査する一般的なコードベースには、どれも欠けています。
- Android：SDKの初期化はApplication.onCreateではなく、WorkManagerのタスクから実行する
- Android：広告ビューはWeakReferenceで保持し、onDestroyViewで参照をnullにする
- iOS：didFinishLaunchingからSDKの初期化処理をutility QoSのキューにディスパッチし、メインスレッドをブロックしない
- iOS：広告デリゲートの無効化と循環参照の解消は、deinitではなくviewWillDisappearで行う
- 共通：同意状況、ネットワーク状態、SDKの準備状態を把握するステートマシンを通じて、すべての広告リクエストの実行可否を制御する
クラッシュの主な発生原因
- メインスレッドでのSDK初期化：私たちが目にする中で、最も多い原因
- onCreate / didFinishLaunchingでの同期的な広告読み込み
- 不要になった広告ビューを保持し続けることによるメモリ圧迫
- 同意状態と広告リクエストの間で発生する競合状態
収益への影響に基づくクラッシュアラート
クラッシュ率のアラートは、通常、固定の割合をしきい値に設定され、発報しても無視されがちです。代わりに、収益への影響を基準にしましょう。特定のクラッシュシグネチャによる1日の推定収益損失がXドルを超えたら通知する仕組みにすれば、オンコール担当のエンジニアも、夜中に起きて対応する価値のあるアラートだと判断できます。私たちは、BigQueryへのエクスポートデータを使ってこの仕組みを実現するCloud Functionテンプレートを提供しています。
不具合を防ぐ基本の実装
SDKはバックグラウンドディスパッチャーで初期化し、すべての広告リクエストを同意状態のステートマシンで制御し、広告の表示枠が閉じられたら直ちに広告ビューへの参照を解放しましょう。どれも目新しい手法ではありません。それでも、私たちが監査する一般的な実装には、いずれも欠けています。
クラッシュ率を、単なるコード品質の指標ではなく収益改善のレバーとして捉えましょう。そうすれば、安定性改善の優先順位をめぐる議論は、ずっと短くなります。
今週取り組むこと
クラッシュのダッシュボードを開き、上位3つのクラッシュシグネチャに上記のモデルを適用して、それぞれの損失額をドルで書き添えましょう。最大の損失原因を修正するリリースなら、次のApp Storeの審査期間が終わる前に、改修コストを回収できるはずです。
