テスト結果を信頼する前に、GA4の購入履歴と注文テーブルを照合してください。

GA4プロパティでは先月4,180件の購入が報告されています。一方、注文テーブルには4,690件と表示されています。どちらが正しいかと問われた場合、正直なところ、不足している510件の注文がどこへ行ったのかが分かるまでは、どちらも正しくありません。これは単なるデータの整理の問題ではありません。あらゆる実験結果や優先順位付けスコアは、未知の量と未知の方向で誤っている数値に基づいて計算されているのです。

Google は測定されていない大きなスライスを通常として扱います。同意モードの行動モデリングはプロパティが記録するまでオンになりません 1日あたり少なくとも1,000件のイベント analytics_storage='denied' 少なくとも7日間それより下のデータは、欠損したままです。

これは、eコマースチームで分析やCROを担当する方を対象としています。最終的には、調整表、ギャップを具体的な原因ごとに分解した表（それぞれにテスト項目あり）、そして説明可能な許容範囲の数値が完成します。

購入照合が実際に測定するもの

調整とは「数字を一致させること」ではありません。数字は決して一致しませんし、無理やり一致させようとするチームは、たいていの場合、そのギャップを放置するよりも悪い結果を招いています。調整は、ギャップの大きさ、それを生み出す具体的なメカニズム、そしてどれだけの損失をどれだけのコストで補填できるかという3つの質問に答えるものです。私たちは、実験を行う前に必ず調整を実施します。なぜなら、注文の一定割合が知らず知らずのうちに失われてしまうようなコンバージョンイベントを基準としたテストは、実験とは言えないからです。

ステップ1：注文IDで結合できる2つのテーブルを取得する

注文ごとに、両方のシステムから同じカレンダー範囲の行を1つずつ取得し、両方のシステムに存在するキーを使用する必要があります。

• バックエンド： 注文ID、施設の報告タイムゾーンでの作成タイムスタンプ、GA4で設定したのと同じ税金と配送基準に基づく注文金額、支払い方法、デバイス、国、ステータス。
• GA4: BigQueryのエクスポートであって、UIではありません。クエリ purchase イベント ecommerce.transaction_id, event_timestamp, ecommerce.purchase_revenueデバイスカテゴリ、およびトラフィックソース。

BigQuery を意図的に使用してください。同意モードからのモデル化されたデータは GA4 標準レポートと一部の探索に表示されますが、Google は、 BigQueryのエクスポートでは、オーディエンス、ユーザーエクスプローラー、コホートまたはリテンションの探索、あるいは予測指標などを確認できます。UIを注文テーブルと比較すると、推定値と事実を比較していることになります。

次に、注文IDでフル外部結合を実行します。これで、3つのバケットが作成されます。両方で実行されたもの、バックエンドのみで実行されたもの、GA4のみで実行されたものです。3つ目のバケットはサイズは小さいですが、最も診断に役立ちます。

ステップ2：ギャップを1つではなく3つの方法で表現する

単一の月間パーセンテージでは全てが隠されてしまいます。以下の3つ全てを計算してください。

1. 注文数のギャップ： （バックエンド注文数からGA4で一致した購入数を差し引いた数）／バックエンド注文数。これにより、トラッキング損失を分離できます。
2. 収益ギャップ： 金額についても同様の計算を行います。件数の差が3%で、売上の差が11%の場合、追跡の問題ではなく、金額の定義の問題（税金、送料、割引、通貨、ギフトカードなど）です。
3. 日々のギャップ変動： 日々の注文数の差をグラフ化します。横ばいの場合は、同意やブロック要因などの構造的な原因を示します。急増は、展開、キャンペーンの急増、または決済プロバイダーの障害を示します。

ステップ3：ギャップを具体的な原因に分解する

この表を上から順に見ていきましょう。それぞれの原因について、1時間以内に確認または否定できる検査方法が記載されています。

2人は特別な配慮を受けるべきだ。 transaction_id 重複排除はウェブストリームでのみ機能し、アプリストリームでは機能しません。また、Googleは空の文字列を送信するとアナリティクスの重複排除が機能しないと警告しています。 あらゆる 購入イベントの実施 transaction_id=''そのバグ一つで、一日の大半が無駄になってしまう可能性があります。また、不要な参照元リストはデータストリームごとに50ドメインに制限されているため、複数のアクワイアラー、ウォレット、銀行ページを使用している場合は、これが大きな問題となります。

【内部データが必要：スウィタスの和解活動におけるこれら9つの原因の分布状況を示すデータ。読者がどの原因が通常最も多いかを把握できるようにするため。】

ステップ4：自分が守れる許容範囲を設定する

Googleは許容される誤差範囲の数値を公表しておらず、よく引用される「5%なら問題ない」という表現も、私たちが調べた限りではGoogleの公式文書には見当たりません。数値そのものだけでなく、分解方法に基づいて、独自の誤差範囲を設定してください。

これらは当社の運用基準であり、業界標準ではありません。重要なのは、説明のつかない3%は、説明のついた8%よりも悪いということです。

ステップ5：作業時間あたりの回復件数が最も多い順序で修正する

1. 値の定義とタイムゾーン。 エンジニアリングではなく設定作業で、通常は午後半日程度で終わる。
2. 重複したトランザクションIDおよび空のトランザクションID。 データレイヤーの修正を1件行いました。
3. ドメインをまたいだ不要な参照。 両方を設定したら、ステージング環境ではなく、実際の支払い返送経路で再テストしてください。
4. サーバー側での購入イベント。 測定プロトコルを使用して、注文システムから購入を送信します。 client_id 生成されたウェブタグ。Google では、これらのイベントが元のクライアント側イベントのタイムスタンプから 48 時間以内に発生することを要求しており、そうでない場合、アトリビューションが期待どおりに処理されない可能性があります。これは、ブロッカーやレンダリングされなかった確認ページによって失われた注文を回復するためのものです。
5. 同意アーキテクチャ。 最も時間がかかり、政治的な側面も大きい。残りの部分は、既知の、規模が明確で、文書化されたギャップとして扱う。

トルコやEUで販売する場合、何が変わりますか？

2つの地域的な要因が数字に影響を与えている。

トルコでも同意はオプトイン方式だが、Googleのセーフティネットはない。 トルコのデータ保護当局は、法的根拠なしに広告およびマーケティング用クッキーを運用していたウェブサイト運営者に対し、決定2022/1358（2022年12月23日）で30万トルコリラの罰金を科し、必須ではないクッキーについては積極的なオプトインを義務付けた。多くのトルコのサイトは、同意モードのシグナルを送るバナーではなく、Googleタグを完全にブロックするバナーで対応した。この区別はコストがかかる：モデリングの必要性 analytics_storage='denied' イベントが存在するためには、何も表示されないようにする必要があります。何も表示されないバナーは、Googleがモデル化するための情報を提供しないため、データは推定されるのではなく、消滅してしまいます。

トルコの3DSフローは、郵便で購入者に返送されます。 iyzicoを使用すると、加盟店はデコードされた3DSページを表示し、OTP確認後、iyzicoは加盟店のページにリダイレクトします。 callbackUrl 　 status, paymentId (NAIST) と mdStatusPOST 駆動の戻りは、リダイレクトによって削除される可能性があるため、Google がクロスドメイン測定を破る原因として挙げているものです。 _gl 目的地が読み込まれる前に。カード決済のギャップが大部分を占め、代金引換のギャップがほぼゼロである場合、これが理由です。

広く流布されている2つの主張を検証できなかった

「SafariはファーストパーティCookieの保存期間を7日間に制限する。」 不正確です。WebKitのドキュメントによると、ITPはJavaScriptクッキーやその他のスクリプト書き込み可能なストレージを7日後に削除します。 ユーザーインタラクションなしまた、分類ドメインからのリンク装飾によってランディングページにアクセスした場合、JavaScript Cookieの有効期限を24時間に制限するという別の制限も設けています。Simo Ahavaのテストでは、有効期限は暦日ではなくブラウザの使用日数に基づいて計算されるため、リピーターは1週間以上識別子を保持できることが判明しました。

「5％の誤差は許容範囲内です。」 この数値の出典はGoogleでは見つかりませんでした。ベンダーのブログやフォーラムの回答などで出回っている情報です。あくまでも民間伝承として捉え、基準値として扱わないでください。

この方法が破綻する点

アプリストリームは対象外です。 transaction_id 重複排除は適用されません。また、「注文」が単一のイベントではない定期購入モデルや部分出荷モデルにも適用されません。同意を拒否したユーザーのIDを復元することはできず、ボリュームを推定することしかできません。チャネルアトリビューションは修正されません。これは別の、より困難な問題です。また、注文テーブルがクリーンであることを前提としています。キャンセルされた注文や不正利用でブロックされた注文が両側で矛盾してカウントされている場合、クエリにのみ存在するギャップを追うことになります。

よくある質問

どのくらいの頻度で実行すれば良いでしょうか？ 一度は完全な分解分析を実行し、その後は日ごとのギャップチャートを作成します。チェックアウト、CMP、決済プロバイダー、またはタグマネージャーに変更があった場合は、必ず完全な分解分析を再実行してください。

BigQueryの代わりにGA4インターフェースを使ってみてはどうでしょうか？ インターフェースには、エクスポートには含まれないモデル化されたユーザーやセッションが含まれる場合があるため、Googleの2つの数値は互いに矛盾する。推定値と照合しても、その差を分解することは不可能である。

サーバーサイドタグ付けによって、このギャップは完全に解消されるだろうか？ いいえ。この機能は、ブロッカーによって失われた注文や、表示されなかった確認ページによって失われた注文を復元します。同意を拒否したユーザーの注文は復元しません。

GA4のバージョンが当社のバックエンドよりも高いのですが、そのようなことはあり得るのでしょうか？ はい。通常、ページの更新、空のページ、または再利用されたページから重複した購入イベントが発生します。 transaction_idあるいは、制作施設に向けて発砲する準備命令。

同意モードはトルコにおける同意ギャップを解消するのか？ 部分的には可能です。拒否されたシグナルは、Googleのボリュームしきい値の範囲内でモデリングを可能にします。ただし、トルコの規則に基づく合法的なバナーの代替にはなりません。

適切なギャップとはどのようなものか？ すべてのパーセンテージポイントに名前が付いている。説明のつかない3%よりも、記録された8%の方がはるかに優れている。

この問題を修正した後、過去の報告書を改めて作成すべきでしょうか？ いいえ。固定日を注釈として記録し、各期間を別々の系列として扱ってください。追跡対象のコンバージョンを再計算すると、監査証跡が失われます。

差が10%以上ある場合でも、A/Bテストを実施できますか？ テストツール内で測定された相対的な指標に基づいて実行しますが、ギャップが分解されるまでは、GA4による絶対的な収益への影響を報告しないでください。

今月は自分のストアでこの照合を実行するか、 弊社の分析チームにお任せください。 そして、分解結果、許容誤差、修正順序をお渡しします。

ソース

• [GA4] 同意モードの行動モデリング、Google アナリティクス ヘルプ
• [GA4] トランザクションIDを使用して重複するキーイベントを最小限に抑える、Googleアナリティクスヘルプ
• [GA4] 不要な参照元、Google アナリティクス ヘルプ
• [GA4] クロスドメイン測定、Google アナリティクス ヘルプ
• Measurement ProtocolイベントをGoogle Analytics、Google for Developersに送信する
• 同意モードのパラメータ、Google Tag Platform のドキュメント
• WebKitにおけるトラッキング防止
• WebKitブラウザのJavaScriptクッキーから有効期限制限が削除されました、Simo Ahava
• KVKK クルル カラリ 2022/1358、2022 年 12 月 23 日
• 3DS実装、iyzico開発者向けドキュメント