注文は1件なのにGA4の購入が2回？注文番号と購入完了ページの記録を比べる

最初に、注文原本と購入の記録を並べる

先に確かめるのは、二つの資料が同じ注文を指しているかです。注文原本は、店が何を受注したかを確認する資料。購入の記録は、サイトがGA4へ送る操作の情報です。同じものを数えているとは限りません。

GA4はWebやアプリの利用を測るGoogleの道具です。購入したことを伝える操作の記録を purchase と呼び、その記録へ渡す取引の番号が transaction_id です。ここでは、注文原本との対応を確認するための「購入記録へ渡す番号」として扱います。注文番号そのものは、資料を結ぶために必要なので残します。

Web実装担当へ、調べる期間と、どのサイト・送信先・操作で記録が出たかを添えて資料を依頼します。注文原本、購入完了時の記録、同じ画面を再表示したときの記録を並べます。資料がまだなければ未確認とし、番号や送信回数を想像で埋めません。

Googleのeコマース計測資料は、購入のイベントと必要な情報を実装して送る仕組みを説明しています。この記事のメモは、その実装や実際の決済を代行する道具ではありません。

同じ注文の再記録と、別注文の同じ番号を分ける

番号を見るときは、同じ注文なら同じ番号か、別の注文なら別の番号かの両方を比べます。下の例は、注文原本で成立を確認したという架空の設定です。

• 注文001には記録1と記録2があります。購入完了時と同じ画面の再表示で、どちらにも注文001が渡っています。同じ注文の再記録候補です。2行だから新しい注文が2件あった、と増やしません。
• 注文002の記録3には注文002が渡っています。一方、別の注文003の記録4にも注文002が渡っています。注文003は原本の番号と不一致で、別注文の番号を使っている状態です。注文002と注文003を一つの注文へまとめません。
• 注文003の記録4を、資料上で注文003へ書き換えて済ませません。元の記録を残し、番号をどこから読み取ったかを実装担当へ確認します。

GoogleのトランザクションIDの資料では、注文ごとに一意の番号を使い、同じユーザーの購入の重複を抑える方法を説明しています。異なる注文へ同じ固定番号を使うと、購入を少なく数えてしまう可能性があります。多く見える記録を減らすためだけに、全部の注文へ同じ番号を付ける方法は使いません。

七行の元注文・操作・番号項目・渡した値・ブラウザー条件・次の確認を、同じ項目で読み比べます。記録を読むことと、実GA4で何件に集計されたかを確かめることは別です。

5注文と7行の送信記録を比べる

すべて架空の説明用原票です。番号セルが空の記録5は空文字で、番号項目欄と併せて読みます。記録6・7の項目なしと区別してください。実GA4の受信・集計件数は未確認です。

詳しい七行は補足を開くと、元の注文番号と渡した番号を近くで読み比べられます。記録5の空文字と、記録6・7の項目不在も分けて表示します。

空文字と、番号の項目がない状態を分ける

どちらも画面では空欄に見えることがあります。番号の項目があり、その値が空なのか。番号の項目自体が見当たらないのか。 ここを分けて担当へ渡します。

注文004の記録5には transaction_id の項目がありますが、値は空文字 "" です。注文原本の番号を読み取る箇所、値を渡すタイミングを実装担当へ確認します。公式資料は空文字の番号を送らないよう案内しています。この架空行から、何件が実際に集計されたかまでは決めません。

注文005の記録6と記録7には、番号の項目がありません。記録7は同じ完了画面を再表示したときのものです。元資料にない項目を、空文字や注文005で補完しません。確認用の資料から省略されたのか、送る情報にないのかも、まだ分かりません。どの送信元と資料を見たかを実装担当へ確かめます。

記録5の空文字は「""（空文字）」と表示し、「番号項目」では「項目あり・空文字」と示します。記録6と7の「項目なし」と分けて読みます。どちらも0件の購入や確認済みを意味しません。

集計を決めつけず、再表示と番号生成を実装担当へ確認する

渡すメモは「7行を何件へ減らすか」ではなく、どの注文と記録が対応し、どこが未確認かです。実装担当には、次の順で確認を依頼します。

1. 元注文の番号を、どの資料や処理から読み取るか。別注文へ前の番号が残る箇所がないか。
2. 初回の購入完了時と、再読込・別タブ・後日の再訪で、購入の記録がどう作られるか。今回の7行だけでは、すべての経路を試したことにはならない。
3. Web側とサーバー側など、どの送信元・送信先の資料を見ているか。実際の受信とレポートの集計を、同じ対象・期間でどう確認するか。

番号による公式の重複抑制の説明は、Webストリームの範囲です。ストリームは、GA4がサイトやアプリの情報を受け取るまとまりを指します。アプリストリームへ同じ説明を自動適用しません。「同じ説明用ブラウザー」という原票の記述だけで、実際の利用者を識別できたとも認定しません。同意条件や送信経路が原因だと決めつけず、取得できた資料と不明を分けます。

Google広告の「Count」と取引番号の資料も、広告クリック後の成果の数え方と、同じ購入の重複を番号で抑えることを区別しています。Google広告の設定をGA4へ移したり、「1セッション1回」に変えれば番号の不一致が直ると扱ったりしません。この記事では設定を変更しません。

今日の注文1件を、次の確認ができるメモにする

まず注文1件を選び、原本と対応する送信記録を並べます。「渡した番号」「項目の有無」「観察した関係」「未確認の資料」「次の担当」を残せれば、実装担当が調べる場所を具体化できます。

報告では、たとえば「注文001に対応する記録1・2は、購入完了時と再表示という別の操作で、同じ注文001を渡している。実受信と集計は未確認」と、原本と送信記録を分けて説明します。

資料の種類、確認した番号と項目の有無、残る確認と担当の役割を記録します。実顧客の氏名や認証情報を載せず、分からない点を未確認のまま残します。

送信記録と注文原本の違いが説明できても、GA4の実集計や修正の効果は別の確認です。元の記録を消さず、実装担当が確認した資料と結果を追記します。今日の一歩は、件数を合わせることではなく、注文1件と記録の対応を説明できる形で渡すことです。

注文台帳とWebの報告がつながらない場合は、比較した資料の種類、番号の一致・不一致、まだ分からないことを添えてDREEXYへ相談できます。支援範囲・費用は個別に確認してください。Yumexyは開発中です。詳しい支援内容は相談時に確認してください。

実装担当へ、注文と送信記録の違いを具体的に伝える

注文001なら、同じ注文の記録1・2で操作の場面が違い、同じ番号が渡ったことを伝えます。注文003なら、原本と違う注文002が渡った記録4を示します。注文004の空文字と、注文005の項目不在も分けます。

番号を作る・読み取る箇所、完了画面を再表示した経路、送信元と送信先の資料を、実装担当へ確認します。元の資料を残し、実際の受信と集計を別に確かめます。説明用の記録を実注文や実計測の結果として使いません。

確認に使った公式資料

• Google Analytics：トランザクションIDと購入の重複。注文ごとの番号、空文字、Webストリームの範囲を確認。
• Google Analytics：eコマース計測。購入イベントを実装して送る仕組みを確認。
• Google広告：取引番号とCount設定の違い。GA4へ広告の数え方を移さないための境界の確認。

2026年10月12日に該当箇所を確認。本文の5注文・7行と記入例は架空の教材です。実GA4の集計・タグの修正・顧客の成果を検証した値ではありません。