アラートとCurrentsでContent Card配信をモニタリングする
デバッグツール、しきい値アラート、Currentsイベント、APIモニタリングを使用して、ユーザーから報告される前にContent Card配信の低下を検出します。
この例について
架空のモバイルバンキングブランドであるPyrite Financialは、アプリのホーム画面にある専用スロットにContent Cardを表示しています。このスロットには大多数のユーザーに対してカードが表示されることが想定されているため、スロットが空であることは調査すべきシグナルになります。
この例では、次の方法を紹介します。
- SDKデバッガー、内部グループ、イベントユーザーログを使用して、テスト段階でContent Cardの統合を検証する
- 想定されるメッセージ量に対して、キャンペーンまたはキャンバスのしきい値アラートを設定する
- Currentsでキャンバスのエントリ、Content Cardの送信、インプレッション、中止を追跡する
- メッセージングをトリガーするREST APIエンドポイントで、量の低下と200以外のレスポンスを監視する
- Datadogやキャンバスのエクスポートエンドポイントで、送信量の補助的なチェックを追加する
- Brazeが把握できないアプリ側のフォールバック動作をログに記録する
Content Cardの配置がビジネス上重要で、配信が低下したことを示す運用上のシグナルが必要な場合に、この方法を使用してください。各ステップは任意のため、ワークスペースですでにサポートされているものから始めてください。
考慮事項
- まず、ターゲットとなるすべてのユーザーに対して配置内に常にカードを表示すべきか、それとも一部のユーザーではスロットが空でも問題ないかを決めてください。量のしきい値とフォールバックロジックは、この答えによって変わります。
- BrazeはSDKの接続性をモニタリングし、インシデントをBrazeステータスページで報告しています。この例では、キャンペーンとキャンバスの設定、メッセージ量、APIトラフィック、アプリ側のフォールバック動作など、お客様自身でモニタリングする内容を扱います。
- すべてのトリガーがメッセージを生成するわけではありません。トリガーがBrazeに到達した後、ジャーニーロジック、ターゲティング、フリークエンシーキャップ、レート制限によって送信数が減少する可能性があります。トリガー量と送信量は1対1で一致させるのではなく、傾向として比較してください。
- イベントレベルのモニタリングにはCurrentsが必要です。Currentsがない場合は、代わりにキャンペーンとキャンバスの分析、しきい値アラート、RESTエクスポートエンドポイントを使用してください。
- Datadogのメトリクスは送信数のみを報告し、BrazeダッシュボードやCurrentsとわずかに異なる場合があります。
- 過度なリフレッシュはレート制限される可能性があります。SDKは、Content Cardのリフレッシュリクエストにデバイスごとのレート制限を適用します。リフレッシュメソッドは短時間に繰り返し呼び出すのではなく、ユーザーライフサイクルの意味のあるタイミングで呼び出してください。Content Cardsのレート制限とバナーとしてのContent Cardsのレイテンシーを改善するを参照してください。
- Liquidは意図的にカードを抑制することがあります。Liquidがメッセージを中止すると、Brazeは送信ではなくContent Card中止イベントを記録します。中止は条件付きコンテンツの想定どおりの動作として扱い、その量が変化した場合にのみシグナルとみなしてください。
- カードがないときにアプリでデフォルトのコンテンツを表示する場合は、それを独自のアプリ分析で追跡してください。Brazeが把握できるのは送信した内容のみで、アプリがカードとプレースホルダーのどちらを表示したかはわかりません。
設定
ステップ1: リリース前に統合を検証する
本番環境のアラートが統合の不備ではなく実際の問題を反映するように、想定どおりの動作を確認します。
- SDKデバッガーでデバッグセッションを作成し、SDKのアクティビティをリアルタイムで確認して、カードのリクエストとインプレッションが記録されていることを確かめます。
- テストアカウントを内部グループに追加し、リリース前にテストユーザーに対してキャンペーンまたはキャンバスをテストできるようにします。
- 個々のユーザーのイベントユーザーログを確認し、どのキャンペーンが各カードをSDKに配信したかを確認します。
テスト中に確認した送信、インプレッション、中止の量を記録してください。これらが、設定するしきい値のベースラインになります。
ステップ2: キャンペーンまたはキャンバスにしきい値アラートを設定する
しきい値アラートは、メッセージ量が想定範囲外になったときにメールまたはWebhookで通知します。WebhookアラートはSlackチャネルやオンコールシステムに転送できます。
- キャンペーン: キャンペーン分析ページで上限と下限のしきい値を設定します。設定手順については、キャンペーンアラートを参照してください。
- キャンバス: アラートの管理ページで、ユーザーエントリ、送信メッセージ、またはその両方に対するアラートを設定します。設定手順については、キャンバスのしきい値アラートを参照してください。
下限のしきい値は、通常の量より少なく、かつゼロより大きい値を選択してください。そうすることで、完全な停止を待たずに部分的な低下で通知がトリガーされます。
ステップ3: Currentsでエントリ、送信、インプレッションを追跡する
Currentsは、メッセージエンゲージメントイベントと顧客行動イベントをほぼリアルタイムでデータプラットフォームにストリーミングするため、Brazeダッシュボードの外で量とレイテンシーをモニタリングできます。
キャンバスから送信されるContent Cardの場合、これらのイベントがエントリからインプレッションまでのパスをカバーします。
| イベント | Currentsイベント名 | わかること |
|---|---|---|
| キャンバスエントリ | users.canvas.Entry |
ユーザーがカードを送信するキャンバスにエントリした |
| Content Card送信 | users.messages.contentcard.Send |
Brazeがユーザー向けにカードを作成して送信した |
| Content Cardインプレッション | users.messages.contentcard.Impression |
カードがユーザーのインプレッションを記録した |
| Content Card中止 | users.messages.contentcard.Abort |
Liquidロジックによってカードの送信が阻止された |
Content Cardキャンペーンの場合は、送信、インプレッション、中止のイベントをモニタリングし、campaign_idでフィルターします。
- 量のモニタリング: 一定の期間におけるキャンバスまたはキャンペーンごとの送信数とインプレッション数を追跡し、履歴データに基づくしきい値を下回ったときにアラートを出します。
- レイテンシーのモニタリング: 作成レイテンシーはエントリイベントと送信イベントを、表示レイテンシーは送信イベントとインプレッションイベントを比較します。カードが最初のインプレッション時に作成される場合、エントリからインプレッションまでを測定すると作成時間と表示時間が混在するため、表示レイテンシーには送信からインプレッションまでのタイミングを使用してください。
各段階の量を比較すると、よくある障害パターンを特定しやすくなります。
- エントリの減少は、上流のトリガーまたはオーディエンスの問題を示しています。
- エントリが安定していて送信が減少している場合は、ジャーニーロジック、ターゲティング、またはLiquidによる中止が考えられます。カードが最初のインプレッション時に作成される場合は、ユーザーがまだアプリを開いていない可能性もあります。
- 送信が安定していてインプレッションが減少している場合は、SDKのリフレッシュ、配置のレンダリング、デバイスのレート制限など、カードの作成から表示までの間に問題があることを示しています。
イベントのペイロードとフィールドについては、メッセージエンゲージメントイベントを参照してください。
ステップ4: APIトラフィックとエラーレスポンスを監視する
トリガーがお客様自身のシステムから発生している場合は、それを供給するAPIレイヤーをモニタリングしてください。
- メッセージングをトリガーするエンドポイントにAPI使用状況アラートを設定します。量の低下と、200以外のレスポンスの増加に対する条件を構成してください。
- それらのエンドポイントの
200以外のレスポンスを確認します。エラーレスポンスの増加は、最近のリリースで不正な形式のリクエストが混入したか、呼び出しがレート制限に達していることを示している可能性があります。
ステップ5: 補助的な量のチェックを追加する
既存のオブザーバビリティツールやスケジュールされたジョブで送信量データを確認したい場合に使用します。
- Datadog: Datadog統合は、キャンペーン、キャンバス、キャンバスステップの識別子でタグ付けされた
braze.messaging.sentメトリクスを提供します。特定の期間における特定のメッセージステップからの送信数を確認するために使用してください。これらの数は集計レベルでContent Card送信量を近似したもので、ユーザーや送信の識別子は含まれません。 - エクスポートエンドポイント:
/canvas/data_seriesと/canvas/data_summaryをポーリングしてキャンバスのエントリとメッセージ送信数を取得し、実行ごとの結果を比較して傾向や異常を見つけます。
ステップ6: アプリでフォールバック動作をログに記録する
Brazeが報告するのは送信した内容であり、アプリがレンダリングした内容ではありません。Brazeが把握できない次のケースについて、アプリ側のログまたは分析を追加してください。
- フィードのリフレッシュは完了したが、配置に使用できるカードがなかった。
- アプリがカードの代わりにフォールバックコンテンツを表示した。
- リフレッシュリクエストが失敗したか、レート制限された。
Brazeのデータと並べて確認したい場合はこれらをカスタムイベントとして送信し、そうでない場合は独自の分析プラットフォームに保存してCurrentsのインプレッション量と比較してください。
ステップ7: アラート発生時にトリアージする
次のチェックを順番に行います。
- Brazeステータスページで進行中のインシデントがないことを確認します。
- Currents(またはキャンバスとキャンペーンの分析)で、同じ期間のエントリ、送信、インプレッション、中止の量を比較します。カードが最初のインプレッション時に作成される場合、ユーザーがアプリを開くまではエントリ量が送信量を上回ることがあります。量を比較する際はこの点を考慮してください。
- メッセージをトリガーするエンドポイントについて、API使用状況アラートと
200以外のレスポンスを確認します。 - アプリ側のフォールバックイベントや空の配置イベントを、Currentsのインプレッション量と比較します。
- SDKデバッガーとイベントユーザーログで、サンプルユーザーを使用して再現します。