アプリ内メッセージのプッシュプライマー

ユーザーにプッシュ許可を求めるチャンスは一度しかないため、プッシュ登録を最適化することは、プッシュメッセージのリーチを最大化するために極めて重要である。これを実現するには、アプリ内メッセージを使って、ユーザーがオプトインを選択した場合、どのようなメッセージを受け取ることが期待できるかを、ネイティブのプッシュプロンプトを表示する前に説明すればよい。これはプッシュ・プライマーと呼ばれる。
Braze でプッシュプライマーのアプリ内メッセージを作成するには、iOS、Android、または Web のアプリ内メッセージを作成するときに、ボタンのクリック時動作「プッシュ通知の権限を要求」を使用できます。
前提条件
この機能にはボタンのクリック時動作が必要です。これは、以下の最小バージョン以降でサポートされています。
さらに、以下で説明するプラットフォーム固有の詳細に注意してください。
| OS バージョン | 追加情報 |
| |———- | ———————- |
| Android 12 以前 | プッシュプライマーの実装は推奨されません。プッシュはデフォルトでオプトインされているためです。 |
| Android 13+ | ユーザーがプッシュアクセス許可プロンプトを2回拒否した場合、Android は Braze プッシュプライマーメッセージを含むそれ以降のプロンプトをブロックします。この後に権限を付与するには、ユーザーはデバイス設定でアプリのプッシュを手動で有効にする必要があります。 |
一般情報
- プッシュプロンプトは、オペレーティングシステムによって強制されるインストールごとに1 回のみ表示できます。
- アプリのプッシュ設定が明示的にオンまたはオフの場合、プロンプトは表示されない。仮承認のユーザーに対してのみ表示される。
- アプリのプッシュ設定がオンになっている:ユーザーはすでにオプトインしているため、Brazeはアプリ内メッセージを表示しない。
- アプリのプッシュ設定がオフ:ユーザーをデバイス設定内のアプリのプッシュ通知設定にリダイレクトする必要がある。
手動でコードを除去する
このチュートリアルを使って設定したアプリ内メッセージは、ユーザーがアプリ内メッセージボタンをクリックすると、ネイティブのプッシュプロンプトコードを自動的に呼び出す。プッシュ通知の許可を 2 回要求したり、間違った時間に要求したりしないようにするには、開発者は、実装されている既存のプッシュ通知統合を変更して、アプリ内メッセージがユーザーに表示される最初のプッシュ通知プライマーであることを確認する必要があります。
開発者は、アプリやサイトのプッシュ通知の実装を見直し、プッシュ権限を要求するコードを手動で削除すべきである。例えば、以下のコードへの参照を削除する:
1
requestAuthorizationWithOptions
1
requestAuthorization
1
2
3
braze.requestPushPermission()
// or
appboy.registerAppboyPushMessages()
1
android.permission.POST_NOTIFICATIONS
ステップ 1:アプリ内メッセージを作成する
まず、アプリ内メッセージを作成し、メッセージタイプとレイアウトを選択します。
メッセージとボタンの両方に十分なスペースを確保するには、フルスクリーンまたはモーダルメッセージレイアウトを使用します。全画面を選択した場合は、画像が必要であることに注意してください。
ステップ 2:メッセージを構築する
さて、いよいよコピーを加える番だ!ここで、プッシュプライマーは、プッシュ通知をオンにするようにユーザーをプライミングする必要があることに注意してください。メッセージ本文では、ユーザーがプッシュ通知をオンにすべき理由を強調することをお勧めする。どのような種類の通知を送りたいのか、どのような価値を提供できるのか、具体的に説明すること。
例えば、あるニュースアプリは次のようなプッシュ・プライマーを使うかもしれない:
1
Breaking news on the go! Enable push notifications to get alerts for major stories and topics that matter to you.
ストリーミングアプリでは、次が使用される場合があります。
1
Get push notifications from Movie Cannon? Notifications may include new movies, TV shows, or other notices and can be turned off at any time.
ベストプラクティスおよびその他のリソースについては、カスタムオプトインプロンプトの作成を参照してください。
ステップ 3:ボタン動作を指定する
アプリ内メッセージにボタンを追加するには、2つのButtonブロックをメッセージにドラッグし、アプリ内メッセージのプライマリボタンとセカンダリボタンとして使用する。また、メッセージに行をドラッグし、ボタンを行にドラッグして、ボタンが同じ水平の行にあるようにすることもできます(上下に重なっているのとは対照的です)。通知を許可する」と「今は許可しない」をスターターボタンとしてお勧めするが、割り当て可能なボタンのプロンプトはたくさんある。
ボタンコピーを追加したら、各ボタンのクリック時の動作を指定する:
- ボタン 1:これを「メッセージを閉じる」に設定します。これはセカンダリーボタンで「今は許可しない」オプションです。
- **ボタン 2: **これを「プッシュ通知の権限を要求」に設定します。これはプライマリボタンで「通知を許可する」オプションです。

ステップ 4: 配信のスケジュール
プッシュプライマーを適切な時間に送信するように設定するには、アプリ内メッセージをアクションベースのメッセージとしてスケジュールし、トリガーアクションとしてカスタムイベントを実行する必要がある。
理想的なタイミングはさまざまだが、Brazeは、ユーザーが何らかの価値の高いアクションを完了するまで待つことを提案している。これは、ユーザーがアプリやサイトに価値を見出し始めていることを示すか、プッシュ通知で対応できる切実なニーズがある場合だ(例えば、ユーザーが注文をした後で、配送追跡情報を提供したい場合など)。こうすることで、プロンプトはあなたのブランドにとってだけでなく、顧客にとっても有益なものとなる。

ステップ 5: ユーザーのターゲット設定
プッシュプライマーキャンペーンの目的は、ユーザーがまだプッシュ権限を付与していないデバイスに、プッシュを促すことである。これには、初めてのユーザーや、新しいデバイスを手に入れたりアプリケーションを再インストールした既存ユーザーも含まれる。
コードレス・プッシュ・プライマーによる自動抑制:コードなしのプッシュプライマー(「プッシュアクションボタンの権限を要求する」アクション)を使用する場合、プッシュサブスクリプションフィルターをセグメンテーションに追加する必要はない。SDKは、すでにアクティブなプッシュトークンを持っているデバイスでは、他のデバイスでのユーザーのプッシュステータスに関係なく、アプリ内メッセージを自動的に抑制する。複数のデバイスを持つユーザーをターゲットにする方法の詳細については、複数のデバイスを持つユーザーをターゲットにするを参照のこと。
コードなしのプッシュ・プライマーを使用していない場合は、フィルターを追加する。Foreground Push Enabled For App is false 。このフィルターは、まだフォアグラウンドプッシュ通知にオプトインしていない個々のアプリのインストールを識別する。
Push Subscription Status is not Opted In のようなユーザーレベルのフィルターを使用すると、別のデバイスですでにオプトインしているユーザーが除外され、新しいデバイスでプロンプトを受け取れなくなる。
そのうえで、どのような追加セグメントが最も適切だと感じるかを決めることができます。例えば、2回目の購入を完了したユーザー、会員になるためにアカウントを作成したばかりのユーザー、あるいは週に2回以上アプリを訪れるユーザーなどをターゲットにすることができる。これらの重要なセグメントでユーザーをターゲティングすることで、ユーザーがオプトインし、プッシュを有効にする可能性が高くなります。
複数のデバイスを持つユーザーをターゲットにする
Brazeはユーザーデータをデバイスレベルではなくプロファイルレベルで取得するため、複数のデバイスを所有するユーザーをターゲットにすることは困難である。セグメンテーションのプッシュサブスクリプションフィルターは、特定のターゲッ トデバイスのサブスクリプション状態ではなく、単一のデバイスのサブスクリプ ション状態に基づいて、ユーザーを含めたり除外したりする。さらに、iOSの暫定状態は、これらのデバイスが技術的にはフォアグラウンド・プッシュトークンを持っているが、ユーザーが明示的にオプトインしていないため、複雑さを増している。
プッシュサブスクリプションフィルターの問題点
ユーザーが異なるプッシュサブスクリプションステートを持つ複数のデバイスを持っている場合、セグメンテーションのプッシュサブスクリプションフィルターは、いくつかのデバイスをターゲットにすることができないかもしれない。こんなシナリオを考えてみよう:
Scenario 1: User has two devices on different platforms
ユーザーは2つのデバイスを持っている:
- 装置A:Androidでは、プッシュを選択した。
- デバイスB:iOS、プッシュにオプトインしていない
機能しないセグメンテーションフィルター:
Push enabled = false- ユーザーはAndroid端末でプッシュをイネーブルメントにしているため、セグメンテーションには該当しない。セグメンテーションにはiOSデバイスは含まれていない。Push subscription status is not opted in- ユーザーはAndroid端末でプッシュをイネーブルメントにしているため、セグメンテーションには該当しない。セグメンテーションにはiOSデバイスは含まれていない。
機能するセグメンテーションフィルター:
Push enabled for iOS = false- ユーザーはAndroidデバイスでプッシュをイネーブルメントにしているが、我々はiOSデバイスのみをターゲットにしているため、ユーザーはセグメンテーションに該当する。セグメンテーションにはiOSデバイスも含まれる。
Scenario 2: User has two iOS devices with different states
ユーザーは2台のiOSデバイスを持っている:
- 装置A:プッシュする
- 装置B:暫定的にイネーブルメントは有効だが、オプトインはしていない
機能しないセグメンテーションフィルター:
Push enabled = false- デバイスAはプッシュにオプトインされているので、ユーザーはセグメンテーションに落ちない。セグメンテーションにはデバイスBは含まれていない。Provisionally opted in = true- デバイスAは完全にオプトインされており、暫定的な状態ではない。ユーザーはセグメンテーションに入らない。セグメンテーションにはデバイスBは含まれていない。Push enabled for app > iOS = false- デバイスAはiOSでプッシュをオプトインしているため、ユーザーはセグメンテーションに該当しない。セグメンテーションにはデバイスBは含まれていない。Push subscription status is not opted in- デバイスAはプッシュにオプトインされているので、ユーザーはセグメンテーションに落ちない。セグメンテーションにはデバイスBは含まれていない。
結果:これらのプッシュフィルターを組み合わせて使用すると、セグメンテーションは少なくとも1つのデバイスを除外することになる。
Scenario 3: User has three or more devices on the same OS
ユーザーは3つのデバイスを持っている:
- 装置A:プッシュする
- 装置B:プッシュするようオプトインしていない
- デバイスC:プッシュするようオプトインしていない
機能しないセグメンテーションフィルター:
Push enabled = false- デバイスAはプッシュにオプトインされているので、ユーザーはセグメンテーションに落ちない。セグメンテーションには、デバイスBとCは含まれていない。Push enabled for app > X = false- デバイスAは指定されたアプリでプッシュするようオプトインされているため、ユーザーはセグメンテーションに該当しない。セグメンテーションには、デバイスBとCは含まれていない。Push subscription status is not opted in- デバイスAはプッシュにオプトインされているので、ユーザーはセグメンテーションに落ちない。セグメンテーションには、デバイスBとCは含まれていない。
結果:これらのプッシュフィルターを組み合わせると、少なくとも1台はターゲットから外れることになる。
ソリューション:コードなしのプッシュ・プライマーを使う
推奨されるソリューションは、プッシュステータスのセグメンテーションフィルターを追加せずに、コードなしのプッシュプライマー(「プッシュ許可のリクエスト」ボタンアクション)を使用することである。
自動抑制だ:コードなしのプッシュトークンプライマーは、すでにアクティブなプッシュトークンを持っているデバイスでは自動的に抑制される。SDKは、特定のデバイスのユーザーがすでにプッシュトークンを持っているかどうかをチェックする。SDKは、ユーザーがすでにオプトイン済みであることを発見した場合(例えば、以前のリクエストやデバイス設定から)、追加のセグメンテーションフィルターを必要とせずに、アプリ内メッセージを自動的に抑制する。プライマーは、ユーザーがプッシュを暫定的にオプトインしている場合も含め、他のすべてのシナリオで表示される。
コードなしのプッシュプライマーを使用する利点は、その機能がBraze SDKによってサポートされていることである。SDKは、メッセージを表示する特定のデバイスのプッシュトークンのステータスを検出できるため、複数のデバイスを持つユーザーを除外する可能性のあるプロファイルレベルのセグメンテーションフィルターに依存する必要はない。
考慮事項
コードプッシュ・プライマーは必要ない:自動抑制を機能させるには、コードなしのプッシュ・プライマーを使用しなければならない。Request Push Permission “ボタンアクションの代わりにカスタムロジックやディープリンクを設定した場合、SDKはプッシュプライマーを表示しようとしていることを識別できない。この結果、そのデバイスのサブスクリプション状態に関係なく、メッセージが表示される。
オプトアウトしたユーザーを抑制する:明示的にプッシュをオプトアウトしたユーザー(例えば、ネイティブリクエストやデバイス設定から)にはアプリ内メッセージを抑制し、それらのユーザーを別のナーチャリングキャンペーンでリターゲティングしたい場合がある。そのためには、以下のLiquidロジックをノーコードプライマーと組み合わせて使用する:
1
2
3
4
{% if targeted_device.${foreground_push_enabled} == false %}
{% abort_message('user turned off push notifications') %}
{% endif %}
- message goes here -
targeted_device Liquidフィルターは、ユーザープロファイルではなく、メッセージが表示されているデバイスのみを見ている。そのデバイス上で、foreground_push_enabled は、アクティブなフォアグラウンド・プッシュトークンがあるときはtrue に設定され、オペレーティングシステムがプッシュ通知が無効になった(例えば、ユーザーが明示的にオフにした)とレポートしたときはfalse に設定される。まだプッシュ権限状態に応答していないまったく新しいデバイスの場合、foreground_push_enabled は設定されておらず、何の値も持たない。Liquidの条件は、```false` を特にチェックするため、明示的にオプトアウトしているデバイスに対してのみ、プライマーを抑制する。
ステップ 6:コンバージョンイベント
Brazeは、コンバージョンのデフォルト設定を提案しているが、プッシュ・プライマーを取り巻くコンバージョンイベントを設定したい場合もあるだろう。
GitHub でこのページを編集