Google Analyticsのreferral spamはfilterを入れる前に元dataを残してhostnameを確認する

Google Analyticsのreferral reportに見覚えのないdomainが急に増えても、参照元名だけで恒久的なfilterを入れません。元のdataを残すviewを一つ持ち、hostname、session数、期間、実際のsite accessを確認します。そのうえで、report上から除いて比べる段階と、今後のdataへfilterを適用する段階を分けてください。

referral spamは、参照元として意味のないdomainや不自然なsessionをreportへ混ぜ、流入の数字を読みづらくすることがあります。問題は、見知らぬdomainが一件あることだけではありません。その数字を本当の紹介流入として扱い、広告、content、営業の判断を誤ることです。まずdataの意味を確かめ、除外した結果と元の結果を比べられるようにします。

参照元nameと実際に計測されたsite accessを分ける

Google Analyticsのreferral reportは、利用者がどこからsiteへ来たかを考える入口になります。しかし、reportに表示されたdomainが、必ずしも自社siteへ通常のbrowser accessを送ったことを保証するわけではありません。知らない参照元が増えたときは、期間を絞り、hostnameと閲覧pageを確認します。

hostnameは、計測dataがどのhost nameで送られたかを見るための項目です。自社siteで通常使うdomainと違うhostname、または値がないdataが多く混ざっているなら、参照元reportだけで判断しません。正規のdomain、test domain、payment service、form serviceなど、計測を許可するhost nameを先に書き出します。

説明用の仮例として、普段は少数の参照元しかないsiteで、あるdomainから数百sessionが記録された場合を考えます。最初に見るのは、そのdomain名を検索することではありません。Google Analyticsで対象期間を絞り、hostnameが自社domainか、landing pageが実在するpageか、sessionが特定の時刻へ集中していないかを確認します。これらを確認しなければ、紹介された流入なのか、reportを汚すdataなのかを分けられません。

本当に外部siteから紹介された流入なら、閲覧したpage、滞在、問い合わせなどを確認します。意味のある紹介流入まで一括で除外すると、contentが読まれた経路を失います。見覚えのないdomainと、不要なdataを同じものにしません。

filterは元dataを変えるため慎重に使う

Google Analyticsのview filterは、適用した後に受け取るdataへ影響します。Google Analyticsの公式資料は、filterを使う場合にも、filterを適用しないmaster profileを残し、別のprofileで除外することを勧めています。filterを入れたあとで条件が間違っていたと気付いても、すでに除いたdataを同じviewへ戻すことはできません。

referral spamを疑うときも、最初からmain viewへhostname filterやsource filterを入れません。次の三つを分けます。

1. 元dataを残すview。filterを入れず、何が記録されたかを後から確認する。
2. 確認用のsegment。report上で特定のsourceやhostnameを一時的に除き、数字の差を見る。
3. 実務用のview。条件を確認した後に、今後のreportを読みやすくするfilterを入れる。

segmentは、過去のdataを見ながら「このsourceを除くと何が変わるか」を確かめるために使えます。filterは、今後受け取るdataを整理するために使います。同じ除外という言葉でも、dataを消さずに比較する作業と、これからのdataへ条件を適用する作業は違います。

たとえば、特定のsourceを除くsegmentでsession数が大きく下がっても、それだけでhostname filterを決めません。source名を少し変えた別のdataがあるか、正規domainの計測も除かれないか、同じ期間に広告campaignやsite変更がなかったかを確認します。filterは長く使う設定なので、一時的な数字への反応だけで追加しません。

hostnameの条件は正規domainから作る

hostname filterを作るときは、除きたいdomainの一覧から始めるより、計測してよいhost nameの一覧から始めます。wwwの有無、HTTPとHTTPS、test environment、決済やformの戻りpageなど、自社の計測が起こり得る場所を確認します。ここを確認せずに「自社domainを含むものだけ」と決めると、必要な計測まで落とすおそれがあります。

WordPressを使うsiteでは、theme変更やplugin追加のあとに、test siteや一時URLへGoogle Analytics codeが残ることがあります。公開siteだけを見てhostname filterを作ると、testのdataが混ざる理由を見落とします。先にtracking codeが入っているdomainを洗い出し、何のために計測するかを決めます。不要なtest dataを今後入れないなら、filterだけでなくtracking codeを外すことも検討します。

外部の制作者や広告運用者へ確認を頼む場合は、Google Analyticsの管理権限を渡すだけで終わりません。正規domainの一覧、使用中のview、filterの内容、変更する担当者、変更日を共有します。filterを作る作業と、計測するsiteを決める責任を分けます。accountやpropertyを誰が所有し、委託を終えたあとに誰が設定を確認できるかも残します。

数字を直す前に判断の対象を決める

referral spamらしいdataが混ざると、全session数、参照元別の成果、広告以外の流入を読み誤る可能性があります。しかし、全てのreportを同じ条件で見直す必要はありません。まず、どの判断に使うreportかを決めます。月ごとのcontent評価なら、正規hostnameだけのsegmentで記事別のsessionとconversionを比べます。広告費の判断なら、advertising trafficと自然流入を別に確認します。

数字を除いた後は、元dataと実務用viewを同じ期間で並べます。sessionが減った理由がfilterなのか、実際の流入減少なのかを分けるためです。filterを入れた日をannotationへ残せば、後でgraphが変わった理由を追えます。数字をきれいに見せるためではなく、次の判断で対象を取り違えないために記録します。

最初の一手は、怪しいsourceを一つ選び、source、hostname、landing page、期間を同じreportで確認することです。元dataを残したままsegmentで比べ、filterを入れるかを決めます。