プッシュ通知をContent Cardsのメッセージ受信トレイに保持する
通知を閉じた後も、重要なプッシュの内容を確認できるようにします。対応するContent Cardをカスタムのアプリ内メッセージ受信トレイに送信し、キーと値のペアで受信トレイをフィルターします。
この例について
架空のモバイルバンキングブランドであるPyrite Financialは、Braze でプッシュ通知の送信を始めようとしています。消費者がプッシュ通知を閉じると、そのメッセージはデバイスの UI から消えてしまいます。
マーケティングチームとプロダクトチームは、消費者がアプリ内のベルアイコンから永続的なメッセージ受信トレイを開けるようにしたいと考えています。消費者は受信トレイで、書類の準備完了アラート、取引通知、計画メンテナンスのメッセージを再度開くことができます。
同社はすでにアプリの別の場所 (記事など) でContent Cardsを使用しています。このパターンでは、2 つ目のContent Cardsの配置としてメッセージ受信トレイを追加します。この受信トレイでは次のものを受け取ることができます。
- プッシュ通知のみ
- Content Cardのみ
- プッシュ通知と対応するContent Cardの両方
プッシュ通知のタップとContent Cardのタップは、同じ遷移先 (書類画面など) にディープリンクできます。一部のプッシュメッセージでは、タップすると受信トレイ自体が開きます。
この例では、プッシュ通知とContent Cardsの配信を連携させる方法を紹介します。SDK でカスタム受信トレイのUIを構築する方法については、チュートリアル: Content Cardsの受信トレイを参照してください。カードのレイアウトの詳細については、カスタムContent Cardsの作成を参照してください。
考慮事項
- Content Cardsは送信後最大 30 日間利用できます。Content Cardsは、閉じたカードを含め、ユーザーごとのフィード上限である有効期限内のカード 250 枚にカウントされます。各カードのペイロードは、Liquidのレンダリング後に 2 KB までに制限されます。Content Cardを作成するを参照してください。
- アプリの他の場所ですでにContent Cardsを使用している場合は、キーと値のペア (例:
feed_type: inboxとfeed_type: article) を使用して配置を分けます。これにより、各画面にはそれぞれのカードのみが表示されます。アプリでフィルターするまで、すべてのカードは 1 つの SDK フィードを共有します。Content Cardsのフィードのカスタマイズを参照してください。 - Content Cardsはセッション開始時に自動的に更新されます。追加の更新には
requestContentCardsRefreshを使用します。受信トレイを開いたときや、プルして更新したときに更新してください。更新のレート制限に達しないよう、継続的な更新やタブ切り替えのたびの更新は避けてください。 - カスタム受信トレイのUIでは、インプレッション、クリック、閉じる操作を手動でログに記録する必要があります。未読バッジ (ベルアイコン上のドットなど) はアプリ側で管理します。
- 受信トレイに保持するプッシュ通知には、それぞれ対応するContent Cardが必要です。正しいキーと値のペアとディープリンクを含めてください。Content Cards チャネルが常に含まれるよう、マルチチャネルのキャンペーンテンプレートまたはキャンバステンプレートを使用してください。
- フォローアップのロジックなしでプッシュ通知とContent Cardを同時に送信する場合は、マルチチャネルキャンペーンを使用します。遅延、分岐、再エンゲージメント、またはエンゲージメントに基づく後続のステップが必要な場合は、キャンバスを使用します。
設定
ステップ 1: 受信トレイのキーと値のペアとディープリンクを定義する
アプリが受信トレイのカードをフィルターして処理するために使用する extras (キーと値のペア) を決めます。次の表は設定例です。
| キー | 値の例 | 目的 |
|---|---|---|
feed_type |
inbox |
カードをメッセージ受信トレイに含める (他のフィードからは除外する) |
message_type |
document, outage, transaction |
受信トレイ UI でのグループ化やスタイル設定 (任意) |
doc_id |
12345 |
消費者がその書類を開いたときにアプリがカードを閉じられるようにする ID (任意) |
ユースケースごとにディープリンクの遷移先を決めます。次の表は遷移先の例です。
| ユースケース | プッシュ通知のディープリンク | Content Cardのディープリンク |
|---|---|---|
| 新しい書類または取引 | 書類画面または取引画面 | 同じ遷移先 |
| 計画メンテナンス | メッセージ受信トレイ | 受信トレイのカード詳細またはステータスページ |
開発チームに、これらのキーに基づくフィルタリング、未読状態 (任意)、分析の実装を依頼してください。受信トレイ用のすべての Content Card で同じキーを再利用します。
ステップ 2: マルチチャネルキャンペーンまたはキャンバスを選択する
カスタマージャーニーに応じて、マルチチャネルキャンペーンまたはキャンバスを選択します。次の表で 2 つの方法を比較します。
| 状況 | 推奨される方法 |
|---|---|
| フォローアップのない 1 回限りまたはスケジュールされたお知らせ (例: 計画メンテナンス) | プッシュ通知とContent Cardsを含むマルチチャネルキャンペーン |
| フォローアップの可能性があるイベントトリガー型のジャーニー (例: 書類の準備完了後、未読の場合にリマインド) | プッシュ通知とContent Cardsを含むメッセージステップを使ったキャンバス |
このパターンの例については、キャンバスでの Content Cards — プッシュ通知の受信トレイを参照してください。
ステップ 3: メッセージ配信を設定する
マルチチャネルキャンペーン
- メッセージング > キャンペーンに移動し、キャンペーンを作成を選択してから、マルチチャネルを選択します。
- 作成ステップでチャネルを追加を選択し、プッシュとContent Cardsを追加します。
- プッシュ通知を作成します。クリック時の動作で、ディープリンクを受信トレイまたは別のアプリ内の遷移先に設定します。
- 一致する、または補完する内容でContent Cardを作成します。設定タブで新しいペアを追加を選択し、ステップ 1 で決めた受信トレイのキーと値のペアを追加します。Content Cardのディープリンクを設定します。
- 新しい書類などのイベントには、アクションベースの配信をスケジュールします。計画メンテナンスにはスケジュールされた配信を使用します。オーディエンスを定義します。
- 今後の受信トレイ連携型のプッシュキャンペーンにも Content Cards チャネルと同じ
extrasが含まれるよう、テンプレートまたはチェックリストを保存します。
キャンバス
- メッセージング > キャンバスに移動し、キャンバスを作成を選択します。ジャーニーのエントリスケジュールとオーディエンスを設定します (例: 書類の準備が完了したときのカスタムイベント)。
- プッシュとContent Cardsの両方を含むメッセージステップを追加します。フローで必要な場合は、連続したメッセージステップを使用します。
- キャンペーンの場合と同じ方法で、ディープリンクと受信トレイのキーと値のペアを含めてプッシュ通知とContent Cardを作成します。
- 必要に応じて、Content Cardのエンゲージメントを使用する後続のステップを追加します。たとえば、48 時間以内にクリックがなかった場合にフォローアップメッセージを送信します。これらのフィルターに依存する前に、カスタム受信トレイがどの分析データをログに記録しているかを確認してください。
ステップ 4: アプリの受信トレイの動作を確認する
ローンチ前に、アプリが次のように動作することを開発チームと確認してください。
- アプリのライフサイクルの早い段階で、Content Cardsの更新を 1 回だけサブスクライブします。Content Cardsがすでに他の場所で稼働している場合は、既存のサブスクリプションを再利用します。
- キャッシュされたカードから受信トレイをレンダリングし、開いたときやプルして更新したときに更新します。
extrasが受信トレイと一致するカード (例:feed_typeがinboxと等しいカード) に絞り込みます。- カスタム UI のインプレッション、クリック、閉じる操作をログに記録します。React Native では、次の SDK メソッドを使用します。
getCachedContentCardsrequestContentCardsRefreshlogContentCardImpressionlogContentCardClickedlogContentCardDismissedprocessContentCardClickAction- 非推奨の
getContentCardsメソッドではなく、getCachedContentCardsを使用してください。
- 必要に応じて、消費者が関連するアクションを完了したとき (例: 書類画面で
doc_idを開いたとき) にカードを閉じます。これは、受信トレイでのタップによる閉じる操作に加えて行います。
ステップ 5: 3 つの配信モードをテストする
- プッシュ通知のみ: 通知が届き、受信トレイにはカードが表示されません。
- Content Cardのみ: 受信トレイにカードが表示され、プッシュ通知は送信されません。
- プッシュ通知と Content Card: 両方が同時に送信され、ディープリンクが設計どおりに動作します。プッシュ通知を閉じた後もカードは残ります。未読バッジ、閉じる操作、分析が期待どおりに動作します。
テスト中にレート制限によって受信トレイの更新がブロックされないよう、現実的な画面遷移の中で更新をテストしてください。