コンテンツにスキップ

プッシュ通知を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を同時に送信する場合は、マルチチャネルキャンペーンを使用します。遅延、分岐、再エンゲージメント、またはエンゲージメントに基づく後続のステップが必要な場合は、キャンバスを使用します。

設定

アプリが受信トレイのカードをフィルターして処理するために使用する 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: メッセージ配信を設定する

マルチチャネルキャンペーン

  1. メッセージング > キャンペーンに移動し、キャンペーンを作成を選択してから、マルチチャネルを選択します。
  2. 作成ステップでチャネルを追加を選択し、プッシュとContent Cardsを追加します。
  3. プッシュ通知を作成します。クリック時の動作で、ディープリンクを受信トレイまたは別のアプリ内の遷移先に設定します。
  4. 一致する、または補完する内容でContent Cardを作成します。設定タブで新しいペアを追加を選択し、ステップ 1 で決めた受信トレイのキーと値のペアを追加します。Content Cardのディープリンクを設定します。
  5. 新しい書類などのイベントには、アクションベースの配信をスケジュールします。計画メンテナンスにはスケジュールされた配信を使用します。オーディエンスを定義します。
  6. 今後の受信トレイ連携型のプッシュキャンペーンにも Content Cards チャネルと同じ extras が含まれるよう、テンプレートまたはチェックリストを保存します。

キャンバス

  1. メッセージング > キャンバスに移動し、キャンバスを作成を選択します。ジャーニーのエントリスケジュールとオーディエンスを設定します (例: 書類の準備が完了したときのカスタムイベント)。
  2. プッシュとContent Cardsの両方を含むメッセージステップを追加します。フローで必要な場合は、連続したメッセージステップを使用します。
  3. キャンペーンの場合と同じ方法で、ディープリンクと受信トレイのキーと値のペアを含めてプッシュ通知とContent Cardを作成します。
  4. 必要に応じて、Content Cardのエンゲージメントを使用する後続のステップを追加します。たとえば、48 時間以内にクリックがなかった場合にフォローアップメッセージを送信します。これらのフィルターに依存する前に、カスタム受信トレイがどの分析データをログに記録しているかを確認してください。

ステップ 4: アプリの受信トレイの動作を確認する

ローンチ前に、アプリが次のように動作することを開発チームと確認してください。

  1. アプリのライフサイクルの早い段階で、Content Cardsの更新を 1 回だけサブスクライブします。Content Cardsがすでに他の場所で稼働している場合は、既存のサブスクリプションを再利用します。
  2. キャッシュされたカードから受信トレイをレンダリングし、開いたときやプルして更新したときに更新します。
  3. extras が受信トレイと一致するカード (例: feed_type が inbox と等しいカード) に絞り込みます。
  4. カスタム UI のインプレッション、クリック、閉じる操作をログに記録します。React Native では、次の SDK メソッドを使用します。
    • getCachedContentCards
    • requestContentCardsRefresh
    • logContentCardImpression
    • logContentCardClicked
    • logContentCardDismissed
    • processContentCardClickAction
    • 非推奨の getContentCards メソッドではなく、getCachedContentCards を使用してください。
  5. 必要に応じて、消費者が関連するアクションを完了したとき (例: 書類画面で doc_id を開いたとき) にカードを閉じます。これは、受信トレイでのタップによる閉じる操作に加えて行います。

ステップ 5: 3 つの配信モードをテストする

  • プッシュ通知のみ: 通知が届き、受信トレイにはカードが表示されません。
  • Content Cardのみ: 受信トレイにカードが表示され、プッシュ通知は送信されません。
  • プッシュ通知と Content Card: 両方が同時に送信され、ディープリンクが設計どおりに動作します。プッシュ通知を閉じた後もカードは残ります。未読バッジ、閉じる操作、分析が期待どおりに動作します。

テスト中にレート制限によって受信トレイの更新がブロックされないよう、現実的な画面遷移の中で更新をテストしてください。

New Stuff!