ネットショップで「購入が完了したこと」をきちんと数えたい。GTM（Googleタグマネージャー）を使えばできると聞いたけれど、何をどう設定すればいいのか、そして数えた先で何が変わるのかが、いまひとつ見えない。そんな段階の方に向けた記事です。
結論: GTMとdataLayer（データレイヤー）でEC購入を計測する基本は、カートの種類が違っても共通の型でつかめます。ただし大切なのは、計測は「数える」までで終わらせないことです。購入数や売上金額は取れても、「どのチャネルが本当に売上を生んでいるか」「次にどこへ予算を回すか」は、計測しただけでは出てきません。数えた数字を売上の判断につなげるところまでが、計測の目的です。
なお、主要なカートごとに「購入計測ができるかどうか」を比べたい方は ECカートのGTM計測を比較｜対応可否の先で差がつく が向いています。本記事は比較ではなく、カート問わず共通の「やり方の型」を整理します。
まとめ解説動画
目次
この記事のまとめ#
-
EC購入の計測は「dataLayer→GTM→解析」という共通の型で動く
購入が完了したときに、売上金額や注文番号をdataLayerという受け渡しの場所に積み、GTMがそれを受け取って解析ツールへ送る。カートが違っても、この流れ自体は同じです。
-
そろえるのは「発火」「値と注文IDの受け渡し」「重複の防止」の3点
購入のタイミングで一度だけ計測が動き、売上と注文番号が正しく渡り、同じ購入を二重に数えない。この3点をそろえれば、購入計測の土台はできます。
-
計測は「数える」で終わらせず、売上の判断につなげる
購入数は取れても、「どのチャネルが売上を生んだか」はGA4の標準では見えにくい部分です。数えた数字を、チャネルごとの売上効率まで降りて初めて、次の一手が決まります。
1.EC購入の計測はどう動くのか―dataLayerからGA4までの型#
結論: EC購入の計測は、「購入完了→dataLayerに積む→GTMが受け取る→解析ツールへ送る」という共通の型で動きます。カートが違っても、この流れは変わりません。
購入計測というと難しく聞こえますが、データの流れはシンプルです。お客さんが購入を完了した瞬間に、売上金額・注文番号・買われた商品といった情報を、dataLayer（ページ上の「受け渡しの場所」）に積みます[2]。GTMはそこに積まれた情報を受け取り、GA4などの解析ツールへ「購入イベント」として送ります。
ポイントは、カートの種類が違っても、この「dataLayerに積んでGTMが送る」という骨組みは共通だということです。違うのは、dataLayerにどう情報を積むか（カートの仕様）の部分だけです。だから、まずこの型を理解しておくと、どのカートでも応用が利きます。GA4側のイベント設定の基本は GA4のイベント設定 完全ガイド｜計測の土台をそろえる もあわせてどうぞ。
2.カート問わず共通の購入計測の手順#
結論: カート問わず、そろえるのは「発火」「値と注文IDの受け渡し」「重複の防止」の3点です。この3つができれば、購入計測の土台はできます。
設定の細かい画面はカートごとに違いますが、そろえるべき中身は共通です。次の3点を押さえます。
- 発火（いつ計測を動かすか）：購入が完了した画面（サンクスページなど）で、計測が一度だけ動くようにします。途中のページで動くと、買っていない人まで数えてしまいます
- 値と注文IDの受け渡し：売上金額と注文番号（注文ID）を、dataLayer経由で正しく渡します。金額が渡らないと「件数は分かるが売上が分からない」状態になります
- 重複の防止：同じ購入を二重に数えないようにします。注文番号を目印にして、すでに数えた購入は数えない設計にしておくと安全です
この3点は、いわば購入計測の「土台」です。土台がそろっていないと、この後どんなに分析しても、もとの数字が信用できません。逆に言えば、この3点さえそろえば、購入計測としては合格点です。カートごとの対応可否は ECカートのGTM計測を比較｜対応可否の先で差がつく、Shopifyでの設定確認は GA4 eコマース設定チェックリスト｜Shopify編 に整理があります。
3.計測がズレる典型と、その先で差がつく理由#
結論: 計測は「ブラウザでスクリプトが動いたとき」しか記録しないため、サーバー側の記録とは数が合いません。ズレの正体を知ったうえで、計測の先（チャネル別の売上）まで進めると差がつきます。
計測の土台ができても、数字は完璧にはなりません。理由は、GTMやGA4の計測がブラウザ上でスクリプトが実行されたときにしか動かないからです。お店のサーバーが記録する注文と、ブラウザで動く計測は、別のしくみで数えています。だから、両者の数はぴったりは合いません[1]。
ここに、もうひとつのズレが重なります。bot（プログラムによる自動アクセス）です。botの中にはスクリプトを実行するものもいて、購入でもないのにアクセスとして記録され、参照元が分からないまま「Direct（直接）」や「不明」として数字が膨らみます。人が来ていないのに数字だけが立ち上がる、というズレです。計測のズレを放っておくと、その歪んだ数字をもとに「このチャネルが効いている」と判断してしまい、予算の配分まで狂っていきます。
そして、計測の本当の価値は、ここから先にあります。購入数や売上金額が取れても、「どのチャネルが本当に売上を生んだか」「次にどこへ予算を回すか」は、GA4の標準レポートでは構造的に見えにくい部分です。計測は数えるための土台であって、数えた数字を売上の判断につなげて、はじめて意味を持ちます。
RevenueScopeの解決策
結論: 計測した数字を、bot を除いたうえでチャネル別の売上効率（RPS）まで降ろして1画面で見せる——これは GA4 標準では構造的に重く、RevenueScope の領域です。
購入計測の土台ができても、「で、どのチャネルに予算を寄せればいいのか」のところで止まりがちです。RevenueScope は、計測した売上を、bot を除いた人間の数字でチャネルごとに分け、訪問1回あたりの売上（RPS）まで降ろして1画面に並べます。さらに、どのチャネルにも紐づかない売上は、ごまかさず「出どころ不明」の行として隠さず明示します。
たとえば「RevenueScope に聞くと、こう返ってきます」を表にすると、次のようなイメージです（数字はデモデータ）。
| チャネル | 購入数 | 売上（円） | RPS（円） |
|---|---|---|---|
| 検索 | 90 | 90,000 | 100 |
| メール | 60 | 54,000 | 180 |
| 広告A | 40 | 16,000 | 20 |
購入数だけ見れば検索が最多ですが、訪問1回あたりの売上（RPS）で見ると、いちばん効率がよいのはメールです。計測で「数える」ところから、「どのチャネルが効いているか」まで降りて初めて、次に予算を寄せる先が見えてきます。RevenueScope は、last/first/linear/time-decay といったアトリビューションの見方を切り替えて、上流で貢献したチャネルも確かめられます。なお、RevenueScope は購入計測そのものを代わりに設定するツールではなく、計測された数字を読み解いて売上の判断材料にする役割です。チャネルごとの効率の比べ方は ECのSaaS別チャネル分析を比較｜売上で見比べる、RPS という見方は RPSとは｜訪問1回あたりの売上で集客の質を見る もあわせてどうぞ。
よくある質問#
Q. GTMを使わずに購入計測はできませんか？
カートによっては、GTMを使わずに購入計測のしくみが用意されている場合もあります。ただしGTMを使うと、計測の発火タイミングや値の受け渡しを一か所で管理でき、カートをまたいでも同じ考え方で扱えます。どのカートでも応用が利く点が利点です。
Q. 計測した売上と、カートの管理画面の売上が合いません。
ある程度のズレは起こり得ます。GTMやGA4の計測はブラウザでスクリプトが動いたときにしか記録されず、サーバーが記録する注文とは数え方が違うためです。bot の混入や、計測タグが動かないケースも差を生みます。ぴったり合わせるより、ズレの原因を知ったうえで、傾向をつかむために使うのが現実的です。
Q. 購入数は取れています。次に何を見ればいいですか？
「どのチャネルが売上を生んだか」を見ます。購入数や売上合計は取れても、チャネルごとの売上効率（RPS）まで降りないと、次にどこへ予算を寄せるかは決まりません。bot を除いた人間の数字でチャネル別に見ると、判断がぶれにくくなります。
まとめ#
GTMとdataLayerでEC購入を計測する基本は、「購入完了→dataLayerに積む→GTMが受け取る→解析ツールへ送る」という、カート問わず共通の型でつかめます。そろえるのは、発火・値と注文IDの受け渡し・重複の防止の3点です。ただし、計測はブラウザでスクリプトが動いたときしか記録されず、サーバーの記録や bot の影響で数字はズレます。そして購入数が取れても、どのチャネルが本当に売上を生んだかは、GA4の標準では見えにくい部分です。計測を「数える」で終わらせず、bot を除いたチャネル別の売上効率まで降ろして、次の一手につなげる。そこまで進めて、購入計測は売上の判断に役立ちます。
どの広告が売上を生んでいるか、一目でわかる
月5,000セッションまで、AIアナリストもずっと無料。クレジットカード不要。最短5分で導入。
