キャンバスのトラブルシューティング
このページは、キャンバスのトラブルシューティングに役立ちます。
トリガーされたキャンバスステップがユーザーに届かなかったのはなぜですか?
まず、カスタムイベントがBrazeに渡されていることを確認する。Analytics> カスタムイベントレポートに移動し、それぞれのカスタムイベントと日付範囲を選択します。イベントが表示されない場合は、正しく設定されているか、ユーザーが正しいアクションを行ったかを確認する。
カスタムイベントが表示される場合は、さらに以下の方法でトラブルシューティングを行う:
- ユーザープロファイルのダウンロードをチェックして、イベントがトリガーされたことと、イベントがいつトリガーされたかを確認します。イベントがトリガーされている場合は、イベントがトリガーされた時点のタイムスタンプを、キャンバスが有効になった時点と比較します。このイベントは、キャンバスが有効になる前にトリガーされた可能性があります。
- カスタムイベントがトリガーされたときにユーザーがセグメンテーションにいたかどうかを判断するために、キャンバスおよびターゲティングに使用されたセグメントの変更ログを確認する。ユーザーがセグメントに含まれていなかった場合、キャンバスステップを受け取っていません。
- ユーザーがセグメンテーションによってコントロールグループに登録され、その結果キャンバスステップを受け取ることができなかったかどうかを確認します。
- スケジュールされた遅延がある場合は、遅延が発生する前にユーザーのカスタムイベントがトリガーされていたかどうかを確認します。遅延前にイベントがトリガーされていた場合、ユーザーはキャンバスステップを受け取っていません。
アプリ内メッセージは、REST API ではなく、SDK 経由で送信されたイベントによってのみトリガーできます。
なぜ俺のキャンバスは期待通りに送信されないんだ?
キャンバスは堅牢かつ複雑であり、作成する際には多くの時間と注意を要します。もしキャンバスが思い通りに送信されない場合は、キャンバスのスケジュール、エントリのオーディエンス、エントリ設定を確認し、キャンバス作成のステップを見直すことをお勧めする。
スケジュール
- キャンバスは正しくスケジュールされていますか?
- 正しい日付と時間を選択しましたか?
- キャンバスを起動してから、アクションベースの配信のために、ユーザーが指定されたアクションを実行しましたか?
エントリ設定
エントリ設定は、キャンバスの送信方法を理解するために重要です。キャンバスにエントリする可能性のある人数を制限しているかどうかを確認してください。
メッセージを受信する資格がなくなったユーザーは、キャンバスを終了することもできます。例えば、キャンバスにプッシュ通知のみが含まれている場合、最初のステップを受信した後にプッシュ通知をオプトアウトしたユーザーはキャンバスから離脱します。異なるキャンバスステップを使用して、代わりのユーザー ジャーニーを追加することを検討してください。
オーディエンスをセグメント化する
ターゲットオーディエンスに関する次の質問を考慮します。
- 正しいセグメントを選択しましたか?
- セグメントはどのように設定されていますか?
- そのセグメントにユーザーが含まれていることを確認したか?
- キャンバスにエントリするユーザーの数を制限するフィルターを追加しましたか?
- ユーザーがバリアントの最初のステップを受信する条件を満たしていますか? 例えば、キャンバスの最初のステップがプッシュ通知で、エントリオーディエンスがすべてプッシュ通知無効である場合、ユーザーはメッセージを受信しません。
夏時間の日、なぜ誰も私の毎日スケジュールされたキャンバスに入らなかったのか?
夏時間(DST)の切り替え日には、毎日スケジュールされたキャンバスは通常より最大1時間早く、または遅く実行されることがある。エントリー条件がカスタム属性やイベントに依存し、そのタイムスタンプがスケジュールされたエントリー時刻から1時間以内に収まる場合、サマータイム実施日にはユーザーがまだ条件を満たしていない可能性がある。属性やイベントがまだ記録されていないためだ。
例えば、ユーザーが通常、カスタム属性のp.m更新を3:00に受け取るとしよう。これはあなたのキャンバスのタイムゾーンでの時刻だ。そしてあなたのキャンバスは毎日3:30に実行される。これも同じp.mタイムゾーンでの時刻だ。夏時間開始の日には、キャンバスはその属性更新に対して通常より最大1時間早くユーザーを評価する可能性がある。つまり、属性が記録される前に評価が行われるのだ。再応募を無効にすると、前日に入力したユーザーは再応募できなくなる。その結果、その日のエントリ数はゼロになる。
これを避けるには、カスタム属性やイベントの更新が、キャンバスのスケジュールされた開始時刻の1時間以上前に行われるようにすることだ。
なぜ私のオーディエンスはコントロールグループとバリアントグループに均等に分けられなかったのか?
キャンバスを作成する際、次のユースケースのように、オーディエンスがコントロールグループとバリアントグループに均等に分かれることを想定していたかもしれない。なぜそうなったのか、そしてどう修正すべきか、話し合おう!
ユーザーが参加するグループは、ユーザーの設定によって異なる。これは、コントロールグループとバリアントグループのいずれかになります。ユーザーは、エントリステップで定義した全ての条件を満たした場合に、キャンバスに入る。キャンバスを設定するとき、各バリアントとコントロール・グループに入るユーザーの割合を定義する。
コントロールグループが意図せずバリアントグループよりも大きくなった場合は、以下をお勧めします。
- エントリのオーディエンスフィルターを「フォアグラウンドプッシュをイネーブルメントする」に設定せよ。
- プッシュサブスクリプションステータス、メールサブスクリプションステータス、またはその両方のオーディエンスフィルターを「オプトイン済み」または「購読済み」に設定せよ。
コントロールグループを含むキャンバスを作成する際は、エントリオーディエンスの全ユーザーがキャンバス内でメッセージを受信できることを確認すること(例:キャンバスにプッシュ通知やメールメッセージが含まれている場合)。
ユースケース
次のようなシナリオを想像してみよう:
- キャンバスには単一変異体と対照群がある。
- バリアントの最初のステップはプッシュ通知だ。
- ユーザーの90% がバリアント、10% がコントロールグループにエントリするよう選択されました。

このシナリオでは、キャンバスにエントリするユーザーの90% がバリアントにエントリします。
アクティブユーザーを振り返ると、29.8千人のユーザーがいるにもかかわらず、プッシュ通知のイネーブルメントを有効にしているのはその64%に過ぎないことがわかる。

つまり、90%のユーザーがバリアントを入力するように指定したにもかかわらず、それらのユーザー全員が実際にプッシュ通知を受け取れるわけではないということだ。プッシュ通知を受信できないこれらのユーザーも、バリアントにエントリします。
GitHub でこのページを編集