毎月、オウンドメディアの記事ごとのPV（ページの表示回数）を見ているのに、問い合わせや資料請求につながっている記事が分からない。
そんなときに見直したいのが、記事の評価指標です。
PVは、記事がどれだけ表示されたかを見るには有効です。ただし、その記事がCV（コンバージョン）にどれだけ貢献したかまでは分かりません。
記事を評価するときは、記事を入口にしてCVしたケースだけでなく、途中で記事を読んだケースや、別のセッションで記事を読んだあとにCVしたケースまで含めて見る必要があります。
オウンドメディアの評価では、検索順位や流入しているキーワードももちろん見ます。
この記事で扱うのは、それとは別に、GA4やBigQueryを使って何を見るかという話です。
記事を評価するときに見るべき指標と、記事のCV貢献度をどのように集計するか、そして集計したデータを次の記事づくりにどうつなげるかまでを紹介します。
オウンドメディアの記事評価で見るべき指標は、少なくとも以下の指標です。これらを目的に応じて使い分けます。
特に、問い合わせや資料請求などのCVを目的とするオウンドメディアでは、PVの多さとCVへの貢献度を分けて考えます。
用語解説や操作手順など、ユーザーの疑問を1記事で解決できるコンテンツはPVを集めやすい一方、ユーザーがそのまま離脱することもあります。
反対に、比較検討や導入判断に役立つ記事はPVが少なくても、問い合わせや資料請求の前に読まれていることがあります。
PVが多い記事だからといってCVに貢献しているとは限らないのです。
そのため、次にどの記事をリライトすべきかは、PV順に記事を並べても決められません。これから書く記事の方針や、狙うキーワードの選び方も同じです。
PVが多い記事の周辺を埋めていく発想だと、成果から遠いところの記事が増えていく可能性があるのです。
また、読了率やスクロール率を見れば、記事がどの程度読まれたかは分かります。しかし、「そのあとCVしたか」「別のページを経由してCVしたか」までは分かりません。
記事の成果を評価するなら、読了率やスクロール率といった閲覧状況とCVをつなげて見る必要があります。
では、記事のCV貢献度はどのように見ればいいのでしょうか。
記事がCVに貢献したかを見るときは、記事を入口にしたCVだけを見てしまいがちですが、それだけでは不十分です。
少なくとも、次の3つの経路を分けて考える必要があります。
※画像内「着地」＝本文中「ランディング」。画像の見やすさを考え日本語表記とした
それぞれについて説明します。
最も分かりやすいのが、記事にランディングし、そのまま、あるいはサイト内を回遊したうえで、同じセッションの中でCVするケースです。
GA4では、ランディングページやキーイベント（GA4がコンバージョンを指す現行の呼称）のレポートから、記事を入口にしたCVを確認できます。
とはいえ、これだけでは記事のCV貢献をすべて捉えられないので注意が必要です。
サービスページや事例ページを入口にしたユーザーが、検討途中でオウンドメディアの記事を読むことがあります。
例えば、サービスページ → 解説記事（オウンドメディア） → 事例 → 問い合わせ。というケースです。
この場合、ランディングページはサービスページなので、オウンドメディアの記事は「入口」として集計されません。
しかし、CVに至る過程では記事が読まれています。記事を「ユーザーの入口」として評価するだけでは、この貢献を取りこぼします。
ユーザーは、記事を読んですぐ問い合わせるとは限りません。
例えば
というケースがあります。
この場合、記事を読んだセッションとCVしたセッションが異なります。そのため、セッション単位の集計だけでは、最初に読まれた記事と後日のCVを結びつけにくくなります。
3つの経路を見る場合、GA4のレポートでこと足りる部分と、BigQueryが必要な部分に分かれます。
先ほど紹介した3つの経路のうち、(1)「記事にランディングしてCV」は、GA4の標準レポートや探索レポートでも把握できます。
(2)「途中で記事を読んでからCVした」と(3)「別のセッションで記事を読んでからCVした」も、GA4である程度は確認できます。
ただし、別のページにランディングしてから記事を読んだケースや、記事を読んだセッションとCVしたセッションが分かれているケースを、記事単位で一覧にして継続的に集計しようとすると、GA4だけでは難しいです。
GA4では、記事のPVや、ランディングページごとのコンバージョンを確認できますが、パスの分析を厳密にやろうとすると、GA4だけでは足りません。
そこで使うのが、GA4のBigQueryエクスポートです。
BigQueryに蓄積されたGA4のローデータなら、ユーザーごとのページ閲覧とCVイベントを時系列に並べ、CVまでの期間にどの記事が読まれていたかを集計できます。
セッションではなくユーザーを単位にするので、セッションをまたいだ行動もつながります。
ここでいうユーザーは user_pseudo_id で、厳密にはブラウザとデバイスの単位です。同じ人がスマートフォンとパソコンで読んだ分は、別のユーザーとして数えられます。
ユーザー単位に時系列で並べ替えただけでは、記事ごとの貢献度を比べられません。CVの何日前までを貢献として数えるかを先に決めておきましょう。
ここは商材によって変わります。一律に決めるものではありません。検討期間が長い商材なら長く取り、短い商材なら短く取ります。
自社の商材について、検討が始まってから問い合わせに至るまでのリードタイムは、営業やインサイドセールスに聞けばわかることが多いです。その期間を参考にして、貢献期間を決めます。
例えば、問い合わせまでが数日で終わる商材なら7日から14日、1か月前後で決まる商材なら30日、検討が数か月に及ぶ商材なら60日から90日、といった置き方になります。
期間を短く取りすぎると、初期に読まれた記事の貢献が消えます。長く取りすぎると、関係の薄い記事まで貢献として数えられて、記事同士の差が出なくなります。
1回のCVに複数の記事が関与することは珍しくありません。このとき、「どの記事にどれだけ貢献度を配るか」を決めておかないと、記事同士を比べられません。
最初は均等に配るところから始めます。どの記事がCVにつながったのかを、始める前の思い込みで決めないためです。運用が回り始めてから、CVに近い位置で読まれた記事に重みを寄せる形へ変えていきます。
同じ記事を複数回読んだ場合の配布割合も、あわせて決めておきます。読んだ回数で数えるか、1回のCVにつき1回として数えるかで、記事の順位が変わります。
以下が記事ごとの貢献度を測る参考クエリです。これを使うと記事ごとのPVとCV貢献度が並んで出ます。
ユーザー単位で見ているので、3つの経路をまとめて拾えます。
記事が入口だったか、途中で読まれたか、別のセッションだったかを区別せずに、CVの手前で読まれていれば貢献として数える形です。
-- GA4のBigQueryエクスポートから、記事ごとのPVとCV貢献度を出す
-- プロジェクトID、データセット名、記事のURL条件、CVイベント名は自社のものに置き換えてください
DECLARE lookback_days INT64 DEFAULT 30; -- 貢献として数える期間。商材のリードタイムに合わせる
DECLARE min_engaged_sec INT64 DEFAULT 30; -- この秒数以上読まれた接触だけを「読まれた」として数える
DECLARE min_cv_count INT64 DEFAULT 2; -- 関与したCVがこの件数に満たない行は参考値として下に送る
DECLARE cv_event_names ARRAY<STRING> DEFAULT ['generate_lead', 'contact_complete']; -- CVとして扱うイベント名(複数指定できます)
DECLARE start_date DATE DEFAULT DATE_SUB(CURRENT_DATE('Asia/Tokyo'), INTERVAL 90 DAY); -- 集計したい期間の開始日(タイムゾーンはGA4プロパティの設定に合わせる)
WITH events AS (
SELECT
user_pseudo_id,
event_timestamp,
event_name,
(SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id,
(SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'engagement_time_msec') AS engagement_time_msec,
REGEXP_REPLACE(
REGEXP_REPLACE(
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location'),
r'\?.*$', ''), -- パラメータを落とす
r'/+$', '' -- 末尾のスラッシュを揃えて同じ記事をまとめる
) AS page_url
FROM `プロジェクトID.analytics_XXXXXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(start_date, INTERVAL lookback_days DAY))
AND FORMAT_DATE('%Y%m%d', CURRENT_DATE('Asia/Tokyo'))
),
-- 記事ページだけに絞る
article_events AS (
SELECT *
FROM events
WHERE REGEXP_CONTAINS(page_url, r'/media/') -- 記事のURLの条件。一覧・カテゴリなどのハブページが混ざる場合はここで絞り込む
),
-- 記事ごとのPV。フィルタをかけない生の閲覧回数
article_pv AS (
SELECT page_url AS article_url, COUNTIF(event_name = 'page_view') AS pv
FROM article_events
WHERE event_timestamp >= UNIX_MICROS(TIMESTAMP(start_date, 'Asia/Tokyo'))
GROUP BY article_url
),
-- 一定時間以上読まれたセッションを判定する
-- user_engagement はそのページ自身の滞在時間を持つので、ページ単位で合計する
article_reads AS (
SELECT
user_pseudo_id,
session_id,
page_url AS article_url,
MIN(event_timestamp) AS read_timestamp,
COUNTIF(event_name = 'page_view') AS pv_in_session -- このセッション内のpage_view数
FROM article_events
GROUP BY user_pseudo_id, session_id, article_url
HAVING SUM(IF(event_name = 'user_engagement', IFNULL(engagement_time_msec, 0), 0)) >= min_engaged_sec * 1000
),
-- 一定時間以上読まれたセッションで発生したpage_view数の合計。pvと同じ単位で数える
article_reads_count AS (
SELECT article_url, SUM(pv_in_session) AS reads
FROM article_reads
WHERE read_timestamp >= UNIX_MICROS(TIMESTAMP(start_date, 'Asia/Tokyo'))
GROUP BY article_url
),
-- CVイベントを取り出す
conversions AS (
SELECT user_pseudo_id, event_timestamp AS cv_timestamp
FROM events
WHERE event_name IN UNNEST(cv_event_names)
AND event_timestamp >= UNIX_MICROS(TIMESTAMP(start_date, 'Asia/Tokyo'))
),
-- CVの手前、指定した期間内に読まれた記事を結びつける
-- 記事ごとにまとめているので、同じ記事を何回読んでも1回のCVにつき1回として数える
touches AS (
SELECT
c.user_pseudo_id,
c.cv_timestamp,
r.article_url,
MIN(r.read_timestamp) AS first_read_timestamp -- 配分の重みを変えるときに使う
FROM conversions c
JOIN article_reads r
ON r.user_pseudo_id = c.user_pseudo_id
AND r.read_timestamp <= c.cv_timestamp
AND r.read_timestamp >= c.cv_timestamp - lookback_days * 86400 * 1000000
GROUP BY c.user_pseudo_id, c.cv_timestamp, r.article_url
),
-- 1件のCVに複数の記事が関与していれば、貢献を均等に配る
-- 重みの付け方を変えたいときは、この式を書き換える
weighted AS (
SELECT
article_url,
SAFE_DIVIDE(1, COUNT(*) OVER (PARTITION BY user_pseudo_id, cv_timestamp)) AS contribution
FROM touches
),
contributions AS (
SELECT
article_url,
COUNT(*) AS related_cv_count,
SUM(contribution) AS cv_contribution
FROM weighted
GROUP BY article_url
)
SELECT
p.article_url,
p.pv, -- 期間内のPV
IFNULL(r.reads, 0) AS reads, -- 一定時間以上読まれたセッションのpage_view数(pvと同じ単位)
IFNULL(c.related_cv_count, 0) AS related_cv_count, -- その記事が関与したCVの件数
ROUND(IFNULL(c.cv_contribution, 0), 2) AS cv_contribution, -- 配分後のCV貢献度
IFNULL(c.related_cv_count, 0) < min_cv_count AS is_reference -- TRUE は件数が少なく、順位として読まない行
FROM article_pv p
LEFT JOIN article_reads_count r USING (article_url)
LEFT JOIN contributions c USING (article_url)
ORDER BY is_reference, cv_contribution DESC, pv DESC※貢献を均等に配る形のクエリです。
※テーブル名・記事のURLの条件・CVイベント名は、自社のものに置き換えてください。集計期間・貢献期間・読まれたと見なす秒数・参考値に落とす件数は、クエリの先頭で既定値を入れてあるので、そのままでもBigQueryのコンソールに貼って実行できます
出力される結果は6列です。
| 列 | 中身 |
|---|---|
article_url |
記事のURL |
pv |
期間内の表示回数 |
reads |
pv のうち min_engaged_sec 以上読まれた分。単位は pv と同じ |
related_cv_count |
その記事が関与したCVの件数 |
cv_contribution |
配分後のCV貢献度 |
is_reference |
TRUE は関与したCVが少なく、ほかの記事と比べる材料にしない行 |
クエリの結果を、PVの多い順とCV貢献度の高い順に並べ替えたものです（数字はダミーデータです）。クエリ自体は、参考値の行を下に送ったうえでCV貢献度の高い順に返します。
PVの多い順
| 順位 | 記事 | pv | reads | 関与CV | CV貢献度 |
|---|---|---|---|---|---|
| 1 | 記事A | 5,800 | 2,600 | 0 | 0.0 |
| 2 | 記事B | 2,700 | 1,200 | 0 | 0.0 |
| 3 | 記事C | 1,500 | 800 | 0 | 0.0 |
| 4 | 記事D | 1,400 | 170 | 0 | 0.0 |
| 5 | 記事E | 1,250 | 590 | 0 | 0.0 |
| 6 | 記事F | 1,100 | 770 | 0 | 0.0 |
| 7 | 記事G | 1,000 | 500 | 1 | 1.0 |
| 8 | 記事H | 830 | 580 | 1 | 1.0 |
| 9 | 記事I | 700 | 310 | 0 | 0.0 |
| 10 | 記事J | 611 | 369 | 9 | 4.5 |
1位は表示回数（pv）が5,800、そのうち30秒以上読まれたセッションでの表示（reads）が2,600です。割合にすると45%で、開かれたうちの半数近くは30秒以上読まれています。
それでも、CVの手前には一度も現れませんでした。この10本のうち、関与したCVが2件以上ある記事は1本だけで、残りは0件か1件です。PV順に上から手を入れても、CVには近づきません。
ただし、この1位の記事に価値がないという意味ではありません。
メディアへの入口としては最大のpvで、30秒以上読まれた割合も45%と低くありません。CVの手前では読まれていない、というだけです。認知や検索流入を担う記事と、CVの近くで読まれる記事は役割が違います。ここを同じ物差しで並べると、入口の記事を減らす判断になりかねません。
pv と reads の差も、記事ごとに違います。
4位は12%（pv 1,400・reads 170）で、開かれてもほとんど読まれていません。一方6位は70%（pv 1,100・reads 770）で、開かれた分がそのまま読まれる傾向にあります。
7位には貢献度1.0が付いていますが、is_reference が TRUE です。
関与したCVが1件しかなく、その1件がなければ0になる水準です。
CV貢献度の高い順
| 順位 | 記事 | pv | reads | 関与CV | CV貢献度 |
|---|---|---|---|---|---|
| 1 | 記事K | 480 | 230 | 15 | 15.0 |
| 2 | 記事L | 210 | 150 | 10 | 10.0 |
| 3 | 記事M | 66 | 35 | 8 | 8.0 |
| 4 | 記事N | 37 | 29 | 18 | 4.6 |
| 5 | 記事J | 611 | 369 | 9 | 4.5 |
| 6 | 記事S | 32 | 23 | 12 | 3.4 |
| 7 | 記事O | 130 | 58 | 9 | 1.4 |
| 8 | 記事P | 105 | 61 | 7 | 1.2 |
| 9 | 記事Q | 65 | 54 | 6 | 1.1 |
| 10 | 記事R | 40 | 23 | 5 | 0.9 |
CV降順に並べ直すと、顔ぶれが変わります。
1位は480PVの記事で、PVの表の10本には入りません。3位の66PVの記事も同じです。上位10本のPVは32から611までばらついていて、PVの多さでは説明がつきません。
件数と貢献度の関係もここで見えます。
4位は18件のCVに関与していますが、貢献度は4.6です。毎回ほかの記事と一緒に読まれているので、1本あたりの取り分が薄くなっています。逆に2位と3位はそれぞれ10件・8件の関与で、貢献度もそれぞれ10.0・8.0です。ほかの記事を挟まずに読まれて、CVに至っています。件数だけでは、貢献度の高い記事を見分けられません。
上のクエリは、貢献を均等に配る形の例でしたが、配分の付け方はほかにもあります。
どれが自社に合うかは、扱っている商材と記事の作りによって変わります。最初から正解を決めずに、いくつか試して、出てきた記事の並びが実感と合うものを選ぶのが早いです。
上のクエリ例を使う場合は、書き換えるのは weighted の式だけです。touches に first_read_timestamp を残してあるので、読まれた順やCVまでの時間差で重みを付けられます。
書き換え自体はAIに任せられます。「最初に読まれた記事へ重みを寄せたい」と伝えれば、その形のクエリが返ってきます。試す回数を増やせるので、配分を決めるのは早くなります。
ここからは記事を1本ずつ良くしていく話ではなく、メディア全体をどちらへ寄せていくかの話をします。
記事ごとのCV貢献度を集計したら、記事を貢献度の高い順に並べなおします。こうすることで、PV、CV貢献度、テーマ、記事の型などを比較します。
自社のオウンドメディアで成果につながりやすい傾向を探しましょう。
PVは少ないのに、CV前に頻繁に読まれている記事があれば、PVだけでは見つけられなかった重要なコンテンツかもしれません。
私たちが支援したクライアント様の場合は、CV貢献度で見て上位に来たのは、購入に近い位置にある記事でした。
言われてみれば当然の並びですが、実際に数字で確かめられると、どこに手を入れるかの判断がぶれなくなります。
こうした記事は、リライトや内部リンクの改善などの施策を優先的に入れる候補になります。
CV貢献度の高い記事順に並べて、どんなテーマか、どんな記事形式か、読者の検討段階はどこか、どのサービスやCVにつながっているか、を比較します。
そこから、自社メディアで成果につながりやすい記事の傾向を見つけます。他社の「CVにつながる記事の型」をそのまま使っても当たりません。CVにつながる型はメディアごとに違うので、自社のデータから見つけましょう。
見つけた傾向の使い道は、リライトの順番や新しい記事の企画だけではありません。狙うキーワードの選び方、記事から次の記事へつなぐ導線、記事からサービスページへ送る導線、カテゴリの組み方。
オウンドメディアを直していくときの判断は、ひととおりこの傾向を土台にできます。
記事の評価のために集計したデータは、リライト企画や新記事企画にあたっての判断材料にもなります。
その判断を毎月手作業でやるのは大変です。一覧づくりから執筆まで、AIでどう組むかを順番にご紹介します。
まず、BigQueryで集計したデータを、スプレッドシートなどに出して一覧にします。
記事ごとのPV、CV貢献度、テーマ、記事タイプが並んだ表にしましょう。テーマや記事タイプはGA4からは出ないので、記事の管理表から足してください。
これを編集長もライターも見られる場所に置きます。1人だけが数字を持っている状態だと、次に書く記事の判断がその人に集中します。同じ表を見られるようにしておくと、なぜその企画なのかという理由まで共有できます。作り込みすぎなくてよく、記事ごとの数字が一覧で見られれば足ります。
関係者が見る一覧ができたら、データをAIに渡して、次に書く記事の企画案を出させます。
このとき、データだけでは分からない情報を足してください。
例えば、「CV貢献度の高い記事が狙っていたキーワードは何だったのか。」記事を書いた意図にあたる情報です。
数字の並びだけを渡すより、どういう意図で書いた記事が公開後どうなったのかまで渡したほうが、返ってくる企画案の精度が上がります。
出させるのは企画案までで、どれを書くかを決めるのは人です。ここを渡してしまうと、CVにつながる型の記事ばかりが増えて、メディアとしての幅が狭くなります。
企画が決まったら、次はアウトラインと本文です。ここで渡すものは、以下の3つです。
これを渡さないままだと、内容は合っていても、どこかで見たような文章が出てきます。逆に渡しておけば、返ってくる原稿が自社の記事に近づきます。
企画を考え、アウトラインを組み、執筆する。
社内で人がやっていたこの流れをAIのワークフローとして組み立てれば、記事の評価から次の記事までが一連の作業になります。
組んだ直後から、そのまま出せる記事が返ってくるわけではありません。企画案の切り口がずれていたり、書けてはいるものの自社の文章になっていなかったりします。
そこは、人が見て直します。
直して終わりにせず、どこをどう直したのかをAIに返すのが大事なところです。企画の出し方への指摘は次の企画に、文章への指摘は次の執筆に反映されます。繰り返すほど、AIのアウトプットが自社の記事に近づきます。
ここまで、記事の評価と、そのデータを運営に活かす方法を紹介してきました。ここからは、記事評価でよく見かける失敗を挙げます
CV数が少ない状態では、たまたまCVした記事が上位になることがあります。
回避策は、「一定期間のデータを蓄積するか、記事単位ではなくカテゴリ単位で傾向を見る」です。
用語解説など、認知や検索流入を目的とする記事もあります。
回避策は、「記事ごとに期待する役割を先に決めて、そのうえで評価指標を割り当てる」です。読むこと自体が目的の記事に、CVを背負わせないようにしましょう。
PVは、記事がどれだけ表示されているかを知るために必要な指標です。ただし、PVだけでは、その記事がコンバージョンまでの過程でどのような役割を果たしたかは分かりません。
記事の評価では、記事を入口にCVした、途中で記事を読んでCVした、別セッションで記事を読んだあとCVした、という3つの経路まで含めて見ることで、記事のCV貢献をより正確に把握できます。1つ目はGA4の画面で見られます。2つ目と3つ目もGA4である程度は確認できますが、記事ごとに一覧で見続けるなら、BigQueryでユーザー単位の時系列に並べ替えたほうが正確に出ます。
そして、そのデータを使ってCV貢献度の高い記事の傾向を分析すれば、リライトの順番、これから書く記事の方針、記事同士やサービスページへの導線まで、オウンドメディアを直していくときの判断に使えます。
その判断は、毎月手でやるものでもありません。一覧づくりから企画、執筆までをAIのワークフローにして、人が直した内容を返しながら回し続けます。
PVを見るのをやめるのではなく、PVだけで記事の優先順位を決めるのをやめる。オウンドメディアの評価を「どれだけ読まれたか」から「成果にどう貢献したか」へ変えることが、記事の改善につながります。
GA4のBigQueryエクスポートの設定から、ユーザー単位で行動を追える形にデータを整えるところまで対応します。
この記事のクエリを自社のデータで動かしたい。貢献期間や配分の決め方を自社の商材に合わせたい。そうした段階からご相談いただけます。
記事の評価より手前で、GA4の計測設計やキーイベントの設定から見直したい場合はこちらです。
この記事と近いテーマのセミナーを、アーカイブでご覧いただけます。
GA4とBigQueryで小さくはじめる顧客データ基盤入門セミナー
※ セミナーアーカイブ視聴にはお申し込みが必要です。メールアドレスをご登録いただくと、動画のURLをお送りします。
（2026年4月23日開催アーカイブ視聴可）
あなたのGA4分析はなぜAIを使ってもうまくいかないのか AIを使ってもブレない分析軸の作り方セミナー
※ セミナーアーカイブ視聴にはお申し込みが必要です。メールアドレスをご登録いただくと、動画のURLをお送りします。
月に2回、メールマガジンを配信しています。各メンバーによるコラムや書籍紹介、近日開催のセミナー情報、アーカイブ配信のご案内をしております。
お昼休み11:30頃に配信。さっと読めるお手軽メールマガジンです。ご興味がありましたらこちらからご登録下さい。