アクセス解析をする際にはもはや欠かせないツールであるGoogleアナリティクスですが、Webサイト内に埋め込まれたタグとCookieによってユーザーの行動を記録するため、計測されたデータと実際のユーザー行動に差がでたり、そもそもデータが取れなかったりすることがあります。

特に重要なのが、Webサイトに訪問してきたユーザーが、どういう経路をたどってきたのかという情報です。
Googleアナリティクスでは、「参照元/メディア」レポートからこのデータを見ることができますが、その中に「direct/none」というカテゴリがあり、これは本来、URLの直接入力などによって、文字通りダイレクトに訪問してきた場合を指すものです。しかし、何らかの理由で訪問経路が特定できなかった場合も「direct/none」算入されてしまいます。つまり、「direct/none」の割合が多すぎると、実際のユーザーの行動とGoogleアナリティクス上のデータが乖離してしまい、アクセス解析の精度を落とす原因になります。

今回は、この「direct/none」が発生してしまう理由と、その対策について解説していきます。

Googleアナリティクスの「direct/none」の本来の意味と発生する2つの理由

Googleアナリティクスの「direct/none」は、参照元/メディアの表記に従って分解すると、参照元が「direct(直接)」、メディアが「none(無し)」という意味になります。
つまり、Webサイトに直接流入しているので、メディアの情報が取れなかったということです。
Googleアナリティクスの仕様上、全てのデータが正常に計測できていたとしても、「direct/none」は一定数発生します。
まずは、「direct/none」が発生する正常な理由を2つ解説します。

「direct/none」の正常な理由①：URLを直接入力した

「direct/none」の本来の意味は、ノーリファラー、つまりリファラル(参照元)が存在しない直接流入を指します。
その代表例が、ブラウザにURLを直接入力して訪問してきた場合です。
しかし、皆さんの経験上、URLを直接入力してWebサイトに訪問するということはあまりないはずです。なので、URL直接入力によるセッションは、全セッションのうち数%にも満たないごく少ない割合でしょう。
そのため、本来の意味としてはURLの直接入力なのですが、実際にこれが理由で「direct/none」になっていることはほとんどありません。

「direct/none」の正常な理由②：ブックマークしている

ユーザーの流入元が正しく計測できている場合、「direct/none」のうち最も高い割合を占めるのが、ブックマークして訪問しているセッションです。実質的にはURLの直接入力と変わらないノーリファラーなのですが、発生する頻度としては圧倒的にこちらの方が高いはずです。
ブックマークでの流入は、URLの直接入力と同じく「direct/none」の正しい訪問経路ですので、対策の必要はありません。
基本的には、（正常な計測ができている前提では）「direct/none」＝「ブックマーク」と考えてしまっても差し支えないでしょう。

Googleアナリティクスで「direct/none」が誤って発生してしまう7つの理由

Googleアナリティクスの「参照元/メディア」レポートで「direct/none」が計測されてしまった場合、そのセッションの訪問経路を知る手段はありません。
「direct/none」の仕様通り、URLの直接入力やブックマークによってWebサイトに直接流入してきただけなら問題ないのですが、その割合があまりにも高すぎるという場合は、本来は計測されるはずだった訪問経路が正しく計測できなかったというパターンがほとんどです。
まずは「direct/none」が誤って発生してしまう原因として代表的な7つを知ることで、誤った解釈をしてしまわないように注意しましょう。

「direct/none」の誤った原因①：メール内に記載されたリンクからのアクセス

Webサイトへの集客を増やす手段として、メール配信はよく利用される方法です。しかし、メールに記載されたリンクからのアクセスは、Googleアナリティクスが参照元を特定できず、「direct/none」になってしまう場合があります。
これが発生するのは、Gmailなどのブラウザメールではなくメーラーソフト(Outlookなど)でメールを開いている場合です。
GoogleアナリティクスはブラウザのCookieでユーザーを識別するため、ブラウザ以外からのアクセスは正常に計測できず、「direct/none」になってしまいます。

「direct/none」の誤った原因②：スマートフォンアプリからのアクセス

スマートフォンアプリからのアクセスも、ブラウザ以外からのアクセスという点でメーラーと同じであり、誤って「direct/none」に算入されてしまう代表例です。
特に注意すべきなのが、LINEからのアクセスです。
SNSを使った集客は、メールと同じく利用されることが多い方法ですが、FacebookやTwitterからのアクセスは、基本的には「referral」あるいは「Social」として計測されるものの、LINEはこれらには算入されず、全て「direct/none」になってしまいます。
これらの違いはGoogleがSNSとして認識しているかどうかという点にあります。そのため、将来的にLINEからのアクセスも「Social」として計測できるようになる可能性はあるものの、少なくとも現時点では、LINEからのアクセスは計測できないため、注意が必要です。

「direct/none」の誤った原因③：QRコードからの流入

オフラインでの集客を行っている場合、QRコードを表示してそこからWebサイトに訪問してもらうというのもよく利用される方法でしょう。
これもやはり、ブラウザ以外からのアクセスという点で、前の2つと同様であり、「direct/none」に算入されます。
オンラインのみで集客を行っているWebサイトなら気にする必要はない原因ですが、将来的にオフラインの集客も行う可能性を考えて、知識として持っておいた方が良いでしょう。

「direct/none」の誤った原因④：自社サイトがSSL化されていない

これまでに紹介した3つの原因は、流入元がブラウザ以外という点で共通しているものでしたが、ここからは別の原因となります。
原因としてありがちで、対策方法も明確なのが、自社サイトがSSL化されていないというものです。

SSL化とは、WebサイトやWebサイトにアクセスしたユーザーの情報が、悪意ある第三者に盗まれることのないように暗号化するセキュリティ上の処理のことです。
WebサイトがSSL化されているかどうかの見分け方は簡単で、URLの先頭を見ればわかります。「https://～」となっているのがSSL化されたWebサイト、「http://～」となっているのがSSL化されていないWebサイトです。SSL化されていると、「s」が追記されます。
決済や個人情報を扱うページはSSL化してあるものの、それ以外のページはシステム改修にかかるコストの都合上SSL化されていないというWebサイトは少なくありません。
しかし、SSL化されたWebサイトからSSL化されていなWebサイトにユーザーが移動すると、セキュリティ上の観点からユーザーの情報が引き継がれなくなるため、「direct/none」が発生する原因になります。
WebサイトがSSL化されているかどうかは、SEO上の評価にも重大な影響を及ぼしますので、可能であればWebサイト全体をSSL化しておくべきです。

SSL化の有無による情報の引き継ぎ。SSL化されたサイトから非SSLサイトへ移動した際、セキュリティ上の問題から情報が引き継がれないため、「direct/none」が発生する。

「direct/none」の誤った原因⑤：ブラウザ設定などのユーザー環境

ユーザーが、ブラウザやセキュリティソフトの設定で、Googleアナリティクスにデータを引き渡さないようにしている場合、Googleアナリティクスが参照元を正常に計測できなくなるため、「direct/none」の原因になります。
これについては、ユーザーのプライバシーの問題になるため、Webサイト側で行える対策はありません。割合としてはさほど大きくないはずですので、一定数発生してしまうのは仕方ないものと見るべきでしょう。

「direct/none」の誤った原因⑥：リダイレクトによるアクセス

リダイレクトとは、ユーザーがアクセスしようとした本来のURLから、JavaScriptなどの動作によって自動的に別のURLに転送されることを指します。
例えば、WebサイトのリニューアルによってページのURLが変更になった場合、過去にサイト内に記載した内部リンクをそのまま踏んでしまうと、存在しないURLにアクセスすることになってしまいリンクが機能しなくなることがあります。
しかし、Webサイト内の内部リンク全てを書き換えるのは大変なので、リダイレクトの処理を行うことで、新しいURLに自動で転送されるように処理を施す場合があります。
こうしたリダイレクトが間に挟まることで、Googleアナリティクスが参照元を計測できなくなり、「direct/none」に算入されてしまうことがあります。

「direct/none」の誤った原因⑦：セッションが途中で途切れた場合

あまり多いケースではありませんが、ユーザーがWebサイトを訪問し、読み込み途中でブラウザを閉じたり、戻ったりした際に「direct/none」になる場合があります。読み込み途中でGoogleアナリティクスは読み込まれてセッションは記録されたものの、参照元情報が引き継がれる前に離脱した場合はこうなります。
基本的には稀なケースですが、ユーザーが読み込み途中で離脱するということはサイトの表示速度に問題がある可能性があります。ページスピードもSEOの重要な要素なので、可能な限り表示速度は改善したほうがいいでしょう。

Googleアナリティクスで「direct/none」を防ぐための簡単な対策

Googleアナリティクスで誤って「direct/none」が発生してしまう7つの理由について解説してきました。
このうち、①・②・③・⑥と、⑤については、「direct/none」ではなく正常に計測ができるように対策が可能です。
特に、①・②・③・⑥の原因は、発生することが多く、しかも対策も簡単なので、ぜひ実施するようにしましょう。

リンクのURLにパラメータを設定して参照元を計測する

メール、アプリ、QRコード、リダイレクトといった、自社で実施する集客方法が原因で発生する「direct/none」は、リンクのURLにひと手間加えてやるだけで簡単に防止することができます。
そのひと手間というのが、「パラメータ」と呼ばれるものです。

「https://～?utm_source=line&utm_medium=social&utm_campaign=summer_campaign」
というような、URLの最後に「?utm～」で始まる長い文字列がついているのを見たことがある方もいるのではないでしょうか。

ここに記載したのは架空のURLですが、この「?utm～」以降の文字列を「パラメータ」と言い、リンク先に影響を与えることなく自由に設定することができるラベルのようなものと考えてもらえばよいでしょう。
このパラメータで参照元を識別させることでブラウザ以外からのアクセスであっても、Googleアナリティクスが参照元を計測できるようになり、「direct/none」の発生を防止することができます。
パラメータの付け方にもルールがあるのですが、「キャンペーンURLビルダー（https://ga-dev-tools.appspot.com/campaign-url-builder/）」と呼ばれる無料ツールによって簡単に作成することが可能です。
これを使うと、参照元が正しく計測できるようになるだけでなく、例えばメルマガであれば、いつ配信したメールがユーザーの反応が良かったのかどうかまで知ることが可能です。
毎回パラメータを設定するのは少し手間ではあるものの、アクセス解析の精度をぐっと高められる方法ですので、手間を惜しまずぜひ利用するべきです。

Webサイト全体をSSL化する

SSL化されたWebサイトからのアクセスを正しく計測するための方法は、自社サイト全体をSSL化してしまうことです。
これによって参照元が正しく計測できるようになって「direct/none」が防止できるだけでなく、SSL化するだけでGoogleからの評価が上がるため、まだ自社サイトをSSL化していない、あるいはSSL化していないページがある、という場合は、ぜひWebサイト全体をSSL化するべきでしょう。
最近では、SSL化されていないWebサイトではブラウザから警告が出るようになっているため、ユーザーの安心感という観点から見ても、SSL化は必須の施策と言えます。

Googleアナリティクスで「direct/none」が発生する理由と対策まとめ

Googleアナリティクスで「direct/none」が発生する本来の理由2つと、誤って発生してしまう原因の代表的な7つの理由について紹介してきました。
誤って発生してしまう7つの理由のうち、5つはWebサイト側で対策ができるものですので、自社サイトの「direct/none」の割合が高すぎるという場合は、ぜひこれらの対策を行ってみてください。

「direct/none」は、アクセス解析の精度を下げる大きな要因です。「direct/none」の中に、質の高いリファラやユーザーニーズが隠れていることもあります。「direct/none」を可能な限り減らし、ユーザーがどこから訪問しているかを正しく見えるようになれば、Webサイト改善のための施策も正しく行えるようになるはずです。
アクセス解析の精度を上げて、サイト改善に役立てましょう。