Fix High Bounce Product Pages

離脱率の高い商品ページを直す

haldata.net/mcp-dir/ の組み合わせレシピ「売れ筋なのに離脱される商品ページを直す」を、Claude がそのまま実行できる形にしたスキル。 流れは3段で固定する。事実で絞る（GA4・Clarity）→ 理由を読む（TrendViewer）→ 行動に落とす（文案・Shopify下書き）。

なぜこの順か。GA4 だけでは「離脱が多いページ」は分かっても「なぜ」は分からない。レビュー統計だけでは「顧客が何を重視するか」は分かっても「どのページを直すか」が決まらない。両方を重ねて初めて「このページの、ここに、これを書く」が根拠つきで出る。

前提

所要時間の目安：TrendViewer に対象カテゴリの分析が既にあれば 15分以内（HALDATA の検証では4分）。無ければ分析の新規作成に約2時間の待ちが入る（下記 Step 3-a）。

このスキルは EC の商品ページを前提にしている。サービス紹介ページなど EC 以外に使うときは、Step 4 の「記載チェック」を何に読み替えたかをレポートの注意欄に必ず書く。

ツールの正確な引数は references/tools.md にある。GA4 MCP は公式版と自作版で引数の形が違うので、呼ぶ前に必ず参照すること。

Step 0. 入力を確定する

最初にユーザーへ次を確認する。分かっているものは聞かない。

1. GA4 の property_id（数字）
2. 商品ページの URL パターン。既定は /products/（Shopify）。楽天・独自ECなら /item/ など
3. 対象カテゴリ名と、対象商品の JAN または ASIN（分かれば）
4. Shopify に下書きを反映するか（既定：しない。文案の提示まで）

期間は既定で 直近28日、終了日は2日前。GA4 の前日分は確定値でないため、判断に使わない。

Step 1. 事実で絞る（GA4）

run_report を1回。ディメンション pagePath、指標 sessions, bounceRate, engagementRate, averageSessionDuration, keyEvents。 ディメンションフィルタで pagePath が商品ページのパターンを含む行に絞り、指標フィルタで sessions >= 30 を付け、bounceRate の降順で最大20行。

絞り込みの既定値（ユーザーが変えられる）：

70%以上が3ページ未満なら、閾値を外して直帰率上位5ページを採用し、レポートに「閾値未達のため上位5件」と書く。条件を満たすページが5件に届かないときは「該当 N 件」と書く（母集団が小さいサイトでは普通に起きる）。

EC計測（view_item / add_to_cart / purchase）が入っているサイトでは、同じレポートに addToCarts, ecommercePurchases を足し、「見られているのにカートに入らない」を優先順位の第2軸にする。無ければ省く。

Step 2. 離脱の場所を見る（Clarity・省略可）

各対象ページについて query-analytics-dashboard に「{開始日} から {終了日} までの {URL} の平均スクロール到達率とセッション数」を聞く。日付は GA4 と同じ範囲を明示する（"last 28 days" と書くと Clarity は当日を終端に取り、GA4 と2日ずれる）。 読み方：

• 到達率 30%未満 → ページ上部で止まっている。冒頭に「誰の・どんな場面の商品か」が無いのが典型
• 到達率 60%以上なのに直帰 → 下まで読んで買わない。不安（サイズ・耐久・返品）に答えていない
• その間 → 両方の可能性。録画で確認する

list-session-recordings を visitedUrls contains {URL}・scrollDepth 0〜30・count 5 で呼び、録画リンクを3本レポートに載せる。5本取って3本に絞るのは、内部の閲覧を外すため：pagesCount が10を超える、または totalDuration が30分を超えるセッションは社内の回遊や放置の可能性が高いので除く。中身の解釈は人が見るものなので、リンクを渡すだけでよい。

Clarity が無ければこの Step は飛ばし、レポートの注意欄に書く。

Step 3. 理由を読む（TrendViewer）

3-a. データセットを決める

1. list_analyses（state=complete）で、対象カテゴリの分析が既にあるか名前で探す
2. あれば その wldh_slug を使う
3. 無ければ submit_analysis で新規作成する。name は「{カテゴリ}_{yyyy-mm}」、category は {name, detail}（detail にはそのカテゴリで評価される切り口を文章で書く）、products に JAN/ASIN、無ければ search_queries にカテゴリ語。mode は manual
   • 完了まで約2時間。get_analysis_status を15分おきに見る。ユーザーには「分析を仕込んだ。完了したら続きをやる」と伝えていったん止める。再開時は list_analyses から wldh_slug を取り直す
   • データセットの空き枠が無いエラーが出たら、既存の分析を消す判断はユーザーに委ねる（勝手に消さない）

3-b. 観点別の集計を取る

get_analysis_data(wldh_slug, include_per_sku=true, include_sub_viewpoints=false)。 返りは大きい（30 SKU で 70KB を超える）。クライアントがファイルに退避したら、viewpoints[] と、per_sku[] のうち対象商品の行だけを抜き出して読む（jq が使えるなら .viewpoints, (.per_sku[] | select(.code=="<JAN>"))）。

viewpoints[] の name, mention_count, positive_rate, negative_rate を表にする。言及数は以後すべてこの mention_count を使う（3-c の get_review_insights にも件数 total が返るが、あれは文の数で値が違う。閾値も表も mention_count で統一する）。レポート冒頭の「言及 N 件」は total_mentions。

per_sku[] から対象商品（JAN/ASIN 一致）の行を取り、product_id と description（モールに載っている商品説明）を控える。description は Step 4 の「ページに書かれているか」の材料になる。同じ JAN が複数モールで複数行あるときは、ユーザーがモールを指定していればその行、指定が無ければ review_count が最大の行を使い、他の行があることを注意欄に書く。

3-c. 購買動機の観点を決める

get_review_insights(dataset_slug, dimension="motivation", group_by="viewpoint", min_count=30)。 返る meta.baseline_pm_rate が基準。各観点の pm_rate を基準と比べる。

pm_rate が高いだけでは意味がない（基準より高いかで見る）。これは TrendViewer 側の注記でもある。get_review_insights の行と get_analysis_data の観点は name（または viewpoint_ordinal_number）で突き合わせる。

該当する観点が無い判定は「該当なし」と書いて先へ進む。たとえば不安の観点が0件なら、Step 5 の「不安への回答」ブロックは「対象なし（否定率の最大は『{観点}』{x}%）」と1行で書く。無理に作らない。

対象商品が特定できているときは group_by="product" でも取り、商品単位の pm_rate を併記する。

3-d. 使用シーンを取る

get_review_insights(dataset_slug, dimension="context_3w", mall_product_id=<per_skuのproduct_id>, limit=8)。 who / where / when の上位語が「誰が・どこで・いつ使うか」。冒頭文と使用シーンの文案に使う。軸ごとに件数を見ること：上位語の count が3未満の軸は薄いので文案に使わず、「{軸}は薄い（最大 n 件）」と書く。coverage_rate が低い（20%未満）ときは全体を参考程度と書く。

3-e. ニュアンスの確認（任意）

get_review_sentences(dataset_slug, mall_product_id, viewpoint_id, purchase_motivation="only", per_page=20) で、動機の観点の文を読んで「何がきっかけか」を掴む。mall_product_id は 3-b で控えた product_id（JAN ではない）、viewpoint_id は get_analysis_data の viewpoints[].id（viewpoint_ordinal_number ではない）。 読むのは判断のためで、レポートや文案にレビュー原文を写さない。 集計値（件数・率）だけを根拠として書く。文案もレビューの語彙をなぞらず、自分の言葉で書く。

Step 4. ページとレビューを突き合わせる

対応付けのルール

GA4 の pagePath からどの商品かを決める。

1. Shopify なら商品ハンドル（/products/{handle}）→ Shopify の商品情報の barcode が JAN。読めるなら自動で対応付ける
2. 読めなければユーザーに「このページはどの商品（JAN/ASIN）か」を聞く
3. それでも決まらなければ、その商品は カテゴリ全体の傾向 で扱い、レポートにそう明記する（個別商品の観点ではない）

記載チェック

商品ページ本文（Shopify の商品説明、または fetch で取った本文）を読み、Step 3 で決めた観点ごとに3段階で判定する。

• 書かれている：観点名かその言い換えが、根拠（数値・仕様・写真）付きで本文にある
• 触れているが弱い：単語はあるが根拠が無い（「高耐久」とだけ書いてある等）
• 書かれていない：無い

「書かれていない」「弱い」の購買動機観点と不安観点が、追記対象になる。

Step 5. 行動に落とす

対象ページごとに文案を3ブロックで作る。

1. 冒頭1文：最も動機率の高い観点＋3Wの「誰が・いつ」を1文に。到達率30%未満のページはここが最重要
2. 使用シーン：3Wの上位語を2〜3個使った短い段落
3. 不安への回答：否定率30%以上の観点に、仕様・保証・返品条件で答える箇条書き

各ブロックの末尾に根拠を1行付ける（例：根拠：観点「続けやすさ」動機率41%（基準28%）・言及2,611件）。

Shopify への反映

• ユーザーが Step 0 で「反映する」と言っていて、かつ文案を見せて明示的に OK をもらってから、商品説明を更新する
• 公開状態は変えない。下書き（unpublished / draft）にできるなら下書きにする
• 更新前に現在の説明文を控え、レポートの「反映状況」に旧文の保存場所を書く（戻せるように）
• どちらか一つでも満たさなければ、文案の提示で終える

出力フォーマット

レポートは必ずこの形にする（references/report-template.md に雛形）。

# 商品ページ改善レポート（{開始日}〜{終了日}）
## 1. 対象ページ（GA4）
表：ページ / セッション / 直帰率 / エンゲージメント率 / 平均滞在 / スクロール到達率 / 録画
## 2. 顧客が重視している観点（TrendViewer）
表：観点 / 言及数 / 肯定率 / 否定率 / 動機率（基準 x%） / ページ記載（○△×）
## 3. ページ別の改善案
ページごとに：欠けている観点 → 文案（3ブロック） → 根拠
## 4. 反映状況
Shopify 下書き済み / 文案のみ / 要確認
## 5. 注意
データ期間・閾値の変更・読み替え・未接続のMCP・カテゴリ全体で扱った商品

やらないこと

• レビュー原文をレポート・文案に載せない（集計値のみ）
• Shopify・カート側の書き込みを確認なしに行わない。公開状態を変えない
• GA4 の前日データで判断しない
• 対象商品が決まらないのに「この商品の顧客は」と書かない（カテゴリ全体と明記する）

参照

• references/tools.md — 各MCPの正確なツール名・引数・返り値の読み方（GA4 公式版／自作版の違い、Clarity、TrendViewer、Shopify）
• references/report-template.md — レポート雛形
• examples/ — 実行例（HALDATA 自社データで検証。商品名は伏せてある）