Yahoo!検索の検索結果がSSL化されたことによる検索結果における現状(2015年8月20日現在)と、Googleアナリティクスで計測される数値の変化をまとめましたので本コラムにてご紹介させていただきます。
- Yahooの検索結果が18日より段階的にSSL化
- SSLと非SSLサイト間での通信について
- 検索結果からWebサイトへ流入するまでの流れ
- Googleアナリティクスで計測されている現状
- ga.jsにおける検索エンジン判定ロジックと思われる記述内容
- 現状での対応策について
Yahooの検索結果が18日より段階的にSSL化
Yahoo!検索の検索結果が2015年の8月18日より段階的にSSL化されています。段階的としているのは8月18日を起点に全てのYahoo!検索の検索結果がSSL化されるのではなく、少しずつSSL化された検索結果が浸透していくことをあらわします。
「Yahoo!検索」SSL化のお知らせ – Yahoo!検索ガイド – Yahoo! JAPAN
SSL化する理由として主にあげられるのは、SSL化しセキュリティレベルを向上することで、Yahoo!検索の検索ユーザーにおける検索結果でのプライバシーを守るといった意向のためと思われます。検索結果がSSL化することにより、検索ユーザーがどのような検索クエリで検索したのかを第三者が外部より確認することができなくなる一方、検索ユーザーが流入したサイトの運営者側にとっても、どのような検索クエリで検索してサイトにたどり着くことができたのかをアクセス解析ツールや生ログデータから取得することができなくなります。
SSLと非SSLサイト間での通信について
ここで念のために、SSL化されたサイトと非SSLサイト間での通信内容を非常にざっくりとおさらいします。
SSL化されたサイトから非SSLサイトに遷移した場合、非SSLサイト側にリファラーは受け渡すことができません。リファラーとは、Webサイト内に存在するリンクをクリックして別のWebサイトに遷移した際に、どこのWebサイトから遷移したのかを把握することができるアクセスログに記録される項目の1つとします。
一方、SSL化されたサイトからSSL化された別のサイトに遷移した場合は、両サイト間がSSL化された通信となるためリファラーを受け渡すことができます。
簡単にまとめると下記のようになります。
- 遷移した先のサイトBにリファラーを受け渡すことができる。
- サイトA(非SSL) → サイトB(非SSL)
- サイトA(非SSL) → サイトB(SSL)
- サイトA(SSL) → サイトB(SSL)
- 遷移した先のサイトBにリファラーを受け渡すことができない。
- サイトA(SSL) → サイトB(非SSL)
Yahoo!検索の検索結果もWebサイト内のページになりますので、上記のサイトAをYahoo!検索の検索結果とした場合、検索結果がSSL化されたことにより、検索結果からの遷移先であるサイトB(非SSL)にはリファラーを受け渡さないことをあらわします。
検索結果からWebサイトへ流入するまでの流れ
では、サイトをSSL化すればYahoo!検索の検索結果からリファラーを引き継ぐことができるのでしょうか? いいえ、そんなことをしてはYahoo!検索の検索ユーザーにおけるプライバシーを完全に守ることができないので、Yahoo!検索も検索結果にて対策を施しています。
実際に検索結果からWebサイトへ流入するまでのパケットキャプチャーツールで確認してみましょう。
1. Yahoo!検索にて「アユダンテ」と検索します。
下記が上記のYahoo!検索の検索結果ページにおけるURLとなります。
http://search.yahoo.co.jp/search?p=%E3%82%A2%E3%83%A6%E3%83%80%E3%83%B3%E3%83%86&aq=-1&oq=&ei=UTF-8&fr=top_ga1_sa&x=wrt
2. 検索結果ページにおけるURLをhttpsに書き換えます。
現状、検索結果ページが非SSLなのであれば、手動で書き換えることでSSL化された検索結果に変更させることができます。下記が手動で書き換えたSSL化された検索結果ページにおけるURLとなります。
下記がSSL化された検索結果ページのキャプチャーとなります。当たり前ですがデザイン部分は一切変更がありません。ブラウザ(キャプチャーはFirefox)でURLが表示される部分にSSL化された通信であることをあらわす「鍵」マークが表示されている程度となります。
3. パケットキャプチャーツールで通信の流れを確認します。
ブラウザのデベロッパーツールではなくパケットキャプチャーツールにて、SSL化されたYahoo!検索の検索結果からアユダンテのサイトへ流入し、実際に動いたパケットの流れを確認してみます。
すると上記のような流れであることが確認できます。
#No.2 SSL化されたYahoo!検索の検索結果
↓
#No.19 非SSLで作成されたYahoo!検索のリダイレクター
↓
#No.24 SSL化されたアユダンテのWebサイト
上記のように、#No.2のSSL化されたページから#No.19の非SSLページ(ここではリダイレクター)をはさむことでリファラーが受け渡されません。#No.19でYahoo!検索の検索結果から遷移したという情報は外れてしまうことをあらわします。つまりGoogleアナリティクスでの「参照元/メディア」は「(direct) / (none)」になります。
しかし、そこは検索エンジンを提供するYahoo!検索。非SSLページであるリダイレクターにリファラーを受け渡す処理を、Yahoo!検索の検索結果に施しています。
なぜ、SSL化されたページから非SSLページにリファラーが引き渡されているかというと、SSL化がされたページから非SSLページにリファラーを引き渡すことができるmetaタグが設置されているためです。
Yahoo!検索の検索結果におけるソースを表示するとわかるのですが、検索結果ページには下記のmetaタグが設置されています。
<meta name="referrer" content="origin">
上記のmetaタグがSSL化ページに存在することにより、非SSLページにおいてもリファラーを受け継ぐことができています。こちらは2011年の段階でSSL化された検索結果ページを提供しはじめた「www.google.com」と同じ仕様となります。
meta name="referrer"
に関しては、Web担当者Forumの安田編集長が非常にわかりやすくまとめていらっしゃるのでご参照下さい。
meta name=”referrer”は、HTTPS→HTTPでもリファラを出す新しい仕様 | 編集長ブログ―安田英久 | Web担当者Forum
4. 遷移した先のWebサイトにてリファラーを確認する。
非SSLであるリダイレクターにSSL化された検索結果から遷移したことをあらわすリファラーが引き渡されたため、非SSLであるリダイレクターから遷移したページがSSL化されたページでも、非SSLのページでもリファラーを引き継ぐことができます。
#No.24 アユダンテのTOPページに遷移したときのパケットキャプチャーが上記です。
リファラーが「Referer: http://search.yahoo.co.jp
」と記載されていることがわかります。
次から紹介するGoogleアナリティクスで計測される仕組みの補足として、非SSLのYahoo!検索の検索結果からアユダンテのサイトへ遷移したときの流れも紹介します。
非SSLの検索結果ページからの流れは下記あることが確認できます。
#No.1 非SSLのYahoo!検索の検索結果
↓
#No.16 非SSLのYahoo!検索におけるリダイレクター
↓
#No.18 SSL化されたアユダンテのWebサイト
SSL化された検索結果ページと同じようにリダイレクターを挟むものの、リダイレクターは302リダイレクトを行っています。
302リダイレクトはリダイレクターを引き渡すことができるので、No.18のSSL化されたアユダンテのWebサイトにリファラーを引き渡すことに成功しています。
上記のキャプチャーはアユダンテのWebサイトにおけるパケットのキャプチャーになりますが、リファラーに下記のように非SSLであるYahoo!検索の検索結果をあらわすURLが記載されています。
「Referer: http://search.yahoo.co.jp/search?p=%E3%82%A2%E3%83%A6%E3%83%80%E3%83%B3%E3%83%86&aq=-1&oq=&ei=UTF-8&fr=top_ga1_sa&x=wrt
」
一方、おさらいとして確認すると、先程のSSL化されたYahoo!検索の検索結果からアユダンテのWebサイトへ遷移した際に引き渡されたリファラーは下記となります。
「Referer: http://search.yahoo.co.jp
」
この違いがGoogleアナリティクスの計測に影響を及ぼしています。
Googleアナリティクスで計測されている現状
SSL化されたYahoo!検索の検索結果ページからWebサイトへ遷移したときのパケットと、非SSLのYahoo!検索の検索結果ページからWebサイトへ遷移したときのパケットの違いを確認してもわかるように、それぞれWebサイトへ引き渡されるリファラーには大きな違いがあります。
それはクエリパラメータがリファラーに引き渡されていることです。引き渡されているクエリパラメータを先程のパケットキャプチャーで取得したリファラーデータからあらわすと下記の部分となります。
「Referer: http://search.yahoo.co.jp/search?p=%E3%82%A2%E3%83%A6%E3%83%80%E3%83%B3%E3%83%86&aq=-1&oq=&ei=UTF-8&fr=top_ga1_sa&x=wrt
」
上記の部分は文字化けしてこのまま解読することは不可能ですが、非SSLのYahoo!検索で検索した「アユダンテ」と記載されています。Googleアナリティクスには、「search.yahoo.co.jp」というドメインで、クエリパラメータに「アユダンテ」と記載された流入が存在したとGoogleアナリティクスの計測サーバーにヒットを送信することができています。
しかし、SSL化されたYahoo!検索の検索結果からWebサイトへ遷移した際にWebサイトへ引き渡されるリファラーは「Referer: http://search.yahoo.co.jp
」であるため、「search.yahoo.co.jp」というドメインで流入したことは判断できますが、クエリパラメータが存在しない状態となります。
そのため当然のことながらGoogleアナリティクスをはじめとする解析ツールや生ログデータからは、Yahoo!検索で検索した際の検索クエリを確認することができなくなります。
Googleアナリティクスでは検索エンジンとして定義されたホスト名と、その提供されたホスト名を持つ検索エンジンが使用しているクエリパラメータを持つリファラーからの流入を、メディア=organic、参照元=ホスト名、キーワード=クエリパラメータに代入された値として計測しています。
前述の非SSLであるYahoo!検索の検索結果ページから引き渡されたリファラーを例にすると、下記部分を参照して、organicでの流入と流入した際に検索エンジンで検索したキーワードを流入計測しています。
「Referer: http://search.yahoo.co.jp/search?p=%E3%82%A2%E3%83%A6%E3%83%80%E3%83%B3%E3%83%86&aq=-1&oq=&ei=UTF-8&fr=top_ga1_sa&x=wrt
」
SSL化されたYahoo!検索の検索結果からリダイレクターをへて引き渡されるリファラーは、ホスト名は存在しますがクエリパラメータが存在しないため、SSL化されたYahoo!検索の検索結果からの流入はorganicではなくreferralとして扱われてしまいます。
上記はIPアドレスで制限したアユダンテサイトにおける8月18日から8月20日おける流入状況のキャプチャーになりますが、非SSLのYahoo!検索の検索結果ページからの流入をあらわす「yahoo / organic」と、SSL化されたYahoo!検索の検索結果ページからの流入をあらわす「search.yahoo.co.jp / referral」が混在していることがわかります。
ここまででの流れでお気づきの方もいらっしゃるかと思いますが、今回のYahoo!検索の検索結果ページにおけるSSL化の仕様と、すでにSSL化されているGoogleの検索結果ページにおける仕様は同じです(厳密にいうとリダイレクト部分が違いそうですが)。
SSL化されているGoogleの検索結果ページからWebサイトへ遷移した際も、Webサイト側へ引き渡されるリファラー情報はドメイン名のみとなり、クエリパラメータは引き渡されません。
では、なぜSSL化されたGoogleの検索結果からの流入は、「google / referral」ではなく「google / organic」のままなのでしょうか。ちなみにですが、すでにSSL化されているUS版のYahooである「https://www.yahoo.com/」からの流入は「yahoo / organic」と計測されています。
ga.jsにおける検索エンジン判定ロジックと思われる記述内容
調査したところ、ga.jsの記述内に近しい上記の仕様とおもわれる箇所が存在したため共有させていただきます。
Googleアナリティクスをはじめとする解析ツールでは、上記までに記述したように検索エンジンからの流入を計測するための判定ロジックを計測ツール内に用意する必要があります。ユニバーサルアナリティクスであるanalytics.jsは検索エンジンの判定ロジックをサーバーサイドに移してしまったと思われるため、まだサポートが切れていないga.jsの記述内容から確認します。ga.jsに書かれている記述内容を確認するためには、「http://www.google-analytics.com/ga.js」へアクセスすることで記述内容を確認することができます。
「http://www.google-analytics.com/ga.js」へアクセスしてみると、上記のように検索エンジンとして定義していると思われるホスト名、ドメイン名と、その定義した検索エンジンが仕様しているクエリパラメータが記述されています。
Googleであれば、「images.google:q」や「google:q」
Yahooであれば、「yahoo:p」や「yahoo:q」
といった感じで、日本でしかシェアがないと思われる「search.smt.docomo」や「auone」といった検索エンジンも存在します。
Webサイトへ流入した際に定義されたホスト名、ドメイン名を含み、指定のクエリパラメータを持つリファラーが、Googleアナリティクスにてorganicとして流入したと計測されます。この記述ですと、先程のSSL化されたGoogle及びYahooの検索結果ページからの流入は該当しません。
この検索エンジンを定義していると思われる記述の少し下に下記の記述も存在します。
調査した際の仮説ですが、先程の検索エンジンとして定義するホスト名、ドメイン名とそのクエリパラメータに該当しなかったSSL化された検索エンジンを補足ための記述が正規表現を使用したフルパスで記述されていると推測されます。ここで該当した検索エンジンはorganicでの流入としてみなし、クエリパラメータがないのでキーワードに(not provided)を代入していると思われます。
記述されているSSL化された検索エンジンは正規表現を使用していますが主に下記となります。
google.com、search.yahoo.com、bing.com
US版のYahoo!は「https://www.yahoo.com/」ですが、日本のYahoo!は「http://www.yahoo.co.jp/」となりますので、日本のYahoo!であるYahoo!検索は、ここでの検索エンジン判定ロジックからも漏れてしまいorganic流入として計測されず、「yahoo / referral」として計測されてしまっていると思われます。
現状での対応策について
SSL化された検索エンジンを補足するための記述が、これからサポートがきれると想定されるga.jsのファイル内容にも記述されていることから、Yahoo!検索からの流入もいずれ対策していただけると考えることができます。GoogleにとってYahoo!検索は、世界における一島国の1つでしかない日本でシェアの高い検索エンジンでしかありませんが、「search.smt.docomo」や「auone」といった更にシェアの低い検索エンジンを検索エンジンとして認識する対策を行っていることから、Yahoo!検索もreferralとして計測せずにorganicとして計測するように仕様変更を行ってくれると考えることができます。
現在、Googleアナリティクスに用意されている機能から考えると、ビュー設定におけるフィルタにて「search.yahoo.co.jp / referral」で計測されるはずの流入をorganic流入として書き換えて計測することは可能かもしれません。しかし、いずれGoogleアナリティクス側にて対策する可能性を考えると、一時的にフィルタを仕様し計測することへのリスクも考えられます。
もし、デフォルトチャネルグループでの計測を普段から利用している方であれば、下記の設定をデフォルトチャネルグループに加えることで、デフォルトチャネルグループ軸ではorganicでの流入として計測を続けることが可能です。
上記の設定を行うことで、「参照元/メディア」に「search.yahoo.co.jp / referral」は残ってしまいますが、デフォルトチャネルグループとしては「Organic Search」の中に、SSL化されたYahoo!検索の検索流入も、非SSLのままのYahoo!検索の検索流入も計測することが可能となります。
今後、Googleアナリティクスの仕様変更、または少ない可能性ですがYahoo!検索の検索結果における仕様変更が行われることを考えると、最低限の処理におさえておく方が望ましいと筆者は考えています。後々に対応方針に困ることがないように解析担当者、もしくは解析チームにてどのような方針にて対応するか認識あわせをしておくと、変化があった際に動きやすいのではないでしょうか。