WordPressの記事からmakeshopの商品ページへ進んでも、その訪問が購入まで同じ経路として計測されるとは限りません。「商品へ移動できた」「購入イベントが届いた」「記事からの購入として読める」を分けると、設定を変更する前に、どこを確認すべきか整理できます。
WordPressの記事、makeshopの商品、決済・購入の三地点と、訪問の引継ぎ・購入送信の確認境界を示す架空の構成図です。実際の管理画面・顧客データ・計測成果ではありません。
この記事では、記事・商品・決済の三地点を記録する確認票を紹介します。実店舗の設定成功例ではなく、公開公式資料に基づく確認方法です。
記事・商品・決済を三つの行にする
まず、WordPressの記事URL、makeshopの商品URL、決済・購入完了で使われるドメインを別々に記録します。商品ページと購入完了ページが同じドメインとは限らないためです。
次は架空の構成例です。ドメイン名は説明用で、実在店舗の設定や計測結果を示していません。空欄は、現在の設定を管理する担当者が確認して埋めます。
| 地点 | 架空URLの例 | 担当に確認すること | 確認結果 |
|---|---|---|---|
| WordPress記事 | https://content.example.com/guide/ |
タグの設置経路・使う計測先（ストリーム） | 未確認 |
| makeshop商品 | https://shop.example.com/item/ |
標準測定IDか独自タグか・必要イベント | 未確認 |
| 決済・購入完了 | 店舗の契約・設定で確認 | 実際のドメイン・購入イベントの送信 | 未確認 |
この表では、測定IDや秘密情報を公開する必要はありません。「同じストリームを使用」「担当確認待ち」のように、判断に必要な状態を残します。サイトの構成は、URLを見ただけで決めず、設定の所有者に確認しましょう。
境界① 記事から商品の訪問を引き継ぐ
Googleのクロスドメイン測定の公式説明では、対象ページで同じ計測先（ウェブデータストリーム）を識別する同じタグIDを使い、ドメイン間の移動で訪問の引継ぎに使うURL情報（リンカーパラメータ）_gl を受け渡す仕組みが示されています。URLに _gl があることは確認材料ですが、購入イベントの送信や購入をどの流入元に結び付けるか（帰属）まで確認できた意味ではありません。
また、クロスドメイン測定の対象として登録されたドメインへのリンクは、拡張計測の離脱クリックの対象から除外されます。「離脱クリックがゼロだから、記事から商品へ誰も進んでいない」と即断せず、どの計測で遷移を確認する設計なのかを担当へ聞きます。
リダイレクトなどでパラメータが失われる場合もあります。確認票には「ページが開いた」と「訪問の引継ぎを確認した」を別に記録し、引継ぎが不明なら購入元の判断を保留します。
makeshopの標準測定と独自タグを区別する
makeshopのアクセス解析タグの公式マニュアルでは、標準GA4設定の対応イベントとして purchase、begin_checkout、add_to_cart、view_cart、sign_up が示されています。一方、商品詳細表示の view_item はこの標準機能では未対応です。標準測定IDを入れれば、すべての商品閲覧から購入までのイベントが揃う、と扱わないようにします。
標準測定IDの設定と、GTMなどで設置したGA4の独自タグを併用すると、計測が重複する場合があります。「GTMがある」という名前だけで判断せず、GA4をどの経路から送っているかを確認票に書きます。確認前に既存タグを削除する作業には進みません。
境界② 商品から決済・購入を確認する
makeshop公式資料では、有料SSLと独自ドメイン設定などの利用条件により、決済画面のドメインが異なることが示されています。また、一部のクレジットカード決済で3Dセキュア認証画面へ移動する場合、クロスドメインのパラメータが正常に引き継がれず、参照元を計測できなくなる制約も記載されています。現在の契約・決済方式に当てはまるかを担当に確認してください。
ここで、参照元除外とクロスドメイン測定を一つの設定として扱わないことが大切です。確認票では「どのドメインを参照元として扱わない設定か」と「どのドメイン間で同じ訪問を引き継ぐ設定か」を別欄にします。参照元除外の設定を確認しただけで、ユーザーの引継ぎや購入元の帰属が成立したとは判断しません。
| 確認する境界 | 担当へ渡す問い | 記録する状態 |
|---|---|---|
| 記事→商品 | 同じストリームか。どの手段で遷移を確認するか | 遷移確認／引継ぎ未確認 |
| 標準測定と独自タグ | 必要イベントの対応範囲と二重送信を確認したか | 対応確認／重複未確認 |
| 商品→決済 | 実ドメインと認証経路が、現在の設定に合うか | 構成確認／認証経路未確認 |
| 購入完了 | 購入イベントと購入元の判断を、それぞれ確認したか | 購入送信未確認／帰属未確認 |
これは編集上の確認票で、公式の標準様式ではありません。設定の存在、画面の遷移、イベントの送信、購入元の判断を一つの「計測済み」にまとめず、未確認の箇所を残すために使います。
未確認の境界だけを担当へ引き継ぐ
たとえば「記事と商品は開けるが、購入イベントの送信は未確認」なら、記事のリンクを増やす前に、計測担当へその境界を渡します。対象URL、確認した日、分かっている設置経路、未確認の事項を揃えると、同じ調査を繰り返しにくくなります。
実際のタグ変更や注文を伴う検証は、現在の構成と権限を把握する担当が範囲を決めて行います。公式資料を読んだことを、自社で動作検証した実績に置き換えないようにしましょう。まずは三地点と二つの境界を記録し、クリック、購入の送信、帰属をそれぞれ説明できる状態から判断します。
