Webhookキャンペーンを作成する
Webhookキャンペーンを作成するか、マルチチャネルキャンペーンにWebhookを含めることで、他のシステムやアプリケーションにリアルタイム情報を提供し、アプリ外のアクションをトリガーできます。
Webhookを使用して、SalesforceやMarketoなどのシステムやバックエンドシステムに情報を送信できます。たとえば、顧客がカスタムイベントを一定回数実行した後に、プロモーションで顧客のアカウントにクレジットを付与したい場合があります。

ステップ1: メッセージの作成場所を選択する
メッセージをキャンペーンとキャンバスのどちらで送信すべきかわからない場合、キャンペーンは単一のターゲットメッセージングに適しており、キャンバスはマルチステップのユーザージャーニーに適しています。
手順:
- メッセージング > キャンペーンに移動し、キャンペーンを作成を選択します。
- Webhookを選択するか、複数のチャネルをターゲットにするキャンペーンの場合はマルチチャネルを選択します。
- キャンペーンにわかりやすく意味のある名前を付けます。
- (オプション)このキャンペーンの用途を説明する説明文を追加します。
- 必要に応じてチームとタグを追加します。
- タグを使用すると、キャンペーンの検索やレポートの作成が容易になります。たとえば、レポートビルダーを使用する際に、特定のタグでフィルタリングできます。
- キャンペーンに必要な数のバリアントを追加して名前を付けます。追加した各バリアントに異なるWebhookテンプレートを選択できます。このトピックの詳細については、多変量テストとABテストを参照してください。

キャンペーン内のすべてのメッセージが類似している、または同じコンテンツを持つ場合は、追加のバリアントを追加する前にメッセージを作成してください。その後、バリアントを追加ドロップダウンからバリアントからコピーを選択できます。
手順:
- キャンバスコンポーザーを使用してキャンバスを作成します。
- キャンバスを設定したら、キャンバスビルダーでステップを追加します。ステップにはわかりやすく意味のある名前を付けてください。
- ステップスケジュールを選択し、必要に応じてディレイを指定します。
- 必要に応じて、このステップのオーディエンスをフィルタリングします。セグメントを指定し、追加のフィルターを加えることで、このステップの受信者をさらに絞り込むことができます。オーディエンスオプションは、メッセージ送信時にディレイの経過後にチェックされます。
- 昇進動作を選択します。
- メッセージと組み合わせたい他のメッセージングチャネルを選択します。
ステップ2: Webhookを作成する
Webhookをゼロから作成するか、既存のテンプレートを使用するか、Brazeが提供するテンプレートのいずれかを使用できます。次に、エディターの作成タブでWebhookを作成します。
作成タブは以下のフィールドで構成されています。
- 言語
- Webhook URL
- HTTPメソッド
- リクエストボディ

言語
URLとリクエストボディで国際化がサポートされています。メッセージを国際化するには、言語を追加を選択し、必須フィールドに入力します。
コンテンツを作成する前に言語を選択することをお勧めします。そうすることで、Liquid内の適切な場所にテキストを入力できます。使用可能な言語の完全なリストについては、サポートされている言語を参照してください。
右から左に書く言語でコピーを追加する場合、右から左へのメッセージの最終的な表示はサービスプロバイダーのレンダリング方法に大きく依存することに注意してください。右から左へのメッセージをできるだけ正確に表示するためのベストプラクティスについては、右から左へのメッセージの作成を参照してください。
Webhook URL
Webhook URL(HTTP URL)はエンドポイントを指定します。エンドポイントは、Webhookでキャプチャした情報を送信する場所です。
ベンダーに情報を送信する場合、ベンダーはAPIドキュメントでこのURLを提供する必要があります。自社システムに情報を送信する場合は、開発チームに確認して正しいURLを使用していることを確かめてください。
Brazeでは、標準ポート80(HTTP)および443(HTTPS)で通信するURLのみが許可されています。
Liquidの使用
Liquidを使用してWebhook URLをパーソナライズできます。特定のエンドポイントでは、URLの一部としてユーザーを識別したり、ユーザー固有の情報を提供したりする必要がある場合があります。Liquidを使用する場合は、URLで使用するユーザー固有の情報ごとにデフォルト値を含めるようにしてください。
HTTPメソッド
使用するHTTPメソッドは、情報を送信するエンドポイントによって異なります。ほとんどの場合、POSTを使用します。
| HTTPメソッド | 説明 |
|---|---|
| POST | 受信サーバーに新しい情報を書き込みます。データ送信時に最も一般的に使用されるメソッドです。 |
| GET | 新しい情報を書き込むのではなく、既存の情報を取得します。定義上、GETリクエストはリクエストボディをサポートしません。 |
| PUT | エンドポイントの情報を更新し、既存の情報をリクエストボディの内容で置き換えます。 |
| DELETE | HTTP URL内のリソースを削除します。 |
リクエストボディ
リクエストボディは、指定したURLに送信される情報です。Webhookリクエストのボディは、JSONキーと値のペアまたはRawテキストで作成できます。
JSONキーと値のペア
JSONキーと値のペアを使用すると、JSON形式を期待するエンドポイント向けのリクエストを簡単に作成できます。これはJSONリクエストを期待するエンドポイントでのみ使用できます。たとえば、キーがmessage_bodyの場合、対応する値はYour order just arrived!のようになります。キーと値のペアを入力すると、コンポーザーがリクエストをJSON構文で設定し、JSONリクエストのプレビューが自動的に表示されます。

Liquidを使用してキーと値のペアをパーソナライズできます。ユーザー属性、カスタム属性、またはイベントプロパティをリクエストに含めることができます。たとえば、顧客の名とメールアドレスをリクエストに含めることができます。各属性にデフォルト値を含めるようにしてください。
Rawテキスト
Rawテキストオプションを使用すると、任意の形式のボディを期待するエンドポイント向けのリクエストを柔軟に作成できます。たとえば、XML形式のリクエストを期待するエンドポイント向けのリクエストを作成する場合に使用できます。
Rawテキストでは、Liquidを使用したパーソナライゼーションと国際化の両方がサポートされています。

Content-Type リクエストヘッダーをapplication/x-www-form-url-encodedに設定した場合、リクエストボディはURLエンコードされた文字列としてフォーマットする必要があります。例:
1
to={{custom_attribute.${example}}}&text=Your+order+just+arrived

ステップ3: 追加設定を構成する
リクエストヘッダー(オプション)
特定のエンドポイントでは、リクエストにヘッダーを含める必要がある場合があります。コンポーザーの作成セクションで、必要な数のヘッダーを追加できます。

一般的なリクエストヘッダーには、Content-Type仕様(XMLやJSONなど、ボディで想定されるデータの種類を記述するもの)や、ベンダーまたはシステムの認証情報を含むAuthorizationヘッダーがあります。

HTTPヘッダー名は、RFC 7230、セクション3.2(「各ヘッダーフィールドは大文字小文字を区別しないフィールド名で構成される」)に従い、大文字小文字を区別しません。受信エンドポイントや中間サービス(CDNなど)がヘッダーの大文字小文字を変換しても、ヘッダー処理には影響しません。Content-Type、content-type、CONTENT-TYPEはすべて同一として扱われます。
Content-Type仕様では、キーContent-Typeを使用する必要があります。一般的な値はapplication/jsonまたはapplication/x-www-form-urlencodedです。
認証ヘッダーでは、キーAuthorizationを使用する必要があります。一般的な値はBearer {{YOUR_TOKEN}}またはBasic {{YOUR_TOKEN}}で、YOUR_TOKENはベンダーまたはシステムから提供された認証情報です。
ステップ4: メッセージのテスト送信
キャンペーンを公開する前に、Brazeではwebhookをテストしてリクエストが正しくフォーマットされていることを確認することをお勧めします。
テストを行うには、テストタブに切り替えてテストwebhookを送信します。ランダムユーザー、特定のユーザー(メールアドレスまたは外部ユーザーIDを入力)、または任意の属性を持つカスタマイズされたユーザーとしてwebhookをテストできます。
テストwebhookを送信すると、レスポンスメッセージを含むダイアログが表示されます。webhookリクエストが失敗した場合は、エラーメッセージを参照してwebhookのトラブルシューティングを行ってください。以下の例は、無効なwebhook URLを使用した場合のwebhookのレスポンスを示しています。
1
2
3
4
5
6
7
8
9
404 Not Found
{
"error": {
"message": "Unrecognized request URL. Please see https://lob.com/docs or email us at [email protected].",
"status_code": 404
}
}
詳細については、テストメッセージの送信を参照してください。
ステップ5: キャンペーンまたはキャンバスの残りの部分を構築する
次に、キャンペーンの残りの部分を構築します。webhookを構築するためのツールの最適な使用方法については、以下のセクションを参照してください。
配信スケジュールまたはトリガーを選択する
webhookは、スケジュールされた時間、アクション、またはAPIトリガーに基づいて配信できます。詳細については、キャンペーンのスケジュールを参照してください。
アクションベースの配信では、キャンペーンの期間とサイレント時間を設定することもできます。
このステップでは、ユーザーがキャンペーンを再度受け取れるようにすることや、フリークエンシーキャップルールの有効化など、配信コントロールを指定することもできます。
ターゲットユーザーを選択する
次に、セグメントまたはフィルターを選択してオーディエンスを絞り込み、ユーザーをターゲットにする必要があります。このステップでは、セグメントからより大きなオーディエンスを選択し、必要に応じてフィルターを使用してそのセグメントをさらに絞り込みます。おおよそのセグメント人口がどのようになるかのプレビューが自動的に表示されます。正確なセグメントメンバーシップは、メッセージが送信される前に常に計算されることに留意してください。

メッセージは、ターゲットオーディエンスステップで設定した条件にすでに合致しているユーザーにのみ送信されます。その後も、スケジュール配信ステップで定義したトリガーを満たす必要があります。ターゲットオーディエンスは待合室のようなものです。次のアクションが発生したときに進むことができるのは、すでに中にいるユーザーだけです。
コンバージョンイベントを選択する
Brazeでは、キャンペーンを受信した後にユーザーが特定のアクション(コンバージョンイベント)を実行する頻度を追跡できます。ユーザーが指定されたアクションを実行した場合にコンバージョンがカウントされる最大30日間のウィンドウを設定するオプションがあります。
まだ完了していない場合は、キャンバスステップの残りのセクションを完了してください。キャンバスの残りの部分の構築方法、多変量テストやインテリジェントセレクションの実装方法などの詳細については、キャンバスドキュメントのキャンバスを構築するステップを参照してください。
ステップ6: 確認とデプロイ
キャンペーンまたはキャンバスの最後の構築が完了したら、詳細を確認し、テストしてから送信します。
知っておくべきこと
エラー、リトライロジック、タイムアウト
Webhookは、Brazeサーバーが外部エンドポイントにリクエストを送信する仕組みに依存しているため、エラーが発生することがあります。最も一般的なエラーには、構文エラー、期限切れのAPIキー、レート制限、予期しないサーバー側の問題などがあります。Webhookキャンペーンを送信する前に、以下を確認してください。
- Webhookの構文エラーをテストする
- パーソナライズされた変数にデフォルト値が設定されていることを確認する
Webhookの送信に失敗した場合、エラーメッセージがメッセージアクティビティログに記録され、エラーのタイムスタンプ、アプリ名、エラーの詳細などの情報が含まれます。

エラーメッセージだけではエラーの原因が十分に明確でない場合は、使用しているAPIエンドポイントのドキュメントを確認してください。通常、エンドポイントが使用するエラーコードの説明と、その一般的な原因が記載されています。
レスポンスコードとリトライロジック
Webhookリクエストが送信されると、受信サーバーはリクエストの処理結果を示すレスポンスコードを返します。以下の表は、サーバーが返す可能性のあるさまざまなレスポンス、キャンペーン分析への影響、およびエラーの場合にBrazeがキャンペーンの再配信を試みるかどうかをまとめたものです。
| レスポンスコード | 受信済みとしてマーク? | リトライ? |
|---|---|---|
20x(成功) |
はい | 該当なし |
30x(リダイレクト) |
いいえ | いいえ |
408(リクエストタイムアウト) |
いいえ | はい |
429(レート制限) |
いいえ | はい |
その他の4XX(クライアントエラー) |
いいえ | いいえ |
5XX(サーバーエラー) |
いいえ | はい |

Brazeは、このセクションで前述したステータスコードに対して、指数バックオフを使用して30分以内に最大5回リトライします。エンドポイントに到達できない場合、リトライは24時間にわたって分散されることがあります。
各Webhookは、タイムアウトまでに90秒が許可されています。
Retry-Afterおよびレート制限レスポンスヘッダーは、リトライ可能な試行(例:408、429、5XXの後)までBrazeが待機する時間に影響を与えることがあります。これらのヘッダーは、401などのリトライ不可能なレスポンスをリトライ対象にするものではありません。
403 ForbiddenとIP許可リスト {#403-forbidden-and-ip-allowlisting}
403 Forbiddenレスポンスは、エンドポイントがリクエストを受信したが拒否したことを意味します。一般的な原因には、無効または欠落した認証、不十分なAPI権限、およびBrazeの送信IPアドレスをブロックするネットワークルール(ファイアウォールやWebアプリケーションファイアウォールなど)があります。
Webhookリクエストが一貫して403を返し、認証ヘッダーが正しい場合は、Webhookを受信するサーバーでクラスターのBraze IPを許可リストに追加してください。IP許可リストを参照してください。Connected Contentリクエストは同じ送信IPを使用します。Connected Content IP許可リストを参照してください。
その他の4XXトラブルシューティング手順については、WebhookとConnected Contentリクエストのトラブルシューティングを参照してください。
認証とConnected Content認証情報
送信Webhook HTTPリクエストでは、エンドポイントに対する認証にConnected Content認証情報(:basic_authまたは:auth_credentials)を添付することはサポートされていません。代わりに、Webhookのリクエストヘッダーを使用して認証を設定してください。送信時にトークンやシークレットを取得するには、ヘッダーまたはボディフィールドに{% connected_content %}タグを配置して、Webhookが送信される前にLiquidが解決するようにします。
保存済みWebhookテンプレートとキャンペーンの使用状況
Brazeには、特定の保存済みWebhookテンプレートを参照しているすべてのキャンペーンまたはキャンバスステップを一覧表示する組み込みレポートはありません。使用状況を監査するには、同じURLとHTTPメソッドを使用しているWebhookステップを確認するか、Brazeサポートにお問い合わせください。
トラブルシューティングと追加のエラー詳細
特定のWebhookエラーの詳細な説明、トラブルシューティング手順、および解決方法については、WebhookとConnected Contentリクエストのトラブルシューティングを参照してください。また、異常ホスト検出システムの仕組みや、Brazeが自動メールおよびBraze Currentsの追加ログを通じてエラー通知を提供する方法についても説明しています。
IP許可リスト
BrazeからWebhookが送信されると、Brazeサーバーは顧客またはサードパーティのサーバーにネットワークリクエストを送信します。IP許可リストを使用すると、WebhookリクエストがBrazeから送信されていることを確認でき、セキュリティの層を追加できます。
Brazeは以下のIPからWebhookを送信します。リストされたIPは、許可リストにオプトインされたAPIキーに自動的かつ動的に追加されます。

BrazeからBrazeへのWebhookを作成し、許可リストを使用している場合は、127.0.0.1を含む以下のすべてのIPを許可リストに追加する必要があります。
インスタンスUS-01、US-02、US-03、US-04、US-05、US-06、US-07の場合、関連するIPアドレスは次のとおりです。
23.21.118.19134.206.23.17350.16.249.952.4.160.21454.87.8.3454.156.35.25152.54.89.23818.205.178.15
インスタンスUS-08の場合、関連するIPアドレスは次のとおりです。
52.151.246.5152.170.163.18240.76.166.15740.76.166.17040.76.166.16740.76.166.16140.76.166.15640.76.166.16640.76.166.16040.88.51.7452.154.67.1740.76.166.8040.76.166.8440.76.166.8540.76.166.8140.76.166.7140.76.166.14440.76.166.145
インスタンスUS-10の場合、関連するIPアドレスは次のとおりです。
100.25.232.16435.168.86.17952.7.44.1173.92.153.1835.172.3.12950.19.162.19
インスタンスEU-01とEU-02の場合、関連するIPアドレスは次のとおりです。
52.58.142.24252.29.193.12135.158.29.22818.157.135.973.123.166.463.64.27.363.65.88.253.68.144.1883.70.107.88
インスタンスAU-01の場合、関連するIPアドレスは次のとおりです。
13.210.1.14513.211.70.15913.238.45.5452.65.73.16754.153.242.23954.206.45.213
インスタンスID-01の場合、関連するIPアドレスは次のとおりです。
108.136.157.246108.137.30.20716.78.128.7116.78.14.13416.78.162.20843.218.73.35
インスタンスJP-01の場合、関連するIPアドレスは次のとおりです。
13.159.155.21254.199.221.24113.192.23.1654.250.120.13918.181.114.2323.114.38.100
インスタンスKR-01の場合、関連するIPアドレスは次のとおりです。
43.200.215.452.79.67.17552.79.113.60
ユーザーの削除
個々のユーザーまたはユーザーのセグメントを削除するには、オーディエンス > オーディエンスの管理 > ユーザーの削除に移動します。ダッシュボードは一括セグメント削除(最大1,000万プロファイル)をサポートしており、7日間のキャンセル期間が含まれ、共有REST APIレート制限を消費しません。手順、制限、権限については、ユーザーの削除を参照してください。
より小さなバッチでのプログラムによる削除には、Webhookキャンペーンの代わりに/users/deleteエンドポイントを使用してください。