KARTEでは、2人のユーザーが「実は同じユーザーである」ということがわかったときに、その2人のユーザーのデータをマージする仕組みが提供されています。ここでは、そのユーザーマージの仕様について簡単に紹介します。
前提知識
- KARTEの「ユーザー」に関する概要については、次の記事をご覧ください
ユーザーマージを発生させるべき状況の例
たとえば次のような状況では、ユーザーマージが発生させることでKARTE上で同一ユーザーとして判定できるようになります。
- 同一人物がスマートフォンのブラウザとPCのブラウザを使って同一Webサイトを利用しており、それぞれで同一アカウントにログインした場合
- 同一人物がWebブラウザとスマートフォンアプリを使って同一サービスを利用しており、それぞれで同一アカウントにログインした場合
- Webブラウザ経由でWebサイトにログインしており、何らかの理由でCookieが削除されたが、その後同じアカウントにログインし直した場合
KARTEでは、ブラウザやアプリに対してKARTEが払い出した visitor_id と呼ばれるIDを使って、アノニマスなユーザーの同一性を確認しています。そのため、ブラウザAとブラウザB、ブラウザとアプリ、などを同一人物が併用していても、KARTE上ではvisitor_idが別になり、別々のユーザー(ビジター)として扱われます。
KARTEにおけるユーザー種別と対応するID
現在、KARTEのユーザーには3つの種類があります。それぞれ、異なるIDをキーにしてユーザーの同一性が確認されます。
- ビジター
- KARTEがブラウザやアプリに対して払い出した visitor_id によって生成されるユーザー
- メンバー
- identifyイベントで連携された独自の user_id によって生成されるユーザー
- 一般的に、user_id にはサービス側で管理されるログインIDや、それをハッシュ化した値
- external user
- KARTEに連携された外部サービスのID( external_id )によって生成されるユーザー
なお、identifyイベントでuser_idが連携されていないユーザーについても、KARTE側では仮の user_id が発行されます。また、ユーザー種別毎に、そのユーザーをマージできる先のユーザー種別が異なります。
ユーザー種別 | 仮のuser_id | マージ先に指定できるユーザー種別 |
---|---|---|
ビジター | vis-{{visitor_id}} |
external user / メンバー |
external user | wuid-xxx-{{external_id}} |
メンバー |
わかりやすいように、マージできる/できない例をいくつか示します。
- マージできる例
- ◯ 「ビジター」を「external user」や「メンバー」にマージする
- ◯ 「external user」を「メンバー」にマージする
- ◯ 「ビジター」がマージされた「external user」をさらに「メンバー」にマージする
- マージできない例
- ✕ 「external user」を「ビジター」にマージする
- ✕ 「メンバー」を「external user」や「ビジター」にマージする
ユーザーマージを発生させる方法
実際にKARTEでユーザーマージを発生させる方法について紹介します。
identifyイベントを発生させ、user_idフィールドを連携する
まず、最も代表的なユーザーマージの方法について説明します。
KARTEでは、visitor_idしか保持していない「ビジター」に対してidentifyイベントを発生させuser_idフィールドを連携すると、そのユーザーは「ビジター」から「メンバー」に昇格します。
内部的には「ビジター」と「メンバー」は別ユーザーとして扱われますが、「ビジター」はidentifyイベントでuser_idフィールドが連携されるとそのuser_id値に対応する「メンバー」に対してユーザーマージされます。
また、1人の「メンバー」に複数の「ビジター」をマージすることもできます。前述のように、本来は同一人物であるはずのユーザーが別々の「ビジター」になってしまった場合であっても、それぞれに対して同一のuser_idを連携することで、1人の「メンバー」に対してマージすることができます。
これにより、最初は別々だったユーザーを「実は同じユーザーだった」とKARTE上で解釈しなおした上で、さらに自社の会員情報と紐付けることができます。
「external_id連携タグ」で外部サービスのIDを連携する
ビジターに対して「external_id連携タグ」を使って外部サービスのIDを連携し、ユーザーマージを発生させることもできます。この機能は、サーバーサイドCookieを使って「本来は同一ブラウザからのアクセスであるにも関わらずKARTE上では別々のユーザーとして計測されたビジター」をKARTE上でも同一ユーザーとして解釈し直したい、というニーズを満たすために用意されたものです。
この方法で「ビジター」がマージされる先は、「メンバー」ではなく「external user」になります。
「ビジター」 -> 「external user」 -> 「メンバー」という2段階のユーザーマージを順次発生させることも可能です。たとえば次のように、「external user」を介して複数の「ビジター」を「メンバー」にマージすることもできます。
- あるWebブラウザによるアクセスが「ビジター a」とみなされる
- 「ビジター a」に「external_id A」が連携され、「ビジター a」が「external_user A」にマージされる
- 何らかの理由でそのWebブラウザのCookieに書き込まれたvisitor_idが消失し、別の「ビジター b」とみなされるようになる
- 「ビジター b」に「external_id A」が連携され、「ビジター b」も「external_user A」にマージされる
- その後、そのWebブラウザでサービスにログインしたときにidentifyイベントで「user_id α」が連携され、「external_user A」が「メンバー α」にマージされる
これにより、意図せず別々のユーザーとみなされてしまった複数のビジターを、「実は同じユーザーだった」とKARTE上で解釈しなおすことができます。
KARTEで提供される一部の外部サービス連携機能で外部サービスIDが連携される
KARTEで提供される一部の外部サービス連携機能では、その外部サービスのIDがKARTEに連携された際に「external_user」が生成されたり、「ビジター」がその「external_user」にマージされたりすることがあります。
代表的なのは、KARTEのLINE連携機能です。
たとえば次のように、Web上の行動データが紐付く「ビジター」をLINEの行動データが紐付く「external_user」にマージさせたり、さらに「メンバー」にマージさせたりすることが可能です。
- KARTEのLINE連携機能により、LINE公式アカウントに友だち追加したユーザーのLINE IDが「external_id L」として連携され、「external_user L」が生成される
- 「ビジター a」がWebサイト上でLINEログインをしたことで、「ビジター a」に対して「external_id L」が連携され、「ビジター a」が「external_user L」にマージされる
- その後、そのWebブラウザでサービスにログインしたときにidentifyイベントで「user_id α」が連携され、「external_user L」が「メンバー α」にマージされる
これにより、Webサイトでの行動データ、LINEでの行動データ、独自の顧客属性データを横断したセグメント条件を設定したり、Web上の行動データを元にLINEのメッセージ配信を出し分けたりすることができます。
なお、KARTEのLINE連携機能については次の記事をご覧ください。
- LINE連携 - 概要 | ドキュメント / 接客タイプ / LINE | KARTEサポートサイト
- 接客サービスでLINE IDとユーザーIDを連携させる | ドキュメント / 接客タイプ / LINE | KARTEサポートサイト
ユーザーマージされるとどうなるか?
KARTE上でユーザーマージがされた場合の効果としては、主に次の2点あります。
- ユーザーストーリー画面の統合
- マージ前のユーザーに対して発生したイベントを、マージ後のユーザーのユーザーストーリー画面でまとめて見ることができるようになります
- ユーザーデータの統合
- マージ前後のユーザーのユーザーデータが統合され、セグメント条件判定等にマージ後のユーザーデータが使われるようになります
ここでは、2人の「ビジター」に対して同じuser_idをidentifyイベントで連携して同一の「メンバー」にマージしたケースを例に説明します。
ユーザーストーリー画面の統合
ユーザーマージが発生すると、マージ前のユーザーの情報をマージ後のユーザーのユーザーストーリー画面でまとめて見ることができるようになります。
たとえば「ビジター A (vis-A
)」に対して dummy-user-id
というuser_idをidentifyイベントで連携すると、「ビジターA」のユーザーストーリー画面には [マージ済み] というテキストでマージ後の「メンバー」のユーザーストーリー画面へのリンクが表示されます。
さらに「ビジター B (vis-B
)」に対して dummy-user-id
というuser_idを連携しても、同様になります。
マージ後の「メンバー」のユーザーストーリー画面を見ると、「ビジターA」時代のセッションと「ビジターB」時代のセッションが同一画面上で表示されていることがわかります。
また、「メンバー」へのマージ以降に「ビジターA」や「ビジターB」に対して発生したイベントは、自動的にマージ後の「メンバー」に対して紐付いて発生するようになり、「メンバー」のユーザーストーリー画面に表示されます。これにより、たとえばPCとスマートフォンなど全く別の端末でのユーザー行動であっても、1つの画面上で横断的に見ることができるようになります。
ユーザーデータの統合
ユーザーマージがされた場合の2つ目の主な効果は、ユーザーデータがマージされることです。
たとえば、それぞれ2回ずつviewイベントを発生させた2人の「ビジター」を1人の「メンバー」にマージした場合、その「メンバー」のviewイベントの送信回数は 2+2 で 4 になります。
もちろん「送信回数」だけではなく、様々な統計値がマージされるようになっています。次の画像は、viewイベントの「閲覧ページのパス」に関する統計値がマージ前後でどのように変化するかを示した例です。
同一人物のviewイベントやbuyイベントが別々のユーザーに対して発生した場合でも、こうしたユーザーデータのマージ処理によって、マージ後のユーザーの合算した統計値をもとにセグメント条件の判定を行うことができます。
誤ったユーザーマージを発生させてしまうとどうなるか?
ここまで見てきたように、ユーザーマージの処理はKARTE上でのユーザーの解釈を変える強力なものです。
他方、本来は別々の人物であるはずのユーザーを誤ってマージしてしまうと、取り返しがつかなくなってしまうケースがあります。たとえば、本来はユーザーAに対して紐付けたいIDや個人情報がユーザーBに紐付いてしまうことで、意図しない内容の接客サービスがユーザーに配信されてしまう恐れがあります。
ユーザーマージを発生させる「identifyイベント」や「external_id連携タグ」の実装をするときは、十分に検証を行い、意図しないIDが連携されないように注意してください。
よくある質問
Q. あるユーザーにマージされたユーザーの一覧を確認することはできますか?
マージ後のユーザーのユーザーストーリー画面から、そのユーザーに対してマージされたuser_idの一覧を確認できます。
- [表示中のユーザーデータ > ... > すべてのユーザーデータを見る] から[すべてのユーザーデータ]を開く
- [マージされたユーザー] という項目を検索する