ポリシー違反「サイトの仕様:ナビゲーション」を解決した話

2024年4月10日

開発環境
OS:Windows 11
SDK:Android Studio Flamingo | 2022.2.1

概要

ポリシー違反「サイトの仕様:ナビゲーション」がなかなか解決せず、解決まで1ヶ月半かかった話。

最初の警告メールの指摘はアプリのクラッシュ

2月29日、ポリシー違反「サイトの仕様:ナビゲーション」の警告メールが届きました。

指摘を受けたアプリは「WatchOverMe」。

早速、AdMobコンソールのポリシーセンターを確認します。

指摘されたポリシー違反は、「サイトの仕様:ナビゲーション」。

添付されていた画像を確認するとアプリがクラッシュした画面のスクリーンショットでした。

「サイトの仕様:ナビゲーション」とはどんな違反なのか?

どうやら「ユーザーにとって有益ではないページを表示している」違反のようです。

添付画像から察するとアプリがクラッシュして使えないからポリシー違反ということか?

と、いうことで「正常に動作します。」という旨を記載し、再審査の申請をしました。

次の警告メールの指摘はマップ画面?

再審査の申請から2日後、またしても警告メールが届きました。

やはり違反内容は、「サイトの仕様:ナビゲーション」。

そして、添付されていた画像はマップ画面。

アプリはやっぱりクラッシュしなかったのか。。。

次の指摘は、アプリ起動後に表示されるマップ画面が真っ青だという指摘のようです。

これは現在地座標が取得できなくて(0,0)地点を表示しているためだと思われるため、

「アプリは位置情報の取得を許可して使います」という旨を記載し、再度、再審査を申請。

次の警告メールはアプリ起動時広告

再審査を申請した翌日、警告メールが届きました。

違反内容は変わらず、「サイトの仕様:ナビゲーション」。

そして、添付されていた画像はアプリ起動時広告。

えっ、アプリ起動時広告が指摘されるのか!?

AdMobの標準機能であるアプリ起動時広告が指摘されてしまいました。

そして、なんとGoogle Playからも広告表示に関するポリシー違反の指摘が届きました。

AdMobだけではなく、アプリ自体にポリシー違反が!?

まずはGooglePlayに対し、「広告表示にはAdMobの標準機能を使っている」という旨で異議申し立てを行います。

違反してました

異議申し立てから10日後、異議申し立て却下の通知がきました。

どういうことか?

改めてアプリ起動時広告のガイドラインを確認してみると下記の記載を発見。

思いっきり違反していました。

そこでアプリ起動時広告を削除してアプリを再リリースします。

まだ続くポリシー違反

GooglePlayのポリシー違反は解除されました。

が、AdMobのポリシー違反は相変わらず解除されません。

次はスプラッシュ画面を指摘されました。

スプラッシュ画面の表示を7秒→3秒に変更してアプリを再リリースします。

まだまだ続くポリシー違反

次はホーム画面を指摘されました。。。

位置情報の許可をしないと表示されないんだが。。。

対応する

ニッチもサッチも展開になってしまったので思い切って起動周りの処理を変えます。

プッシュ通知の表示でコールするstartForegroundの引数追加に対応できていませんでした。

最初の指摘はこれだったのか・・・

最終的に以下の改修を実施。

・対象年齢を8歳から13歳以上に引き上げ、ファミリー向けプログラムを回避

・それに伴い、アプリ起動時広告を再度、表示させるよう改修

・イニシャル画面を追加し、位置情報を許可させるよう改修(許可しない場合はアプリ強制終了)

・Android14対応(アプリクラッシュ回避)

そして、修正版アプリをリリース。

リリースが反映されたのを確認し、審査をリクエストします。

ポリシー違反解除

ついにようやくポリシー違反が解除されました。

上記について押させておく必要がありました。

ポリシー違反「GooglePlayアプリの無効化」を解決した話とファミリー向けアプリの実装方法の訂正について

2024年2月27日

開発環境
OS:Windows 11
SDK:Android Studio Flamingo | 2022.2.1

概要

ポリシー違反「GooglePlayアプリの無効化」の警告メールが届きました。

対応から解決までの話。

ファミリー向けアプリのAdMob実装に潜む誤り

2月24日、GooglePlayから以下のメールが届きました。

位置情報共有アプリ「Watch Over Me」。

このアプリは親子の間で位置を共有することを意図したアプリとなっており、ユーザーの対象年齢は子供を含めた全年齢としています。

そこで必要となるのがファミリーポリシー対応です。

この点については抜かりなく実装し、以下のようなまとめ記事も作っていました。

ファミリーポリシー違反に対する指摘メールが届き、アプリが削除されてしまいました。

違反内容を詳しくみると「aaid」というAndroid特有のIDをアプリから送信してしまっているようです。

アプリの機能として「aaid」送信を実装していないのでAdMobが送信しているのは間違いありません。

子供向けのAdmob設定を行うと「aaid」の送信は抑制されるはずなのになぜ。。。

なんてことを思っていたら、Admobから広告配信中断予告が届きました。

AdMobコンソールから見た詳細が以下。

どうしたものか。。。

AdMob実装の誤りに気付く

ファミリーポリシー対応を実装していはずなのに「aaid」が送信されている。

ということは、子供向けのAdMob設定のコードに誤りがあるのか?

ネット検索してみたところ、UnityのAdMob設定に関するサイトで以下の記載が見つかりました。

ソースコードを修正する

initial処理前にこども向けのパラメータ設定を行う必要がありました。

ということでソースコードを修正します。

そして、アプリをリリース。

ポリシー違反解除

1日後、アプリがリリース審査が通り、アプリがストアに復帰しました。

そして、AdMobコンソールをチェックすると

ポリシー違反が解除されていました。

今回の修正に伴い、まとめ記事も修正しました。

GDPRメッセージをAndroidアプリに組み込む

2024年2月13日

開発環境
OS:Windows 11
SDK:Android Studio Flamingo | 2022.2.1

概要

AndroidアプリにGDPRメッセージを組み込みます。

AdMobに表示された警告

AdMobのコンソール画面を表示したところGDPRメッセージについて警告が表示されていました。

2024年1月14日からイギリス、または、欧州経済領域で広告を表示するには事前に広告表示に関する確認が必要になるようです。

GPDRメッセージとはその確認のための案内文であり、UMP SDKをアプリに組み込むとAdMobで作成したメッセージを表示してくるようです。

GDPRメッセージ作成の流れ

早速、実装していきます。

まずは、AdMobのコンソール画面に表示された「GPDRメッセージを作成」をタップします。

(メニュー「プライバシーとメッセージ」のGDPRから作成・編集することもできます。)

GDPRメッセージの作成フローが表示されます。

流れに沿って設定していけば滞りなく実装できます。

ステップ1.メッセージを作成する

まずはGDPRメッセージを作成します。

メッセージ自体はデフォルトのフォーマットがあるためそのまま使用します。

設定すべき項目としては、

「表示対象アプリ」、「言語」、「同意しないボタンの表示有無」ぐらいです。

私は、同意しないボタンを表示するパターンと表示しないパターンの2パターン作成し、

表示対象アプリをそれぞれのパターンに振り分けることにしました。

基本的には同意しないボタンを表示しないパターンを使用し、

こども向けゲームアプリだけ同意しないボタンを表示するパターンを使用することにしました。

ステップ2.UMP SDKを組み込む

メッセージの作成が終わったら、アプリにUMP SDKを組み込みます。

まずはbuilde.gradleの実装。

    implementation 'com.google.android.ump:user-messaging-platform:2.1.0'

次に必要なモジュールをインポートします。

import com.google.android.ump.ConsentForm
import com.google.android.ump.ConsentInformation
import com.google.android.ump.ConsentInformation.OnConsentInfoUpdateFailureListener
import com.google.android.ump.ConsentInformation.OnConsentInfoUpdateSuccessListener
import com.google.android.ump.ConsentRequestParameters
import com.google.android.ump.UserMessagingPlatform
import com.google.android.ump.ConsentDebugSettings
import java.util.concurrent.atomic.AtomicBoolean

あとは適当な場所にメッセージの呼び出し処理を追加します。

    private lateinit var consentInformation: ConsentInformation
    private var isMobileAdsInitializeCalled = AtomicBoolean(false)

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val params = ConsentRequestParameters
            .Builder()
            .setTagForUnderAgeOfConsent(false)
            .build()

        consentInformation = UserMessagingPlatform.getConsentInformation(this)
        consentInformation.requestConsentInfoUpdate(
            this,
            params,
            OnConsentInfoUpdateSuccessListener {
                UserMessagingPlatform.loadAndShowConsentFormIfRequired(
                    this@MainActivity,
                    ConsentForm.OnConsentFormDismissedListener {
                        // Consent has been gathered.
                        if (consentInformation.canRequestAds()) {
                            initializeMobileAdsSdk()
                        }
                    }
                )
            },
            OnConsentInfoUpdateFailureListener {

            })

        if (consentInformation.canRequestAds()) {
            initializeMobileAdsSdk()
        }
    }

最後にメッセージロード後の処理を追加して完了です。

    private fun initializeMobileAdsSdk() {
        if (isMobileAdsInitializeCalled.get()) {
            return
        }
        isMobileAdsInitializeCalled.set(true)

        MobileAds.initialize(this)
    }

ステップ3.デバッグする

最後に動作確認をします。

まずはデバッグ用のパラメータを追加します。

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val debugSettings = ConsentDebugSettings.Builder(this)
            .setDebugGeography(ConsentDebugSettings.DebugGeography.DEBUG_GEOGRAPHY_EEA)
            .addTestDeviceHashedId("46********************E1")←デバッグ機のデバイスID
            .build()

        val params = ConsentRequestParameters
            .Builder()
//            .setTagForUnderAgeOfConsent(false)
            .setConsentDebugSettings(debugSettings)
            .build()

        consentInformation = UserMessagingPlatform.getConsentInformation(this)
        consentInformation.requestConsentInfoUpdate(
            this,
            params,
     ~
    }

デバッグするには、デバッグ機のデバイスIDが必要になります。

アプリを起動するとログにデバイスIDが出力されます。

ログは「.addTestDeviceHash」で絞り込むと見やすいです。

アプリを起動させ、以下のような画面が表示されたら実装成功です。

もう1度確認したい場合は、

consentInformation.requestConsentInfoUpdateの前に以下を追加すると

同意を行った後もまた案内文が表示されるようになります。

        consentInformation.reset()

ここまで動作確認できれば、あとはリリースするだけです。

お疲れさまでした。

ポリシー違反「ユーザーの意図しないクリック:レイアウト」を解決した話

2024年2月12日

開発環境
OS:Windows 11
SDK:Android Studio Flamingo | 2022.2.1

概要

ポリシー違反「ユーザーの意図しないクリック:レイアウト」の警告メールが届きました。

対応から解決までの話。

警告メールが届いてから2日で広告配信停止

ポリシー違反「ユーザーの意図しないクリック:レイアウト」の警告メールが届きました。

指摘を受けたアプリは「サムズアップ」です。

あとで対応すればいいかとしばらく放置していた2月11日(日)。

広告配信停止通知がきてしまいました。

はやくないですか!?

3連休中ののんびりモードも一転。

慌てて指摘内容を確認します。

バナー広告のすぐ上にカウントボタンを配置しているのですが、

どうやらそれを指摘されているようです。

対応する

指摘内容を踏まえ、バナー広告の配置を下から上に変更。

これでバナー広告周辺にクリックするものはなくなりました。

あとは修正版アプリをリリース。

リリースが反映されたのを確認し、審査をリクエストします。

ポリシー違反解除

審査リクエストを出した17時間後、ポリシー違反が解除されました。

ポリシー違反「サイトの仕様:ナビゲーション」を解決した(?)話

2024年2月12日

開発環境
OS:Windows 11
SDK:Android Studio Flamingo | 2022.2.1

概要

ポリシー違反「サイトの仕様:ナビゲーション」の警告メールが届いたのですが

どうも腑に落ちません。

そんなときの対応から解決までの話。

意図した動作ではないものに対する指摘

ポリシー違反「サイトの仕様:ナビゲーション」の警告メールが届きました。

指摘を受けたアプリは「みてみて」です。

そして指摘内容が以下。

添付されていた画像は2枚。

2枚目の画像はアプリが反応していないエラー画面のようです。

そして、問題として挙げられた「サイトの仕様:ナビゲーション」について確認すると。

どうやらアプリの「START」をタップしたが、反応がなくエラーとなった。

コンテンツが存在しないのではないか。

そのような指摘に思われます。

ちょっと待て、と言ってみる

アプリの仕組みとしては、「START」をタップするとFirebaseから投稿データを取得し、

マップ画面を表示するのですが、ネットワークが悪いのか、Firebaseのアクセスが遅延したのか、

アプリがエラーとなったようです。

これは外部要因によるエラー。

アプリとしては対応いたしかねます。

そこで「審査をリクエスト」からアプリのコンテンツが用意されていることを訴え、異議申し立てをしてみました。

ポリシー違反解除

審査リクエストを出した9時間後、ポリシー違反が解除されました。

こういうこともあるんですね。

ポリシー違反「動的コンテンツについて」を解決した話

2024年1月7日

開発環境
OS:Windows 11
SDK:Android Studio Flamingo | 2022.2.1

概要

ポリシー違反「偶発的クリックを誘導するレイアウト – 予期しないタイミングでのインタースティシャル広告の表示」を解決した2日後のこと。

ポリシー違反「動的コンテンツについて」の警告メールが届きました。

ポリシー違反「偶発的クリックを誘導するレイアウト – 予期しないタイミングでのインタースティシャル広告の表示」を解決した話については以下を参照ください。

ポリシー違反は何度も届く

ポリシー違反を解決して安堵したのもつかのま、またしても警告メールが届きました。

指摘されたアプリは前回同様、「エストーク」、サーバーレスでも動くチャットアプリです。

前回のポリシー違反が解決できていなかったのか?

不安を胸にポリシーセンターを表示します。

検出された問題は、

「動的コンテンツについて」

添付画像はありません。

前回のポリシー違反ではなかったとのことでまずは一安心。

今回の指摘は分かりやすい内容です。

「動的コンテンツがメインとなっているページではGoogle広告を表示できない」とのこと。

前回のポリシー違反で整理したアプリ「エストーク」のインタースティシャル広告表示タイミングを見直すとフレンドリスト表示時、画像リスト表示時、チャット画面表示時の3か所です。

確かに動的コンテンツ(チャット)をメインとする画面でインタースティシャル広告を表示しています。

そこで指摘に従い、チャット画面表示時はインタースティシャル広告を表示しないよう改修しました。

ポリシー違反解除

審査リクエストを出した翌日、ポリシー違反が解除されました。

動的コンテンツがメインとなっているページではGoogle広告を表示できない。

勉強になりました。

ポリシー違反「偶発的クリックを誘導するレイアウト – 予期しないタイミングでのインタースティシャル広告の表示」を解決した話

2024年1月7日

開発環境
OS:Windows 11
SDK:Android Studio Flamingo | 2022.2.1

概要

ポリシー違反「偶発的クリックを誘導するレイアウト – 予期しないタイミングでのインタースティシャル広告の表示」の警告メールが届きました。

ポリシー違反の発生から解決までの顛末。

ポリシー違反は唐突に届く

またしても唐突にポリシー違反の警告メールが届きました。

今回指摘されたのはアプリ「エストーク」、サーバーレスでも動くチャットアプリです。

今回はどんな指摘なんでしょうか。

早速、ポリシーセンターを表示します。

検出された問題は、

「偶発的クリックを誘導するレイアウト – 予期しないタイミングでのインタースティシャル広告の表示」

そして、添付されていた画像は、

インタースティシャル広告が表示された画像でした。

問題とあわせて考察すると

偶発的クリックを誘発するタイミングでインタースティシャル広告を表示してますよ、という指摘のようです。

そこで改めてアプリ「エストーク」のインタースティシャル広告表示タイミングを見直すとフレンドリスト表示時、画像リスト表示時、チャット画面表示時の3か所でした。

画面を表示するタイミングで確率でインタースティシャル広告を表示しています。

ポリシー違反の指摘を踏まえると画面表示時にインタースティシャル広告を表示すると偶発的クリックを誘発する、ということのようです。

さて、どう改修するか。

表示タイミング自体は変えたくない。

でも、画面表示のタイミングで唐突にインタースティシャル広告を表示すると偶発的にクリックを誘発する。

そこでインタースティシャル広告を表示する前に「これから広告を表示します。」というポップアップを表示するように改修してみました。

ポリシー違反解除

審査リクエストを出した翌日。

ポリシー違反が解除されました。

画面表示直後にインタースティシャル広告を表示させる場合は

広告を表示する旨をポップアップ表示するなどワンクッション置いた方がよさそうです。

ポリシー違反「コンテンツの前面に重なって表示されるGoogleが配信する広告の扱い」を解決した話

2023年10月22日

開発環境
OS:Windows 11
SDK:Android Studio Flamingo | 2022.2.1

問題

以下に示した画像はポリシー違反「コンテンツの前面に重なって表示されるGoogleが配信する広告の扱い」に該当します。 修正しなさい。

概要

とあるアプリの改修リリースを行ってから5か月が経過したある日、突如、ポリシー違反「コンテンツの前面に重なって表示されるGoogleが配信する広告の扱い」の警告メールが届きました。

ポリシー違反の発生から解決までの顛末。

ポリシー違反は突然に

アプリ「みてみて」を改修し、リリースしたのが2023年5月4日。

それから5か月が経過した10月14日、突如、ポリシー違反の警告メールが届きました。

メールが届いた時点ですでに広告配信に制限がかけられている模様。

それは困る、と慌ててAdmobのポリシーセンターを確認してみると、

ポリシーセンターに問題と関連画像が表示されていました。

検出された問題は、

「コンテンツの前面に重なって表示されるGoogleが配信する広告の扱い」

そして、添付されていた画像は、

アプリのマップ画面でした。

どうやらこのマップ画面が違反対象のようです。

う~ん、何が駄目なのか・・・

パッと見た感じでは分かりません。

なんとか解決の糸口はないかと「重なっている」点に注目してみると

Googleマップの上にバナー広告を配置していたことに気付きました。

そう確信し、レイアウトの調整を行い、アプリをリリース。

アプリがストアに展開されるのを確認し、ポリシーセンターから審査をリクエスト。

違った

そして、翌日。

早々と返ってきた返事。

ち、違ったのか・・・

こうなってくると何が駄目なのか、Admobに聞きたくなるが明確な問い合わせ先がない。

そこでなんとか意思疎通を図ろうと試みる。

リクエストのコメント欄に「コンテンツと表示が重ならないようマップ画面のレイアウトを修正しました。修正内容が間違っているなら詳細を教えて欲しい」

と記入。再度、リクエスト。

すると約2時間後・・・

また同じフォーマットでメールが返って来た!

コメントに対するリアクションもない・・・

どう改修すればよいか検討がつかない、しかし、広告配信の制限を解除したい。

広告自体を削除すれば、コンテンツと重なるという違反は解除されるはず。

これで少なくともマップ画面以外の広告は復帰できる。

そう期待し、再審査に挑んだ。

う、嘘だろ

そして翌日。

届いたメールを見て驚愕した。

デバッグ用フォルダ

ポリシー違反が解決されていない。

そ、そんなバカな・・・

広告自体を削除したのに・・・

絶望しかけたそのとき、

ふとポリシーセンターを見直してみると問題の欄に違反項目が追加されていた。

ヒントを出してくれているのかい!(涙

新たに追加された問題は、「サイトの仕様:ナビゲーション」であった。

ガイドラインを確認すると広告の近くにボタンなどを配置し、誤操作を誘発してしまうのはポリシー違反になるとのこと。

その点を考慮し、レイアウト調整を行い、アプリをリリース。

再審査をリクエストした。

ポリシー違反解除

問題発生から4日。

ついにポリシー違反が解除されました。

はてさて最初の指摘でこの修正ができるものなんだろうか?という疑問が沸き起こる。

最終的にポリシー違反が解除されたレイアウトが以下です。

回答

Admob広告ユニットIDをデバッグとリリースで使い分ける

2023年1月23日

開発環境
OS:Windows 10
SDK:Android Studio Dolphin | 2021.3.1

概要

Admobから与えられたアプリID、広告ユニットIDをデバッグモードで使用してしまうとAdmobから警告を来て、収益に影響が出てしまいます。
そうならないためにもリリースとデバッグモードで広告ユニットIDを分けて定義しておくと便利です。

Admobを表示するときに必要となるID

Admobをアプリに表示させるにはアプリIDと広告ユニットID、少なくとも2つのIDを定義する必要があります。

アプリID、広告ユニットIDはAdmobで作成することができますが、

アプリのデバッグ時に使用することはできません。

代わりにデバッグ時にはサンプルIDを使用します。

【 サンプルアプリID 】

ca-app-pub-3940256099942544~3347511713

サンプル広告ユニットID

広告フォーマットサンプル広告ユニットID
アプリ起動ca-app-pub-3940256099942544/3419835294
バナーca-app-pub-3940256099942544/6300978111
インタースティシャルca-app-pub-3940256099942544/1033173712
インタースティシャル動画ca-app-pub-3940256099942544/8691691433
報酬型ca-app-pub-3940256099942544/5224354917
報酬型インタースティシャルca-app-pub-3940256099942544/5354046379
ネイティブアドバンスca-app-pub-3940256099942544/5354046379
ネイティブアドバンス動画ca-app-pub-3940256099942544/1044960115
サンプル広告ユニットID一覧

デバッグ用定義とリリース用定義

アプリIDと広告ユニットIDはstring.xmlに定義して管理します。

まずリリース用のアプリID、広告ユニットIDをstring.xmlに定義します。
(下3行がID定義となります。)

<resources>
    <string name="app_name">Look Look</string>
  ・・・
  ・・・
  ・・・
    <string name="ts_adview">Advertisement will be displayed from now on.</string>
    <string name="ad_attribution">Ad</string>
    <!-- admob -->
    <string name="admob_id_manifest">ca-app-pub-xxxxxxxxxxxxxxxx~xxxxxxxxxx</string>
    <string name="admob_id_bottom_main">ca-app-pub-xxxxxxxxxxxxxxxx/xxxxxxxxxx</string>
    <string name="admob_id_bottom_map">ca-app-pub-xxxxxxxxxxxxxxxx/xxxxxxxxxx</string>
</resources>

次にデバッグ用のアプリID、広告ユニットIDをstring.xmlに定義します。

デバッグ用のstring.xmlは最初は存在しないため、新たにデバッグ用フォルダ内に作成します。

【 デバッグ用フォルダの場所 】

(プロジェクトフォルダ)/app/src/debug/res/values/string.xml

※フォルダがない場合はフォルダも作成します。

※多言語化対応している場合は言語毎のvaluesフォルダ(例えば日本語の場合、values-ja
 フォルダ)にstring.xmlを格納します。
 string.xmlの定義内容は全て同じで問題ありません。

デバッグ用フォルダ
<resources>
    <!-- admob -->
    <string name="admob_id_manifest">ca-app-pub-3940256099942544~3347511713</string>
    <string name="admob_id_bottom_main">ca-app-pub-3940256099942544/6300978111</string>
    <string name="admob_id_bottom_map">ca-app-pub-3940256099942544/6300978111</string>
</resources>

string.xmlには、AdmobのサンプルIDだけ定義すればOKです。

アプリID、広告ユニットIDを参照する

あとはstring定義を参照するだけです。

(AdroidManifestの定義例)

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  ・・・
    <application
  ・・・
        <meta-data
            android:name="com.google.android.gms.ads.APPLICATION_ID"
            android:value="@string/admob_id_manifest" />
  ・・・
        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:theme="@style/AppTheme.NoTitleMain">
  ・・・
       </activity>
  ・・・  
    </application>
</manifest>

(レイアウトXMLの定義例)

<?xml version="1.0" encoding="utf-8"?>
<ConstraintLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    xmlns:ads="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MapsActivity">


    <com.google.android.gms.ads.AdView
        android:id="@+id/adViewMap"
        ads:adSize="SMART_BANNER"
        ads:adUnitId="@string/admob_id_bottom_map"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        app:layout_constraintStart_toStartOf="parent"
        android:layout_marginStart="0dp"
        app:layout_constraintBottom_toBottomOf="parent"
        android:layout_marginBottom="0dp">
    </com.google.android.gms.ads.AdView>
</androidx.constraintlayout.widget.ConstraintLayoutt>

これでデバッグとリリースの使い分けができるようになりました。

いつも通りにデバッグを行えばサンプルIDが参照され、リリースアプリの作成を行えば、リリース用IDが参照されるようになります。

ファミリーポリシーを遵守すべきなのか、決断する

概要

アプリのターゲットユーザーを13歳未満とする場合に考慮すべきファミリーポリシー。
以前にもファミリーポリシーを遵守するために広告を制限するなどあれこれと試行錯誤してきましたが、ついに決断の時がきました。
ファミリーポリシーをこのまま遵守し続けるべきなのか?

以前に行った対策は以下。

リリース審査でリジェクトされる

ヒットアンドブローを題材にしたWi-Fi Directゲーム、サムライロード

アプリをAndroid13に対応させようと軽微な改修を行い、リリースしたところ、ファミリーポリシー違反によるリジェクトとなりました。

リジェクト理由として添付されていた画像は以下。

リジェクト理由としては「広告コンテンツがファミリーポリシーに反している」とのこと。

そして、そのポリシー違反の広告が「Pickaroo」というアプリの広告のようです。

では、「Pickroo」とはどんなアプリなのか?

ネットで調べてみると、日常用品のデリバリーサービスアプリでした。

ちなみにファミリーポリシーの規約に関するサイトに違反例として掲げられているのがこちら。

違反例を参考に判断すると、ポリシー違反ではないような気もします。。。

異議申し立てをすることでリジェクトを回避できるかもしれませんが、そもそもファミリーポリシーを遵守すべきなのだろうか?

13歳未満をターゲットにする意図

13歳未満をターゲットにしなければ、ファミリーポリシーの遵守は必要ありません。

では、なぜ13歳未満をターゲットに含めたのか?

それは、13歳未満を対象にすることでユーザー層を拡大したい、親子で楽しんでもらいたい、という思いがあったからです。

ですが、ここで改めて実際に13歳未満のユーザー数を調べてみます。

「android 世代別」で検索した結果、ヒットした記事を参考にすると、

Androidユーザー全体に対する10代男女の割合が、5.4%。

13歳未満に限るともっと少ないはずです(おそらく1%未満)。

つまり、ユーザー層の拡大に対する期待値は予想以上に低いという事実。

そして、その期待値の割に対し、広告の制約が大きいということ。

ターゲットユーザーを13歳以上とする

上記の理由から、サムライロードについては、13歳未満のユーザーに対するアプリの普及を断念することにしました。

それにより、以下の変更を実施。

・Google Play Consoleでターゲットユーザーを13歳以上に変更

・AdMobのアプリ設定から広告制限を撤廃

・アプリ内の広告リクエストからレーティング制御を削除

・アプリのタイトル変更(サムライロードからサムライキルに。敢えてキルと言う表現を避けていた)

変更後、リリースした結果、無事、リリース審査に合格しました。

総括

13歳未満のユーザーターゲットとAdMobの相性はやはり良くないですね。

広告収入を抜きにした目的(13歳未満のユーザーと親和性の高い商品展開をしていてサービスとしてアプリを提供するなど)がないと厳しいかなと感じました。

残念ですが、サムライロードは13歳未満のユーザーターゲットから撤退です。