LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

ATTとプッシュ通知許諾とは — 許可されないと計測も再訪促進もできない

ATT/プッシュ通知の許諾率改善とは、iOSのATT（App Tracking Transparency：アプリ追跡透過性）フレームワークおよびプッシュ通知について、ユーザーが「許可」を選ぶ割合を高めるためのアプリUX設計・運用の取り組みを指します^*1。

ATTはAppleが導入したプライバシーフレームワークです。アプリがIDFA（Identifier for Advertisers：広告識別子）にアクセスするには、ユーザーが許可ダイアログで明示的に同意する必要があります^*1。ユーザーが「許可しない」を選ぶと、アプリ側は広告効果の計測に必要なIDFAを取得できなくなります。

プッシュ通知の許諾も同様で、ユーザーが一度「許可しない」を選ぶと、アプリ側からその設定を変更できません。再度許可を求めるには、ユーザーがiOSの設定アプリを自ら開いて変更する必要があります。つまり、OSのダイアログを表示するタイミングと事前の説明の質が、その後の計測精度や通知到達率を大きく左右します。

ATTとプッシュ許諾の違い：求める情報・OSの挙動・影響範囲

ATTとプッシュ通知の許諾は、どちらもユーザーの同意を求める仕組みですが、目的・OSの挙動・影響範囲が異なります。混同したまま設計すると、それぞれの対策が中途半端になります。

ATTが求めるのは「広告識別子（IDFA）へのアクセス許可」です^*1。許可するとアプリが広告効果の計測・クロスアプリのトラッキングに活用できます。許可しない場合、アプリはIDFAにアクセスできず、広告ROASの正確な計測が難しくなります。このダイアログはアプリがIDFAへのアクセスを試みる直前に一度だけ表示され、再表示はできません。

プッシュ通知の許諾が求めるのは「通知を送信する権限」です^*2。ユーザーが許可すると、アプリからバッジ・サウンド・アラートを届けられます。休眠ユーザーへの再訪促進や、タイムリーな情報提供の基盤となります。ATTと同様に、一度「許可しない」を選ぶとアプリ側から再要求することはできません。

両者に共通する課題は、OSダイアログが表示されるタイミングとユーザーの心理状態が許諾率に直結する点です。アプリの価値をまだ理解していない段階でダイアログが出ると、反射的に「許可しない」が選ばれやすくなります。

なぜ許可されないか：ダイアログ設計の落とし穴

許諾率が低い原因の多くは、OSダイアログを表示するタイミングとユーザーへの事前説明の欠如にあります。設計の落とし穴を整理します。

初回起動直後にダイアログを出している

アプリを初めて開いたばかりのユーザーは、そのアプリが自分にとって価値があるかどうかをまだ判断できていません。その状態でATTやプッシュ通知の許可を求めると、「何のためにデータを使うのかわからない」という不安から「許可しない」を選ぶ傾向があります。

価値を体験する前に許可を求めるのは、ユーザーが納得感を持てない状態でのリクエストです。初回起動直後を避け、アプリの核となる機能を一度使ってもらった後にダイアログを表示する設計が、許諾率を高める定石とされています^*2。

プレパーミッションを設けていない

iOSのATTダイアログはAppleが用意した固定フォーマットで、開発者が文言を自由に変えることはできません。OSのダイアログだけを表示しても、ユーザーはなぜこの許可が必要なのかを理解できないことがあります。

プレパーミッション（Pre-permission）とは、OSの許可ダイアログを表示する前に、アプリ独自のカスタムUIで許可の目的・ユーザーへの利点を説明するメッセージです。プレパーミッションを先に見せ、ユーザーが納得した上でOSダイアログを出すことで、許諾率を高める効果があると知られています^*2。

文言が抽象的でユーザーのメリットが伝わっていない

「トラッキングの許可をお願いします」という表現では、ユーザーはメリットを感じにくいです。「パーソナライズされたおすすめを届けるために利用します」のように、ユーザーが受け取る具体的な価値を提示する文言の方が同意を得やすくなります。

プレパーミッション設計：利点提示・タイミング・文言の3つの柱

プレパーミッションを機能させるには、利点の提示・表示タイミング・文言の3点を設計する必要があります。

利点提示：ユーザーが「何を得るか」を前面に出す

ATTのプレパーミッションでは「広告識別子を使うことでユーザーが得る価値」を具体的に伝えます。例えばECアプリであれば「あなたの好みに合わせた商品を優先的に表示します」、ゲームアプリであれば「プレイスタイルに合ったイベント情報をお届けします」のように、プライバシー保護ではなくユーザーへの価値にフォーカスした文言が効果的です^*2。

プッシュ通知のプレパーミッションも同様です。「通知を許可すると何が届くか」を明示することで、ユーザーは許可する・しないの判断をしやすくなります。「セール開始時にお知らせします」「注文状況をリアルタイムで確認できます」のような具体性が重要です。

タイミング：価値を体験した後に表示する

ATTのダイアログを表示する最も避けるべきタイミングは、アプリを初めて起動した直後です。推奨されるタイミングは、ユーザーがアプリの価値を体験した後です。例えばECアプリなら商品の検索・閲覧を一度経験した後、フィットネスアプリなら初回のワークアウト記録が完了した後が挙げられます^*2。

プッシュ通知の場合も同様に、オンボーディングの最初の画面ではなく、ユーザーが「この通知を受け取りたい」と感じる文脈が生まれたタイミングに合わせます。注文完了画面で「配送状況を通知で受け取りますか？」と尋ねる設計は、ユーザーにとって通知の価値が自然に理解できる場面です。

文言：OSダイアログのカスタムテキストと一致させる

iOSのATTダイアログには「NSUserTrackingUsageDescription」で設定したカスタム文言が表示されます^*1。プレパーミッションのメッセージとこのカスタム文言を一貫した内容にすることで、ユーザーが感じる違和感を減らせます。プレパーミッションで「広告に使います」と書いてOSダイアログに「利便性向上のため」と表示されると、ユーザーの不信感につながります。

A/Bテストで許諾率を継続的に高める方法

プレパーミッションの文言・デザイン・タイミングは、A/Bテストで継続的に検証することで許諾率を高めていけます。

A/Bテストで検証すべき変数

一度に複数の要素を変えると何が効いたかわからなくなります。変数を1つずつ変えてテストすることが基本です。検証の対象として有効なのは次の要素です。

• 見出し文言：「通知を許可してください」と「お得な情報をいち早くお届けします」の比較
• ビジュアル：テキストのみと図解・アイコン付きの比較
• 表示タイミング：初回起動後3ステップ目と初回機能使用後の比較
• ボタン配置：「許可する」を上に配置するか下に配置するかの比較

計測指標とサンプルサイズ

A/Bテストで見るべき指標は「プレパーミッションを見た後にOSダイアログで許可を選んだ割合（許諾転換率）」です。サンプルサイズが小さいと統計的に有意な差が出ないため、十分なユーザー数が集まるまで結論を出さないことが大切です。Firebase Remote Config（ファイヤーベース リモートコンフィグ）やA/Bテスト基盤を活用することで、テストの設計・集計を自動化できます。

テスト結果の反映と次のサイクル

テスト結果を踏まえて勝者バリアントを本番適用した後も、ユーザー属性・時期・キャンペーン状況によって最適な文言やタイミングは変わることがあります。定期的に再テストするサイクルを維持することで、許諾率の水準を保てます。

許諾率と計測精度の関係：なぜ許諾率が低いと広告ROASが読めなくなるか

ATTの許諾率が低いと、アプリのマーケティング効果の計測に直接影響します。

IDFAが取得できないユーザーについては、広告クリックからアプリインストール・購買までの経路を追跡する手段が大きく制限されます。広告プラットフォームが提供するROAS（Return On Ad Spend：広告費用対効果）の計算に使えるデータが減るため、どの広告チャネルへの投資が効果的かを判断しにくくなります。

Appleはこの問題に対してSKAdNetwork（エスケーアドネットワーク）という集計ベースの計測フレームワークを提供しています。ただしSKAdNetworkはユーザー単位の追跡ではなく集計データを提供する仕組みのため、詳細なユーザーセグメント別の計測は限定的です。ATTの許諾率を高めることは、広告投資の判断精度を維持するための手段のひとつです。

プッシュ通知の許諾率が低い場合は、休眠ユーザーへの再訪促進に使えるチャネルが失われます。メールや広告でリエンゲージメントを図るには追加のコストがかかります。プッシュ通知は許可されたユーザーへの直接リーチとして費用効率の高いチャネルであるため、許諾率の維持・向上は継続率やLTV（Life Time Value：顧客生涯価値）にも影響します。

外注でATT/プッシュ許諾UXを進める場合の進め方

プレパーミッション設計とA/Bテスト基盤の構築を外注する場合、スコープの定義と担当分けの明確化が手戻りを防ぐ鍵です。

外注前に整理しておくこと

外注先に依頼する前に、以下の点を整理しておくと認識ずれを防げます。

• ATT許諾とプッシュ通知許諾のどちらを先に手を付けるか（両方同時は工数が膨らみやすい）
• プレパーミッションのUIはデザイン込みで依頼するか、文言のみ外注先に渡して実装は内製するか
• A/BテストにFirebase Remote ConfigやAdjustなどのツールを使うか、独自実装とするか
• テスト結果のレポートをどの粒度で受け取り、誰が次の施策を判断するか

発注時に確認すべきこと

外注先を選ぶ際に確認すべきポイントは3点です。第一に、iOSのATT実装（NSUserTrackingUsageDescriptionの設定・AppTrackingTransparencyフレームワークの呼び出し）の実績があるか。第二に、Apple Human Interface Guidelines^*2の通知・プライバシーに関するガイドラインを把握しているか。第三に、A/Bテスト基盤の設計・集計レポートの作成まで一貫して対応できるかです。

プレパーミッションの文言やUI設計はアプリのブランドトーンと密接に関わります。外注先に文言を任せる場合は、ブランドガイドライン・既存の通知文言の例・競合アプリの参考事例をあらかじめ共有することで、戻しが減ります。

内製と外注の比較：スキル要件・工数・リスク

ATT/プッシュ許諾UXの設計・実装・改善を内製で担うか外注するかは、チームのモバイル開発経験・A/Bテスト基盤の有無・改善サイクルの継続性によって判断が変わります。

内製と外注の組み合わせも有効です。ATT・プッシュ通知の初期実装とA/Bテスト基盤の構築を外注し、その後の文言最適化や継続テストは内製チームが担うという進め方で、スキルトランスファーを図りながらコストを抑えられます。

注意点：過度な誘導の禁止とAppleガイドライン遵守

プレパーミッションの設計には、Appleが定めるガイドラインの範囲を守ることが前提条件です。ガイドラインに違反した設計はアプリのリジェクトや削除につながります。

過度な誘導・金品提供は禁止されている

Appleのガイドライン^*2では、トラッキングの許可を条件に報酬・特典・機能のロック解除などのインセンティブを提供することは禁止されています。「許可すればポイントを付与する」「許可しないと一部機能が使えない」といった設計は審査で指摘される対象です。

プレパーミッションが許されるのは「ユーザーに利点を説明する」ことであり、「許可しなければ不利になる」と感じさせる圧力的な表現は避ける必要があります。

プッシュ通知は「通知の価値」を具体的に伝える範囲で説明する

プッシュ通知のプレパーミッションでは、送る通知の内容・頻度を正直に伝えることが大切です。実際に送る通知の内容と乖離したプレパーミッションは、許諾後にユーザーが期待と違うと感じて通知をオフにする原因になります。許諾後の通知体験が期待通りでないと、長期的には通知到達の機会が減ります。

ATTダイアログは欠かさずリクエストする前に設定する

ATT（App Tracking Transparency）を正しく実装するには、IDFAへのアクセスを試みる前に`requestTrackingAuthorization`を呼び出す必要があります^*1。この手順を踏まずにIDFAにアクセスしようとした場合、iOS 14.5以降では0が返ります。実装ミスはデータ欠損につながるため、外注先の実装を発注側でもレビューすることをお勧めします。

まとめ：ATT/プッシュ許諾率を高める3つの判断軸

本稿では許可されない原因の分析からはじまり、ATTとプッシュ通知の違い・プレパーミッション設計の3つの柱・A/Bテストの進め方・外注の進め方・内製との比較・注意点までを整理しました。要点を3つに集約します。

第一に、OSのダイアログを表示するタイミングが許諾率を大きく左右するという点です。初回起動直後を避け、ユーザーがアプリの価値を体験した後にプレパーミッションを挟んでからOSダイアログを表示することが、許諾率を高める設計の基本です^*2。

第二に、プレパーミッションの文言はユーザーが受け取る価値を具体的に伝える内容にすることです。「トラッキングを許可してください」では動機が生まれません。「あなたに合った情報をお届けするために使います」のように、ユーザー目線のメリットを前面に出した文言がAppleのガイドラインの範囲内で有効です。

第三に、外注でUX設計・実装・A/Bテストを進める場合は、スコープと判断基準を発注前に合意しておくことで手戻りを防げます。ATT実装経験の有無・Appleガイドラインへの理解・テスト結果レポートの粒度を確認した上で外注先を選ぶことが、リジェクトリスクを低減する準備になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Apple「Requesting Authorization to Track — App Tracking Transparency」
2. *2　出典：Apple「Human Interface Guidelines — Notifications / Privacy」

Tweet