TRACKING RELIABILITY AUDIT
広告の数字を信じる前に、送信経路を一度だけ確かめる。
Shopify・GA4・Google Ads・Metaの変更後に、purchaseの二重送信、transaction_idの欠落、value/currencyの不一致などを1ファネルだけ第三者チェックします。
初回確認ではAnalyticsアカウント権限は不要です。観測できたリクエストだけを証拠にし、顧客実績や改善効果を作り話で補いません。
- 01対象フローを1つ決める
購入・リードなど、確認したい1経路に限定。
- 02ブラウザ送信を確認
イベント回数・主要パラメータ・送信先を観測。
- 03事実と仮説を分けて返す
修正が必要なら、その後に別途範囲を決める。
「タグがある」ではなく、1件の購入がどう送られたかを見る。
Shopifyや計測ツールは複数の導入経路を持つため、変更・移行・引き継ぎの後に二重送信や欠落が残ることがあります。
初回で見るもの
- purchase等の主要イベントが意図した回数で送られるか
- transaction_id・value・currency等の主要フィールド
- GA4 / Google Ads / Meta等への明確な送信ミス
- 同じ操作の再読込・二重導入で再送される兆候
初回だけでは断定しないもの
- GA4や広告管理画面が最終的にどう集計・帰属したか
- 売上改善・ROAS改善などの顧客成果
- GTM・Shopify・CAPI側の根本原因（追加確認が必要な場合）
- 本番修正・デプロイ
WHY THIS MATTERS
重複purchaseは、レポートの見た目だけの問題ではない。
二重送信
Shopify側の標準連携とGTM・カスタムピクセル等が併存すると、同じ購入が複数経路から送られる可能性があります。
transaction_id
Googleは、Webストリームのpurchaseで一意のtransaction_idを重複除去に使うと説明しています。空欄や不一致は確認対象です。
変更後の回帰
ストア移行、タグ変更、担当交代の後は「設定があるか」ではなく、同じ操作で何が実際に送られるかを再確認します。
根拠: Google Analytics — transaction_id deduplication · Shopify — GA4 ecommerce setup and duplicate transactions
向いているのは、変更を止められないチーム。
制作会社・EC運営・広告/analytics担当が、クライアントや自社の変更後に独立したセカンドチェックを欲しい時に使います。
- 01
制作・Shopify agency
公開後や移行後の計測QAを追加したい。
- 02
広告運用・analytics
GA4・広告媒体・ストアの数字が噛み合わない。
- 03
引き継ぎ前後
旧実装と新実装が混在していないかを確認したい。
- 04
1件だけ先に確認
大きな契約前に、監査の価値を小さく確かめたい。
FAQ
最初に決めている境界。
最初からGA4や広告アカウントの権限が必要ですか？
いいえ。初回は、公開またはクライアント承認済みの1ファネルをブラウザ側から確認します。管理画面アクセスが必要な調査や修正は、価値が確認できた後に別途範囲を決めます。
何を確認しますか？
purchaseなどのイベントが何回送られたか、transaction_id・value・currencyなど主要項目が入っているか、送信先やイベント名に明確な不一致がないかを、観測できたリクエストの範囲で確認します。
監査だけで原因まで断定できますか？
断定しません。最初のレポートでは、ブラウザから実際に観測できた事実と原因仮説を分けます。GTM・Shopify設定・広告管理画面側の確認が必要な場合は、その次の調査として明示します。
制作会社や広告代理店でも使えますか？
はい。クライアント案件の変更後チェックや、引き継ぎ時の独立したセカンドチェックを主な用途として想定しています。