Universal AnalyticsのUser IDはログイン会員へ自社IDを割り当てて端末をまたぐ行動をまとめる

Universal AnalyticsのUser IDは、ログインした会員を自社の認証システムで識別できるサイトに使います。会員ごとに自社で発行した同じIDをanalytics.jsへ渡すと、複数の端末やセッションに分かれた利用を一つのIDで分析できます。

User IDへ氏名、メールアドレス、電話番号を入れてはいけません。未ログインの訪問者を行動の似方から推測し、既存会員へ結び付けるものでもありません。自社がログインによって確定できる会員だけを対象にします。

User IDにはログイン後に確定する自社IDだけを渡す

User IDには、次の条件を満たす文字列を使います。

• 自社の認証システムが会員ごとに発行している
• 同じ会員へ継続して同じ値を割り当てる
• 端末が変わっても、ログインすれば同じ値を取得できる
• 値だけでは氏名や連絡先を特定できない

たとえば、説明用の仮例として、会員データベース内の連番をそのまま外部へ見せず、解析用に別の内部IDを割り当てます。IDと会員情報の対応は自社側で管理し、Google Analyticsへ対応表を送りません。

ブラウザーのCookie、IPアドレス、閲覧ページの組合せから会員を推測してIDを作らないことも重要です。自社の認証システムから得た、ログイン済み利用者の永続的で個人を直接識別しないIDをanalytics.jsへ設定します。

analytics.jsは認証せず確定したIDを送る

analytics.jsは、訪問者のログインを判定する仕組みではありません。認証システムがログイン済みの会員を確定し、そのIDをトラッカーへ渡します。

次は説明用の仮例です。signedInUserIdは、認証に成功した場合だけ、サーバー側から安全に出力される内部IDとします。

if (signedInUserId) {
	ga('create', 'UA-XXXX-Y', {
		'userId': signedInUserId
	});
} else {
	ga('create', 'UA-XXXX-Y');
}

ga('send', 'pageview');

ログインしていない場合はuserIdを設定しません。空文字、共通の仮ID、端末ごとに作った推測値を送ると、別の利用者を同じ会員としてまとめる原因になります。

ログイン状態がページの途中で変わるサイトでは、どの時点からIDを付けるかも決めます。コードを置く担当者だけに任せず、認証担当者、Google Analyticsプロパティの管理者、レポートを確認する担当者で条件を共有します。

計測コードとCross Device reportsは役割が違う

User IDの処理は、三つに分けると確認しやすくなります。

User IDのレポートは、会員名簿を作るための画面ではありません。4月2日に発表されたCross Device reportingは、画面、訪問、端末をまたぐ匿名の利用状況を見るための機能です。会員情報の管理は自社のシステムに残します。

機能が表示されることを確認してから実装する

User IDは4月2日に段階的な提供が始まりました。4月3日時点ではclosed betaで、すべての利用者に提供されていません。対象プロパティでUser IDを利用できない場合は、計測コードだけを先に入れて完了としません。

最初の一手は、テスト用会員を一人決め、その会員へ割り当てる内部ID、IDを出すログイン条件、IDの管理者を書き出すことです。次に、対象プロパティでUser IDを利用できるか確認します。利用できる場合だけ、テスト環境で一台目と二台目からログインし、同じIDが送られる範囲を確かめます。