別ドメイン?サブディレクトリ?企業ブログをGoogleアナリティクスで分析するのに知っておかなければならないこと

オウンドメディアや企業ブログを運用する際、「別ドメイン」か「サブディレクトリ」では、Googleアナリティクスの分析に大きな差が発生します。この記事では、ドメイン/サブドメイン/サブディレクトリにおけるGoogleアナリティクスの集計仕様の違いや、ECサイトなどで活用できるクロスドメイントラッキングの仕組みを解説していきます。

別ドメイン?サブディレクトリ?企業ブログを分析するうえで知っておかなければならないこと

先日、はてなブログBusinessプランのリリースに合わせて『週刊はてなブログ』がお届けする「連続企画:コンテンツと企業 2020」の第2弾として「企業ブログの価値を、どう計る?アクセス解析の専門家 小川卓とコンサルタント 村山佑介が「ブログ運用担当者が見るべき数字」を語る」が公開されました。

 

blog.hatenablog.com

 

対談内では、株式会社HAPPY ANALYTICS代表取締役の小川さまと私が、企業ブログ内で運用する際のコンテンツの目標設定のあり方から、企業ブログにおけるフェーズごとの分析やコンテンツごとに見るべき数値などを対談させていただきました。

 

なぜ「ブログ運用担当者が見るべき数字」というテーマにて対談させていただいたのか?について記載させていただきます。

数年前から企業のマーケティング活動の一環として、企業側がブログなどで情報を発信するオウンドメディアを運用する企業が増えてきました。オウンドメディアでは、ユーザーが企業が発信したコンテンツにふれることで、ときに密な接触を促進できたり、ときに長く良好な関係性が続くなど、幸福なコミュニケーションを築き上げることができるためです。

 

しかし、オウンドメディアを運用する企業が増えてきた一方で、長年の間において良質なコンテンツを発信し続けてきたオウンドメディアを閉鎖する企業もチラホラと見かけることも増えてました。良質なコンテンツを提供することができなかったオウンドメディアは潰れて然るべきですが、なぜ良質なコンテンツを発信してきたオウンドメディアまでもが閉鎖してしまうのでしょうか?

 

様々な要因は企業ごとに存在しますが、主に下記のような要因が考えられます。

 

経験や勘などのなんとなくの感情で意思決定される環境企業が得ることができると想定していたリターンに見合わなかったと判断KPIなどの見るべきデータを見誤っていた 

オウンドメディアの運用を開始する際に目的や戦略などのデザインが行われず、トップダウンや声の大きい方がオウンドメディアの運用開始を意思決定してしまうと、運用開始後の評価がとても難しくなります。目的があり、目的のゴールがあり、そのゴールにむけて何を達成していけばよいかが整理されていると、運用中に課題が発生してもデータから意思決定し打ち手が出やすくなります。

 

データによって意思決定される環境でも、企業が得ることができるリターンが見合わなかったという判断もあるはずです。当たり前ですが、オウンドメディアを企業側が運用するにもコストというリソースが発生し、そのリソースに応じたリターンを考えなければいけません。

 

ただし、小川さまや私が関わってきた企業サイトでも、運用するオウンドメディアによっては見るべきKPIがしっかりと定まっていない、特に深い検討もせず月間のページビュー数しか確認していない、といったケースを目にしてきました。そのようなケースですと、オウンドメディアにおける本来のアセットを見極めることができず、誤った判断にてオウンドメディアを閉鎖してしまうこともあるかもしれません。

ラストクリックでは成果としてコンバージョンに貢献していないが、初回接触ではラストクリックの数十から数百倍のコンバージョンを獲得していたことがわかったというオウンドメディアも世の中にはたくさんあるというのに…。

 

「本来、保有していたはずの価値を正しいデータ分析ができなかったから閉鎖」というのは、オウンドメディアを運用して企業の他に、そのオウンドメディアが発信するコンテンツのファンとなっていたユーザーにおいても、とても残念なものです。

 

この記事では対談記事の補足として、メインサイトと異なるドメインでオウンドメディアを運用しているケースと、メインサイトと同じドメイン内のサブディレクトリ内でオウンドメディアを運用しているケースという2つのケースにおけるアナリティクス上のデータの違いや、オウンドメディアを分析する上でよく利用するGoogleアナリティクスのセグメントなどをご紹介します。

これからオウンドメディアの開始を検討されている方や既にオウンドメディアを運用している方のご参考になれば幸いです。

(株式会社JADE 村山佑介)

 

アナリティクスにおけるドメインとサブディレクトリ

オウンドメディアとメインサイトが異なるドメインなのか、同じドメイン内にオウンドメディアとメインサイトが存在するのかで、正しくデータを集計する難易度、データを分析する上での精度に大きく差が生じます。

対談記事内でご紹介させていただいているはてなブログBusinessプランにおける一番の利点は、サブディレクトリオプションを利用することでメインサイトとして運用する企業サイトのサブディレクトリにオウンドメディアとしてブログを展開できることです。SEO観点でも、企業サイトのブログをメインサイトとは異なるドメインで展開するのではなく、メインサイトとは同じドメイン内のサブディレクトリに展開した方が大きな影響があります。詳しくは下記の記事をご確認ください。

 

ja.dev

私からはドメイン、サブドメインやサブディレクトリにおけるアナリティクスの影響を下記の項目にてそれぞれご紹介します。

 

  • Googleアナリティクスにおけるユーザーとは
  • サブディレクトリと別ドメインにおける集計仕様
  • クロスドメイントラッキングの仕組み
  • cidの上書きによる想定されるデータへの悪影響
  • Googleアナリティクスの管理画面にて必要な対応 

 

Googleアナリティクスにおけるユーザーとは

SEOのみならずアナリティクスにおいてもGoogleアナリティクスの場合においては、ドメインにおける影響を大きく受けます。Webサイトに設置するトラッキングコード(gtag.jsもしくはanalytics.js/ga.js)によって異なりますが、私、村山という1人のユーザーでもドメインごとに1ユーザーとしてデータが集計されます。

例えば、www.example.com と www.example.net の2つのWebサイトを同じデバイス内にインストールされているChromeでそれぞれ閲覧しても2ユーザーとして集計されます。これはドメインが異なるためです。

一方で、www.example.com/aaa/ と www.example.com/bbb/ という同じドメイン内のサブディレクトリで展開されている2つのWebサイトを同じデバイス内にインストールされているChromeでそれぞれ閲覧すると1ユーザーとして集計されます。これは2つのWebサイト間でサブディレクトリは異なりますが、同じドメインとなるためです。

トラッキングコードの計測実装しだいでは異なるケースもありますが、上記のデータ集計仕様においてデータが集計されるのが一般的です。

 

引用

推奨されている JavaScript スニペットを使用すると、Cookie はできる限り上位のドメインで設定されます。 たとえば、ウェブサイト アドレスが blog.example.co.uk の場合、Cookie ドメインは analytics.js によって .example.co.uk に設定されます。できる限り上位のドメインに Cookie を設定することで、追加の設定なしでサブドメインをまたいで測定を行うことができます。

参照ページ

developers.google.com

 

引用

ドメインとサブドメインに異なる Cookie が設定されている場合、それぞれのユニーク ユーザーが別々にカウントされ、2 つのサイト間のリンクは参照トラフィックとしてカウントされます。2 つのサイトは、検索やキャンペーンの情報も共有しません。これは、各サイトがトラッキング コードで同じウェブ プロパティ ID を使用する場合も同様です。

参照

support.google.com

 

Googleアナリティクスではドメインごとに生成されたファーストパーティCookieによってデータが集計され、Cookie内におけるcidというパラメータの値によって、1ユーザーとして定義されます。実際にGoogleアナリティクスサーバーに送信されるビーコンを確認してみましょう。

 

下記(画像1-1)は普段、私が利用しているChromeで弊社WebサイトのTOPページを閲覧した際に、Googleアナリティクスサーバーに送信されるビーコンをパケットキャプチャしたものです。

 

画像1-1

村山が株式会社JADEのWebサイトを閲覧したときに送信されるGoogleアナリティクスのパケットキャプチャ
緑色矢印の先にcidというパラメータがあり「1397347447.1574129585」という値が付与されてデータが送信されていることがわかります。

 

一方で、同じChromeでもシークレットモードで弊社WebサイトのTOPページを閲覧した際に、Googleアナリティクスサーバーに送信されるビーコンをパケットキャプチャしたものが下記(画像1-2)となります。

 

画像1-2

村山がシークレットモードで株式会社JADEのWebサイトを閲覧したときに送信されるGoogleアナリティクスのパケットキャプチャ

黄色矢印のの先にもcidというパラメータがありますが値「1444299090.1600150693」が付与されてデータが送信されています。先程の「1397347447.1574129585」という値とは異なります。

私のChromeにおけるシークレットモードでは、Cookieを保存しないように設定されているためシークレットモードを閉じるごとにCookieが削除されます。GoogleアナリティクスにおけるCookieも例外ではありません。

そのため、標準のChromeではcidの値が「1397347447.1574129585」となり、シークレットモードでのcidの値は「1444299090.1600150693」となりました。cidの値がGoogleアナリティクスにおける1ユーザーをあらわしますので、上記までにご紹介したTOPページの閲覧にて、2ユーザー、2セッションがGoogleアナリティクスのデータとして集計されたことになります。

 

サブディレクトリと別ドメインにおける集計仕様

Googleアナリティクスの集計仕様に基づき、企業サイトやサービスサイトをはじめとするメインサイト内のサブディレクトリにてオウンドメディアを展開していた場合、同じドメインとなりますので、1ユーザーとして集計されます。

下記、画像(2-1)のように、それぞれのディレクトリ内にあるページを閲覧しても、cidには共通の値が付与されてデータが送信されます。

 

画像2-1

1人のユーザーが同じドメイン内のサブディレクトリ内ページを閲覧したときに送信されるcidとその値

 

一方で、企業サイトやサービスサイトをはじめとするメインサイトと、オウンドメディアを別ドメインで展開していた場合、下記の画像(2-2)のようにそれぞれのドメインにて1ユーザーとして集計され、合計2ユーザーとなります。

 

画像2-2

1人のユーザーが異なるドメイン内のページを閲覧したときに送信されるcidとその値

 

WebサイトにおけるCookie利用の場面においては、ユーザーとは「同一デバイス内のブラウザ単位」を指すことが少なくありませんが、Googleアナリティクスでの集計仕様においてはその定義とは異なります。

 

Googleアナリティクスでは、ドメインごとにユーザーを定義する値を発行するため、ドメインが異なると別のユーザーとしてデータ集計されてしまいます。

 

クロスドメイントラッキングの仕組み

Googleアナリティクスで集計されるユーザーの定義はドメイン単位であっても、世の中には異なるドメイン間でも同じユーザーとしてデータ集計したい関係性をもつWebサイトも存在します。

代表的な例として、商品を検索し紹介できるECサイトとサードパーティ製のショッピングカートでドメインが異なるケースです。ECサイト www.example.com からカートへ遷移すると、www.example.net という異なるドメインでカート以降のステップが展開されることを実際に体験された方も多いのではないでしょうか。

 

前述までのGoogleアナリティクスのデータ集計仕様では、ECサイトとショッピングカートで異なる2ユーザーとして集計されてしまいますし、ECサイトへ施策した集客キャンペーンをショッピングカートへ共有することができません。商品の購入完了に至っても、Google広告の成果なのか、SEOの成果なのか、メルマガの成果なのか、測定できないのはアナリティクスツールとして不十分です。また、広告プラットフォームを展開するGoogleとしては広告の成果を正しく計測することで、広告を利用するユーザーに広告の影響力、成果をデータとして確認していただくことが必要です。

 

そのために用意された計測仕様が、Googleアナリティクスにおけるクロスドメイントラッキングです。クロスドメイントラッキングの計測仕様に則って、異なるドメイン間にクロスドメイントラッキングの要件を満たした計測実装を行うことで、異なるドメイン間でも同じユーザーとしてデータを集計することが可能となります。

 

引用

クロスドメイン トラッキングの動作

たとえば、オンライン ストアを運営していて、サードパーティのショッピング カートが次のように別のドメインでホストされているとします。

www.example-petstore.comwww.example-commerce-host.com/example-petstore/クロスドメイン トラッキングを使用しない場合、最初にオンライン ストアを訪れ、それからサードパーティのショッピング カートに移動したユーザーは、異なる期間に異なるセッションを開始した 2 人のユーザーとしてカウントされます。

クロスドメイン トラッキングを使用している場合は、アナリティクス レポートに 1 人のユーザーによる 1 回のセッションとして記録されます。これは「サイト間のリンク」とも呼ばれます。オンライン ストアからショッピング カートへ移動したユーザーが 2 人ではなく 1 人と見なされ、ストアで開始されたセッションもショッピング カートまで継続されます。

参照

support.google.com

 

企業サイトやサービスサイトをはじめとするメインサイトと、オウンドメディアを別ドメインで展開していた場合でのケースで説明させていただくと、それぞれの異なるドメインを前述のクロスドメイントラッキングと行うことで、下記の画像(2-3)のように同じユーザーとしてデータ集計させることができるのです。

 

画像2-3

1人のユーザーがクロスドメイントラッキングが設定された異なるドメイン内のページを閲覧したときに送信されるcidとその値

 

しかし、ここで大きな注意点があります。

クロスドメイントラッキングでは、cidというパラメータの値を異なるユーザー間で継承することで、同じユーザーとしてデータ集計を実現させます。

つまりオウンドメディアとメインサイトを異なるドメインで運用していた場合、オウンドメディアでデータ集計されていたcidの値をメインサイトへ引き渡します。下記の画像(2-4)のように www.example.com でのcidの値が、www.example.net でのcidの値へ引き渡します。

 

画像2-4

1人のユーザーがクロスドメイントラッキングが設定された異なるドメイン内を遷移した際に発生するcidの継承

 実際にクロスドメイントラッキングが設定されている異なるドメイン間でWebページを遷移すると、異なるドメイン間で遷移した際にURLへ付与される"?_ga="というパラメータが、cidの引き渡し処理に利用されています。

 

もし、ここでメインサイトにおいても同じプロパティにデータを送信するcidとその値が下記の画像(2-5)のように存在していたとします。下記の画像例では、「1444299090.1600150693」という値でアイコンでいうとクマさんです。

 

画像2-5

1人のユーザーがクロスドメイントラッキングが設定されていないドメイン内のページをそれぞれ閲覧した際のcid

 

そのユーザーがクロスドメイントラッキングが計測実装されたオウンドメディアを経由してメインサイトへ到達することで、オウンドメディアで生成されたcidとその値が継承され、下記の画像(2-6)のように上書きされてしまうのです。

 

 画像2-6

1人のユーザーが異なるドメイン内のページ間を遷移したことで発生するcidとその値の継承と上書き

クロスドメイントラッキングが計測実装されているドメイン間の遷移にて、www.example.net ではアイコンがクマさんだったユーザーが、www.example.com ではアイコンがコアラさんだったユーザーによって上書きされてしまいました。今後、ona同じブラウザで www.example を閲覧してもクマさんというユーザーが戻ってくることはありません。

 

cidの上書きによる想定されるデータへの悪影響

Googleアナリティクスにおけるクロスドメイントラッキングの集計仕様は理解できたとしても、それがデータに対してどのような悪影響が発生しうるかピンとこない方は少なくはないのではないでしょうか。クロスドメイントラッキングによりcidが上書きされることで想定されるデータへの悪影響を、少し怖いケースとして記載してみます。

 

  1. 例えば、メインサイトにサイト訪問回数であるセッションが100以上の良質なユーザーが1万ユーザーいたとします。
  2. そのメインサイトを運営する企業にて、メインサイトとは異なるドメインでオウンドメディアが新規で立ち上がり、メインサイトへの動線も設置されました。
  3. オウンドメディアとメインサイトで同じユーザーとしてデータが集計されるように、Googleアナリティクスにおけるクロスドメイントラッキングでの計測実装が対応完了しました。
  4. 前述の1万ユーザーを含む多くのユーザーがオウンドメディアを新規訪問で閲覧し、オウンドメディア内の動線からメインサイトを閲覧しました。
  5. Googleアナリティクスのクロスドメイントラッキングを行っていたことで、オウンドメディアからメインサイトへ遷移したユーザーは異なるドメインでも同じユーザーとしてデータが集計されました。

 

さて、問題です。

1. で記載したサイト訪問回数であるセッションが100以上の良質なヘビーユーザーが1万ユーザーは、5.においてGoogleアナリティクスにて、どのようにデータとして処理されるでしょうか?

 

答えは、メインサイトにおいても訪問回数が1回の新規ユーザーとしてデータが集計されます。

 

オウンドメディア経由でメインサイトを閲覧するまでの、サイト訪問回数であるセッションが100以上の良質なユーザーとしてデータが戻ってくることはありません。先程のアイコンにおけるクマさんです。メインサイトのみ閲覧していた際のcidの値は、オウンドメディア経由でメインサイトへ遷移することでオウンドメディアドメインにて生成されたcidの値によって上書きされてしまうためです。

 

もし、メインサイトへのセッションが100以上のユーザーを対象とするユーザーリストをGoogleアナリティクスで作成し、Google広告へインポートし、Google広告を配信するリストとして活用していた場合、リストに含まれるユーザー数が減少し、Google広告の表示回数が減少するといった可能性も考えられます。

 

その際、新設したオウンドメディアとメインサイトをクロスドメイントラッキングしたことによる影響だと気づく関係者は、どれくらいいるのでしょうか。

 

少し怖いケースとしてのご紹介でしたが、実際に発生するよくあるケースです。また、AMPページから非AMPページにおける遷移でもAMPページのcidの値を非AMPページへ引き渡すことでも、同様のデータ集計による事象が発生します。

下記ヘルプページに記載されているデータが一時的に大きく変動する可能性があるというのは、クロスドメイントラッキングによるデータへの影響と同様の仕組みとなります。

 

引用

AMP のクライアント ID がデータに及ぼす影響

注: AMP キャッシュとサイト本体との間で AMP クライアント ID を同期すると、既存の Google アナリティクス ユーザー識別子(コホート分析、ライフタイム バリュー、オーディエンス ターゲティングなどの機能に使用)が一度リセットされます。これにより、新規ユーザーに関する指標や関連レポートのデータが、一時的に大きく変動する可能性があります。

参照

support.google.com

 

異なるドメインでメインサイトとオウンドメディアを運用し、かつクロスドメイントラッキングを設定した場合、上記までに紹介したGoogleアナリティクスの計測仕様におけるデータへの影響が考えられます。

 

Googleアナリティクスの管理画面にて必要な対応

計測実装側でもGoogleアナリティクスの初心者さんには難易度が高いクロスドメイントラッキングですが、Googleアナリティクスのレポート表示における対応にも注意しなければいけません。

といいますのも、Googleアナリティクスでは標準的な実装の場合、ホスト名はレポート上に表示されません。そのため、サブドメイン間で同じURLパスが存在する場合、レポート上にホスト名を表示しないと1つのページとして統合されて集計されてしまうのです。下記の画像(3-1)はホスト名を表示していない状態です。

 

画像3-1 

Googleアナリティクスのレポート表示でホスト名を表示していない状態

 

クロスドメイントラッキングで複数の異なるドメイン間のページを1つのプロパティ、ビューで計測し、複数の異なるドメイン間で同じURLパスが存在した場合、セカンダリディメンションで「ホスト名」を表示することで下記の画像(3-2)ようなデータになるケースもあります。

 

画像3-2

Googleアナリティクスのレポート表示でホスト名を表示した状態

 

example.com にも example.net にもTOPページが存在しますが、Googleアナリティクスではディメンション「ページ」にて"/"と処理されて集計されます。ホスト名を表示しないと、example.com と example.net のTOPページにおけるページビュー数などの指標が合算されてレポートに表示されてしまうのです。

 

レポート表示時のみならず、Googleアナリティクスにおけるセグメントやカスタムレポートの作成すら、分析ユーザーが意図したデータとは異なるデータが抽出されてしまう可能性が発生します。クロスドメイントラッキングを実現するためには、計測実装だけでなくGoogleアナリティクス管理画面側での設定も正確に行う必要があるのです。

 

トラッキングコードによってはサブドメイン間においてクロスドメイントラッキングの対応が必要ありませんが、レポート表示におけるGoogleアナリティクス管理画面側の対応は必須となるため設定する際は注意が必要となります。ビューフィルタにてディメンション「ページ」に対して「ホスト名」を付与するように設定すると下記の画像(3-3)ようなレポート表示になります。

 

画像3-3

Googleアナリティクスのレポート表示でページにホスト名を表示した状態 

今回、新たにリリースされたはてなブログBusinessのサブディレクトリオプションではメインサイトのサブディレクトリでオウンドメディアを展開することが可能です。そのため、メインサイトとオウンドメディアで同じドメインを利用するため、Cookieに計測されるcidの値も同じ値を使うことが可能となります。同一ユーザーとしてデータの連続性を保ちながらデータを集計が可能になることは、データが汚れない、分析しやすい形式でデータが表示されるなど、アナリティクスの観点で非常にメリットが大きいと言えます。

 

オウンドメディアを分析する上でのGoogleアナリティクス活用方法

小川さんとの対談時に話にあがったオウンドメディアを分析する上でのGoogleアナリティクス活用法をいくつか補足として紹介させていただきます。

 

  • 記事別にフロー型orストック型を確認する方法
  • 分析視点でデータをカスタマイズ
  • コンテンツの貢献度を確認するためのセグメント一例 

 

今回ご紹介させていただく例は、数ある分析方法の中の1つの例でしかありませんが、初心者の方むけにご紹介させていただきます。

 

記事別にフロー型orストック型を確認する方法

対談時に小川さんより、

「集客できる記事は、大きく分けて2種類です。バズで短期的に大きく集客できる記事と、長期に渡って細く人を集めトータルで集客できている記事です。話題性を重視したアプローチと、普遍性を重視したアプローチと解釈してもいいでしょう。オウンドメディアではこの2つのアプローチを両輪として意識する必要があります。」

 とお話いただきました。

まさに小川さんのおっしゃるとおりで、記事には2つのアプローチ方法があり、私は、「バズで短期的に大きく集客できる記事」をフロー型の記事、「長期に渡って細く人を集めトータルで集客できている記事」をストック型の記事と分類しています。

Googleアナリティクスでは集計されたデータを使って、記事別にフロー型の記事なのか、ストック型の記事なのかを確認することができます。

 

例えば、下記の画像(4-1)レポートはGoogleアナリティクスのデータと接続したデータポータルにて、日別に各ページで発生したセッションの傾向を表示していますが、この表示状態だとどの記事がフロー型なのか、ストック型なのかを確認することが難しい状態です。

 

画像4-1

Googleデータポータルでの記事別セッション傾向のレポート

 

そこで上記のレポートを累計のセッションが表示されるように設定します。設定方法は、下記の画像(4-2)のように色分けで分割された内部ディメンションの各系列に対して、「累計」のチェックボックスをオンに変更するのみとなります。

 

画像4-2

Googleデータポータルで色分けした内部ディメンションのそれぞれの系列を累計へ

 

各系列の「累計」をオンへ変更することで下記の画像(4-3)ような、ランディングページ別の累計セッションを確認することが可能になります。

 

画像4-3

Googleデータポータルでの記事別累計セッション傾向のレポート

 

各ページで増加傾向が異なるのがわかりますね。

日付が経過するにつれて緩やかに増加しているページは「長期に渡って細く人を集めトータルで集客できている記事」であるストック型の記事、短い期間で瞬間的にセッションが急増しているページは「バズで短期的に大きく集客できる記事」であるフロー型の性質が強い記事を確認することができます。

 

上記のレポートの中でも「/entry/blog/tsuji/meo-evil」は、緩やかにセッションが増加しつつも、瞬間的にセッションが急増しているタイミングが2回あることがわかります。

そこで、「/entry/blog/tsuji/meo-evil」に絞り、チャネル別で累計のセッションを確認したのが下記の画像(4-4)となります。

 

画像4-4

Googleデータポータルでの特定の記事における累計セッション傾向のレポート

 

「/entry/blog/tsuji/meo-evil」は、Organic Searchで緩やかにセッションを獲得するストック型の記事の性質が強いのですが、Twitterで2回のバズ、直近ではFacebookやReferralでのプチバズが見られています。なぜ、このタイミングで流入数が増加することになったのか。その要因をさらに深く確認することで、他の施策への応用や他記事での横展開が可能かもしれません。

 

分析視点でデータをカスタマイズ

小川さんよりコンテンツごとの目的を整理することだ大事とお話いただきました。大きく分類すると、集客系の記事で人を集め、コンバージョンに誘導する記事でコンバージョンをとる。その間をアシスト系の記事でつなぐという流れです。コンテンツごとに目的を整理したとして、その目的別の分類をGoogleアナリティクスには反映できないと考えている方も多いのではないでしょうか。

 

実はGoogleアナリティクスでは、主要な「ページURL別にページビュー数を確認できる」といった機能だけではなく、コンテンツに対して分析視点に応じたデータを追加しカスタマイズすることができるのです。それはカスタムディメンションを利用する方法です。計測実装時に対応するか、データ集計される際にデータインポートでデータ処理するか、にてデータの追加の実現方法は異なりますが、分析目的に応じたデータ整理が可能です。

例えば、記事ページであれば記事を執筆した著者ごとのデータを確認したいかもしれません。下記の画像(4-5)は、著者名をカスタムディメンションに追加した場合のデータイメージです。

 

画像4-5

Googleアナリティクスでカスタムディメンションに著者名を計測

 

上記のようにコンテンツごとに分析したい分類軸が決まったら、コンテンツ別にカスタムディメンションを活用することで、分析者の目的に応じたディメンションを作成することができます。カスタムディメンションにてデータ集計したデータは、もちろんデータポータルでも利用することが可能なため、下記の画像(4-6)ように著者別のレポートを表示することも可能です。

 

画像4-6

Googleデータポータルで著者別のPVを棒グラフで表示

 

上記のような著者名別のページビュー数を確認しても、特定の著者が新規ユーザーを集めやすいなどのデータが確認できますね。このデータに対して他のカスタムディメンションで集計した記事カテゴリなどのデータを加えることで、「特定の著者による特定の記事カテゴリは集客に向いている」や「特定の著者による記事カテゴリに分類された記事がxページ以上したユーザーはコンバージョン率が高まる」といった分析できるようになります。

便利なカスタムディメンションですが、カスタムディメンションを利用する際は、どのような分析軸であれば、分析しやすいのか、具体的なアクションへ落とし込むことができるのかをよく検討した上で、計測実装や設定を行うようにしましょう。カスタムディメンションなどを利用し、データをカスタマイズしていくとGoogleアナリティクスで集計したデータを飛躍的に分析しやすく変化させることも可能となります。

 

コンテンツの貢献度を確認するためのセグメント例

オウンドメディア内に記事を中心とするコンテンツを公開した後、ページビュー数は簡単に確認できるけど、そのコンテンツがビジネスに貢献したのか確認したくなります。

Googleアナリティクスのコミュニティでもページごとのコンバージョン率をデータ抽出したいといった書き込みを多く見かけますが、残念ながらページごとのコンバージョン率はGoogleアナリティクスの集計仕様上、シンプルな形式にて表現することができません。

では、どのようにコンテンツの貢献度を確認するのか?私は主に、セグメントの中でシーケンスセグメントを利用したり、コンバージョンセグメントを利用しています。例えばセグメントの中のシーケンスセグメントを使うイメージは下記の画像(4-7)となります。

 

画像4-7

Googleアナリティクスのシーケンスセグメントでブログ流入後にCVにしたユーザーの抽出

 

上記は、ブログページへの流入がきっかけでWebに初回接触したユーザーで、その初回接触内のセッション、もしくはその後のセッションも含めてコンバージョンである「目標の完了数」を計測したユーザーを絞り込むシーケンスセグメントとなります。

このセグメントを適用した上で、ランディングページ別のセッションレポート、ページ別のページビュー数レポートを確認すると、ビジネスの成果として貢献した記事などを確認することが可能です。

 

セグメントを作成する際の注意点としては、セグメントで設定したデータ抽出内容をしっかりと確認することです。セグメントは簡単に設定することができる一方で、設定内容に誤りがあることが原因で分析者が意図していないデータの抽出が実行されてしまうことがあります。

分析者が意図したデータ抽出内容とGoogleアナリティクスで表示されたデータにて整合性がとれているか、Googleアナリティクス内でセグメントを適用した状態にてユーザーエクスプローラー内で抽出されたユーザー内のデータから確認するようにしましょう。

 

はてなブログBusinessとアナリティクス

企業ブログを運営開始を検討した場合、主な選択肢は以下となります。

  • メインサイトとは別のドメイン
  • メインサイトのサブドメイン
  • メインサイト内のサブディレクトリ

 

辻の記事にも記載したようにSEOへの影響もさることながら、アナリティクスにおける計測実装や設定、分析手法などにも影響が発生します。

ただ、世の中の企業や事業者におけるWebサイトやオウンドメディアを見てみると、メインサイトとは別のドメインやサブドメインで展開されているケースが多いように見受けられます。それはコスト、運用管理やサイトポリシーなどの側面からメインサイトとは別のドメインやサブドメインを選択するという判断かもしれません。ただ、今回の記事にも記載しましたようにアナリティクスだけでもいくつかのデメリットが存在するのが現状です。

 

そのような現状を踏まえ、本来はメインサイト内のサブディレクトリにオウンドメディアを展開したいが、様々な要因が障壁となって実行できない企業、事業者向けに、はてなブログのサブディレクトリ設置対応を実現することが出来ないかをご相談させていただいたのが「はてなブログBusiness」のスタートでした。

 

はてなブログBusinessは、申込み条件として「資本金5000万円以下」もしくは「設立5年未満」の企業のみとなり、スタートアップや中小企業を対象の中心とするサービスとなります。また、利用するには月額2万円のコストが発生してしまいます。

ただし、アナリティクスだけの側面のみを考えても、Googleアナリティクスの複雑な計測実装、管理画面の設定や分析者への負担を軽減することが可能です。私は現在までに多種多様なWebサイトのアナリティクスデータを拝見してきましたが、正しい計測実装、正しい管理画面の設定が対応できている上でGoogleアナリティクスを活用できている企業の方が稀であったように思います。

そのことを考えますと、計測実装をはじめとするデータ整備に大きな不安を抱え込まずに、データに対して分析を専念することができるのは大きなメリットだと言えます。

 

オウンドメディアによっては、データをしっかりと整備された形で集計し、そのデータを分析することで、オウンドメディアの成果やビジネスへの貢献度をしっかりと確認し、その後の意思決定に役立てることができます。Googleアナリティクスが分析ツールとして広く使われていますが、Googleアナリティクス内の機能をしっかりと活用できているかどうかによって、データ分析からのアウトプットも大きく異なってきます。まとめますと下記の視点がとても重要です。

 

  • 設計に基づいた整備されたデータ集計
  • 分析に必要なツールの設定とデータのカスタマイズ
  • アナリティクスツールの仕様を正しく理解した上でのツール活用 

 

これらはメインサイトとオウンドメディアにおいて、別ドメインなのか、サブドメインなのか、同じドメイン内のサブディレクトリによって、計測実装、設定や分析における難易度、工数や学習コストなどへ大きな影響が発生すると考えています。

 

オウンドメディアを展開していく上で様々な選択肢がありますが、今回の対談および本記事が選択する上での判断材料として活用いただけることができれば幸いです。

 

 

対談企画のその他の補足記事はこちら