メディアサイトの計測設計｜目的・KPIとH2到達イベントをつなぐ

メディアの計測は「記事をどう改善するか」から決める

メディアではPVが増えても、必要な説明まで届いたのか、次の行動につながったのかは分かりません。この記事では「記事のどのH2まで到達したか」をGA4で測り、導入文・目次・見出し順を見直すための計測設計を作ります。問い合わせを軸にした計測設計の基本を、メディア運営へ具体化した記事です。

確認済みの実装例：2026年10月5日、本メディアのGTMに article_h2_view を公開し、計測設計記事の閲覧操作からGA4リアルタイムで2件を受信しました。最初の2つのH2のテキストが各1件として表示されたことも確認しています。条件・重複抑止は独立テスト8項目で確認しました。集計後の探索表示、改善効果、第三者による再現は未確認です。以下のKPI数値は実績ではなく架空例です。

1．事業目的・記事の役割・KPIをつなぐ

最初に収益モデルと記事の役割を決めます。広告型なら広告収益、会員型なら有料会員の獲得・継続、見込み顧客獲得型なら有効な相談が事業側の成果です。H2到達はその手前の観測値として使います。

最初から全指標に目標を設定する必要はありません。まず同条件の基準値を集め、編集チームが判断できる期間と最低母数を事前に決めます。数値を上げるためだけに見出しを細かく分割すると、記事の価値とは無関係にイベント数が増えます。

2．「どこまで読んだか」を観測可能な定義にする

本記事のイベントは、本文のH2の50%以上が画面内に連続1秒表示されたことを意味します。ブラウザーのタブが表示中であることも条件です。文章を理解したこと、H2以下の節を読み終わったことは判定できないため、指標名を「H2到達」とします。50%・1秒は本メディアの編集上の設計値であり、Googleが定めた読了基準ではありません。

GA4の拡張計測 scroll は、初めてページの約90%の深さが表示されたときのイベントです。長さが異なる記事や、見出しごとの到達を区別する目的には追加設計が必要です。拡張計測の公式説明

たとえばH2の1→5へジャンプした人は、2・3・4を読んだとは扱いません。最終H2への到達も最終節の読了ではありません。単純な階段状の離脱ファネルになるとは限らない点を、編集会議でも共有してください。

3．イベントと送信パラメータを設計票へ書く

見出しを挿入すると番号が変わり、書き換えるとテキストが変わります。公開日・改訂日・対象URL・見出し一覧を残し、改訂前後を同じ節として比較できるか確認します。氏名、メールアドレス、会員ID、検索入力などを見出しや送信値に混ぜないでください。

メディア向け計測設計票を保存して、目的・分子・分母・テスト結果を記入します。以下は公開記事の固定見出し向けです。会員ごとに変わる見出し、無限スクロール、SPAのページ遷移は個別設計が必要です。

4．GTMへH2到達の計測を追加する

設定前の条件

GTMの編集権限と公開担当、GA4の編集者以上の権限、対象サイトの変更確認が必要です。GTMが設置済みで、送信先のGoogleタグがInitialization - All Pagesで動作し、通常の page_view が受信されていることを先に確認します。初期設定とGTM設定も参照してください。

本メディアにはすでに同イベントを実装しています。本メディアへ再追加する手順ではありません。 自分のサイトへ導入する場合、既存タグに同じイベントがないことを確認してください。

サイトのHTMLを確認する

実装例は以下の構造を前提にしています。本文のH2だけを選べるか、開発者ツールのElementsで確認してください。記事判定のJSON-LDが Article であること、canonicalがクエリやフラグメントを含まない正規URLであることも確認します。BlogPosting のみのサイトには、このコードをそのまま使えません。

<article class="article-body">
  <h2 id="section-1">目的とKPIを決める</h2>
  <p>本文...</p>
  <h2 id="section-2">イベントを定義する</h2>
  <p>本文...</p>
</article>

コードを設定してプレビューする

1. GTM用H2到達コードを保存し、テキストエディターで開きます。これは本メディアの実装を教材用に置換したものです。
2. YOUR_HOSTNAME を対象ホスト名だけに、G-XXXXXXXXXX を自分のGA4の測定IDに置き換えます。プロパティIDの数字ではありません。セレクター article.article-body > h2[id] が自分のサイトに合わなければ実装担当者と調整します。
3. GTMで対象コンテナを選び、「タグ」→「新規」→「タグの設定」→「カスタムHTML」を開きます。ファイル全体をscriptタグごと貼り、名前を「GA4 - article_h2_view - H2到達」とします。
4. トリガーを「All Pages」に設定して保存します。コード自身がHTTPS・ホスト・記事・本文H2を限定し、DOMの準備を待ちます。
5. 「プレビュー」を押し、対象のHTTPS記事URLを入力して接続します。記事を開き、H2を画面内に1秒以上置きます。
6. Tag AssistantでカスタムHTMLタグの発火を確認し、GA4のDebugViewまたはリアルタイムで受信とパラメータを確認します。タグの発火だけでは完了としません。
7. 次節のテストが通ったら、変更一覧に意図しないタグがないことを確認し、「公開」でバージョン名と条件を残します。公開後も通常の閲覧操作から受信を確認します。

コードは既存Googleタグへ gtag('event', ...) を渡して送信します。同名のGA4イベントタグを別に作って二重送信しないでください。 Googleタグ自体の新設も不要です。既存の同意設定は維持し、同意状態や広告ブロッカー等で測れない利用者がいることを前提にします。停止時は今回のタグを一時停止し、変更を公開します。

送信APIの仕様はGoogleタグのリファレンスを参照。教材の監視条件とコードは本メディアの実装例です。ダウンロードしただけでは自分のサイトで検証済みになりません。

5．成功・失敗・重複をテストする

同じ記事の同じ見出しに戻るテストと、リロードして新しいページ表示にするテストを分けます。期待値と実測値、端末、URL、時刻、コンテナのバージョンを記録してください。

本メディアでは、連続表示、ページ内1回、素早い通過、タブ非表示、ジャンプ、サブトップ除外、本番以外の除外、二重設置防止を独立したコードテストで確認しました。これと別に、本番記事からの2件の受信と見出しテキストをGA4で確認しています。すべての端末・同意状態の実測を保証するものではありません。

0件なら、対象プロパティ・測定ID→公開バージョン→HTTPSとホスト→Article判定→H2セレクター→表示条件→同意状態の順に確認します。2件以上なら同名タグ、サイトコードへの重複実装、リロードを調べます。受信テストのアクセスは本番データへ含まれるので、検証期間を変更台帳に残します。

6．GA4に見出し別の集計項目を登録する

1. 対象プロパティの「管理」→「データの表示」→「カスタム定義」を開きます。
2. 同じパラメータの登録がないことを確認し、「カスタム ディメンションを作成」を選びます。
3. ディメンション名を「H2番号」、スコープを「イベント」、イベントパラメータを h2_index として保存します。
4. 同様に「H2見出し」・「イベント」・h2_text を登録します。候補が出ない場合もコードと同じ名前を入力し、綴りを照合します。
5. 記事URLは標準のページ項目を使います。今回の分析に不要なIDや総数までカスタム定義を増やしません。

本メディアはこの2項目を登録済みです。カスタム定義は作成後、通常24〜48時間でレポートに利用できるようになります。未計測だった過去のH2到達は復元できません。見出しテキストは記事数に応じて種類が増えるため、集約表示や高基数の影響にも注意します。カスタム定義の公式説明

7．探索で記事別・見出し別に確認する

GA4の「探索」→「自由形式」を開きます。ディメンションに「ページパスとスクリーンクラス」「H2番号」「H2見出し」「イベント名」、指標に「イベント数」「総ユーザー数」を追加してください。行にページパス→H2番号→H2見出し、値に2つの指標を置きます。フィルターはイベント名が article_h2_view と完全一致、ページパスが対象記事と完全一致です。

番号は数値の順に読んでください。文字として1・10・2の順になる場合は、エクスポートした表で数値として並べ直します。この記事の作成時点では集計後の探索表示は未確認で、上記は確認するための手順です。

到達率の分子と分母をそろえる

編集上の提案として「期間内にそのH2へ到達したユーザー数 ÷ 同じ記事を閲覧したユーザー数」を使います。分子は上の探索の該当H2行の総ユーザー数。分母は別タブで同じ期間・ページパス・端末などの条件を保ち、イベント名を page_view として得た総ユーザー数です。分母側にはH2番号やH2見出しの条件を付けません。

架空例：記事閲覧200人、H2の3へ到達80人なら40%。H2の3のイベントが100回でも、100÷200をユーザー到達率とは呼びません。同じ人が再訪した場合、期間内のいずれかの閲覧で到達すれば分子に入るため、1回の訪問における読了率でもありません。

同じユーザーが複数H2に含まれるので、行の人数を合計しません。H2イベントで絞った表の合計を記事閲覧者数にすると分母を誤ります。セッション単位や表示単位の厳密な到達分析が必要なら、識別単位を設計したうえでBigQuery等で集計してください。

8．数字を編集判断とAIの照合につなげる

中盤の到達率が低くても、文章が悪いとは即断しません。流入クエリと記事のずれ、目次でのジャンプ、冒頭だけで解決する記事、画像の長さ、モバイル表示、計測欠落を先に調べます。見出しごとの到達は改善の候補を探す手掛かりです。

架空の判断例：手順のH2到達が低い場合、端末・流入をそろえて導入文と目次を点検します。「手順を前へ移す」を試すなら、変更日・対象記事・比較期間・主指標・会員獲得等の確認項目を先に残します。変更前後の差だけで因果や成果を断定しません。

AIへ渡す前に、前提条件シートに収益モデル、記事の役割、イベント定義、期間、端末、流入、見出し変更、欠測を記入してください。許可された集計値だけを渡し、利用者を特定するデータや認証情報は渡しません。

メディア記事の改善候補を点検してください。
目的：[事業目的と記事の役割]
対象：[記事URL、期間、端末・流入条件、変更日]
定義：article_h2_viewはH2の50%以上・連続1秒・可視タブで到達。
各H2は1ページ表示につき1回。目次ジャンプの通過節は補完しない。
データ：[見出し一覧、各H2の総ユーザー数、同じ記事のpage_view総ユーザー数]
未確認：[欠測、同意、集計待ち、改訂の影響]
各到達率を再計算し、分子・分母を明記してください。
事実・仮説・次の確認を分け、読了や因果を断定しないでください。
H2人数は合計しないでください。未確認値は補完しないでください。
提案は1件に絞り、採用条件と保留条件を示してください。

人が確かめる箇所は、GA4の抽出条件、分母がpage_viewのユーザー数か、80÷200＝40%のような計算、改訂前後の見出しの対応です。AIがイベント回数を人数に置き換えた場合は採用しません。

完了条件と運用の引き継ぎ

目的とKPI、送信条件、パラメータ、キーイベントの要否、テスト結果が埋まり、GA4受信と集計条件を説明できることが完了条件です。公開バージョンと停止方法も記録します。H2構造やテンプレートを変えたら再テストし、見出し番号と内容の対応を更新してください。

次は探索レポートの基本と月次報告の作り方で、条件を残した報告へ進みます。実装済みであることと、メディアの成果が改善したことは別々に評価します。

記事メディア全体の成果・KPI・前提条件・テスト環境と社内アクセスの扱いは、メディアのCV・KPI設計ガイドでまとめて確認できます。

AI支援で制作。公式資料の確認日：2026年10月5日。次回確認予定：2027年1月5日。H2到達のGTM公開と本番GA4受信を確認済み。集計後の探索表示、改善効果、実務者監修、第三者再現は未確認です。掲載の記入例・数値例は架空の教材であり、実績ではありません。