Connected Contentデバッガー

Connected Contentデバッガーを使用すると、各Connected Content呼び出しのライブリクエストとレスポンスを確認できるため、キャンペーンやキャンバスを開始する前にエンドポイント、ヘッダー、Liquidタグを検証できます。

デバッガーについて

Connected Contentを使用すると、レンダリング時に外部APIへのHTTPコールを実行し、そのレスポンスをLiquidでメッセージに挿入することで、リアルタイムデータによるメッセージの強化が可能です。このコールはBraze外部で実行されるため、キャンペーンやキャンバスを公開する前に、Brazeが送信したリクエストの内容、エンドポイントが返した結果、またはコールが失敗した理由を正確に確認することが難しい場合があります。

Connected Contentデバッガーは、公開前にこれらの問題をトラブルシューティングするのに役立ちます。プレビューとテストセクションで、メッセージ内のすべてのConnected Contentコールに対するライブリクエストとレスポンスを表示します。これにより、エンドポイント、ヘッダー、Liquidタグが正しく設定されているかどうかを、すべてBrazeダッシュボード内で確認できます。

サポート対象

Connected Contentデバッガーは、以下の領域で使用できます。

• バナー
• キャンバスのコンテキストステップ
• Content Cards
• メール
  • テンプレートを含む
  • フッターと購読ページは除く
• アプリ内メッセージ
• プッシュ通知
• SMS/MMS/RCS
• Webhook
  • テンプレートを含む
• WhatsApp

デバッガーの使用

プレビューを実行するたびに、Brazeは自動的にConnected Contentの呼び出し結果をプレビュータブに表示します。デバッガーを使用するには：

1. {% connected_content %}タグでメッセージを設定します。
2. プレビューとテストセクションに移動します。メッセージにConnected Contentタグが含まれている場合、Connected Contentの呼び出し数と成功・エラーのステータスを含むサマリービューを確認できます。

3. 詳細を表示を選択して、プレビューの横にデバッガーを開きます。ドロワーには、各Connected Content呼び出しのURLと結果を示すテーブルが表示されます。

4. 各URLと結果の横にある表示を選択すると、リクエストとレスポンスのヘッダー、ペイロード、メソッド、所要時間、キャッシュ情報を確認できます。

5. 結果を確認し、必要に応じてタグ、ヘッダー、またはエンドポイントを調整します。その後、新しいプレビューを生成して修正を確認します。

テンプレートに複数の{% connected_content %}タグが含まれている場合、デバッガーは実行されたすべての呼び出しを一覧表示します。1つのテンプレートから複数のメッセージ本文をレンダリングするチャネル（例えば、HTML、プレーンテキスト、AMP本文を個別にレンダリングするメールや、デバイス固有の本文を個別にレンダリングするクイックプッシュなど）の場合、デバッガーは現在プレビュー中の本文だけでなく、すべての本文にわたるConnected Content呼び出しをすべて表示します。

デバッグ出力を理解する

各Connected Contentコールには、独自のResponseタブとRequestタブが表示されます。コールが成功したかどうかを確認する最初の指標となるため、デフォルトではResponseタブが表示されます。

URLの詳細

フィールド	説明
URL	BrazeがコールしたLiquidタグ解決済みの完全なURL。
Method	使用されたHTTPメソッド（GETまたはPOST）。
Status code	エンドポイントが返したHTTPステータスコード（例：200、404、500）。Braze固有のコードについては、レスポンスコードのトラブルシューティングを参照してください。

Responseタブ

フィールド	説明
Duration	リクエストの完了にかかった時間（秒単位）。Durationはライブ（キャッシュされていない）コールに対してのみ表示されます。
Served from cache	このレスポンスがエンドポイントへのライブコールではなく、BrazeのConnected Contentキャッシュから提供されたかどうかを示します（YesまたはNo）。キャッシュされた結果は以前のレスポンスを反映しており、エンドポイントの現在の状態とは限りません。
Response body	エンドポイントが返したレスポンスボディ。

Requestタブ

フィールド	説明
Headers	Connected Contentタグからのヘッダー（:headers、認証情報、:content_typeなどのオプション）。
Body	送信されたリクエストボディ（POSTリクエストの場合）。

デバッガーに表示されるリクエストヘッダー

Request タブには、Connected Contentタグからのヘッダーが一覧表示されます。カスタム :headers、保存された認証情報、:content_type や :basic_auth などのタグオプションで設定されたヘッダーが含まれます。Brazeは、エンドポイントへの送信リクエストに標準ヘッダー（例: User-Agent や Host）も追加します。これらのBrazeが追加したヘッダーは、:headers で設定した場合にデバッガーに表示されます。

Brazeは、送信されるConnected Contentリクエストに以下のヘッダーを追加します。ほとんどのヘッダーは、タグ内でまだ指定されていない場合にのみ設定されます。:headers、認証情報、またはタグオプションで指定したヘッダーは、指定した通りに送信されます。

ヘッダー	Brazeが設定するタイミング
User-Agent	まだ設定されていない場合、BrazeはBraze Sender <version>を送信します。バージョン文字列は変更される場合があります。User-Agentでトラフィックをフィルタリングする場合は、Braze Senderで始まるすべての値を許可してください。一貫した値を送信するには、:headersでUser-Agentを設定してください。
X-Braze-Sender-Version	常にConnected Contentの送信元バージョンに設定されます。
Accept-Encoding	まだ設定されていない場合、Brazeはgzipを送信します。
Authorization	URLにユーザー名とパスワード（user:pass@host）が含まれている場合、Brazeはその認証情報から導出されたBasic Authorizationヘッダーを追加します。明示的なAuthorizationヘッダーはこれを上書きします。URLに認証情報を含めるのではなく、:basic_authまたは:headersの使用をお勧めします。
Host	Hostヘッダーを設定しない限り、リクエストURLのホスト名です（例：https://www.example.com/abc/123の場合はwww.example.com）。
Content-Length	ボディが存在する場合のリクエストボディのバイト単位のサイズです。
BrazeToBraze	Braze RESTエンドポイントへのリクエストに対してのみtrueに設定されます。その他の送信先では省略されます。

認証情報のリダクション

Connected Contentタグで:basic_auth、一般的なシークレットヘッダー、キー、またはその他の認証情報オプションを使用している場合、デバッガーはRequestタブでそれらの値をリダクションし、一連のアスタリスク（*）に置き換えます。これにより、プレビューとテストで値を公開することなく、認証情報がリクエストに含まれていることを確認できます。

認証情報がリダクションされている場合でも、認証の失敗は引き続き表示されます。エンドポイントが401または403を返した場合、そのステータスコードはResponseタブに通常どおり表示されるため、認証情報自体は非表示であっても、認証の問題でリクエストが拒否されたことを判断できます。

レスポンスコードのトラブルシューティング

エンドポイントエラーとBrazeが課す制限

Responseタブに表示されるすべての非2XXステータスコードが、エンドポイントから返されたものとは限りません。BrazeはConnected Contentの呼び出しに独自の制限を適用しており、これらはエンドポイントエラーに似たレスポンスを生成することがあります。

408、429、502、503、504、599などのレスポンスコードが表示される場合、問題は通常Braze側の呼び出しに起因しており、ホストの健全性、タイムアウト、またはペイロードサイズに関連しています。エンドポイントが一貫して大きなレスポンスを返す場合は、メッセージに必要なフィールドのみにレスポンスペイロードをトリミングすることを検討してください。

エンドポイントが予期しないステータスコードを返した場合

Requestタブを使用して、URL、タグからのヘッダー、およびボディを確認してください。予期しない4XXレスポンスの一般的な原因は、URL、ヘッダー、またはボディ内のLiquidタグが想定通りに解決されなかったことです。{{ }}の参照が、プレビュー対象のユーザーまたはコンテキストに存在するフィールドを指しているか確認してください。

レスポンスが古い場合

ResponseタブのServed from cacheを確認してください。Yesと表示されている場合、デバッガーは新しい呼び出しではなく、以前にキャッシュされたレスポンスを表示しています。現在のエンドポイントの動作を確認するには、タグに一時的に:no_cacheを追加するか、キャッシュが期限切れになるまで（:cache_max_ageの設定に従って）待ってください。

関連記事

• Connected Contentリファレンス
• Connected Content API呼び出しを行う
• 送信リクエストヘッダー
• WebhookとConnected Contentリクエストのトラブルシューティング