ウェブ解析 on Marketechlabo

URLの構造~ホスト名、パス、パラメータ、ハッシュの成り立ちとSEO

Wed, 23 Aug 2017 00:00:00 +0900

URLと向き合う必要性

URLはインターネット上でページのありかを特定する文字列。サイト制作、コンテンツ管理の観点のみならず、webマーケターにとってもさまざまな集客施策で直面するものである。

リマーケティング広告を配信する際、訪問したURL別にリストを作る
アクセス解析においてページビューはURL単位で計測する
SEO上はURLの正規化など、特に重要

意外と技術的に込み入ったところがある。

URLの基本は1URL＝1コンテンツであり、1URLで複数のコンテンツが対応する（そのURLでアクセスしたときに表示されるコンテンツが時によって異なる）のでもよくないし、複数のURLで同一のコンテンツが対応するのも問題となる。こちらはSEOでは重複コンテンツということで特に問題となる。

ところが実際、特にシステムを使った動的サイトではURLは必ずしもこの原則に対応しない。そこでアクセス解析やSEOを実施する際には、この原則に合うよう技術的な調整をする必要が出てくる。

簡単にwebの通信の仕組み

URLの話をする前に、まず簡単にwebの通信の仕組みと用語について説明する。

用語

よく出てくる用語

ブラウザ: webページを表示させるソフト。Google ChromeやMicrosoft Edgeなどのソフトである。
（web）サーバ: webページを公開する側のシステム
（web）サイト: 実際にはwebページが1ページのみ独立して存在することは少なく、複数のページが組み合わさって一つの役割（企業の紹介、サービスの提供など）をなしている。そのひとまとまりに公開されているwebページ群をwebサイトという。
HTTP: webページを表示させるための通信の仕様（プロトコル）の名前。HTTP/2などというのはバージョンが新しくなるという意味。HTTPSは暗号化された（セキュアな）HTTP通信という意味。

手順

ブラウザがサーバにアクセスし、こういうコンテンツが欲しいと要求する＝リクエスト
サーバからコンテンツのデータをブラウザに返す＝レスポンス
ブラウザはそれを受け取って表示する＝レンダリング

リクエストの内容を指定するのがURLである。

マーケターがURLを指定する場面

リマーケティング

リマーケティング広告を配信する際、特定のページを訪問した人にのみ広告を配信する。特定のページ別を訪問した人に対して入札を強めたり広告のクリエイティブを変えたりする。

そのリストを作る際にURLを指定する。ここでURLの指定の仕方が間違っていると正しく広告が配信されなくなる。

アクセス解析

ページ別のページビュー数を把握する際、URL単位で見る。また特定のページを見たユーザを絞り込む際などにURLを指定する。

その際、同じページであるはずなのにURLが異なるものが存在すると、同じコンテンツのページを見ているのに別々にカウントされてしまう。そうするとページを見た総数を正しく把握できなくなるなど、数字の読み違いが発生してしまう。

たとえば広告などの流入元を識別するパラメータが付く場合と付かない場合とでURLは異なるが、これらは同じページとしてカウントするのが適切である。また

のように末尾にindex.htmlが付く場合と付かない場合で同じページを表す場合があるが、それも同様である。

アクセス解析において同じページは同じURLとしてカウントしてほしい。

そのためにシステム側、アクセス解析ツール側それぞれで調整が発生することがある。

SEO

SEOにおいても同じページなのにURLが異なるケースがあると、ページに対する評価が分散して本来のSEOパワーを引き出せなくなってしまう。

<link rel="canonical">を使ったりシステム側でURLを書き換えたりするなど、URLの正規化が必要になる。

アクセス解析でもSEOでも1URL＝1コンテンツの原則が守られていないケースでは1URL＝1コンテンツとして扱ってもらえるよう、アクセス解析ツールや検索ロボットに対して指示をする、調整が必要にある。

URLの構造

URLの文字列はいくつかの要素に分解される。

プロトコル	ホスト	パス名	（?クエリ文字列）	（#ハッシュ）
http://	www.example.com	/audio/list.php	?page=2&sortby=price
https://	example.com	/audio/detail.php	?id=123	#rev

※クエリ文字列はある場合とない場合がある
※ハッシュはない場合が多い

GA4の計測検証をBigQueryを使って行う

Wed, 06 Jan 2021 00:00:00 +0900

GA4の計測の検証はBigQueryエクスポートを使って行うのが普通になる。検証の方法にはいくつかあるのだが、ほかの方法だと欠点がある。リアルタイムレポートではイベントが発生し、パラメータに値が入ってきているのはわかるが、どのイベントでどのパラメータの値が入っているかまではわからない。DebugViewは有効化しないと使えない。

BigQueryエクスポートを使うとすべてのサイト訪問に対して計測して数分以内には各パケット（イベント）でどのパラメータにどの値が入っているかがわかるし、詳細な検証ができる。 GA4のBigQueryデータはパラメータやユーザープロパティがネストされているため、クエリでは毎回それをフラット化する手続きをする必要があり、やや面倒。検証の目的に合わせて使うクエリがパターン化されるのでこの記事ではそれを紹介する。

検証用のおすすめ設定

ログのストリーミング出力設定

GA4のBigQueryエクスポート設定でログ出力をストリーミングにする。これを有効にすることでイベント発生から数分以内にログがBigQueryに取り込まれる。この指定をしないと1日1回しかデータが取り込まれず、翌日の朝にならないと検証ができない。設定方法は以下の「頻度」の「ストリーミング」のチェックを入れる。

計測のバージョン番号をパラメータ設定する

送信する変数（イベントパラメータ、ユーザープロパティ）をバージョン管理するといい。 イベントパラメータに現在の設定のバージョン番号を記録し、全イベントでそれを送る。 GTMで送信するパラメータ／ユーザープロパティを変更する都度、バージョンを更新する。計測された値がどの設定によるものなのか、簡単に照合できる。

全イベントで共通して送るのでイベントタグでなく設定タグに入れておく。

計測バージョン番号の確認

各計測バージョンがいつからいつまで計測されていたのか、計測されたイベントの数（行数）を確認する

select
 p.value.string_value v_name,
 min(timestamp_micros(event_timestamp)) min_time,
 max(timestamp_micros(event_timestamp)) max_time,
 count(0) n_events
from `prj.analytics_99999999.events_*` t1, unnest(event_params) p
where p.key = 'config_version'
group by 1
order by 2 desc

ページビューIDについて

同じページビューで発生したイベントをグルーピングするためのIDとして、GA4のBigQueryエクスポートにはbatch_page_idが含まれている。同じページビューで発生したイベントはこの値が同じになるため、「あるページでバナーを閲覧→そのバナーをクリックした」などの行動を把握できる。

以前はカスタムのページビューIDをGTMで設定する必要があったが、batch_page_idがデフォルトで計測されるようになったため、通常はこちらを使えばよい。

ページの読み込み開始タイムスタンプをパラメータ設定する

ページの読み込み開始からイベント発生までどのくらい時間が経過したのか、検証の観点からもユーザ行動把握の観点からも必要である。イベント発生のタイムスタンプは常に計測される（event_timestamp）が、経過時間の起点としてページの読み込み開始タイムスタンプをイベントパラメータに入れておくと、その差分からイベント発生までにかかった時間がわかる。

ブラウザに格納されているページの読み込み処理のタイムスタンプにはいろいろ候補があるが、Navigation Timing API Level 2のPerformanceNavigationTimingを使うのがよい。

function(){
 var entries = performance.getEntriesByType('navigation');
 if (entries.length > 0) {
 return Math.round(entries[0].startTime + performance.timeOrigin);
 }
 return null;
}

そのままGTMのカスタムJavaScript変数として登録すればいい。

計測されているパラメータ数を見る

イベントごとに計測されているパラメータの種類を一覧にする

select
 event_name,
 p.key key,
 count(0) cnt
from `prj.analytics_99999999.events_*`, unnest(event_params) p
group by 1,2
order by 1,2
;

Googleアナリティクス4のBigQueryエクスポート仕様

Thu, 11 Mar 2021 00:00:00 +0900

GA4のBigQueryエクスポートの仕様とデータの扱い方を説明する。GA4のログはネストされたレコードなど特殊な形式になっており、そのままでは扱いにくいのでいくつかテクニックがある。

BigQueryへのエクスポート設定

GA4の管理画面で設定するが、手順はこちらの記事を参照。 https://www.marketechlabo.com/ga-app-web-property-to-bigquery/

テーブルの場所

プロジェクト：GA4のBigQueryエクスポート設定で指定したプロジェクト
データセット「analytics_999999999」（「999999999」の部分はプロパティID）
テーブル名
- 前日までのデータ（日付別に）「events_20210101」
  - 「20210101」の部分は日付
  - GA4のBigQueryエクスポート設定画面の「エクスポートタイプ」で「毎日」のチェックを入れている場合に出力される
- 今日のデータ、前日未集計分のデータ「events_intraday_20210102」
  - 「20210102」の部分は日付
  - エクスポートタイプ設定で「ストリーミング」のチェックを入れている場合に出力される
  - 「ストリーミング」と「毎日」を両方オンにしている場合は毎日のテーブルが生成されるとこのテーブルが削除される

出力時刻は午前7-9時ごろ。レポートのタイムゾーンに依存するため、米国のままにしていると夜11時ごろに出力される。GA4ではなくFirebase Analyticsの場合はUTC。タイムゾーン設定がない。

日付でシャーディングされたテーブル

GA4のBigQueryエクスポートでは日単位でテーブルが分かれている。

前日まで：events_20210101, events_20210102, …, events_20210127
当日：events_intraday_20210128

このように一つの内容（エンティティ）を表すテーブルを実体としては異なる複数のテーブルに分けて分散格納することをシャーディング（sharding）という。BigQueryでは共通の接頭辞で、末尾が_YYYYMMDD形式の日付で異なる名前のシャーディングテーブルはウェブ画面上では一つのテーブルであるかのようにまとめて表示される。

シャーディングされたテーブル群ではクエリをかける際、日単位で対象のテーブルを絞り込めばメモリの節約ができる。またクエリでも以下のようにfrom句でテーブル名を指定する際にワイルドカード*を付けると、そのワイルドカード条件にマッチするテーブル名、つまり前方一致でマッチするテーブル名のすべてを対象にできる。

select
 ...
from
 `prj.analytics_999999999.events_*`

そしてwhere句で_table_suffixを使ってワイルドカードの部分の文字列を指定することができる。

select
 ...
from
 `prj.analytics_999999999.events_*`
where
 _table_suffix between '20210101' and '20210110';

上はテーブル名末尾の日付文字列部分が20210101から20210110の間（2021年1月1日から2021年1月10日までのログ）を対象にしたクエリだが、結果は以下と同じ。

select ... from `prj.analytics_999999999.events_20210101`
union all
select ... from `prj.analytics_999999999.events_20210102`
union all
 :
select ... from `prj.analytics_999999999.events_20210110`

_table_suffixはアスタリスクの部分にマッチする文字列を表す。つまり下の2つのfromは同じものを意味する。

from `prj.analytics_999999999.events_*` where _TABLE_SUFFIX = '20210101'

from `prj.analytics_999999999.events_20210101`

_table_suffixを指定してクエリ対象のテーブルを絞り込むことによって、処理するデータ量つまりクエリコストの節約ができる。単純にfromでワイルドカードを指定したまま_table_suffixを使った絞り込みを行わないと全期間のテーブルがクエリの対象になり、そのデータサイズに対して課金される。クエリを実行する際は必ず_table_suffixで期間を絞り込もう。

一方でパーティショニングも同様にデータを分けて格納しているが、テーブルの実体としては一つである。シャーディングもパーティショニングもクエリを実行する際、日付単位で対象のテーブルを絞り込めばメモリの節約ができる。

なおシャーディングテーブルは基本的に同じ列構成になるのだが、GA4の場合、同じシャーディングテーブル群であってもある日を境に列が追加されることがある。その場合select *をすると列が一致しないというエラーが発生するので、列名もワイルドカードではなく個別に指定しなければならない。

主な項目

GA4のログは1行1イベントを表す履歴データである。1行の中にネストされたデータ構造を持つ列もある。

ユーザー
- ユーザー識別子
- ユーザープロパティ: user_properties.***
イベント
- イベント名: event_name
- タイムスタンプ: event_timestamp
- バッチ処理関連
  - ページビューの識別子: batch_page_id
  - 同一ページ内での何番目の計測パケット送信なのか: batch_ordering_id
  - 同じ計測パケットの中でのイベントの順序: batch_event_index
- イベントパラメータ: event_params.***
トラフィック
- ユーザーの最初の流入元: traffic_source.***
- 各イベント行における流入元: collected_traffic_source.***
- セッションの流入元: session_traffic_source_last_click.***
デバイス関連: device.***
地域: geo.***
eコマース関連変数
- 取引に関する情報: ecommerce.***
- 商品に関する情報: items.***
同意関連: privacy_info.***
ストリームID: stream_id（ウェブ、アプリなど1つのGA4プロパティで複数のストリームがある場合に識別する）

ユーザー

ユーザの識別子として2種類の列がある。

GA4無料版と有料版のBigQueryエクスポートの違い

Wed, 23 Mar 2022 00:00:00 +0900

2種類のBigQueryエクスポート

GA4のBigQueryエクスポートデータには以下の2種類がある。

イベントデータ
ユーザーデータ

ユーザーデータは1行1人で、user_pseudo_id単位で集約したデータと、user_id単位で集約したデータのそれぞれのテーブルが生成される。所属するオーディエンスの情報やユーザ（user_pseudo_id / user_id）単位の通算指標が含まれる。分析によく使うのがイベントデータで、1行1イベントでイベントパラメータなどがネストされて含まれている。

エクスポートの頻度

イベントデータの出力頻度は以下の3種類がある。

ストリーミング＝リアルタイム。重複や使えない列あり（トラフィック関連の列）
毎日→翌日に、前日分をまとめて、重複除外処理やトラフィック情報のアトリビューション処理済みの形で出力される
毎日（高頻度）＝「毎日」のデータを当日高頻度で出力する。「ストリーミング」と「毎日」の中間だが、トラフィック関連の列は出力される

これらは設定画面の「頻度」に対応している。

この中で「毎日（高頻度）」は有料版限定のオプションになる（無料版の管理画面では選択肢が表示されない）。

ストリーミングデータの問題点

ストリーミングデータでは重複や欠損の行が一部含まれる可能性があるのと、流入元アトリビューション処理ができておらず、traffic_source.***列とsession_traffic_source_last_click.***が欠損して出力される。 https://support.google.com/analytics/answer/9358801

このテーブルには、その日に発生したセッション アクティビティのレコードが保持されます。ストリーミング エクスポートはベスト エフォート型の処理であり、イベントの遅れやアップロードの失敗などにより、データに漏れが生じる場合もあります。データは 1 日を通して継続的にエクスポートされます。セッションが複数のエクスポート周期にまたがっていると、テーブルにはそのセッションのレコードが複数保存されることがあります。
BigQuery のストリーミング エクスポートには、新規ユーザーについては次のユーザー アトリビューション データは含まれません。
traffic_source.name（レポート ディメンション: ユーザーのキャンペーン）
traffic_source.source（レポート ディメンション: ユーザーの参照元）
traffic_source.medium（レポート ディメンション: ユーザーのメディア）

1日1回の再計算の中ではこれらを処理し、より正確なデータを生成しなおす。より正確なデータや、Googleのアトリビューションと同じロジックの流入元データtraffic_source.***（「ユーザーの参照元」など）とsession_traffic_source_last_click.***（「セッションの参照元」など）の情報が欲しければ毎日のデータを使う必要がある。

BigQueryエクスポート設定のパターンと出力されるテーブル

BiqQueryエクスポート設定では2個のチェックボックスがあった。2個のいずれかを選択するのではなく、それぞれチェックを入れる形式である。つまり以下の3パターンの出力設定がある。

ニアリアルタイムのデータのみ
1日1回再計算データのみ
ニアリアルタイム＋1日1回再計算

それぞれについて生成されるテーブル名を見ていく。まず**データセット名はいずれもanalytics_計測ID**となる

ニアリアルタイムデータのみ

生成されるテーブル名

events_intraday_YYYYMMDD

（YYYYMMDDの部分は毎日の日付が入る）（例）

2022年3月1日の日中は
- events_intraday_20220301: 2022年3月1日のリアルタイムデータ
2022年3月2日の日中は
- events_intraday_20220301: 2022年3月1日の全データ（不完全かも）
- events_intraday_20220302: 2022年3月2日のリアルタイムデータ
2022年3月3日の日中は
- events_intraday_20220301: 2022年3月1日の全データ（不完全かも）
- events_intraday_20220302: 2022年3月2日の全データ（不完全かも）
- events_intraday_20220303: 2022年3月3日のリアルタイムデータ

というテーブルが存在することになる。

GA4/Firebaseのログをフラット化する汎用クエリ

Thu, 27 Jan 2022 00:00:00 +0900

GA4（Firebase）のログを扱う際、ネストされているイベントパラメータやユーザープロパティをフラット化しないと使いにくい。ところが格納されているパラメータやプロパティは決まっているわけではないため、通常はそれをハードコーディングで指定することが多い。つまり使用しているパラメータやプロパティに応じてその都度クエリを手動作成することになる。しかしそれでは面倒なので、どんなイベントパラメータやユーザープロパティを使っていても、それがどんな型であっても、オールマイティにフラット化するクエリを作る。存在するパラメータやプロパティに基づいて動的にクエリを作って実行する。このクエリひとつあればどんなケースにも対応できる、汎用的なものである。

イベントパラメータ（ユーザープロパティ）名を使った動的クエリ

フラット化の詳細はこちらを参照。 https://www.marketechlabo.com/ga4-bigquery-export-spec/

たとえばネストされたイベントパラメータga_session_id（整数型）とpage_location（文字列型）をフラット化するクエリは

select
 user_pseudo_id,
 event_name,
 (select p.value.int_value from unnest(event_params) p where p.key = "ga_session_id") ga_session_id,
 (select p.value.string_value from unnest(event_params) p where p.key = "page_location") page_location
from `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`;

なおこの記事ではGoogleが公開しているサンプルデータセットbigquery-public-data.ga4_obfuscated_sample_ecommerceを使っている。実際のプロジェクトでは自身のプロジェクトとデータセットに差し替えること。

この中で動的になるのは以下の部分

(select p.value.【動的：型】 from unnest(event_params) p where p.key = "【動的：パラメータ名】") 【動的：パラメータ名】,

ここに入る値は

ga_session_idの場合、p.value.int_valueと"ga_session_id"
page_locationの場合、p.value.string_valueと"page_location"

である。なおBigQueryではマルチバイト文字を列名にする際はバッククォートで囲む必要があり、列名の部分に日本語がある場合バッククォートを入れないとエラーになる。動的に実行する場合はパラメータ名をそのまま列名にすることになるため、パラメータ名に日本語を入れると不都合である。このような動的処理をすることを踏まえるとパラメータ名には日本語を使わないほうがいい。

イベントパラメータではなくユーザープロパティの場合も同様にできる。つまり

イベントパラメータ（ユーザープロパティ）名と型の一覧を取得し、ループで文字列として代入し、SQL文を生成する
そのSQL文をクエリとして実行する

ことが求められる。

同じイベントパラメータに複数の型が混在する対策

変数の型によって格納されるカラムは異なる。

変数の型	列名
`string`	`event_params.value.string_value`
`int64`	`event_params.value.int_value`
`float64`	`event_params.value.double_value`

（タイムスタンプやdateなど、これ以外の型はイベントパラメータでは扱われない）

同じパラメータに複数の型が混在するケースがある。例えば16進数として生成された値では、たまたま数字だけで構成された値は整数（int64）になるし、A-Fの文字が入ると文字列（string）になる。それぞれp.value.int_valueとp.value.string_valueという別の列に格納される。つまりそれぞれの列から値を取得することになる。

さらに出力を「1パラメータ＝1列」として格納するため型を合わせる（キャスト）必要がある。

select
 user_pseudo_id,
 event_name,
 (select
 case
 when p.value.string_value is not null then safe_cast(p.value.string_value as string)
 when p.value.int_value is not null then safe_cast(p.value.int_value as string)
 when p.value.double_value is not null then safe_cast(p.value.double_value as string)
 else null
 end
 from unnest(event_params) p where p.key = "param1") param1
from `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`;

ところがどの型にキャストすればいいのかが問題になるが、

ウェブログからSQLで指標を計算する8構文～GA4のBigQueryを題材に

Thu, 05 Nov 2020 00:00:00 +0900

Googleアナリティクス4プロパティが登場し、誰でもBigQueryにログを出力できるようになった。ログ分析を始める環境は揃ったわけだが、ログ分析のノウハウはあまり世に出ていない。SQLを使ってこれらを分析する方法を少し紹介する。どんな高度なログ分析をするにしても、これが基本となる。

ウェブ分析の指標

ウェブ分析の基本は

ページビュー数
セッション数
人数

のカウントである。複雑な分析も、結局カウントしているのはこの3つの指標に集約されることが多い。Eコマースになると購入金額の合計なども入ってくることはある。

そしてこれに「○○した」という条件が付いて

イベント○○が発生した回数
- ○○したページビュー数
  - パラメータ△△の値が□□だったイベント○○が発生した回数（ページ□□のページビュー数）
○○したセッション数
○○した人数

をひたすらカウントする。たとえば

資料ダウンロードボタンをクリックした回数
80％以上スクロールしたページビュー数
自然検索から流入したセッション数
コンバージョン完了ページを見た人数

である。これらもページビュー数／セッション数／PV数のカウントであるのは同じで、「○○した」条件に絞り込んでカウントしているだけである。

そして絶対数だけでなく率の指標

○○したセッション率（セッション単位CVRなど）
○○した人数率（ユーザ単位CVRなど）

を計算して歩留まりを見る。これにさまざまなディメンションをかけて比較するだけで、見ている指標はほとんどこれだけなのである。

指標をBigQueryからSQLで計算する

無条件の単純なページビュー数／セッション数／人数のカウント

GA4に限らずログ分析の原則として、1行1ページビューになっていればページビュー数は行数のカウント

COUNT(ユーザID)

セッション数はユニークなセッションIDの数のカウント

COUNT(DISTINCT セッションID)

ユーザ数はユニークなユーザIDの数のカウント

COUNT(DISTINCT ユーザID)

となる。

GA4の形式の場合、ページビュー数（ページビューイベントが発生した回数）

SELECT
 COUNT(
 CASE
 WHEN event_name = 'page_view' THEN user_pseudo_id
 ELSE NULL
 END
 ) AS n_pageviews
FROM
 `prj.analytics_999999999.events_*`;

event_name = 'page_view'である行数をカウントする。

総人数

SELECT
 COUNT(
 DISTINCT user_pseudo_id
 ) n_visitors
FROM
 `prj.analytics_999999999.events_*`;

ユーザを特定する列user_pseudo_id（明示的にSDK内でユーザーIDを設定している場合はuser_idを使う。いずれも文字列型）があるので、これをユニークカウントする。

総セッション数

SELECT
 COUNT(DISTINCT
 CONCAT(
 user_pseudo_id,
 '-',
 CAST(
 (SELECT ep.value.int_value FROM UNNEST(event_params) ep WHERE ep.key = 'ga_session_id') AS string
 )
 )
 ) AS n_sessions
FROM
 `prj.analytics_999999999.events_*`;

GA4の仕様で、単体でユニークなセッションを特定するIDを指す列はない。ユーザごとのセッションを特定する（あくまでユーザ内なのでグローバルにセッションを特定できるわけではない）変数がページビューイベントのパラメータga_session_id（整数型）になる。

Googleアナリティクスなどのツールにとらわれないウェブ解析の基本的な考え方

Mon, 25 Jun 2018 00:00:00 +0900

ツールを問わずやりたいのはアクセス解析

Googleアナリティクスは無料でアクセス解析、ウェブ解析ができるツールで、手軽に使えるような環境からよく「Googleアナリティクスの使いかたを学びたい」という声が出てくる。有料なので使う人はあまり多くはないが、アクセス解析ツールといえばAdobe Analyticsも同じ仲間であり、やることは同じである。

重要なのは「Googleアナリティクス」という固有のツールの使い方を知ることではなく、アクセス解析／ウェブ解析の目的とプロセスを学ぶことである。ツールの違いは方言みたいなもので、使うときに知識として学べばいい。そうしておけばGA、AAだけでなく、どんなツールにも対応できるし、ログ解析にも応用できる。

逆にそれを知らないと、情報量が多い、画面構成が複雑であるアクセス解析ツールに惑わされて肝心のやりたいことをできない、出すべき情報を得るのに無駄に時間がかかってしまう。ということで、まずはアクセス解析の基本的な考え方を整理する。

分析の基本的な考え方

アクセス解析／ウェブ解析の前に、そもそも分析とはどういうものかを踏まえておく必要がある。これについては以下のページを参照のこと。シリーズの後のページまでは読まなくてもいいが、このページの内容は押さえておこう。 /objectives-approach-data-analysis/

ウェブ解析でもクロス集計を意識する

ウェブ解析においても上のページで説明したようなクロス集計を意識するのがいい。ディメンションごとに指標を見る。ドリルダウン、スライス、ダイスを駆使して深掘りをするということである。

それを強く意識することが、数多くの項目とレポートの種類がある解析ツールの画面に惑わされない秘訣になる。そしてそういったツールがなくても、データさえ揃っていればピボットテーブルを駆使してExcelでも分析ができるということがわかるだろう。ある程度進んだ分析ではGoogleアナリティクスの画面を使わず、ExcelやTableau、Looker Studioをメインに使った分析が普通になる。GA4では探索機能もあり、画面上でのアドホックな深掘りがしやすくなっている。

Adobe Analyticsでも同様に「ワークスペース」というTableau／ピボットライクな画面を使った分析が中心になっている。

アクセス解析の指標とディメンション

指標とディメンションが重要になるわけだが、実際にアクセス解析ツールの画面で見ると

指標

ビルトイン指標

アクセス解析ツールにビルトインで実装されている指標で使うのは

PV数
セッション数（訪問数）
人数（ユーザ数、ユニークユーザ数）
コンバージョン数（問合せ数）
滞在時間
直帰率
離脱率

あたりになる。Googleアナリティクスでは約200の指標があるが、実際に使うのはほとんどここに集約される。

なおGA4ではユニバーサルアナリティクスから指標体系が一部変更されている。特にエンゲージメントセッション数、エンゲージメント率といった指標が追加されている。GA4における直帰率はエンゲージメントセッションの逆（10秒以上滞在、2ページ以上閲覧、キーイベント発生のいずれもなかったセッションの割合）として定義されており、ユニバーサルアナリティクスの直帰率とは定義が異なる点に注意が必要である。

指標は作ることもある

ところが重要なのはこれらの指標に基づいて

○○したセッション数
○○した人数

などの指標を新たに作れるということである。「○○した」というのは、「商品詳細ページを閲覧した」「会社概要ページを見た」など、こちらが知りたい内容に合った特定の行動である。「コンバージョンしたセッション数」などというのも、結局「コンバージョン完了ページを閲覧したセッション数」ということでしかない。

こういった「特定のステップに到達した数」を指標化するというのは、コンセプトダイアグラムやカスタマージャーニー的な考え方で必要となる。そこでは**「○○した」の部分の着眼点**が重要になる。

数と率は分けて考える

絶対数と率・平均系の指標は分けて考える

絶対数→セッション数、CV数
率・平均→CVR、平均PV数

たとえば「対前月比でCV数は減少したが、CVRは上がった」というケース。絶対数と率（平均）は時にトレードオフの関係になることもある。特にCV数が大きくなるとCVRが下がるというのは広告の世界でありがちで、獲得ボリュームを増やそうとするとCPAは悪化するのは当然のことである。

指標の因果関係を踏まえて

「セッション数」×「コンバージョン率」＝「コンバージョン数」
「セッション数」×「平均PV数」＝「PV数」

「コンバージョン数が増えた」なぜコンバージョン数が増えるのか？セッション数を増やせばCV数も増えるし、CVRが上がればCV数が増える。「コンバージョン数が増えた」というだけではどちらなのか分からない。この意識は目標・KPI設計においても重要となる。直接「コンバージョン数を増やす」アクションはない。「流入を増やす」か「コンバージョン率を上げる」か、どちらかのアクションしかないのである。

PV数についても同様で、ユーザが訪問して、何ページか見る。その一人一人が「何ページ」見たかというのが平均PV数である。その積み重ねでトータルのPV数になる。

数×率（平均）＝数

努力できる施策に直結する指標は率・平均系の指標になる。

コンバージョン数 → コンバージョン率
流入数 → 平均流入単価

数の問題だけであればお金をかけて広告を出せば解決する。それだと赤字になって意味がないので、CPAという平均の指標が重要になる。

切り口（ディメンション）

アクセス解析ツールにビルトインで実装されているディメンションでよく使うのは

デバイス（モバイル／デスクトップ／タブレット）
新規訪問かリピート訪問か
ユーザ属性（性別、年齢など）
流入元
流入ページ（ランディングページ）
ページ（URL）
ページのカテゴリ

あたりになる。Googleアナリティクスでは約250のディメンションがあり、これら以外のディメンションを使うこともある（指標ほど使うものが限定されているわけではない）が、まずはこのあたりを意識しておけばいい。

ディメンションの深掘りはマクロからミクロへ

ディメンションの深掘り、ドリルダウンはマクロからミクロに掘り下げていく方向で考える。最初からすべてミクロに見ていたのでは追いつかない。

メディアサイトのアクセス解析と重要な指標、コンテンツ分析の着眼点

Sat, 12 Aug 2017 00:00:00 +0900

ニュースメディアや雑誌のウェブ版に加え、企業が自社で運営するオウンドメディアも多数存在する。こういったサイトではお問い合わせ、資料請求といった目先のコンバージョンがない。会員登録などはあったとしても、サイト全体のゴールというほどの位置づけではない。こういった目先のコンバージョンポイントのないメディアサイトのアクセス解析で考慮することを解説する。

メディアサイトの分析で考慮すること

メディアサイトのイシュー

メディアサイトの運用の主眼はPV数を増やすことに置かれていることが多い。それ以外ではユーザ数を増やす、滞在時間を上げる、会員数を増やすなどである。

それを実現するためのサイト内での施策は

コンテンツ何がウケるのか、どんな記事を書いたらいいのか
UI 基本的にページ遷移させることに主眼
- メニュー等共通パーツ
- テンプレートごと
- 記事ごと
  - リンク
  - ページ分割
キャンペーンや広告（タイアップ）の企画

オウンドメディアの場合、将来のコンバージョンにつながるユーザの獲得ということが重要になる。とはいえメディアである。メディアとしての役割が果たせないとわざわざオウンドメディア施策をやる意味はないので、上記のことは考慮しなければならない。

ページの分類

メディアサイトの構造はどうなっているのか。たとえばEコマースであれば

トップページ
商品一覧
商品詳細
カート～購入遷移

が代表的なサイト構成となる。メディアサイトでは、2つの切り口から見ることになる。

ユーザに情報を与える上での（=情報設計上の）機能
内容（トピック）

重要なのは最初の計測設計の段階でこれらの属性を各URLに紐づけておくこと。そしてGoogleアナリティクスであればコンテンツグループとして登録することである。

ページの機能別分類

トップページ
記事一覧
- カテゴリ別
- 著者別
- ○○別
- 新着記事一覧
個別記事
その他個別ページ
- キャンペーンLP
- 業態に応じてケースバイケース
会員登録遷移

これらは機能による分類である。トップページはサイトを代表するページという機能がある。会員登録遷移には会員登録させるという機能がある。どんな話題を扱っていても、共通してこれらの機能は必要となる。

そして機能によって閲覧状況、ユーザに期待する動きは異なる。個別記事ページはすべてのテキストを読んでもらうことがゴールになるし、記事一覧ページは目的の記事に遷移してもらうことがゴールになる。機能別に見るべき指標やその目標値は異なる。読了率やページ閲覧時間などを記事一覧ページで適用するのがナンセンスなのはわかるだろう。

そもそも機能の違うページは比較対象にならない。トップページを個別記事ページと比較する意味はないし、記事一覧ページと比較することも不適切である。あくまでこれらは別々に議論、評価すべきもの。比較というのはユーザに与える機能、すなわちページを見るシナリオがある程度同じページ間で行うべきものである。

分析において念頭に置くべきは機能分類ごとに分析するということなのである。ちなみによく言われる「コンテンツ」というのは記事一覧ページ＋個別記事ページのこと。これらをトピックや編集意図によって分類して分析していくことになる。

ページの内容（トピック）による分類

これとは別にコンテンツによる分類、すなわち記事のさまざまな切り口からの分類がある。

カテゴリ
- 大カテゴリ
- 小カテゴリ
著者
編集意図（メタ情報）
- 特定の情報を知ってもらいたい
- エンゲージメント強化
- 賑やかし
- 自然検索からの集客

カテゴリや著者は記事の属性、インデックスとしてCMSに登録されているものだろう。編集意図というのが難しいかもしれないが、記事ごとにある、記事の目的や閲覧者に対して期待する行動などに基づく分類である。たとえば自然検索集客のためのストック型コンテンツ、バズ狙いの面白記事、コンバージョンさせるための訴求型コンテンツといったものになる。

すべてがバズ狙いの賑やかしの記事であっても中身の薄いメディアになるし、エンゲージメント強化ばかり意識していても訪問者が来なければ意味がない。メディアにおいて重要なのは編集方針に基づいてこれらの個別記事ごとの狙い（意図）のバランスを取っていくことである。これがメディアの「色」になり、ブランドになる。

ストック型の記事を作るのにバズ狙いの要素を入れるとコンテンツがブレて本来の効果を発揮しにくくなるだろう。CMSには登録しないかもしれないが、あとでそれぞれの編集意図が正しく機能しているかを確認し、編集にフィードバックするためにも必要な分類である。

またここではキーワードやタグクラウドのように細分化されすぎた切り口で見ても分析とアクションがとりにくい。分析にはある程度の粒度が必要である。「コンテンツ」の部分、主に個別記事についてこれらの分類ごとにパフォーマンスを見ていくことになる。

Googleアナリティクスでコンテンツグループを設定する場合は、機能別分類で1軸、残りを内容別の各分類（カテゴリ、著者、…）に割り当てることになる。

コンテンツの役割と見るべき指標

上記は分類、ディメンションにあたるもので、今度は見るべき数値、指標を説明する。

webサイトの訪問履歴をCRM的な観点で見る

Tue, 14 Feb 2017 00:00:00 +0900

Webサイトの分類とKPIの方向性

目的のあるサイト

特定分野のポータルサイト、情報サイト（比較サイト、不動産ポータルなど）
- リードを送る
企業サイト
- ブランド紹介、理解
- 実店舗誘導
ECサイト
リード獲得型（問合せ、資料請求）
キャンペーン、プロモーションサイト
- 知ってもらう
- 参加してもらう
会員向けサイト
- 特定の行動
- アクティブ率を高める

→目的の達成数がKGIになる。KPIはそれを構成する要素。基本的には目的達成までのカスタマージャーニー、コンセプトダイアグラムを描き、各ステップの到達数を見ていくのがいい。目的の種類によってセッション限りで達成する場合と、ある程度のリードタイムをもって達成する場合がある。その場合は訪問間隔や訪問回数などCRM観点も意識する。

目的のない（暇つぶし）サイト

動画
ニュース
まとめサイト
ソーシャルメディア

→訪問者の特定の行動がマネタイズに結びつかない以上、KGIは広告収入が主なものとなる。 KPIは媒体価値を高めるものとしての閲覧系の指標

目的なし（暇つぶし）系のサイトのKPI

目的なし（暇つぶし）系のサイト、メディアサイトのKPIを追う。訪問者の特定の行動がマネタイズに結びつかない以上、KGIは広告収入が主なものとなる。 KPIは媒体価値を高めるもの。

媒体価値というのは基本的に訪問者に対して与える影響度の大きさということで、概念としては大体

訪問者の質
訪問者の数
回数
接触した、メッセージを伝えた時間
メッセージを伝えたときの意識の深さ

といったものの掛けあわせになる。

PV数、延べ滞在時間

メディアサイトでよく言われるPV至上主義。
PV数はそもそも「どれだけの量の訪問者がどれだけの長さそのサイトにいたか」のグロスの指標。
「サイトにいたか」という意味では滞在時間も同じ目的の指標になる。

PV数＝訪問（セッション）数×平均PV数
延べ滞在時間＝訪問（セッション）数×平均滞在時間

平均PV数、平均滞在時間

平均PV数、平均滞在時間とも

訪問（セッション）あたりの回遊（遷移）状況
訪問（セッション）あたりの精読状況＝実際にページを読んでいる時間

のこと。単純にページを遷移させるのであればある程度小手先のテクニックが使える。しかし実際に読んでいるかは別問題ということで、PVではなく滞在時間に着目する考え方が出てきている。実際に意識を持って読んでもらっている時間というのが重要になる。

訪問数（流入数、セッション数）

PV数、延べ滞在時間を構成するもう一つの要素が訪問数＝セッション数。流入そのものでもある。メディアの影響度のボリュームは一般にリーチとフリークエンシーで構成される。セッション数も概念としてはこれらを掛けたもの

セッション数＝リーチ（ユーザ数）×フリークエンシー（平均訪問回数）

ということになる。施策によって流入は増やすものである。

フリークエンシー（訪問回数）

どれだけリピート訪問を生み出したか。
施策によってある程度上積みできるものではある。

リーチ（ユーザ数）

実はリーチは後でついてくるもの。強いて言えば新規ユーザを獲得する流入元を開拓するのがユーザ数を増やすことにはなるが、基本的には流入数を増やすことでユーザ数は増えるものである。

ただ、流入数は増えているがリピート訪問ばかりでユーザ数が減少しているなどという事態はよろしくない。ユーザ数の増加率は健全な成長のKPIになる。

ユーザ数自体は

月間のユニークユーザ数
ウィンドウ○日のアクティブユーザ数

などで測れる。

見ていくポイントと流れ

それぞれの指標の数値を上げていくためにはどうすればいいか。着目すべきポイントを整理する。

流入
回遊・精読
リピート

回遊とリピートはサイト内の努力によるところも大きいが、流入の質にも依存する。回遊もリピートも多いのが理想だが、両方満たす流入自体そんなにあるものではない。つまり両方追っていたのでは流入自体が増えない。回遊が少なくてもリピートが多ければいい。その逆もあり。と考える必要がある。さすがに回遊もリピートもしないのは微妙ではある。