Yahooの検索結果ページSSL化のあおりを受けて、嘘情報が結構氾濫しているなぁ、と思ったので、アクセス解析ツール上の正確な集客チャネル定義と、検索エンジンSSL化の本当の問題点を整理した方が良い気がしてます。
ということで、一旦アクセス解析ツールが何をどう判定しているのかを軽く整理して、その後に検索エンジンやキーワードの取得方法についての正しい仕組みについて書こうと思います。
※なお、以下では度々「リファラー」という言葉を使いますが、これはJavaScriptオブジェクトのdocument.referrerで取得できる「前のページのURL情報」のことを示す意味で使用しています。そのため、HTTP Request headerのRefererとは異なりますので悪しからず。
まず基本的な集客の定義について
下記の4つは広告を出稿していないサイトでも大体デフォルトで表示されるのではないかな、と思います。
- Referral
- Organic Search
- Direct
- Social
↓こんな感じで。
さて、とりあえずデフォルトの定義で言うと、それぞれはどういう意味か。
【Referral】これは自ドメイン以外からの流入を示します。管理画面上の[Referral Exclusion List]の設定にも依存します。Adobeの場合は[内部URLフィルタ]ってやつですね。
【Organic Search】これは言わずもがな、GoogleやYahooからの自然検索流入です。Referralの中でも特定のドメイン「www.google.com」や「search.yahoo.co.jp」からの流入等、Google AnalyticsやAdobe Analyticsが「検索エンジンのドメイン」として認識・事前登録されているドメインからの流入がこの項目に入ります。検索エンジンとしての登録ドメイン定義もまた、管理画面から追加可能です。
【Social】先にSocialです。これもOrganic Searchと同様の仕組みで、事前登録ドメイン（facebook.com等）に合致したらこれに入る、ということです。
【Direct】最後のDirectですが、これを意外と勘違いして捉えられてる方が多い気がします。これはURL直接入力も含むのですが、正確には「リファラーが空の状態でサイトに訪問した」という意味です。この赤字の定義、重要なので覚えておいてください。次からの鍵になります。
SSLサイトからの流入時にはリファラーが取得できない。
「検索エンジンがSSL化すると、キーワードが取れなくなる」
という話が世の中でよく聞かれると思いますが、まずこれは不正確です。正確には、SSL（https://〜）のサイトから非SSL（http://〜）の別ドメインサイトに移る際に、特別な設定をSSLサイト側が行っていない場合に、リファラーが非SSLサイト側で取得できなく（空の状態に）なります。
逆に、SSLサイトからSSLサイトへのサイト遷移の場合、リファラーは取れます。
つまり、検索エンジンがSSL化したって、自社ウェブサイトが検索エンジン側に元々SSLがデフォルトであると認識させられていれば、論理的には検索キーワードは取れるわけです。（canonical設定をhttps:で始めて各種リンクやサーバ設定をちゃんとしとけばできる話です。）
けど実際にGoogleからの検索キーワードは、自社ウェブサイトが完全SSL化されていても取得できません。加えてGoogleはhttps:で、自社サイトがSSL非対応であったとしたら、そもそもリファラーは空になります。
・・・。
・・・。
そう、本来、GoogleがSSL化されて問題になるのは、リファラーが空になるということ。つまるところ、Googleからの自然検索流入が「Direct」として判定されるのです。これがGoogleSSL化時の一番の懸念事項だったわけです。キーワードが取れる取れないなんてどうでもいい話で、本当のウェブ分析上の問題はこっちだったわけですね。
で、この問題は今回のYahooのSSL化でも同様なのです。
キーワード云々というのは小さな問題で、そもそもYahooから来た事自体がわからなくなる可能性がある、というのが今時点での最大懸念事項です。
でも、今時点でSSL化されたGoogleからでも流入数はわかるわけです。さてナゼでしょう？？？
答えは、Google（SSLサイト側）は特別な設定を行っているから、です。
リファラーはサーバサイドの設定で偽装が可能です。なので、GoogleはSSL化すると同時に、リファラーを「https://www.google.com」や「https://www.google.co.jp/」として送信するように設定をしてくれています。そのため、アクセス解析ツール上でも「Direct」ではなく、「Organic Search」と判定できる状態になっています。
not providedというのは、正確な表現をすると、元々のアクセス解析ツール側の検索キーワード抽出ルールであるリファラーのq=パラメータが提供されていない、ということを意味しています。
“http://www.google.co.jp/search?q=google+analytics&oq=google+analytics&sourceid=chrome&es_sm=119&ie=UTF-8″という検索結果ページからうちのサイト（http://www.pablos.jp）にアクセスされた場合、GAはリファラー、つまり先述赤字箇所を取得し、検索キーワードとして”google analytics”というものを判別・切り出して取得していました。これが、リファラー情報が”https://www.google.co.jp/”となっているために、(not provided)と表記されているだけの話です。
はい、話をYahooに戻します。
今回のYahooのSSL化において、最大の懸念事項は、ちょっと上の方にも書きましたが、検索キーワードが取得できるか否か、ではないです。それはアナリストの観点からすると、ただの些事。
問題は、YahooがSSL化に伴って、ちゃんとサーバサイドでリダイレクト処理する際にリファラーに「search.yahoo.co.jp」の文字列を残しておいてくれないと、ウェブデータ上、「Direct」もしくは「Referral」が急増して、データがぐちゃぐちゃになっちゃう！！っていうことです。
リファラー送る設定せず、空状態ならば「Direct」。
リファラー設定が「search.yahoo.co.jp」ではなく「www.yahoo.co.jp/search」みたいな事前設定がいの文字列が万が一設定されようものなら、すべて「Referral」。
困りますよね。困るんですよ、めちゃくちゃ。なので、キーワードの有無というのは正直どうでも良いんです。多分検索クエリ文字列をサーバサイド処理時にリファラーに残す処理をするとしたら、サーバサイドの処理が１ステップ増えて維持コストが増加してしまうから、多分切られると思うんです。でも、キーワード切られるより、まずちゃんと「search.yahoo.co.jp」という文字列だけは残してくれないと大惨事になっちゃうんですよ、っていうことです。
なので、Yahooの検索エンジンSSL化の動向は、ちゃんとサイト流入時のリファラーをモニタリングして、場合によってはGAやAdobe Analyticsの検索エンジンドメイン設定等をチューニングしないといけないです。
以上です。
なお、余談です。上記すべて理解していただいた方はすでに想像がついていると思いますが、https://のサイトから自社http://へのリンクが貼られてて、そこからの流入がある場合、「Direct」として判定されてる場合があります。多分ボリューム小さいので気にすることではないと思いますが。
