分析の概要
このガイドは、Braze が収集するデータの種類、Braze でのカスタムイベントとカスタム属性の違い、およびこれらの分析を管理するためのベストプラクティスを理解するのに役立ちます。
Brazeの実装を完了する前に、マーケティングチームと開発チームがマーケティング目標について話し合う必要があります。追跡の対象と、Braze でそれを追跡する方法を決定するときは、これらの目標を検討し、そこから後方に作業していくと便利です。
このプロセスの例については、このガイドの最後にある[タクシー/ライドシェアアプリ]16のケースを参照してください。
自動的に収集されるデータ
最初に使用したアプリ、最後に使用したアプリ、合計セッション数、デバイス OS など、特定のユーザーデータは SDK で自動的に収集されます。統合ガイドに従って SDK を実装すると、このデフォルトデータ収集を利用できるようになります。このリストを確認することで、ユーザーに関する同じ情報を複数回保存しなくて済みます。セッションの開始と終了を除き、自動的に追跡される他のデータはすべて、データポイントの割り当てを消費しません。
特定のデータ項目のデフォルト収集をブロックするプロセスを許可するには、SDK プライマーに関する記事を参照してください。
カスタムイベント
カスタムイベントは、ユーザーによって行われるアクションです。これらは、アプリケーションとの高価値なユーザーインタラクションをトラッキングするのに最適です。カスタムイベントをログに記録すると、構成可能な遅延を設定して任意の数のフォローアップキャンペーンをトリガーできます。また、そのイベントの最新性と頻度に基づいて次のセグメンテーションフィルターが有効になります。
セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
---|---|---|
カスタムイベントがX回以上発生したかどうかを確認します | 以上 | 数値 |
カスタムイベントがX回未満で発生したかどうかを確認します | 未満 | 数値 |
カスタムイベントが正確にX回発生したかどうかを確認します | 完全一致 | 数値 |
カスタムイベントの最終発生時期が日付 X より後かをチェックする | 後 | 時間 |
カスタムイベントの最終発生時期が日付 X より前かをチェックする | 前 | 時間 |
カスタムイベントが最後に発生したのがX日以上前かどうか確認してください | 以上 | 過去の日数 (正の数) |
カスタムイベントが最後に発生したのがX日未満かどうか確認してください | 未満 | 過去の日数 (正の数) |
カスタムイベントがX(最大値 = 50)回以上発生したかどうかを確認する | 以上 | 過去 Y 日間 (Y = 1、3、7、14、21、30) |
カスタムイベントがX(最大 = 50)回未満発生したかどうかを確認する | 未満 | 過去 Y 日間 (Y = 1、3、7、14、21、30) |
カスタムイベントが正確にX(最大=50)回発生したかどうかを確認します | 完全一致 | 過去 Y 日間 (Y = 1、3、7、14、21、30) |
Braze はセグメンテーション用として、これらのイベントが発生した回数と、各ユーザーの最終実行時刻を記録します。カスタムイベントの分析ページで、各カスタムイベントが発生する頻度を集約して表示できます。また、より詳細な分析を行うために、経時的にセグメントごとに表示することもできます。これは、キャンペーンがカスタムイベントのアクティビティにどのように影響したかを確認するのに特に役立ちます。Brazeが時系列にオーバーレイする灰色の線を見て、最後にキャンペーンが送信された時を示します。
[カスタム属性を増やすと]10、カスタムイベントと同様にユーザーアクションのカウンターを保持できます。ただし、時系列でカスタム属性データを表示することはできません。ユーザーのアクションは、時系列で分析する必要がない場合、この方法で記録する必要があります。
カスタムイベントの保存
すべてのユーザープロファイルデータ(カスタムイベント、カスタム属性、カスタムデータ)は、それらのプロファイルがアクティブである限り保存されます。
カスタムイベントプロパティ
カスタムイベントのプロパティを使用すると、Brazeはカスタムイベントおよび購入にプロパティを設定することができます。したがって、これらのプロパティを使用して、トリガー条件の絞り込み、メッセージングのパーソナライゼーションの強化、未加工データのエクスポートによるより高度な分析の生成を行えます。プロパティ値は文字列、数値、ブール値、または時間オブジェクトにすることができます。ただし、プロパティ値は配列オブジェクトにすることはできません。
たとえば、ユーザーがカートを放棄したときに e コマースアプリケーションでそのユーザーにメッセージを送る必要がある場合、ユーザーのカートの「カート値」のカスタムイベントプロパティを追加することで、ターゲットオーディエンスをさらに改善し、キャンペーンのパーソナライゼーションを強化できます。
カスタムイベントプロパティは、メッセージングテンプレート内でパーソナライゼーションのためにも使用できます。トリガーイベントを使用した[アクションベースの配信]19]を使用する任意のキャンペーンは、メッセージングのパーソナライゼーションのためにそのイベントからカスタムイベントプロパティを使用できます。ゲームアプリケーションがレベルをクリアしたユーザーにメッセージを送信したい場合、そのレベルをクリアするのにかかった時間のプロパティを使用してメッセージをさらにパーソナライズすることができます。この例では、メッセージは条件付きロジックを使用して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 fromm 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 %}
カスタムイベントプロパティは、メッセージングをパーソナライズしたり、アクションベースの詳細な配信キャンペーンを構築したりするのに役立ちます。イベントプロパティの最新性と頻度に基づいてセグメントを作成したい場合は、カスタマーサクセスマネージャーまたはサポートチームに連絡してください。これには追加のデータコストがかかる場合があります。
カスタム属性
カスタム属性は、標準属性を使用した場合よりも高い特異性でユーザーをターゲットにすることができる非常に柔軟性の高いツールです。カスタム属性は、ユーザーに関するブランド固有の情報を保存するのに最適です。カスタム属性の時系列情報は保存されないため、前のカスタムイベントの例のようには時系列情報に基づくグラフを取得できないことに注意してください。
カスタム属性の保存
すべてのユーザープロファイルデータ(カスタムイベント、カスタム属性、カスタムデータ)は、それらのプロファイルがアクティブである限り保存されます。
カスタム属性のデータ型
カスタム属性として格納できるデータ型を以下に示します。
文字列(英数字)
文字列属性は、お気に入りのブランド、電話番号、アプリケーション内での最後の検索文字列など、ユーザー入力の保存に役立ちます。文字列属性の長さは最大 255 文字です。
次の表は、文字列属性に利用可能なセグメンテーションオプションについて説明しています。
セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
---|---|---|
文字列属性が入力された文字列と完全に一致するかどうかを確認します | 等しい | 文字列 |
文字列属性が入力された文字列部分的に一致するかどうか、または正規表現を確認します | 正規表現に一致する | 文字列 または 正規表現 |
文字列属性が、入力された文字列または正規表現と部分的に一致しないかどうかを確認します。 | 正規表現に一致しない | 文字列 または 正規表現 |
文字列属性が入力された文字列と一致しないかどうかを確認します | 等しくない | 文字列 |
ユーザーのプロファイルに文字列属性が存在するかどうかを確認します | 空白である | 該当なし |
ユーザーのプロファイルの文字列属性が存在しないかどうかを確認します | 空白でない | 該当なし |
セグメント化にDOES NOT MATCH REGEXフィルターを使用する場合、そのユーザープロファイルに値が割り当てられたカスタム属性が既に存在している必要があります。Brazeは、ユーザーを適切にターゲットするためにカスタム属性が空白かどうかを確認するために「OR」ロジックを使用することを提案しています。
正規表現フィルターの使用方法の詳細については、このドキュメントを参照してください Perl compatible regular expressions (PCRE)。
正規表現に関するその他のリソース:
配列
配列属性は、ユーザーに関する情報の関連リストの保存に適しています。例えば、ユーザーが視聴した最後のコンテンツ 100 個を配列内に保存すると、特定の関心に基づくセグメンテーションができます。
カスタム属性の配列は一次元のセットです。多次元配列はサポートされていません。カスタム属性配列に要素を追加すると、その要素が配列の最後に追加されます。ただし、すでに存在する場合は、現在の位置から配列の最後に移動されます。例えば、配列['hotdog','hotdog','hotdog','pizza']
がインポートされた場合、一意の値のみがサポートされるため、配列属性には['hotdog', 'pizza']
として表示されます。
配列が最大数の要素を含んでいる場合、最初の要素は破棄され、新しい要素が最後に追加されます。次に、Web SDKでの配列の動作を示すいくつかの例コードを示します:
1
2
3
4
5
6
7
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']
カスタム属性配列内の要素の最大数は、25にデフォルト設定されています。個々の配列の最大値は、Braze ダッシュボードの [データ設定] > [カスタム属性] で100まで増やすことができます。この最大数を増やす必要がある場合は、カスタマーサービスマネージャーに連絡してください。要素の最大数を超える配列は、含まれる要素が最大数になるよう切り捨てられます。
次の表は、配列属性の利用可能なセグメンテーションオプションについて説明しています。
セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
---|---|---|
配列属性に、入力された値と完全一致する値が含まれているかを確認します | 値を含む | 文字列 |
配列属性に、入力された値と完全一致する値が含まれていないかを確認します | 値を含まない | 文字列 |
配列属性に、入力された値、または正規表現と部分一致する値が含まれているかを確認します | 正規表現に一致する | 文字列 または 正規表現 |
配列属性に値があるかどうかを確認します | 値がある | 該当なし |
配列属性が空であるかどうかを確認します | 空である | 該当なし |
[Perl 互換の正規表現 (PCRE)]11 を使用します。
日付
時刻属性は、特定のアクションが最後に実行された時刻の保存に役立ちます。そのため、コンテンツ固有の再エンゲージメントメッセージをユーザーに提供できます。
カスタムイベントまたは購入イベントが最後に発生した日付は自動的に記録されるため、カスタム時刻属性を使用して重複記録しないでください。
相対日付 (1 日超前、2 日未満など) を使用した日付フィルターでは、1 日を 24 時間として扱います。これらのフィルターを使用して実行する任意のキャンペーンには、24時間単位ですべてのユーザーが含まれます。例えば、最後に使用したアプリが1日以上前の場合、キャンペーンが実行される正確な時刻から「最後にアプリを使用したのが24時間以上前」のすべてのユーザーをキャプチャします。同じことが、より長い日付範囲で設定されたキャンペーンにも当てはまります。つまり、アクティベーションからFIVE日後は、過去120時間を意味します。
次の表は、時間属性に利用可能なセグメンテーションオプションについて説明しています。
セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
---|---|---|
時間属性が、選択した日付よりも前であるかを確認します | 前 | カレンダー日付セレクター |
時間属性が、選択した日付よりも後であるかを確認します | 後 | カレンダー日付セレクター |
時間属性がX日以上前の日数前かどうかを確認します | 以上 | 過去の日数 |
時間属性がX日未満の数日前かどうかを確認します | 未満 | 過去の日数 |
時間属性がX日以上先の未来の日数であるかどうかを確認します | 超 (未来) | 未来の日数 |
時間属性がX日未満の未来の日数であるかどうかを確認します | 未満 (未来) | 未来の日数 |
ユーザーのプロファイルに時間属性が存在するかどうかを確認してください | 空白 | 該当なし |
ユーザーのプロファイルに時間属性が存在しないかどうかを確認してください | 空白でない | 該当なし |
数値
数値属性にはさまざまな使用例があります。数値のカスタム属性を増分すると、特定のアクションやイベントが発生した回数を保存する場合に便利です。標準的な数値には、靴の大きさ、ウエストのサイズ、ユーザーが特定の商品の特徴やカテゴリーを見た回数の記録など、あらゆる種類の用途があります。
支出した金額はこの方法で記録すべきではありません。むしろ、購入方法で記録すべきです。
次の表は、数値属性に利用可能なセグメンテーションオプションについて説明しています。
セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
---|---|---|
数値属性が数値より大きいかどうかを確認します | 以上 | 数値 |
数値属性が 数値より小さいかどうかを確認します | 未満 | 数値 |
数値属性が正確に数値であるかどうかを確認します | 完全一致 | 数値 |
数値属性が数値と等しくないかどうかを確認します | 等しくない | 数値 |
ユーザーのプロファイルに数値属性が存在するかどうかを確認します | 存在する | 該当なし |
ユーザーのプロファイルに数値属性が存在しないかどうかを確認してください | 存在しません | 該当なし |
Booleans (true/false)
ブール属性は、サブスクリプションステータスやユーザーに関するその他の単純なバイナリデータを保存するのに役立ちます。私たちが提供する入力オプションを使用すると、変数がブール値に明示的に設定されているユーザーと、その属性がまだ記録されていないユーザーを見つけることができます。
次の表は、ブール属性の利用可能なセグメンテーションオプションについて説明しています。
セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
---|---|---|
ブール値であるかを確認します | である | 真、偽、真または設定されていない、または偽または設定されていない |
ユーザーのプロファイルにブール値existsがあるかどうかを確認します | 存在する | 該当なし |
ユーザーのプロファイルにブール値が存在しないかどうかを確認してください | 存在しません | 該当なし |
購入イベント/収益トラッキング
アプリ内購入の記録に弊社の購入方法を使用すると、個々のユーザープロファイルに生涯価値 (LTV) が設定されます。このデータは、時系列グラフで収益ページ内で表示できます。
次の表は、購入イベントのために利用可能なセグメンテーションオプションを説明しています。
セグメンテーションオプション | ドロップダウンフィルター | 入力オプション |
---|---|---|
合計支出額が数値より大きいかどうかを確認してください | より大きい | 数値 |
合計支出額が特定の数値未満であるかを確認します | 未満 | 数値 |
合計支出額が正確に数値であるか確認してください | 完全一致 | 数値 |
購入の最終発生時期が日付 X より後かを確認します | 後 | 時間 |
購入の最終発生時期が日付 X より前かを確認します | 前 | 時間 |
前回の購入がX日以上前かどうか確認してください | 以上 | 時間 |
購入が最後に発生したのがX日未満かどうか確認してください | 未満 | 時間 |
購入がX(最大=50)回以上発生したかどうかを確認してください | 以上 | 過去 Y 日間 (Y = 1、3、7、14、21、30) |
購入がX(最大50)回未満で発生したかどうかを確認してください | 未満 | 過去 Y 日間 (Y = 1、3、7、14、21、30) |
購入が正確にX(最大50)回発生したかどうかを確認する | 完全一致 | 過去 Y 日間 (Y = 1、3、7、14、21、30) |
特定の購入の発生回数でセグメンテーションを行う場合は、その購入を個別に [増分カスタム属性]12 として記録する必要もあります。
タクシー乗車共有アプリのユースケース
この例では、どのユーザーデータを収集するかを決定したいライドシェアアプリを考えてみましょう。優れたモデルとして、以下の質問とブレインストーミングのプロセスに沿って進めることをマーケティングチームと開発チームにお勧めします。この演習を終了すると、両方のチームは、目標を達成するためにどのカスタムイベントと属性を収集するとよいかが明確にわかるでしょう。
ケースの質問 No.1: 目標は何ですか?
目標は明確で、ユーザーにアプリ経由でタクシーを呼んでもらうことです。
ケースの質問 No.2: アプリをインストールしてからその目標に至るまで、どのような中間ステップがありますか?
- ユーザーは登録プロセスを開始して、個人情報を入力する必要があります。
- ユーザーは登録プロセスを完了し、SMS 経由で受け取ったコードをアプリに入力して確認する必要があります。
- ユーザーはタクシーを呼ぶ必要があります。
- タクシーを呼ぶには、ユーザーが検索したときにタクシーが利用できなければなりません。
これらのアクションには、以下のカスタムイベントとしてタグを付けることができます。
- 登録開始
- 登録完了
- タクシーの呼び出し成功
- タクシーの呼び出し失敗
イベントを実装した後、次のキャンペーンを実行できます。
- 登録を開始したが、一定期間内に登録完了イベントをトリガーしなかったユーザーにメッセージを送信する。
- 登録を完了したユーザーにお祝いのメッセージを送信します。
- タクシーの呼び出しに失敗し、一定時間内に成功したタクシーの呼び出しがなかったユーザーに謝罪とプロモーションクレジットを送信します。
- タクシーの呼び出し成功数が多いユーザーに、上顧客への感謝の気持ちを示すプロモーションを送信します。
そして他にもたくさん!
ケースの質問 No.3: 私たちのメッセージングに役立つ、ユーザーに関する他のどのような情報が必要でしょうか?
- 彼らがプロモーションクレジットを持っているかどうか?
- ユーザーによるドライバーの平均評価は?
- ユーザー固有のプロモーションコードがあるか?
これらの特性には、以下のカスタム属性のタグを付けることができます。
- プロモーションクレジット残高 (10 進数型)
- ドライバーの平均評価 (数値型)
- 固有のプロモーションコード (文字列型)
これらの属性を追加することで、次のようなユーザーにキャンペーンを送信する機能が得られます。
- 7日間ログインしていないがプロモーションクレジットを持っているユーザーに、そのクレジットが存在することと、アプリに戻って使用することを通知する。
- 低いドライバー評価を与えたユーザーにメッセージを送り、なぜ彼らが乗車を楽しめなかったのかを確認するために直接の顧客フィードバックを得る。
- 当社の[メッセージテンプレートおよびパーソナライゼーション機能]17を使用して、固有のプロモーションコード属性をユーザー向けのメッセージングにドラッグします。
ベストプラクティス
一般的なベストプラクティス
イベントプロパティを使用する
- ユーザーが行うアクションを説明するカスタムイベントに名前を付けます。
- カスタムイベントのプロパティを十分に活用して、イベントに関する重要なデータを表現してください。
- たとえば、50本の異なる映画のそれぞれを視聴するために別々のカスタムイベントをキャプチャするのではなく、映画を視聴することをイベントとしてキャプチャし、イベントプロパティに映画の名前を含める方が効果的です。
開発のベストプラクティス
すべてのユーザーにユーザーIDを設定する
ユーザーIDは、各ユーザーに設定する必要があります。これらは変更されず、ユーザーがアプリを開いたときにアクセスできるようにする必要があります。この識別子を提供することを強くお勧めします。これにより、次のことが可能になります:
- デバイスやプラットフォームを超えてユーザーを追跡し、行動データや人口統計データの質を向上させます。
- [ユーザーデータ API]9 を使用して、ユーザーに関するデータをインポートします。
- 一般的なメッセージとトランザクションメッセージの両方に関して、[メッセージング API]10 を使用して特定のユーザーをターゲットにします。
ユーザーIDは512文字未満でなければならず、プライベートで簡単に取得できないものであるべきです(例えば、単純なメールアドレスやユーザー名ではない)。そのような識別子が利用できない場合、Brazeはユーザーに一意の識別子を割り当てますが、ユーザーIDに対してリストされている機能が欠けています。個人として紐づけられた固有の識別子を持たないユーザーに対して、ユーザーIDの設定を避けるべきです。デバイス識別子を渡すことは、Brazeがデフォルトで提供する自動匿名ユーザートラッキングに対して何の利益も提供しません。以下は、適切および不適切なユーザーIDの例です。
適切なユーザー ID の例:
- ハッシュ化されたメールアドレスまたは一意のユーザー名
- 一意のデータベース識別子
これらはユーザーIDとして使用しないでください:
- デバイス ID
- ランダムな数値またはセッションID
- 一意でない ID
- メールアドレス
- 別のサードパーティベンダーのユーザー ID
さらにセキュリティを高めるために、ユーザーの偽装やなりすましを防ぐSDK認証機能を追加することをお勧めする。
カスタムイベントと属性に読みやすい名前を付ける
想像してみてください、あなたがBrazeを導入してから1年か2年後に使用を開始するマーケターで、「usr_no_acct」のような名前が並んだドロップダウンリストを文脈なしで読むのは怖いかもしれません。イベントと属性に識別可能で読みやすい名前を付けることで、プラットフォームのすべてのユーザーにとって物事が容易になります。次のベストプラクティスを考慮してください:
- カスタムイベントは数字で始めないでください。ドロップダウンリストはアルファベット順に並べられており、数値文字で始まると、選択したフィルターでセグメント化するのがより難しくなります。
- 可能な限り難解な略語や専門用語を使用しないようにしてください
- 例:
usr_ctry
はコード内のユーザーの国を示す変数名としては問題ないかもしれませんが、カスタム属性は Braze にuser_country
のように送信して、後でダッシュボードを使用するマーケターに明確さを提供する必要があります。
- 例:
属性が変更されたときにのみログに記録する
私たちは、Brazeに渡されたすべての属性をデータポイントとしてカウントします。たとえ渡された属性が以前に保存されたものと同じ値を含んでいてもです。変更時にのみデータを記録することで、冗長なデータポイントの使用を回避し、不必要なAPI呼び出しを避けることでスムーズな体験をサポートします。
プログラムでイベント名を生成するのを避ける
新しいイベント名を常に作成している場合、ユーザーを意味のあるセグメントに分割することは不可能です。一般的なイベント(「動画を見た」や「記事を読んだ」)をキャプチャするべきであり、「江南スタイルを見た」や「記事を読んだ」のような非常に具体的なイベントではありません。ミッドタウンマンハッタンのベスト10ランチスポットイベントに関する具体的なデータは、イベント名の一部ではなく、イベントプロパティとして含める必要があります。
技術的な制限と制約
カスタムイベントを実装する際の次の制限と制約に注意してください:
長さの制約
すべてのカスタムイベント、カスタム属性名 (キー)、およびカスタムイベント文字列の値で255文字以上のものは切り捨てられます。理想的には、ネットワークと、アプリのバッテリーのパフォーマンスを向上させるために、これらはできる限り短くする必要があります。可能であれば、50文字に制限してください。
コンテンツの制約
次の内容は、属性とイベントからプログラムによってトリミングされます。次のことを使用しないように注意してください:
- 先頭と末尾の空白
- 改行
- 電話番号内のすべての数字以外の文字
- 例: “(732) 178-1038” は “7321781038” に凝縮されます
- 空白以外の文字はスペースに変換する必要があります
- $ は、カスタムイベントのプレフィックスとして使用しないでください。
- 無効なUTF-8エンコーディング値
- 「私の \\x80 フィールド」は「私のフィールド」に凝縮されます
予約済みのキー
以下のキーは予約されているため、カスタムイベントプロパティとして使用できません。
time
product_id
quantity
event_name
price
currency
値の定義
- 整数値は64ビットです
- デフォルトで小数は15桁の小数桁数を持っています
一般名フィールドの解析
ユーザーに対して1つの汎用名フィールドしか存在しない場合(「JohnDoe」など)、このタイトル全体をユーザーの名属性に割り当てることができます。さらに、スペースを使用してユーザーの名前と姓の両方を解析しようとすることもできますが、この後者の方法には一部のユーザーの名前を誤って認識するリスクがあります。