KARTEのユーザー解析基盤の刷新によって、新解析基盤ではユーザー解析における「強整合性」がサポートされるようになりました。ここでは、「強整合性」のメリットについて説明します。
ユーザー解析における「強整合性」とは？
ユーザー解析における「強整合性」とは、一言でいうと「あるイベント発生時点に参照されるユーザーデータがそれ以前に発生したイベント全てを反映した最新の状態であることが保証される性質」のことです。
具体的な事例で見てみましょう。
「強整合性」が無いとき
KARTEにおけるユーザー解析とは、次のようなプロセスです。
- あるユーザーにイベントが発生する
- そのユーザーの「現在のユーザーデータ」と「現在発生したイベント」を使って最新のユーザーデータが計算される
- 計算されたユーザーデータを使ってセグメントの判定などが行われる
- 計算されたユーザーデータによって「現在のユーザーデータ」を置き換える
このユーザー解析は、ユーザーに対してイベントが発生する度に行われます。
「強整合性」が無い場合、同一ユーザーに複数のイベントが十分な間隔を空けずに連携されると次のようになることがありました。
- イベントAが発生
- 間髪入れずにイベントBが発生
- このとき、イベントAの解析完了が間に合わず、「現在のユーザーデータ」にイベントAの内容が反映されていないことがある
「強整合性」があるとき
KARTEの新解析基盤ではユーザー解析における「強整合性」がサポートされるようになりました。
これにより、複数のイベントが十分な間隔を空けずに連携された場合であっても、ユーザー解析のタイミングで必ず1つ前までのイベントの内容が「現在のユーザーデータ」に反映された状態になります。
「強整合性」があると嬉しいケース
「強整合性」がサポートされたことで、「ある時点で参照されるユーザーデータが古いこと」に起因して発生していた下記のような問題が解消されることがあります。
- 解消されうる問題例
- 古いユーザーデータを使ってセグメント判定が実行され、配信されるはずの接客サービスが配信されなかった
- 古いユーザーデータを使ってセグメント判定が実行され、配信されないはずの接客サービスが配信されてしまった
- 接客サービスの配信停止条件を設定したが、古いユーザーデータを使って判定がされうまく配信停止されなかった
- ユーザー情報変数で接客アクションにユーザー情報を埋め込んだが、古いユーザーデータが埋め込まれてしまった
ユーザー解析の仕様変更について
改めて、ユーザー解析に関して新旧の解析基盤を比較した場合の仕様変更ポイントについて説明します。
「強整合性」のサポート
旧解析基盤
これまで説明した通り、旧解析基盤では「強整合性」はサポートされず、ユーザー解析の結果が実際のユーザーデータに反映されるまでの間にタイムラグがありました。
そのため「古いユーザーデータ」が参照されるケースがあり、様々な問題を引き起こしていました。
新解析基盤
新解析基盤では、ユーザー解析の強整合性がサポートされるようになりました。
あるイベント発生時点に参照されるユーザーデータがそれ以前に発生したイベント全てを反映した最新の状態であることが保証されるようになります。
イベントの同時解析の廃止
旧解析基盤
ユーザー解析の強整合性を活かすためには、イベントの発生順序が重要になります。
実は、旧解析基盤では「ほぼ同時に発生した複数のイベントについては一度にまとめてユーザー解析される」という挙動をする場合がありました。
ただし、複数イベントが必ず同時に解析される保証は無く、不安定な挙動になっていました。
新解析基盤
新解析基盤ではユーザー解析の強整合性をサポートするために「イベントの同時解析」が起きないようにし、よりシンプルでわかりやすい仕様に変更されました。
言い換えると、「イベントには必ず前後関係がある」という前提で処理がされるようになります。
なお、「イベントの同時解析」を前提に配信設定をしていた接客サービスについては、解析基盤の移行前後で挙動が変わるケースがあります。
注意点
ユーザーのマージ処理のタイミングについて
- 複数のイベントが同一リクエストで送信された場合、かつその中にユーザーのマージを発生させるイベントが含まれていた場合には、ユーザーのマージ処理自体は処理の最後に行われます
具体例
- ビジターに対してviewイベントとidentifyイベントがほぼ同時に発生し、同一リクエストでKARTEに送られた
- このとき、viewイベントとidentifyイベントの解析順は制御できない
- 一方で、identifyイベントにuser_idが含まれている場合、ユーザーのマージ処理が発生する
- このユーザーのマージ処理については、viewイベントやidentifyイベントの解析よりも後に行われる
よくある質問
Q. 「イベントの同時解析」を前提に設定していた接客サービスの配信設定はどのように変更すればいいですか？
たとえば次のような配信設定の接客サービスがあったとします。
- 対象ユーザー（セグメント）
- 「東京都に在住（
attributeイベントのpref_cdの最新の値が13に等しい）」
- 「東京都に在住（
- 配信トリガー
viewイベントの閲覧ページパスが/searchに等しい
このとき、旧解析基盤ではviewイベントとattributeイベントが同時解析されると、初めて送られたattributeイベントであっても接客サービスの対象ユーザーに入ることがありました。
しかし、新解析基盤では「強整合性」のサポートが優先されたことで「イベントの同時解析」は廃止されました。
ほぼ同時に発生したviewイベントとattributeイベントの両方の最新情報を考慮して接客サービスを配信したい場合は、次のいずれかの方法で配信設定してください。
イベント送信リクエスト（__metadata）イベントを利用する方法
閲覧ページURL等による条件設定であれば、イベント送信リクエスト（__metadata）イベントに対する条件を配信トリガーにAND条件で追加することができます。
- 対象ユーザー
- 全員
- 配信トリガー
attributeイベントのpref_cdが13に等しい- AND
__metadataイベントのpathnameが/searchに等しい
イベント送信リクエスト（__metadata）イベントについては、こちらのドキュメントをご覧ください。
セグメントを利用する方法
同じ条件をセグメントを作成して絞り込むこともできます。特に、イベント送信リクエスト（__metadata）イベントに存在しないフィールドに対する条件を指定したい場合は、こちらの方法を採用します。
- 対象ユーザー（セグメント）
- 「検索ページを閲覧中（
viewイベントの最新の閲覧ページパスが/searchに等しい）」
- 「検索ページを閲覧中（
- 配信トリガー
attributeイベントのpref_cdの最新の値が13に等しい
イベント送信の順番と解析の順番は一致しますか？
仕様上は一致するようになっています。
たとえば次のようなタグでWebページ上から2つのイベントを発生させたとします。
<script>
krt('send', 'identify');
krt('send', 'attribute');
</script>このとき、WebブラウザからKARTE側にイベントが送信される順番も、KARTEの解析基盤側で解析される順番も、いずれも「identifyイベント → attributeイベント」の順番になります。