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

ユーザーにプッシュ許可を求めるチャンスは一度しかないため、プッシュ登録を最適化することは、プッシュメッセージのリーチを最大化するために極めて重要である。これを実現するには、アプリ内メッセージを使って、ユーザーがオプトインを選択した場合、どのようなメッセージを受け取ることが期待できるかを、ネイティブのプッシュプロンプトを表示する前に説明すればよい。これはプッシュ・プライマーと呼ばれる。
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つドラッグする。これらがアプリ内メッセージのメインボタンとサブボタンとして機能する。また、メッセージに行をドラッグし、ボタンを行にドラッグして、ボタンが同じ水平の行にあるようにすることもできます(上下に重なっているのとは対照的です)。初期設定のボタンとして「通知を許可」と「今はしない」を推奨するが、割り当てられるボタンプロンプトは他にも多数存在する。
ボタンコピーを追加したら、各ボタンのクリック時の動作を指定する:
- ボタン 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
ユーザーは二つのデバイスを持っている。
- デバイス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
ユーザーは三つのデバイスを持っている:
- デバイス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はメッセージを表示する特定の端末上でプッシュトークンのステータスを検知できるため、複数の端末を持つユーザーを除外する可能性のあるプロファイルレベルのセグメンテーションフィルターに依存する必要はない。
考慮事項
ノーコードプッシュの入門書が必要だ:自動抑制を機能させるには、ノーコードプッシュプライマーを使用しなければならない。「プッシュ許可をリクエスト」ボタンアクションの代わりにカスタムロジックやディープリンクを設定した場合、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は、ユーザープロファイルではなく、メッセージが表示されているデバイスだけを見る。その端末では、アクティブなforeground_push_enabledフォアグラウンドプッシュトークンが存在trueする場合に設定され、オペレーティングシステムがプッシュ通知が無効化されたとレポートした場合(例えばユーザーが明示的にオフfalseにした場合)に設定される。まだプッシュ許可状態に応答したことのない全く新しいデバイスでは、foreground_push_enabledこの値は設定されておらず、値を持たない。Liquid状態は特に明示的なオプトアウトがある```false`デバイスに対してのみプライマーを抑制する。一方、この不明な状態にあるデバイスは依然として対象となり、プッシュプライマーを受け取ることができる。
ステップ 6: コンバージョンイベント
Brazeは、コンバージョンのデフォルト設定を提案しているが、プッシュ・プライマーを取り巻くコンバージョンイベントを設定したい場合もあるだろう。
GitHub でこのページを編集