はじめに

個人で開発しているプロダクトにAdMobのインタースティシャル広告を導入しようとした時に幾つか嵌った罠があるのでメモを残しておきます。

罠とは

テスト用のIDがBannerとは違う

手順書にあるIDをすっかり見落としており、バナーやネイティブ広告と同じdebug用のIDを設定したところ広告が表示されれず手間取りました。
これはドキュメントをちゃんと読まなかった私の自業自得ですね。

リスナーの呼ばれ方もBannerとは違う

同じAdListenerクラスをsetして使うのですが、Bannerと同じリスナーが呼ばれるかと思っていたら挙動が違いました。

イベント	Banner	Interstitial
読み込み完了時	onAdLoaded()	onAdLoaded()
表示完了した時	-	onAdOpened()
クリック時	onAdOpened()	onAdLeftApplication()
閉じた時	-	onAdClosed()

Bannerは読み込み完了≒表示完了みたいなタイミングです。
それに対してInterstitial広告は予め読み込む必要があるため、読み込み完了時にはonAdLoaded()が呼ばれ、表示時にはonAdOpened()が呼ばれます。

そして、このonAdOpened()はBannerではクリック時に呼ばれます。
クリック数を集計するつもりでBannerと同じ実装でonAdOpened()にログを仕込んだところ、押した覚えのないクリックが発生したことになってしまい混乱しました。

ちなみに、Interstitialの場合は広告クリック時にonAdLeftApplication()が呼ばれました。
ここには出てきていませんが、onAdClicked()というメソッドを差し置いてonAdOpened()やらonAdLeftApplication()が呼ばれるのはなんだか釈然としません。

音がいきなり出る、その対処方法

実装が終わり、テスト用の広告の表示も問題なく確認できたので、リリースビルドをして本番用の広告で表示確認をしたところ急に端末から大音量の音楽が流れ出しました。
テスト広告ではただの一枚の画像としての広告でしたが本番用は広告の種類にチェックが入っていた場合、動画広告が流れる場合があります。
そして、この音量はデフォルトoff設定用のフラグなどは見当たらず端末の現在の音量によって決定されます。

MobileAdsクラスにsetAppMuted(boolean)というメソッドが有り、それでミュートに出来るかと思ったのですがうまく動かなかったため代替案として力技でミュートのon/offを実行しました。

private fun setAppMuted(muteState: Boolean) {
    val audioManager = getSystemService(Context.AUDIO_SERVICE) as AudioManager
    audioManager.setStreamMute(AudioManager.STREAM_MUSIC, muteState)
}

このメソッドを上述のリスナーの適切な位置から呼び出すことで、動画再生前にミュート状態になり、広告を閉じる時点でミュートが解除されるようになります。

せっかくの動画広告なのにミュートにすることで、広告主の伝えたい情報が視覚からのみに半減してしまうのは本末転倒な気もしますが、いきなり大音量が鳴る広告もそれはそれで心証が悪くなるため組み込むアプリの性質に応じてデフォルトでミュートにするかどうかを考えるべきだと思います。

少なくとも私の作っているアプリに関していうと普段音の鳴るコンテンツが殆ど存在しないため、多少広告の効果が下がってもデフォルトをミュートにし、離反を防ぐことで中長期的に広告を見てもらうことを優先すべきだと判断しました。
（そもそも全画面広告を導入したことによってユーザーの離反率が上がるのではないかという問題は別途あります。）

おわりに

自分がユーザーとして全画面広告というはあまり好きじゃなかったのですが、知り合いから強い勧めを聞いたのでこれから試験的に導入してみます。
また、万が一のレビュー荒れに備えFirebaseのRemoteConfigで表示割合を調整する仕組みの容用意や、AdMobの管理画面からフリークエンシーキャップ¹を設定することである程度表示を制御できる仕組みは一緒に導入しておいたほうが良いと思っています。

同一のユーザーに対する広告表示回数を、1 分、1 時間、または 1 日単位で制限するための上限値。 ↩