概要 - プッシュ許可
プッシュ通知の許可は、アプリがユーザーのデバイスで取得するアプリレベルの権限です。この権限は、ユーザーの通知トレイにプッシュ通知を表示するために必要です。この許可がオフにされている場合、あなたが送信する通知はユーザーには表示されません。通知は静かにバックグラウンドであなたのアプリに配信されます。
プッシュ通知の許可はどのように機能しますか?
Android 12およびそれ以前のバージョンでは、アプリは自動的に通知を送信する権限が付与されますが、Android 13およびそれ以降のOSバージョンでは、アプリが通知を送信する前にユーザーからの権限を要求する必要があります。
- Android 12 またはそれ以下のOSバージョンのデバイス : アプリは自動的に通知を送信する許可が与えられます。これは、ユーザーがアプリに通知を送信するための明示的な許可を与える必要がなく、デフォルトでオプトインされていることを意味します。
-
Android 13 以上のOSバージョンのデバイス
- プッシュ通知の許可は、ユーザーが通知を送信する前にアプリがユーザーからの許可を要求する必要があるAndroid 13の新機能です。ユーザーがAndroid 13以上のデバイスにアプリをインストールすると、ユーザーが許可を与えるまでアプリは通知を送信できません。
Androidは、ユーザーがプッシュ許可を与えるためのランタイム許可を導入しました
- ユーザーが許可を与えた場合、アプリはユーザーに通知を送信できるようになります。
- ユーザーが許可を拒否または無視した場合、アプリはユーザーに通知を送信できなくなります。
この画像は、アプリ(Trip Planner)がユーザーからプッシュ許可をどのように要求するかを示しています。
ユーザーは、古いAndroidバージョンと同様に、アプリの通知設定に移動して許可を変更することもできます。
さまざまなAndroidバージョンでのプッシュ通知の権限の仕組みは次のとおりです:
Android 13以上を対象とするアプリは、この権限がどのように機能するかをより高く制御できます。
以下は、Android 13 互換モードでプッシュ通知の権限がどのように機能するかです:
- アプリは、ユーザーに許可を付与するためのプロンプトが表示されるタイミングと場所を制御できます。
- ユーザーが許可を与えた場合、アプリはユーザーに通知を送信できるようになります。
- ユーザーが権限を拒否または無視した場合、アプリはユーザーに通知を送信できなくなります。
- ユーザーが明示的に権限を2回拒否した場合、ユーザーがアプリを再インストールしない限り、アプリは再度ユーザーにプロンプトを表示できなくなります。
| info |
情報 Google PlayのターゲットAPIレベル要件に従い、2023年8月31日以降:
|
Android 13で互換モード(Android 12またはそれ以下を対象)で実行されるアプリは、通知のための権限を要求しますが、アプリが最初の通知チャネルを作成するときに、ユーザーに権限を付与するように促されます ()
Android 13 互換モードでのプッシュ通知の許可の仕組みは次のとおりです:
- アプリが初めて通知チャンネルを作成すると、ユーザーに権限を付与するよう求められます。
- ユーザーが許可を与えた場合、アプリはユーザーに通知を送信できるようになります。
- ユーザーが権限を拒否または無視した場合、アプリはユーザーに通知を送信できなくなります。これ以降、ユーザーがアプリを再インストールしない限り、再度プロンプトは表示されません。
この権限は、再インストールやデータのクリア時にリセットされます。この権限は、1つの例外を除いて、OSのアップグレード時に保持されます。ユーザーがデバイスをAndroid 12からAndroid 13にアップグレードするとき:
- アプリがAndroid 12で権限を持っていなかった場合、Android 13にアップグレードすると、ユーザーが権限を付与するまでアプリは通知を送信できなくなります。
- アプリがAndroid 12で権限を持っていた場合、Android 13にアップグレード後、アプリはアップグレード後にユーザーが最初にアプリを開くまでの間、保持される一時的な付与を通じて通知を送信できるようになります。ユーザーがアプリを開くと、権限がリセットされ、ユーザーが権限を付与するまでアプリは通知を送信できません。
プッシュ通知の権限を追跡する
Androidがプッシュ通知のオプトイン/オプトアウトトラッキングを有効にするには、MoEngage Core SDKバージョン12.3.01以上にアップグレードしてください。MoEngage SDKは、デフォルトでデバイスのオプトインステータスを追跡します。ユーザーのデバイスのオプトインステータスは、「Reachability Push Android」ユーザー属性によって追跡されます。
ユーザーレベルでのプッシュ許可ステータスの追跡
| リーチ可能性プッシュAndroid属性値 | 到達可能性の説明 |
|---|---|
| 202 - オプトアウトのため到達不可 |
これは、プッシュ通知の受信をオプトアウトしたすべてのAndroidデバイスで利用可能なユーザーの到達可能性の値です。 これらのユーザーはもはや接触可能とは見なされず、キャンペーンの対象にはなりません。 |
| 201 - アクセス可能でオプトイン済み | これは、少なくとも1つのAndroidデバイスでプッシュ通知を受け取ることに同意したユーザーの到達可能性の値です。 |
| 200 - 到達可能でオプトインのステータス不明 |
これは、オプトイン/オプトアウトの設定が追跡されていないユーザーの到達可能性の値です。これらのユーザーは古いSDKバージョンを使用しています。これらのユーザーは到達可能と見なされ、プッシュ通知の送信が試みられますが、これらのユーザーの中にはオプトアウトしている場合があり、通知を見ることができません。 オプトイン/オプトアウトトラッキングは、MoEngage Core SDK バージョン 12.3.01 以上でサポートされています。 |
ユーザーレベルでのプッシュ権限の変更を追跡する
以下はAndroidプッシュ権限変更に関するイベントです:
| 名前 | 説明 | プラットフォーム |
|---|---|---|
| プッシュに登録しました | プッシュ通知にユーザーが登録したときに追跡されます。 | Android |
| プッシュの購読を解除しました |
デバイスのプッシュ許可を「サブスクライブ」から「サブスクライブ解除」に変更したときに追跡されます 注意: このイベントは、デフォルトで権限が拒否されているデバイスでは生成されません。 |
Android |
| info |
情報 これらのイベントは、デバイスのオプトインステータスが変更されたとき、またはユーザーが明示的に許可を確認したときにのみ生成されます。デバイスのデフォルト状態は、プッシュイベントへのサブスクライブ/アンインサブスクライブをトリガーしません。 例 - Android 12 およびそれ以下のデバイスでは、デバイスはデフォルトでオプトインされています。これはプッシュイベントの購読をトリガーしません。Android 13では、ユーザーはデフォルトでオプトアウトされており、プッシュイベントへの「未購読」トリガーは発生しません。ただし、ネイティブプロンプトを介してユーザーにプッシュ許可をリクエストし、ユーザーが許可をブロックした場合、プッシュイベントへの登録解除が行われます。 |
プッシュ通知許可の傾向を時間をかけて追跡する
MoEngageのリーチビリティダッシュボードは、プッシュ通知を受け取ることに同意したすべてのユーザーと、同意していないユーザーのリーチビリティトレンドを表示します。 到達可能性ダッシュボード には、 ダッシュボード > 到達可能性 に移動することでアクセスできます。
詳細については、 プッシュ到達可能性ダッシュボード を参照してください。
Android 13ユーザーのオプトイン率の追跡
ユーザーは複数のデバイスを持っているため、特定のOSバージョンのデータは利用できません。
過去60日間にアプリでアクティブなユーザーのオプトイン率を追跡する手順は以下に示されています。
- Analytics -> Behavior に移動します MoEngage ダッシュボードで。
- 「 イベントとフィルター 」セクションで、 アプリ/サイトが開かれた イベントを実行し、 OSバージョン が 33 であるユーザーを選択します。
- In the フィルターユーザー セクションで、ユーザーをフィルタリングするオプションを選択します。
- ユーザー プロパティ リーチャビリティ プッシュ Android のフィルター条件を次のように選択してください [201-到達可能でオプトイン、202-到達可能だがオプトアウト] 。
- In the Behavior Options 、choose the Analysis type as Unique users 、Compare by as Reachability Push Android 、and the Duration as last 2 months 。
-
「
円グラフの視覚化
」を「
行動チャート
」セクションで選択します。選択したフィルター条件のサンプル画像は以下に示されています。201を比率とするユーザーの割合は、Android 13ユーザーのみのオプトイン率を示す必要があります。他のOSバージョンのユーザーに対するオプトイン率を取得するために、クエリを変更できます。
オプトイン率の向上
この機能の追加のコントロールと柔軟性を享受するために、できるだけ早くAndroid 13以上をターゲットにすることを強くお勧めします。12L(APIレベル32)またはそれ以下をターゲットにし続けると、アプリの機能に関連する権限の要求に関して柔軟性が失われます。
オプトイン方法
ユーザーからオプトインを取得するためのさまざまな方法は次のとおりです:
ダブルオプトインまたは二段階オプトインは、ユーザーの許可を二段階で求めることを含みます。最初にコンテキストを設定し、その後ユーザーを通知設定に移動させて、アプリからのプッシュ通知を有効にします。二段階オプトインの前提条件とキャンペーン設定については、以下に説明します。
二段階オプトインの前提条件
Moengage SDK 12.6.00以上およびInAppバージョン6.5.0以上でアプリ内通知を統合します。コアSDKの互換バージョンについては、 リリースノート を参照してください。
事前許可メッセージ
アプリ内通知を使用すると、ユーザーにプッシュ通知を許可する理由を説明する事前許可メッセージを作成できます。ユーザーが明示的に許可を2回拒否した場合、Androidネイティブプッシュプロンプトをトリガーできないため、この方法はAndroidネイティブプッシュプロンプトを不必要に表示するのを避けるのにも役立ち、再度ユーザーにアプローチすることができます。
二段階オプトインプロンプトを表示するためのキャンペーン設定
アクション
-
通知の許可をリクエストします
ユーザーが資格を持っている場合、このアクションはAndroidのネイティブ通知許可をトリガーします。ユーザーがすでにプロンプトを複数回拒否したか、OSのバージョンが低いために資格がない場合、ユーザーはアプリケーションの通知設定画面にリダイレクトされ、そこで通知の許可を管理できます。 -
通知設定に移動
この操作は、ユーザーをアプリケーションの通知設定画面に移動させ、ユーザーが通知の許可を管理できるようにします。
セグメンテーション
特定のユーザーセグメントを除外する必要がない限り、セグメンテーション条件として「すべてのユーザー」を使用することをお勧めします。Moegnageは以下のケースを自動的に管理します:
-
無関係なユーザー
上記のアクションのいずれかを含むアプリ内通知について、Moengageは無関係なユーザーを自動的にフィルタリングします。例:
- すでにオプトインしているユーザー
- オプトイン許可アクションがサポートされていない古いSDKバージョンを使用しているユーザー
-
Android 12 またはそれ以下のユーザー
これらのアクションは、OS バージョンに基づいてオプトアウトしたユーザーに対して適切な動作を自動的に選択します。Android 12 またはそれ以下のユーザーは、通知の権限を管理できるアプリケーション通知設定画面に移動します。
優先順位
上記のアクションを含むキャンペーンは、自動的にクリティカル機能優先度に設定され、同じトリガー条件を持つ他のキャンペーンよりも優先されます。
最小遅延
数日ごとにユーザーに通知するために最小遅延を追加することを選択できます。すべてのセッションで許可を求める代わりに。
A single-step or one-step opt-in process involves asking for the user’s permission for the app to send Push notifications directly using the prompt to grant permission.これを使用して、ビジネスロジックに基づいてユーザージャーニーの重要なポイントで権限をトリガーできます。MoEngage SDKは、ユーザーにAndroidの権限リクエストを表示する ヘルパーAPI を提供したり、ユーザーを通知設定に移動させたりします。詳細については、 Notification-Runtime-Permissions を参照してください。
自己管理型オプトインでは、開発者は他のランタイムパーミッションと同様に、 Android通知権限 のプロンプトを直接呼び出すことができます。このメソッドを呼び出すと、ユーザーに通知プロンプトが表示されます。ユーザーが権限プロンプトを2回拒否した場合は、表示されません。 通知カウントをSDKに通知する ことを確認してください。他のメソッドが正常に機能するために必要です。
自己管理型オプトインの実装に自信がない限り、代わりにワンステップオプトインを方法として使用することをお勧めします。これは、ユーザーに表示される許可の回数を追跡し、呼び出されたときに次のアクションを暗黙的に理解します。
推奨戦略
ユーザーにプッシュ通知を送信する許可を求めるために、以下に示すいずれかの方法を使用できます。プッシュ通知の最適なユーザー数を得るために実装できるいくつかの推奨戦略があります。
| ターゲットオーディエンス |
プッシュ通知をエンゲージメントチャネルとして大いに依存するアプリ。 |
| 実装 |
次の実装を使用してください:
|
| 初期データからの洞察 |
いくつかのアプリに対して、これが最高のオプトイン率をもたらすことが確認されました。ただし、これはユーザーをイライラさせる傾向があり、アンインストールにつながることがあります。また、フォローアップキャンペーンのパフォーマンスも悪くなります。なぜなら、ユーザーはプッシュ通知の許可を与えるために設定に行かなければならないからです。 |
| ターゲットオーディエンス |
ユーザーが権限についてあまり敏感でないアプリ。 |
| 例 |
この戦略が適用できるいくつかの例は次のとおりです: このフローでは、あなたは次のものを得ることができます:
|
| 実装 |
以下の実装を使用してください:
|
| 初期データからの洞察 |
我々は、ユーザーの30〜60%が、理由の有無にかかわらず、最初のセッションでプッシュプロンプトを受け入れることを観察しました。 |
| ターゲットオーディエンス |
ユーザーが権限を与えることに敏感で、オプトインの理由を求めるアプリ。 |
| 例 |
この戦略が適用できる例は次のとおりです: ユーザーはホームページにアクセスし、2ステップのオプトインプッシュを見ます |
| 実装 |
次の実装を使用してください:
|
| 初期データからの洞察 |
私たちは、ユーザーの30-60%が理由の有無にかかわらず、最初のセッションでプッシュプロンプトを受け入れることを観察しました。 |
| ターゲットオーディエンス |
機能的な利用ケースのためにオプトインしたユーザーのみがプッシュ通知を使用するアプリ。 |
| 例 |
以下は、この戦略が適用できるいくつかの例です:
|
| 実装 |
以下の実装を使用してください: ユースケースベース : これはトリガーベースの 二段階のオプトインキャンペーン です。例えば、「チェックアウト完了」イベント、サンキュー画面、今後のイベント画面、そして「プログラムに登録しました」イベントなど、特定のイベントでトリガーされるアプリ内キャンペーンを設定することができます。お好みのイベントに基づいてイベントトリガーを選択し、セグメンテーション基準をすべてのユーザーとして追加できます。 |
| 初期データからの洞察 |
このことは、ユースケースのアクションを実行するユーザーにのみ連絡を取るため、低いオプトイン率につながることがわかりました。 |