分析
Braze SDKの分析について学習し、Brazeが収集するデータ、カスタムイベントとカスタム属性の違い、分析を管理するためのベストプラクティスについて理解を深めましょう。

Brazeを実装する際には、マーケティング目標についてチームとよく話し合い、Brazeでトラッキングしたいデータとトラッキング方法を最適に決定できるようにしてください。例については、このガイドの最後にあるタクシー/ライドシェアアプリのケーススタディを参照してください。
SDKによって特定のユーザーデータが自動的に収集されます。例えば、アプリの初回使用日、最終使用日、合計セッション数、デバイスOSなどです。統合ガイドに従ってSDKを実装すると、このデフォルトのデータ収集を活用できます。このリストを確認することで、ユーザーに関する同じ情報を重複して保存することを避けられます。セッションの開始と終了を除き、その他の自動的にトラッキングされるデータはデータポイント使用量にカウントされません。
特定のデータ項目のデフォルト収集をブロックするプロセスを許可リストに追加する方法については、SDKの概要の記事を参照してください。
カスタムイベント
カスタムイベントはユーザーが実行するアクションであり、アプリケーションにおける価値の高いユーザーインタラクションのトラッキングに最適です。カスタムイベントを記録すると、設定可能な遅延を伴う任意の数のフォローアップキャンペーンをトリガーでき、そのイベントの最新性と頻度に関する以下のセグメンテーションフィルターが利用可能になります。
| セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
|---|---|---|
| カスタムイベントがX回を超えて発生したかどうかを確認する | MORE THAN | NUMBER |
| カスタムイベントがX回未満発生したかどうかを確認する | LESS THAN | NUMBER |
| カスタムイベントが正確にX回発生したかどうかを確認する | EXACTLY | NUMBER |
| カスタムイベントが最後にX日以降に発生したかどうかを確認する | AFTER | TIME |
| カスタムイベントが最後にX日以前に発生したかどうかを確認する | BEFORE | TIME |
| カスタムイベントが最後にX日以上前に発生したかどうかを確認する | MORE THAN | NUMBER OF DAYS AGO(正の数) |
| カスタムイベントが最後にX日以内に発生したかどうかを確認する | LESS THAN | NUMBER OF DAYS AGO(正の数) |
| カスタムイベントがX回(最大50回)を超えて発生したかどうかを確認する | MORE THAN | 過去Y日間(Y = 1、3、7、14、21、30) |
| カスタムイベントがX回(最大50回)未満発生したかどうかを確認する | LESS THAN | 過去Y日間(Y = 1、3、7、14、21、30) |
| カスタムイベントが正確にX回(最大50回)発生したかどうかを確認する | EXACTLY | 過去Y日間(Y = 1、3、7、14、21、30) |
Brazeは、これらのイベントが発生した回数と、各ユーザーが最後にそのイベントを実行した日時をセグメンテーション用に記録します。カスタムイベント分析ページでは、各カスタムイベントの発生頻度を集計で確認できるほか、より詳細な分析のためにセグメント別の時系列データも確認できます。これは、Brazeが時系列に重ねて表示するグレーの線(キャンペーンが最後に送信された日時を示す)を確認することで、キャンペーンがカスタムイベントアクティビティにどのような影響を与えたかを把握するのに特に役立ちます。


カスタム属性のインクリメントを使用すると、カスタムイベントと同様にユーザーアクションのカウンターを保持できます。ただし、カスタム属性データを時系列で表示することはできません。時系列で分析する必要のないユーザーアクションは、この方法で記録してください。
カスタムイベントの保存
すべてのユーザープロファイルデータ(カスタムイベント、カスタム属性、カスタムデータ)は、そのプロファイルがアクティブである限り保存されます。
カスタムイベントプロパティ
カスタムイベントプロパティを使用すると、Brazeではカスタムイベントや購入にプロパティを設定できます。これらのプロパティは、トリガー条件のさらなる絞り込み、メッセージングのパーソナライゼーションの強化、生データエクスポートによるより高度な分析の生成に使用できます。プロパティ値には、文字列、数値、ブール値、または時間オブジェクトを使用できます。ただし、プロパティ値に配列オブジェクトは使用できません。
例えば、eコマースアプリケーションがカートを放棄したユーザーにメッセージを送信したい場合、ユーザーのカートのcart_valueというカスタムイベントプロパティを追加することで、ターゲットオーディエンスをさらに改善し、キャンペーンのパーソナライゼーションを強化できます。

カスタムイベントプロパティは、メッセージングテンプレート内のパーソナライゼーションにも使用できます。トリガーイベントを持つアクションベース配信を使用するキャンペーンでは、そのイベントのカスタムイベントプロパティをメッセージのパーソナライゼーションに使用できます。ゲームアプリケーションがレベルをクリアしたユーザーにメッセージを送信したい場合、そのレベルのクリアにかかった時間のプロパティを使用してメッセージをさらにパーソナライズできます。この例では、条件ロジックを使用して3つの異なるセグメント向けにメッセージをパーソナライズしています。time_spentというカスタムイベントプロパティは、{{event_properties.${time_spent}}}を呼び出すことでメッセージに含めることができます。
1
2
3
4
5
6
7
{% if {{event_properties.${time_spent}}} < 600 %}
Congratulations on beating that level so fast! Check out our online portal where you can play against top players from around the world!
{% elsif {{event_properties.${time_spent}}} < 1800 %}
Don't forget to visit the town store between levels to upgrade your tools.
{% else %}
Talk to villagers for essential tips on how to beat levels!
{% endif %}
カスタムイベントプロパティは、メッセージングのパーソナライズや、きめ細かなアクションベース配信キャンペーンの構築に役立つよう設計されています。イベントプロパティの最新性と頻度に基づいてセグメントを作成したい場合は、カスタマーサクセスマネージャーまたはサポートチームにお問い合わせください。
カスタム属性
カスタム属性は非常に柔軟なツールであり、標準属性よりも高い精度でユーザーをターゲティングできます。カスタム属性は、ユーザーに関するブランド固有の情報を保存するのに最適です。カスタム属性には時系列情報が保存されないため、カスタムイベントの前述の例のようなグラフは取得できない点にご注意ください。
カスタム属性の保存
すべてのユーザープロファイルデータ(カスタムイベント、カスタム属性、カスタムデータ)は、プロファイルがアクティブである限り保存されます。
カスタム属性のデータ型
以下のデータ型をカスタム属性として保存できます。
文字列(英数字)
文字列属性は、お気に入りのブランド、電話番号、アプリケーション内での最後の検索文字列など、ユーザー入力を保存するのに便利です。文字列属性には、カスタムデータの長さ制限が適用されます(479バイト。シングルバイト文字の場合は約479文字、日本語などのマルチバイトスクリプトの場合は約160文字)。
以下の表は、文字列属性で使用可能なセグメンテーションオプションを示しています。
| セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
|---|---|---|
| 文字列属性が入力された文字列と完全に一致するかを確認する | EQUALS | STRING |
| 文字列属性が入力された文字列または正規表現と部分的に一致するかを確認する | MATCHES REGEX | STRING OR REGULAR EXPRESSION |
| 文字列属性が入力された文字列または正規表現と部分的に一致しないかを確認する | DOES NOT MATCH REGEX | STRING OR REGULAR EXPRESSION |
| 文字列属性が入力された文字列と一致しないかを確認する | DOES NOT EQUAL | STRING |
| 文字列属性がユーザーのプロファイルに存在するかを確認する | IS BLANK | N/A |
| 文字列属性がユーザーのプロファイルに存在しないかを確認する | IS NOT BLANK | N/A |

DOES NOT MATCH REGEXフィルターを使用してセグメンテーションを行う場合、そのユーザープロファイルに値が割り当てられたカスタム属性がすでに存在している必要があります。Brazeでは、ユーザーを適切にターゲティングするために、「OR」ロジックを使用してカスタム属性が空白かどうかを確認することを推奨しています。

配列
配列属性は、ユーザーに関する関連情報のリストを保存するのに適しています。例えば、ユーザーが視聴した最新の100件のコンテンツを配列に保存すると、特定の興味関心に基づいたセグメンテーションが可能になります。
カスタム属性の配列は一次元のセットであり、多次元配列はサポートされていません。カスタム属性の配列に要素を追加すると、その要素が配列の末尾に追加されます。ただし、すでに存在する場合は、現在の位置から配列の末尾に移動されます。例えば、配列['hotdog','hotdog','hotdog','pizza']がインポートされた場合、一意の値のみがサポートされるため、配列属性には['hotdog', 'pizza']として表示されます。
配列が最大要素数に達した場合、最初の要素が破棄され、新しい要素が末尾に追加されます。以下は、Web SDKでの配列の動作を示すサンプルコードです。
1
2
3
4
5
6
var abUser = appboy.getUser();
// initialize array for this user, assuming max length of favorite_foods is set to 4.
abUser.setCustomUserAttribute('favorite_foods', ['pizza', 'wings', 'pasta']); // => ['pizza', 'wings', 'pasta']
abUser.addToCustomAttributeArray('favorite_foods', 'fries'); // => ['pizza', 'wings', 'pasta', 'fries']
abUser.addToCustomAttributeArray('favorite_foods', 'pizza'); // => ['wings', 'pasta', 'fries', 'pizza']
abUser.addToCustomAttributeArray('favorite_foods', 'ice cream'); // => ['pasta', 'fries', 'pizza', 'ice cream']
配列のデフォルトおよび最大要素数は500です。最大配列数は、Brazeダッシュボードのデータ設定 > カスタム属性で更新できます。最大要素数を超える配列は、最大要素数に切り詰められます。

配列カスタム属性がユーザープロファイルに表示されているにもかかわらず値が表示されない場合は、データ設定 > カスタム属性でその属性の最大長を確認してください。最大長が0の場合、値がプロファイルに表示されません。トラブルシューティング手順については、カスタム属性のデータ型を参照してください。
以下の表は、配列属性で使用可能なセグメンテーションオプションを示しています。
| セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
|---|---|---|
| 配列属性が入力された値と完全に一致する値を含むかを確認する | INCLUDES VALUE | STRING |
| 配列属性が入力された値と完全に一致する値を含まないかを確認する | DOESN’T INCLUDE VALUE | STRING |
| 配列属性が入力された値または正規表現と部分的に一致する値を含むかを確認する | MATCHES REGEX | STRING OR REGULAR EXPRESSION |
| 配列属性に値があるかを確認する | HAS A VALUE | N/A |
| 配列属性が空であるかを確認する | IS EMPTY | N/A |

日付
時間属性は、特定のアクションが最後に実行された日時を保存するのに便利で、ユーザーにコンテンツに特化した再エンゲージメントメッセージを提供できます。

カスタムイベントや購入イベントが最後に発生した日付は自動的に記録されるため、カスタム時間属性で重複して記録しないでください。
相対日付を使用した日付フィルター(例:1日以上前、2日未満前)は、1日を24時間として計算します。これらのフィルターを使用して実行するキャンペーンには、24時間単位で該当するすべてのユーザーが含まれます。例えば、「最後にアプリを使用したのが1日以上前」は、キャンペーンが実行される正確な時刻から「24時間以上前に最後にアプリを使用した」すべてのユーザーをキャプチャします。より長い期間を設定したキャンペーンでも同様です。つまり、有効化から5日間は、直前の120時間を意味します。
以下の表は、時間属性で使用可能なセグメンテーションオプションを示しています。
| セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
|---|---|---|
| 時間属性が選択した日付より前かを確認する | BEFORE | CALENDAR DATE SELECTOR |
| 時間属性が選択した日付より後かを確認する | AFTER | CALENDAR DATE SELECTOR |
| 時間属性がX日以上前かを確認する | MORE THAN | NUMBER OF DAYS AGO |
| 時間属性がX日未満前かを確認する | LESS THAN | NUMBER OF DAYS AGO |
| 時間属性がX日以上先かを確認する | IN MORE THAN | NUMBER OF DAYS IN FUTURE |
| 時間属性がX日未満先かを確認する | IN LESS THAN | NUMBER OF DAYS IN FUTURE |
| 時間属性がユーザーのプロファイルに存在するかを確認する | BLANK | N/A |
| 時間属性がユーザーのプロファイルに存在しないかを確認する | IS NOT BLANK | N/A |
数値
数値属性は幅広いユースケースがあります。増分型の数値カスタム属性は、特定のアクションやイベントが発生した回数を保存するのに便利です。標準的な数値は、靴のサイズやウエストサイズの記録、ユーザーが特定の製品機能やカテゴリを閲覧した回数の記録など、あらゆる用途に使用できます。

以下の表は、数値属性で使用可能なセグメンテーションオプションを示しています。
| セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
|---|---|---|
| 数値属性が数値より大きいかを確認する | MORE THAN | NUMBER |
| 数値属性が数値より小さいかを確認する | LESS THAN | NUMBER |
| 数値属性が数値と完全に一致するかを確認する | EXACTLY | NUMBER |
| 数値属性が数値と等しくないかを確認する | DOES NOT EQUAL | NUMBER |
| 数値属性がユーザーのプロファイルに存在するかを確認する | EXISTS | N/A |
| 数値属性がユーザーのプロファイルに存在しないかを確認する | DOES NOT EXIST | N/A |
ブール値(true/false)
ブール属性は、購読ステータスやユーザーに関するその他の単純なバイナリデータを保存するのに便利です。提供される入力オプションにより、変数が明示的にブール値に設定されたユーザーに加えて、その属性がまだ記録されていないユーザーも検索できます。
以下の表は、ブール属性で使用可能なセグメンテーションオプションを示しています。
| セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
|---|---|---|
| ブール値がであるかを確認する | IS | TRUE、FALSE、TRUE OR NOT SET、またはFALSE OR NOT SET |
| ブール値がユーザーのプロファイルに存在するかを確認する | EXISTS | N/A |
| ブール値がユーザーのプロファイルに存在しないかを確認する | DOES NOT EXIST | N/A |
購入イベント / 収益トラッキング
購入メソッドを使用してアプリ内購入を記録すると、各ユーザープロファイルのLTV(LTV)が確立されます。このデータは、収益ページの時系列グラフで確認できます。
以下のテーブルは、購入イベントで利用可能なセグメンテーションオプションを示しています。
| セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
|---|---|---|
| 合計支出額がある数値より大きいかどうかを確認する | GREATER THAN | NUMBER |
| 合計支出額がある数値より小さいかどうかを確認する | LESS THAN | NUMBER |
| 合計支出額がある数値と正確に一致するかどうかを確認する | EXACTLY | NUMBER |
| 最後の購入がX日以降に発生したかどうかを確認する | AFTER | TIME |
| 最後の購入がX日以前に発生したかどうかを確認する | BEFORE | TIME |
| 最後の購入がX日以上前に発生したかどうかを確認する | MORE THAN | TIME |
| 最後の購入がX日以内に発生したかどうかを確認する | LESS THAN | TIME |
| 購入がX回(最大50回)を超えて発生したかどうかを確認する | MORE THAN | 過去Y日間(Y = 1、3、7、14、21、30) |
| 購入がX回(最大50回)未満発生したかどうかを確認する | LESS THAN | 過去Y日間(Y = 1、3、7、14、21、30) |
| 購入が正確にX回(最大50回)発生したかどうかを確認する | EXACTLY | 過去Y日間(Y = 1、3、7、14、21、30) |

タクシー/ライドシェアアプリのユースケース
この例では、どのユーザーデータを収集するかを決定したいライドシェアアプリを考えてみましょう。以下の質問とブレインストーミングのプロセスは、マーケティングチームと開発チームが参考にできる優れたモデルです。この演習を終了すると、両方のチームは、目標を達成するためにどのカスタムイベントと属性を収集するとよいかが明確にわかるでしょう。
ケースの質問 No.1: 目標は何ですか?
目標は明確で、ユーザーにアプリ経由でタクシーを呼んでもらうことです。
ケースの質問 No.2: アプリをインストールしてからその目標に至るまで、どのような中間ステップがありますか?
- ユーザーは登録プロセスを開始して、個人情報を入力する必要があります。
- ユーザーは登録プロセスを完了し、SMS経由で受け取ったコードをアプリに入力して確認する必要があります。
- ユーザーはタクシーを呼ぶ必要があります。
- タクシーを呼ぶには、ユーザーが検索したときにタクシーが利用できなければなりません。
これらのアクションには、以下のカスタムイベントとしてタグを付けることができます。
- 登録開始
- 登録完了
- タクシーの呼び出し成功
- タクシーの呼び出し失敗
イベントを実装した後、次のキャンペーンを実行できます。
- 登録を開始したが、一定期間内に登録完了イベントをトリガーしなかったユーザーにメッセージを送信する。
- 登録を完了したユーザーにお祝いのメッセージを送信します。
- タクシーの呼び出しに失敗し、一定時間内に成功したタクシーの呼び出しがなかったユーザーに謝罪とプロモーションクレジットを送信します。
- タクシーの呼び出し成功数が多いパワーユーザーに、ロイヤルティへの感謝の気持ちを示すプロモーションを送信します。
そして他にもたくさんあります!
ケースの質問 No.3: メッセージングに役立つ、ユーザーに関する他のどのような情報が必要でしょうか?
- プロモーションクレジットを持っているかどうか?
- ユーザーによるドライバーの平均評価は?
- ユーザー固有のプロモーションコードがあるか?
これらの特性には、以下のカスタム属性のタグを付けることができます。
- プロモーションクレジット残高(10進数型)
- ドライバーの平均評価(数値型)
- 固有のプロモーションコード(文字列型)
これらの属性を追加することで、次のようなキャンペーンをユーザーに送信できるようになります。
- 7日間ログインしていないがプロモーションクレジットを持っているユーザーに、そのクレジットが存在することと、アプリに戻って使用するよう通知する。
- 低いドライバー評価を与えたユーザーにメッセージを送り、なぜ乗車を楽しめなかったのかを確認するために直接フィードバックを得る。
- メッセージテンプレートとパーソナライゼーション機能を使用して、固有のプロモーションコード属性をユーザー向けのメッセージングに付け加えます。
ベストプラクティス
一般的なベストプラクティス
イベントプロパティを使用する
- カスタムイベントには、ユーザーが行うアクションを説明する名前を付けてください。
- カスタムイベントプロパティを積極的に活用し、イベントに関する重要なデータを表現してください。
- たとえば、50種類の映画をそれぞれ視聴するたびに別々のカスタムイベントを記録するのではなく、単に「映画を視聴した」というイベントとして記録し、映画の名前をイベントプロパティとして含める方がより効果的です。
開発のベストプラクティス
すべてのユーザーにユーザーIDを設定する
ユーザーIDは各ユーザーに対して設定する必要があります。ユーザーIDは変更されないものであり、ユーザーがアプリを開いたときにアクセス可能であるべきです。この識別子を提供することを強く推奨します。これにより、以下が可能になります:
- デバイスやプラットフォームをまたいでユーザーを追跡し、行動データや人口統計データの品質を向上させる。
- ユーザーデータAPIを使用してユーザーに関するデータをインポートする。
- メッセージングAPIを使用して、一般的なメッセージとトランザクションメッセージの両方で特定のユーザーをターゲットにする。
ユーザーIDは512文字未満でなければならず、プライベートかつ容易に取得できないものである必要があります(たとえば、プレーンなメールアドレスやユーザー名は使用しないでください)。このような識別子が利用できない場合、Brazeはユーザーに一意の識別子を割り当てますが、ユーザーIDで挙げた機能は利用できなくなります。個人に紐付けられた一意の識別子がないユーザーに対しては、ユーザーIDの設定を避けるべきです。デバイス識別子を渡しても、Brazeがデフォルトで提供する匿名ユーザーの自動トラッキングに対してメリットはありません。以下に、適切なユーザーIDと不適切なユーザーIDの例を示します。
ユーザーIDとして適切な選択肢:
- ハッシュ化されたメールアドレスまたは一意のユーザー名
- 一意のデータベース識別子
ユーザーIDとして使用すべきでないもの:
- デバイスID
- 乱数またはセッションID
- 一意でないID
- メールアドレス
- 別のサードパーティベンダーのユーザーID

カスタムイベントと属性に分かりやすい名前を付ける
実装から1~2年後にBrazeを使い始めるマーケターを想像してみてください。追加のコンテキストなしに「usr_no_acct」のような名前が並んだドロップダウンリストを見ると、戸惑うかもしれません。イベントと属性に識別しやすく読みやすい名前を付けることで、プラットフォームのすべてのユーザーにとって扱いやすくなります。以下のベストプラクティスをご検討ください:
- カスタムイベントの名前を数字で始めないでください。ドロップダウンリストはアルファベット順にソートされるため、数字で始めると希望するフィルターでのセグメンテーションが困難になります。
- 可能な限り、分かりにくい略語や専門用語を使用しないようにしてください。
- 例:
usr_ctryはコード内でユーザーの国を示す変数名としては問題ありませんが、カスタム属性としてBrazeに送信する場合は、user_countryのような名前にすることで、後々ダッシュボードを使用するマーケターにとってわかりやすくなります。
- 例:
属性は変更があった場合のみログに記録する
Brazeに渡されたすべての属性は、以前に保存されたのと同じ値が渡された場合でも、データポイントとしてカウントされます。データが変更された場合にのみログを記録することで、冗長なデータポイントの使用を避け、不要なAPI呼び出しを回避してよりスムーズなエクスペリエンスを実現できます。
イベント名をプログラムで生成しない
常に新しいイベント名を生成していると、ユーザーを意味のある形でセグメント化することが不可能になります。通常は、「動画を視聴した」や「記事を読んだ」のような汎用的なイベントを記録すべきであり、「Gangnam Styleを視聴した」や「記事を読んだ: ミッドタウンマンハッタンのランチスポットベスト10」のような非常に具体的なイベントは避けるべきです。イベントに関する具体的なデータは、イベント名の一部としてではなく、イベントプロパティとして含めてください。
技術的な制限と制約
カスタムイベントを実装する際には、以下の制限と制約に注意してください:
文字長の制約
Brazeは、カスタムイベント名、カスタム属性名(キー)、およびカスタムイベントの文字列値に対して、バイト単位の長さ制限(479バイト)を適用します。この制限を超える値は切り捨てられます。文字数で表すと、シングルバイト文字(ASCII など)の場合は約479文字、日本語のようなマルチバイトスクリプトの場合は約160文字(UTF-8で1文字あたり約3バイトと仮定)に相当します。理想的には、アプリのネットワークおよびバッテリーパフォーマンスを向上させるため、名前と値はできるだけ短くし、可能であれば50文字以内に制限してください。
コンテンツの制約
以下のコンテンツは、属性やイベントからプログラムで自動的に除去されます。以下の使用にはご注意ください:
- 先頭と末尾の空白
- 改行
- 電話番号内のすべての数字以外の文字
- 例:「(732) 178-1038」は「7321781038」に変換されます
- 空白以外の文字はスペースに変換される必要があります
- $をカスタムイベントのプレフィックスとして使用しないでください
- 無効なUTF-8エンコーディング値
- 「My \x80 Field」は「My Field」に変換されます
予約済みキー
以下のキーは予約されており、カスタムイベントプロパティとして使用できません:
timeproduct_idquantityevent_namepricecurrency
値の定義
- 整数値は64ビットです
- 小数はデフォルトで15桁の精度を持ちます
汎用の名前フィールドの解析
ユーザーに対して「JohnDoe」のような単一の汎用名前フィールドのみが存在する場合、このタイトル全体をユーザーの名属性に割り当てることができます。さらに、スペースを使用してユーザーの名と姓の両方を解析することも試みることができますが、この方法には一部のユーザーの名前を誤って設定してしまうリスクがあります。