Content Cardsで消費者に注文の更新を通知する

注文管理システム (OMS) から注文の更新を記録し、発送やキャンセルなどの更新に応じてContent Cardsを送信し、キーと値のペアを使ってアプリ内で古いカードを非表示にすることで、カスタムの Content Card フィードを常に最新の注文ステータスに保ちます。

この例について

架空の衣料品・美容小売業者であるFlash & Threadは、モバイルアプリに横スクロールの Content Card フィードを設け、各カードで購入のステータスを表示したいと考えています。たとえば、注文が picked から dispatched (発送済み) に移行したときや、cancelled になったときです。

同社の注文管理システムには、消費者のメールアドレス、注文番号、注文ステータス、追跡URLが保存されており、これらの値が更新されるとBrazeを呼び出すことができます。マーケティング担当者は、ステータスごとに異なるカードの文言を使いたいと考えています (たとえば、dispatched には「ご注文の商品は配送中です」、picked には「ご注文の準備をしています」)。同じ注文の古いカード (dispatched のカードが届いた後の picked のカードなど) を非表示にして、消費者に最新のステータスだけが表示されるようにします。

この例では、次の方法を説明します。

1. 注文管理システムが pending、held、picked、dispatched、cancelled などのステータス変更を記録したときに、カスタムイベント (たとえば order_update) を /users/track に記録する
2. これらのステータスごとに個別のアクションベースの Content Card キャンペーンをトリガーし、イベントプロパティを使ってLiquidでパーソナライゼーションを行う
3. 各カードに order_number や order_hierarchy などのキーと値のペア (extras) を設定する
4. カスタムの Content Card フィードで、order_number ごとに order_hierarchy が最も高いカードのみを残し、それ以外を非表示にする

ダッシュボードの削除イベントだけでは、同じジャーニーから送信された多数のカードの中から特定の注文のカードだけを対象にできない場合に、この方法を使用します。

考慮事項

• Content Cardsは、送信から最長 30 日後に有効期限が切れて削除されます。終了ステータス (キャンセルなど) のカードをより早くフィードから消したい場合は、有効期限を短く設定してください。詳しくは、Content Cardの作成を参照してください。
• 注文管理システムにメールアドレスしかない場合は、/users/track でセカンダリー識別子 email を使ってユーザーを識別します。注文管理システムに external_id がある場合は、そちらを優先してください。カスタムの識別子タイプが必要な場合は、ユーザーエイリアスも選択肢になります。alias_name に識別子の値を、alias_label にタイプ (たとえば email) を設定します。詳しくは、識別子の解決とユーザーエイリアスオブジェクトを参照してください。
• イベントトリガーの方法を使用する場合、カスタムイベントプロパティはLiquidによるパーソナライゼーションやイベントプロパティによるセグメンテーションに利用できます。ただし、属性としても書き込まない限り、プロファイルに属性として保持されることはありません。
• API トリガーの Content Card キャンペーンを代わりに使用すると、カスタムイベント (およびそのデータポイント) の記録を回避できます。ただし、キャンペーンごとに個別のトリガー送信が必要になり、そのシグナルに対するイベントプロパティによるセグメンテーションは利用できなくなります。
• カスタムフィードは、次のセッション開始時または手動で requestContentCardsRefresh を呼び出すまで、セッション中に更新されません。消費者が注文フィードを開いたとき、またはプルして更新したときに、更新を呼び出してください。
• 完全にカスタマイズした Content Card UIでは、分析の手動ロギング (インプレッション、クリック、非表示) が必要です。デフォルトのフィードをサブクラス化する方が手間は少なくなりますが、横スクロールのカルーセルには対応していません。
• この階層ロジックは、1 つの注文番号につき同時に有効なステータスが 1 つであることを前提としています。1 つの注文に複数のステータスが同時に存在する可能性がある場合 (倉庫ごとに分割出荷する場合など) は、別のキー (フルフィルメント ID など) を追加し、残すか非表示にするかのルールに含めてください。
• アプリ側の非表示ロジックには、新しいアプリのリリースが必要です。本番環境の前に、開発用ワークスペースでテストしてください。

設定

ステップ 1: 注文管理システムから注文の更新を記録する

注文管理システムがステータスの変更を記録したら、カスタムイベントを /users/track に送信します。Content Cardのパーソナライゼーションに使用し、アプリが extras から読み取るイベントプロパティを含めてください。

次の表は、プロパティの例を示しています。

メールアドレスでユーザーを識別するリクエストの例は次のとおりです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

POST https://rest.iad-01.braze.com/users/track
Content-Type: application/json
Authorization: Bearer {YOUR_REST_API_KEY}

{
  "events": [
    {
      "email": "[email protected]",
      "name": "order_update",
      "time": "2026-09-28T16:02:05Z",
      "properties": {
        "order_number": "12345",
        "order_status": "picked",
        "tracking_url": "https://www.flashandthread.example/track/12345"
      }
    }
  ]
}

ワークスペースの REST エンドポイントと、users.track 権限を持つ API キーを使用してください。サンプルのメールアドレスと注文の値は、注文管理システムのペイロードに置き換えてください。

ステップ 2: 注文ステータスごとに Content Card キャンペーンを作成する

送信するステータスごとに (たとえば pending、held、picked、dispatched、cancelled)、アクションベースの Content Card キャンペーンを 1 つずつ作成します。

1. メッセージング > キャンペーン に移動し、キャンペーンを作成 を選択してから、Content Cards を選択します。
2. order_update カスタムイベントに対してアクションベースの配信を設定します。対応する order_status イベントプロパティでフィルターをかけ、そのステータスのみがこのキャンペーンに入るようにします。
3. Liquidのイベントプロパティを使って、カードのタイトルまたは本文をパーソナライズします。

1

Order {{event_properties.${order_number}}} is {{event_properties.${order_status}}}.

4. 設定 タブで 新しいペアを追加 を選択し、アプリで使用するキーと値のペアを追加します。

次の表は、階層の例を示しています。アプリは、注文ごとに値が最も高いカードを残します。

5. カードの有効期限 (最長 30 日) を設定します。終了ステータスには短い期間を設定することをお勧めします。

ダッシュボードの削除イベントはキャンペーンレベルで適用されるため、同じキャンペーンの他のカードを残したまま、1 つの注文のカードだけを削除することはできません。そのため、アプリは extras を使って古いカードを非表示にします。

ステップ 3: カスタムフィードで注文ごとに最新のカードを残す

カスタムフィードで Content Card の更新をサブスクライブし、extras を読み取り、order_number ごとに order_hierarchy が最も高いカードを残します。分析の正確性を保つため、残りのカードはプラットフォームの非表示 APIで非表示にします。

フィード内の各カードに対して、次の処理を行います。

1. extras から order_number と order_hierarchy を読み取ります。
2. 同じ order_number を持つカードの中で、最も高い order_hierarchy を見つけます。
3. カードの階層が最も高い値と一致する場合は、そのカードを表示します (カードのフィールドをカスタム UI オブジェクトにマッピングします)。
4. それ以外の場合は、カードを非表示にします。

サブスクライブと非表示の呼び出しは、お使いのプラットフォームの最新のSDKで実装してください。まずは以下を参照してください。

• カードの作成
• フィードのカスタマイズ
• 分析のロギング

消費者がすでにアプリを使用している場合は、requestContentCardsRefresh を呼び出して、次のセッションを待たずに新しい注文カードが表示されるようにします。

ステップ 4: ジャーニーをエンドツーエンドでテストする

1. 同じ注文に対して、order_status の値が段階的に上がる一連の order_update イベントを送信します。
2. 各ステータスのキャンペーンが想定どおりのカードを送信し、Liquidが正しく解決されることを確認します。
3. フィードに注文ごとに 1 枚のカードが表示され、階層の低いカードが非表示になることを確認します。
4. カスタム UIのインプレッション、クリック、非表示がキャンペーン分析に表示されることを確認します。

関連記事

• Content Cardの作成
• Content Cardのキーと値のペアと動作
• カスタム Content Cardsの作成
• Content Card フィードのカスタマイズ
• Content Card 分析のロギング
• POST: ユーザーの作成と更新