Show Menu
トピック×

個別訪問者数の識別

アドビでは Cookie を使用して個別のブラウザーおよびデバイスを追跡しています。

Analytics 訪問者 ID の順序

Adobe Analytics は、訪問者を識別するための様々な手段を提供しています。次の表に、Analytics で訪問者が識別される方法を優先順で示します。
使用順序
クエリパラメーター(収集方法)
次の場合に存在
1
vid(s.visitorID)
s.visitorID が設定されている場合
2
aid(s_vi Cookie)
訪問者 ID サービスを展開する前に訪問者が既に s_vi cookie を持っていた、または訪問者 ID 猶予期間が設定済みである。
3
mid(Experience Cloud 訪問者 ID サービスによって設定される AMCV_ Cookie)
訪問者のブラウザーが cookie(ファーストパーティ)を受け入れる場合
4
fid(フォールバックcookie)
訪問者のブラウザーが cookie(ファーストパーティ)を受け入れる場合
5
IP アドレス、ユーザーエージェント、ゲートウェイ IP アドレス
訪問者のブラウザーが cookie を受け入れない場合
多くの場合、2 ~ 3 の異なる ID が表示されますが、Analytics では前述の表に現れる最初の ID を正式な訪問者 ID として使用します。例えば、(「vid」クエリパラメーターに含まれる)カスタム訪問者 ID を設定している場合、その ID が同様にヒットした他の ID に先立って使用されます。
各 Analytics 訪問者 ID は、Adobe サーバー上の訪問者プロファイルに関連付けられます。訪問者プロファイルは、少なくとも 13 ヶ月操作が実行されなかった場合、訪問者 ID cookie の有効期限にかかわらず削除されます。

カスタム訪問者 ID

s.visitorID 変数を設定して訪問者を識別するためのカスタム方法を実装できます。
カスタム訪問者 ID は、訪問者を固有の方法で識別するサイトで使用できます。例えば、ユーザーがユーザー名とパスワードを使用して Web サイトにログインする際に生成される ID は、カスタム訪問者 ID です。
ユーザーの訪問者 ID を取得および管理できる場合は、次の方法を使用して ID を設定できます。
メソッド
説明
ブラウザーで JavaScript が使用されている場合または他の AppMeasurement ライブラリを使用している場合は、訪問者 ID をデータ収集変数に設定できます。
イメージリクエスト上のクエリ文字列パラメーター
これにより、ハードコードされたイメージリクエスト上の vid クエリ文字列パラメーターを使用して、訪問者 ID をアドビに送信できます。
Data Insertion API
JavaScript を受け付けないワイヤレスプロトコルを使用するデバイスでは、お使いのサーバーからアドビの収集サーバーに、 <visitorid/> XML 要素を含む XML ポストを送信できます。
URL の書き直しおよび VISTA
一部の導入アーキテクチャでは、cookie を設定できない場合に URL の書き直しによってセッションの状態を維持する機能をサポートしています。このような場合、アドビのエンジニアリングサービスで VISTA ルールを導入できます。このルールでは、ページの URL 内のセッション値を検索し、整形して、visid の各値に配置します。
カスタム訪問者 ID には十分な粒度と一意性が必要​ :カスタム訪問者 ID の実装が無効だと、データが不正確になったり、レポートのパフォーマンスが低下する可能性があります。カスタム訪問者 ID が十分な一意性と粒度を備えていない、または共通のデフォルト値(文字列「NULL」や「0」など)に誤って設定されている場合、Adobe Analytics では、多くの異なる訪問者からのヒットが 1 人の訪問者として表示されます。この状況は、データが不正確になる、訪問者のカウントが少なすぎる、その訪問者に対してセグメントが正しく機能しないなどの結果につながります。また、粒度が不十分なカスタム訪問者 ID を使用すると、Analytics レポートクラスターのノード間でデータが分散されなくなります。この場合、1 つのノードが過負荷になり、レポート要求をタイムリーに処理できなくなります。最終的には、そのレポートスイートに関するすべてのレポートが失敗します。
Analytics は数ヶ月分の不均衡なデータを処理できることが多いので、カスタム訪問者 ID が適切に実装されていなくても、レポートのパフォーマンスには直ちに影響しない可能性があります。ただし、時間の経過と共に、適切に実装されていないカスタム訪問者 ID の値が問題となり、影響を受けるレポートスイートの処理を Analytics で無効にする必要が生じる可能性があります。
実装者は、単一のカスタム訪問者 ID 値を、レポートスイートのトラフィックの 1%以上に対して与えないというガイドラインに従う必要があります。ほとんどのレポートスイートでは 1%のガイドラインで十分ですが、非常に大きなレポートスイートでは、レポートのパフォーマンスに影響を与える可能性がある実際の制限が 1%未満となる場合があります。

Analytics 訪問者 ID

ユーザーがサイトに訪問すると、ブラウザーへの HTTP 応答に cookie を含めることで、アドビの Web サーバーによって持続的 cookie が設定されます。この cookie は、指定されたデータ収集ドメインに対して設定されます。
リクエストがアドビのデータ収集サーバーに送信されると、ヘッダーで訪問者 ID cookie( s_vi )の有無がチェックされます。この cookie がリクエストに含まれている場合、この cookie を使用して訪問者が識別されます。この cookie がリクエストに含まれていない場合、サーバーは一意の訪問者 ID を生成し、それを HTTP 応答ヘッダー内に cookie として設定した後、リクエストとともに返送します。この cookie はブラウザーに保存され、以後にサイトを訪問したときにデータ収集サーバーに渡されます。これにより、以後の訪問時にその訪問者を識別できるようになります。

サードパーティ cookie と CNAME レコード

Apple Safari などのブラウザーによっては、現在の Web サイトのドメインと一致しないドメインから HTTP ヘッダーに設定される cookie については保存しないものもあります。例えば、 mysite.com を表示しているとき、データ収集サーバーが mysite.omtrdc.net である場合は、 mysite.omtrdc.net からの HTTP ヘッダーで返された Cookie はブラウザーによって拒否される可能性があります。
この問題を回避するために、多くのお客様は ファーストパーティ cookie を導入する 中で、データ収集サーバーの CNAME レコードを導入しています。お客様のドメインのホスト名をデータ収集サーバーにマッピングするように CNAME レコードを設定すると(例えば、 metrics.mysite.com mysite.omtrdc.net にマッピングする)、データ収集ドメインは Web サイトのドメインと一致するので、訪問者 ID cookie が保存されます。これによって訪問者 ID cookie が保存される可能性が高まりますが、CNAME レコードを設定し、データ収集サーバーの SSL 証明書を保持する必要があるので、ある程度のオーバーヘッドが生じます。

モバイルデバイスの cookie

cookie を使用してモバイルデバイスをトラッキングする場合、測定の実施方法を変更するために使用できる設定がいくつかあります。cookie の有効期間はデフォルトで 5 年ですが、CL クエリパラメーター変数( s.cookieLifetime )を使用してデフォルト設定を変更できます。CNAME 実装での cookie の場所を設定するには、CDP クエリ文字列 s.cookieDomainPeriods を使用します。値を指定しない場合のデフォルト値は 2 です。デフォルトの場所は domain.com です。CNAME を使用しない実装では、訪問者 ID cookie の場所は 207.net ドメインになります。

ID サービス

ID サービスは、従来の Analytics 訪問者 ID メカニズムに代わるものであり、ハートビートビデオ指標、Target と Analytics の統合および今後の Experience Cloud コアサービスと統合で必須となる機能です。
このサービスに関する製品ドキュメントについては「 ID サービス 」を参照してください。

モバイルデバイスの識別

ほとんどのモバイルデバイスがブラウザー cookie を受け付けます。ただし、デバイスが cookie を受け付けない場合は、別の方法を使用してワイヤレスデバイスを一意に識別します。
アドビでは、ほとんどのモバイルデバイスを一意に識別する様々な HTTP 加入者 ID ヘッダーを識別しています。これらのヘッダーには、デバイスの電話番号(または電話番号をハッシュ化したもの)やその他の識別子が含まれます。現在のほとんどのデバイスには、デバイスを一意に識別する 1 つ以上のヘッダーがあり、アドビのすべてのデータ収集サーバーでは、訪問者 ID の代わりにこれらのヘッダーが自動的に使用されます。
一般的なイメージリクエストでは、パス( /b/ss/rsid/1 /)内の「1」は、アドビサーバーに対して、gif イメージを返し、持続的な訪問者 ID cookie( AMCV_ または s_vi )の設定を試行するように命令します。ただし、デバイスが HTTP ヘッダーに基づいてモバイルデバイスとして認識される場合は、「1」の代わりに「5」が渡されます。これは、wbmp 形式のイメージを返す必要があることと、認識済みのワイヤレスヘッダーのリスト(cookie ではない)を使用してデバイスを識別する必要があることを示します。
次の表に、パス内の返されるイメージタイプ値(「1」または「5」)に基づいて使用される ID メソッドの順序を示します。
設定 ID メソッドの順序
/1/
デフォルト:
  • カスタム訪問者 ID
  • cookie
  • 加入者 ID ヘッダー
  • IP アドレス - ユーザーエージェント - ゲートウェイ IP アドレス
/5/ /5.1/ /5.5/
デバイスがワイヤレスデバイスとして識別されました。または、 /5/ はイメージリクエストに手動で設定されていました。
  • カスタム訪問者 ID
  • 加入者 ID ヘッダー
  • cookie
  • IP アドレス - ユーザーエージェント - ゲートウェイ IP アドレス
また、「1」または「5」はイメージリクエストに手動で渡すこともできますが、これらのコードは相互に排他的なので、常に「5」を渡すと、cookie がサポートされていても利用されません。デバイスが cookie をサポートしているかを判定できる独自のメカニズムを組み込んで、cookie をサポートしている場合にイメージ内で「5」ではなく「1」を渡すことができます。この状況で改善される精度は、cookie をサポートするモバイルデバイスの数に限られます。

加入者 ID ヘッダー

cookie には cookie の削除、cookie の承認、ゲートウェイ cookie 管理などに関する問題があるので、一般的に訪問者 ID は cookie よりも信頼性の高いユーザー識別方法です。
モバイル訪問者が使用している携帯電話会社のホワイトリストに追加されると、訪問者識別の変更を改善できます。携帯電話会社の訪問者 ID を利用するには、携帯電話会社に連絡して、ドメインをホワイトリストに追加するように依頼してください。さらに、携帯電話会社のホワイトリストに追加されると、それまでアクセスできなかった加入者 ID ヘッダーにアクセスできるようになります。
以下のヘッダー一覧は、ワイヤレスデバイスを識別するために使用します。ヘッダー処理アルゴリズムは、次の処理をおこないます。
  1. HTTP ヘッダーキー(「X-Up-Calling-Line-ID」などのヘッダーの名前)を抽出します。
  2. アルファベット(A ~ Z、a ~ z)以外の文字を除去します。
  3. ヘッダーキーを小文字に変換します。
  4. キーの末尾と次の表の値を比較して一致を見つけます。
ヘッダー
タイプ
callinglineid
ID
X-Up-Calling-Line-ID: 8613802423312
subno
ID
x-up-subno: swm_10448371100_vmag.mycingular.net
clientid
ID
uid
ID
x-jphone-uid: a2V4Uh21XQH9ECNN
clid
ID
X-Hts_clid: 595961714786
deviceid
ID
rim-device-id: 200522ae
forwardedfor
ID または IP アドレス
X-Forwarded-For: 127.0.0.1
msisdn
ID または IP アドレス
X-Wap-msisdn: 8032618185
clientip
IP アドレス
Client-ip: 10.9.41.2
wapipaddr
IP アドレス
X-WAPIPADDR: 10.48.213.162
huaweinasip
IP アドレス
x-huawei-NASIP: 211.139.172.70
userip
IP アドレス
UserIP: 70.214.81.241
ipaddress
IP アドレス
X-Nokia-ipaddress: 212.97.227.125
subscriberinfo
IP アドレス
X-SUBSCRIBER-INFO: IP=10.103.132.128
例えば、「callinglineid」は、「X-Up-Calling-Line-ID」および「nokia-callinglineid」に一致します。ヘッダータイプは、ヘッダーの内容を示します。ヘッダーの優先順位はこの表の並びのとおりです(「callinglineid」ヘッダーが存在する場合、そのヘッダーが「subno」の代わりに使用されます)。
この場合、 動的変数 を使用すると、ヘッダーから特定の値を抽出できます。

フォールバック ID による方法

訪問者 ID による他の方法が失敗した場合、アドビでは、フォールバック cookie を設定するか、IP アドレスとユーザーエージェントの組み合わせを使用して訪問者を識別します。

フォールバック訪問者の識別方法

JavaScript 1.x 版 AppMeasurement と JavaScript H.25.3(2013 年 1 月リリース)以降のバージョンは、アドビのデータ収集サーバーによって設定される cookie( s_vi )をブロックするブラウザーを使用している訪問者を対象とした、新しいフォールバック訪問者の識別方法を備えています。以前は、cookie を設定できない場合、データ収集時に IP アドレスとユーザーエージェント文字列の組み合わせを使用して訪問者を識別していました。
この更新により、標準的な s_vi cookie を使用できない場合は、ランダムに生成された一意の ID を使用して、Web サイトでフォールバック cookie が作成されます。この cookie は s_fid と呼ばれ、2 年間の有効期限付きで設定され、今後のフォールバック識別方法として使用されます。この変更により、プライマリ cookie( AMCV_ または s_vi )を設定できない状況での、訪問回数と訪問者数の精度が向上します。
訪問総数には、 s_vi cookie またはフォールバック方法を使用して識別されたすべての訪問者が含まれます。

IP アドレス、ユーザーエージェント、ゲートウェイ IP アドレス

の呼び出しの後におこなわれる場合です。 AMCV_ または s_vi s_fid のいずれの cookie も設定できない場合、訪問者は IP アドレスとユーザーエージェントの組み合わせによって識別されます。