GA4の参照元にStripe・PayPalが混ざる原因と除外設定|CVの参照元が決済ドメインに奪われる時の直し方
GA4のCVの参照元がstripe.comやpaypal.comに奪われる原因を仕組みから解説。「除外する参照のリスト」の設定手順、日本の決済・3Dセキュア系の除外ドメイン早見表、設定しても直らない時の5つの原因切り分けまで、広告評価を守る実務手順をまとめました。
この記事のポイント
- GA4でCVの参照元がstripe.comやpaypal.comになるのは、決済ドメインへの遷移をGA4が新規流入と誤認するためです。
- 「除外する参照のリスト」は設定後の新規データにのみ効き、反映まで24〜48時間かかり過去データは修正されません。
- 除外対象はStripe・PayPal・Amazon Pay・楽天ペイ・3Dセキュア系ドメインに絞るのが実務上の定石です。
- 除外後も直らない場合は、反映ラグ・セッション分断・ラストノンダイレクトクリックの残留を順に疑う必要があります。
- 誤った参照元のCVはスマート入札の学習データを汚染し、好調なキャンペーンの予算が縮小される波及リスクがあります。
購入完了のコンバージョンを開いたら、参照元が広告でもオーガニックでもなく「stripe.com / referral」になっている——ECサイトやサブスクサービスのGA4を日常的に見ている担当者なら、一度は遭遇したことがある症状だと思います。広告経由で来ていたはずのユーザーが、決済画面を挟んだ瞬間に「stripe.com」や「paypal.com」からの流入として記録され直されてしまう。GA4 参照元 stripe というキーワードで検索してこの記事にたどり着いた方は、まさにこの状態に直面しているのではないでしょうか。
結論から言うと、これはGA4の不具合ではなく、決済ページへのリダイレクトを新しい訪問として認識してしまう仕組み上の挙動です。原因を理解したうえで「除外する参照のリスト」を正しく設定すれば当日中に対処できますが、設定しても直らないケースも珍しくありません。この記事では、原因の構造から具体的な設定手順、そして除外しても改善しない場合の切り分けフローまで、広告評価を守るために必要な工程を順番に解説します。

GA4の参照元にStripe・PayPalが出てくるのはなぜ?
図1: 決済リダイレクトで参照元が上書きされる流れ
GA4の参照元がstripe.comやpaypal.comになるのは、決済画面への外部遷移をGA4が新規セッションの流入として扱ってしまうためです。GA4はセッションの参照元を、直前にユーザーがどのドメインから来たかで判定します。広告をクリックしてサイトに訪れ、カートを経て決済ページ(Stripeのチェックアウトページやhttps://checkout.stripe.com等)に遷移すると、そこからサイトへ戻ってきた瞬間の参照元が「stripe.com」として記録されることがあります。
決済リダイレクトで参照元が上書きされる流れ
流れとしては、①広告クリックでgclid付きのURLに着地→②GA4がGoogleタグ(gtag)経由でセッションの参照元を「google / cpc」として保存→③決済のためStripeやPayPalのドメインへ遷移→④決済完了後に自社サイトへリダイレクトで戻る、という順序になります。この④の時点で、GA4が新しいセッションと判定すると、参照元がgoogle / cpcからstripe.com / referralなどに上書きされてしまいます。
referral表示と本来の流入元の関係
ここで重要なのは、referralという表示自体は「参照元ドメインが記録されている」という意味しか持たない点です。ユーザーが最初にどこから来たかという本来の流入経路とは別物であり、決済ドメインはあくまで経由地に過ぎません。この違いは、セッションの参照元とユーザーの最初の参照元の違い を理解しておくと切り分けやすくなります。
決済ドメインの参照元を放置するとどうなる?
広告の成果が正しく評価されず予算が削られる不安
決済ドメインの参照元を放置すると、チャネル別のCV集計がゆがみ、広告の実際の貢献度が過小評価されます。GA4のトラフィック獲得レポートは参照元/メディアを基準にチャネルを分類するため、決済ドメインが参照元として記録されたCVは「Referral」チャネルに計上され、本来評価されるべき広告チャネルの成果として反映されません。
トラフィック獲得レポートが壊れる
とくにサブスクリプション型のサービスでは、毎月一定数のCVが決済ドメイン経由に化けることで、広告経由CVの実数が継続的に少なく見える状態が固定化されます。CVの参照元がおかしいと感じたら、まずはこのReferralチャネルへの流入元を確認する習慣が有効です。あわせて GA4とGoogle広告のコンバージョン数が合わない原因7パターン も、参照元のズレがCV数不一致の一因になっているケースの診断に役立ちます。
広告評価と入札最適化への波及
海外の広告運用系メディアSeresaでは、PayPalが誤ってトラフィック獲得レポートの上位に表示され、広告のアトリビューションが崩れる事例が紹介されています。GA4の測定データをGoogle広告に連携している場合、誤った参照元のCVはスマート入札の学習シグナルにも影響し、実際は成果を出しているキャンペーンの評価が下がって予算が縮小される、という指摘もあります。日本のEC・サブスク事業でも、GA4連携でスマート入札を使っている場合は同様の構造でCV評価がゆがむ可能性があるため、参照元の整備は計測担当者だけでなく広告運用担当者にとっても無視できない論点です。
「除外する参照のリスト」の設定手順
図2: 管理画面での5ステップ設定フロー
除外する参照のリストとは、指定したドメインをセッションの参照元として扱わないようGA4に指示する設定です。この設定を使えば、決済ドメインを経由しても直前の参照元(広告やオーガニック検索など)が維持されるようになります。
管理→データストリーム→タグ設定を行う→不要な参照の一覧
GA4管理画面の「管理」から対象のデータストリームを開き、「タグ設定を行う」→「表示」の中にある「不要な参照の一覧」を選択します。ここに登録したドメインは、参照元として計上されなくなります。この機能は内部的にはGoogleタグ(gtag)のignore_referrerパラメータと同じ仕組みで動いており、対象ドメインからの遷移を「サイト内遷移の続き」として扱う指示にあたります。
条件(含む/次で終わる)の選び方
ドメインを登録する際は「含む」と「次で終わる」のいずれかの条件を選びます。checkout.stripe.comのようにサブドメインが固定されていれば「含む」で問題ありませんが、決済代行会社によってはサブドメインが可変のケースもあるため、「次で終わる」でルートドメイン単位(例:stripe.com)を指定した方が漏れを防げます。
設定が反映されたかの確認方法
設定後すぐに古いCVの参照元が変わるわけではありません。Analytifyの解説記事でも触れられている通り、反映には最大24〜48時間ほどかかり、それ以前のデータは遡及して修正されません。確認は、設定から2日以上経過したあとの新規セッションで、決済ドメイン経由の流入がリファラーとして計上されていないかをトラフィック獲得レポートで見るのが確実です。
除外すべき決済・認証ドメインのリスト
日本のEC・サブスク事業で実務上よく登場する決済・認証ドメインを整理すると、以下のようになります。
| 分類 | 代表的なドメイン例 |
|---|---|
| Stripe | checkout.stripe.com / js.stripe.com |
| PayPal | www.paypal.com / paypal.com |
| Amazon Pay | payments.amazon.co.jp |
| 楽天ペイ | checkout.rakuten.co.jp 系 |
| 3Dセキュア(本人認証) | 各カード会社・決済代行会社の認証専用サブドメイン |
Stripe・PayPal・Amazon Pay・楽天ペイ等の主要決済
上表はあくまで代表例であり、実際に登録すべきドメインは自社が利用している決済代行会社の管理画面や、GA4上で実際にReferralとして表示されているドメインを見て特定するのが確実です。同じStripeでも、埋め込み型のチェックアウト(Stripe Elements等)を使っているか、外部ページにリダイレクトする形式かで、参照元として現れるかどうかの挙動が変わることがあります。
3Dセキュア(本人認証)系ドメインの扱い
3Dセキュア(EMV 3-Dセキュア)はカード決済時の本人認証で経由するドメインで、カード会社や決済代行会社ごとに異なるサブドメインが使われます。決済フロー上で必ず経由するにもかかわらず見落とされやすいため、実際にトラフィック獲得レポートに現れたドメインを都度確認し、追加登録する運用が現実的です。
自社サブドメインは登録不要な理由
自社の別サブドメイン(例:shop.example.comからexample.comへの遷移)は、GA4が同一ルートドメイン内の遷移を自動的に自己参照として除外する仕様になっています。そのため、除外する参照のリストにわざわざ自社ドメインを追加する必要はありません。複数の自社管理ドメインをまたぐ場合は、除外リストではなく後述するクロスドメイントラッキングの設定範囲になります。
除外設定したのに直らない時の原因切り分け
一つずつ原因をチェックしていく地道な作業
除外設定をしても決済ドメインの参照元が残る場合、原因は主に4つに切り分けられます。順番に確認すると原因を特定しやすくなります。
反映ラグと過去データ遡及不可
もっとも多いのが、設定直後にすぐ確認してしまうケースです。海外の計測系メディアAttriの解説でも、除外設定は新規データにのみ適用され、過去データには遡及しないと明記されています。設定日より前のCVがそのまま表示されているのは不具合ではなく仕様です。
決済に30分以上かかるとセッションが分断される
GA4のデフォルトのセッションタイムアウトは30分です。ユーザーが決済ページで入力に手間取ったり、離脱して後日決済を完了したりすると、セッションが分断されて別セッション扱いになります。この場合、除外リストが正しく機能していても、分断後の新セッションの参照元として決済ドメインが記録されることがあります。
ラストノンダイレクトクリックで旧referralが残り続ける
GA4のデフォルトのアトリビューションモデルはラストクリック(ラストノンダイレクトクリック)です。除外設定を行った後も、過去にstripe.com等が参照元として記録されたセッションが、しばらくの間はラストノンダイレクトクリックの参照元として保持され続けることがあります。Attriの記事では、これが数ヶ月単位で残る場合があると指摘されており、除外設定=即座に過去のクレジットも書き換わる、という誤解が問い合わせの多くを占める要因になっています。
サーバーサイドリダイレクトではクロスドメイン設定も効かない
海外のSnifflyticsは、決済ゲートウェイの遷移パターンをリダイレクト型・埋め込み型などに分類し、パターンごとに対処が異なると整理しています。とくに注意したいのが、決済代行会社側のサーバーサイドリダイレクトで自社サイトに戻ってくる方式です。この方式ではクリックに付与される_glパラメータが引き継がれないため、クロスドメイントラッキングの設定を組んでいても効果が及びません。GCLIDなどのパラメータがリダイレクトの過程で失われる現象は、GCLIDが遷移先LPで消える原因と対処 で扱っている問題と構造がよく似ています。
除外してはいけないドメインとやりすぎのリスク
除外リストは決済・認証ドメインに絞るのが基本方針です。何でも登録すると、本来把握すべき流入元の情報まで見えなくなってしまいます。
除外対象は『ユーザーが経由するだけのドメイン』に絞る
除外の判断基準は、そのドメインがユーザーの本来の流入経路ではなく、単に決済や認証のために経由するだけのドメインかどうかです。提携メディアやアフィリエイトサイトのように、実際にユーザーがそこから流入している可能性があるドメインを除外リストに入れてしまうと、有効な流入インサイトを失うことになります。
上限50件と棚卸しの考え方
除外する参照のリストは1データストリームあたり最大50件までという制約があります。決済・認証系のドメインは事業拡大に伴って増えていくため、使っていない決済手段のドメインが残っていないか、定期的な棚卸しをしておくと上限に達するリスクを抑えられます。除外後にdirectとして計上されるケースが増えてきた場合は、ノーリファラー直接流入と有料広告を分離するカスタムチャネルグループ設定 を組み合わせると、直接流入と広告流入の混同を防ぎやすくなります。また、自社が複数ドメインを運用している場合の役割分担については、GA4のクロスドメイン設定とサイト遷移後のチャネルの扱い も参考になります。
よくある質問
Q:除外する参照のリストを設定すると、過去のデータも修正されますか? 修正されません。この設定は反映後に発生する新規データにのみ適用され、過去に記録済みのセッションやCVの参照元は書き換わりません。設定の反映自体にも24〜48時間ほどかかるため、設定直後に過去のデータを見て「効いていない」と判断しないよう注意が必要です。
Q:自社サイトのサブドメインも除外リストに追加すべきですか? 基本的に不要です。GA4は同一ルートドメイン内のサブドメイン間遷移を自己参照として自動的に除外する仕様になっています。複数の自社管理ドメインをまたぐ構成の場合は、除外リストではなくクロスドメイントラッキングの設定範囲になります。
Q:除外設定したのにまだstripe.com / referralのCVが出るのはなぜですか? 主に3つの原因が考えられます。1つ目は設定の反映ラグ、2つ目はラストノンダイレクトクリックにより過去に記録された参照元がしばらく残り続ける挙動、3つ目は決済に時間がかかったことによるセッションの分断です。この順番で確認していくと原因を特定しやすくなります。
Q:除外する参照のリストには何件まで登録できますか? 1データストリームあたり上限50件です。上限に対して余裕を持たせるため、決済・認証系のドメインに絞って登録し、使われなくなった決済手段のドメインは定期的に棚卸しするのが実務上の定石です。
Q:参照元除外とクロスドメイントラッキングはどう使い分けますか? 自社で管理している複数ドメインをまたいでユーザーが遷移する場合はクロスドメイントラッキングで参照元を維持し、Stripeやアマゾンペイのような自社管理外の決済ドメインを経由する場合は除外する参照のリストを使う、という役割分担になります。両者は目的が異なるため、片方だけで解決しようとすると設定が噛み合わなくなることがあります。
GA4の参照元が決済ドメインに奪われる問題は、設定を直せば終わりというより、広告評価の正確さそのものに関わる論点です。真策堂では、GA4の計測整備からGoogle広告のスマート入札の評価まで、こうしたデータの歪みが広告投資判断にどう波及するかという観点でのご相談を受けています。参照元の異常に心当たりがある場合は、まずはトラフィック獲得レポートの内訳から確認してみることをおすすめします。
除外すべきドメインを自社のデータから洗い出す手順
「実際に出ているドメインを見て登録する」と言っても、標準レポートのままだと購入に関係ない参照元まで混ざって探しにくいと思います。探索レポートで購入イベントだけに絞ると見つけやすいかなと。
- 探索の「自由形式」を開き、ディメンションに「セッションの参照元 / メディア」「ランディング ページ + クエリ文字列」「ページの参照 URL」を追加する
- 指標に「イベント数」を置き、フィルタでイベント名を purchase(自社の購入完了イベント名)に絞る
- メディアが referral の行だけを残し、ランディングページを確認する
判断基準はランディングページです。サンクスページや注文完了ページがランディングになっている referral のセッションは、流入ではなく「決済からの戻り」である可能性が高いと思います。その行の「ページの参照 URL」に出ているホスト名が、登録候補のドメインになります。
逆に、ランディングが商品ページや記事ページになっている referral は本当の流入かもしれないので、除外候補から外しておいた方が安全かなと思います。
テスト決済で反映前に効き目を確かめる方法
レポートへの反映を待たなくても、ブラウザの開発者ツールで自分のテスト決済を追えば、設定が効いているかはその場である程度判断できると思います。
- Networkタブで
collectを絞り込み、決済前のページと、決済から戻った直後のページのリクエストを見比べる sid(セッションID)が決済の前後で同じ値なら、セッションは継続している- 戻った直後のリクエストに
_ss=1(セッション開始)が付いていたら、そこで新しいセッションが始まっている drに決済ドメインが入っていても、除外が効いていればir=1が一緒に送られることが多い
つまずきやすいのは、dr に決済ドメインが入っているのを見て「効いていない」と判断してしまうパターンです。dr はブラウザが渡すリファラーそのものなので、除外設定をしても値は残ります。見るべきは ir の有無と sid が変わっていないか、の2点かなと思います。
また、リファラーを送らない設定の決済ページから戻ると dr が空になり、除外リストとは関係なく direct 寄りに見えることもあります。この場合は除外リストでは対処できないので、別の問題として切り分けた方が良いと思います。
決済後にサイトへ戻ってこないユーザーの計測漏れ
参照元を直しても、購入数そのものが決済代行会社の管理画面と合わないことがあります。原因として考えやすいのは、決済完了の画面でタブを閉じてしまい、サンクスページに戻ってこないユーザーです。購入イベントをサンクスページの表示で発火させている構成だと、この分は参照元以前に計測されません。
この場合は、決済代行会社のWebhook(決済完了通知)を受けて、サーバーから Measurement Protocol で purchase を送る構成が選択肢になると思います。その際に気をつけたい点は次の通りです。
- 決済へ送り出す前に、GA4の
client_idとsession_idを注文情報に紐づけて保存しておく。これがないと、サーバーから送ったイベントが元のセッションに結びつかず、参照元が付かない購入になりやすい - サンクスページ側の発火と併用するなら、同じ
transaction_idを必ず付ける。値が揃っていないと二重計上の原因になる - Webhookの到着が遅れるとセッションが切れた後の送信になるので、どのくらいの遅延で届くかを事前に確認しておく
どちらの方式に寄せるかは、戻ってこないユーザーの割合次第かなと思います。まずは決済代行会社側の決済件数とGA4の purchase 件数を同じ期間で比べて、差が気になる大きさかどうかを見てから判断するのが良いと思います。
- アクセス解析
GA4でutmパラメータが反映されない原因と確認手順|キャンペーンが(not set)になる4系統の切り分け
GA4でutmパラメータが反映されない、utm_campaignが(not set)になる原因を、表記ルール・リダイレクト・Google広告自動タグとの競合・セッションスコープ仕様の4系統で切り分け。DebugViewを使った5分診断から再発防止の命名ルールまで、当日中に原因特定できる実務手順で解説します。
- アクセス解析
GA4のクロスドメイン設定が効かない・_glパラメータが付かない原因と確認手順|設定・リンク形式・リダイレクトの3層切り分け
GA4のクロスドメイン設定をしたのに_glパラメータが付かない・途中で消える・セッションが切れる原因を、設定・リンク形式・リダイレクトの3層で切り分け。遷移先URLを見る1分テストから、ボタンやフォームで効かない理由、Networkタブでの消失箇所の特定、修正後の検証まで当日中に確認できる手順でまとめました。
- アクセス解析
Looker Studioを共有したらグラフが表示されない原因と対処|「オーナーの認証情報」と「閲覧者の認証情報」の違いと使い分け
Looker Studioを共有したのに相手の画面でグラフが表示されない原因を、レポート共有・データの認証情報・元データ権限の3層で切り分け。オーナーの認証情報と閲覧者の認証情報の違い、変更手順、共有相手別の使い分け、担当交代で壊れない設計まで、当日中に直せる実務手順で解説します。