この工程でやること
購入の記録が合わない原因のうち、最初に手を入れるべきなのが「決済画面へ移る瞬間」です。カートまでは追えていたユーザーの情報が、決済画面に移った途端に消える。この区間をつなぐのがCookie Bridgingと呼ばれる工程です。
やることはシンプルで、決済へ進む直前に、ブラウザの中にある識別情報を注文データの中へ預けておくだけ。預けておけば、決済が完了したあとにサーバー側からその情報を読み出して、どのユーザーの購入だったのかを復元できます。
この記事では、何を預けるのか、いつ預けるのか、そして預ける処理が失敗したときに購入を止めないためのルールを解説します。実装の細かい書き方ではなく、判断のしどころに絞ってまとめています。
ブラウザの中の情報が決済側に届かない理由
識別情報はユーザーの端末の中にしかない
GA4は、サイトを訪れたユーザーを見分けるための識別子を、ブラウザのCookie（ユーザーごとの目印をブラウザ内に保存しておく仕組み）に保存しています。この情報はユーザーの端末の中にあるもので、サーバー側の処理から勝手に覗きにいくことはできません。フロント側の画面が動いている間は読めるのに、画面を離れた途端に手が届かなくなる。この非対称さが、計測が途切れる根っこの部分です。
決済画面はフロントとは別の仕組みで動いている
ヘッドレス構成では、商品を見せる画面と決済を担う画面が、別々のサービスとして動いています。ユーザーから見れば同じ買い物の流れですが、システムから見るとバトンの受け渡しが1回発生している状態です。バトンに何も乗せずに渡すと、決済側は「誰が買ったか」を知らないまま注文だけを作ります。結果として、注文データを後から見ても、どの流入経路から来た購入なのかを判断できません。
だから、注文データという共有の箱に預けておく
解決の考え方は単純で、両者が同時に触れる場所にデータを置いておくこと。それが注文データに付けられるメモ欄（カートや注文に紐づく補足情報の入れ物）です。決済へ進む直前にフロント側から書き込んでおけば、決済完了後にサーバー側から読み出せます。ブラウザの中にしかなかった情報を、注文と一緒に運ばれる荷物に載せ替えるイメージです。
図を一言でまとめると、消えてしまう前にメモへ書き写しておき、決済が終わったあとにそのメモを読む、という流れです。
何を、いつ引き継ぐか
預ける項目は3種類に絞る
分析用の識別子、注文を一意に見分けるための識別子、どのサイト由来の注文かを示す識別子。この3つがそろえば、購入をGA4へ送り直すのに必要な材料は足ります。項目を増やせば分析の幅は広がりそうに見えますが、実際には管理する対象と、うっかり個人情報を持ち出してしまうリスクが増えるだけ。最初は必須のものだけで始めて、運用の中で本当に必要だと分かった項目を後から足すほうが安全です。
書き込むのは「決済へ進む操作をした瞬間」
早すぎると古い情報のまま残りやすく、遅すぎると書き込みが終わる前に画面が移ってしまいます。扱いやすいのは、ユーザーが決済へ進むボタンを押した直後。購入の意思がはっきりした地点なので、処理を差し込む場所も1か所に限定できます。ボタンを押す、メモを書き込む、決済画面へ移る。この順番を必ず守るように処理の流れを固定しておくと、書き込み漏れがほとんど起きなくなります。
使い回しではなく、そのカートに紐づける
同じユーザーが複数のカートを行き来したり、時間を置いてから購入したりする場面はよくあります。識別情報をサイト全体で共有する形にすると、どの注文に対応するのかが曖昧になります。書き込み先は必ず、いま決済へ進もうとしているカートに限定する。こうしておけば、注文が作られた時点で情報が1対1で紐づき、あとから照合するときに迷いません。
購入を止めないための実装ルール
書き込みに失敗しても、決済へは進ませる
通信の一瞬の不調などで、メモの書き込みが失敗することがあります。このとき処理を止めてしまうと、計測のために購入をひとつ失うことになる。優先順位は明確で、購入が先、計測は後です。失敗したら記録だけ残して、ユーザーはそのまま決済へ進ませる。この考え方をfail-open（失敗しても通す）と呼びます。計測の精度は後から積み上げられますが、失った売上は戻ってきません。
受け付ける項目をあらかじめ決めておく
メモの書き込みを受け付ける窓口を、どんな項目でも通す状態にしておくのは危険です。想定していないデータが紛れ込んだり、外部から不正な値を送り込まれたりする余地が生まれます。許可する項目名をリストとして持っておき、そこに無いものは受け付けない。この形にしておくと、安全性が上がるだけでなく、トラブルが起きたときに「何が入り得るか」がはっきりしているぶん原因の切り分けも早くなります。
値の長さと形式に上限を設ける
受け取る値に長さや形式の制限をかけておくと、おかしなデータが入り込んだ時点で止められます。制限がないままだと、記録が肥大化して調査に時間がかかったり、監視の画面が無関係な警告で埋まったりします。短い値であること、決められた形式であること、必要最小限であること。この3つを守るだけで、後工程の運用の手間がかなり軽くなるんですよね。
ログには何を残し、何を残さないか
障害を調べるための記録は、成功か失敗か、失敗の種類、発生した時刻があれば十分です。個人を特定できる情報や、認証に使う秘密の値は残さない。残しすぎれば情報漏えいのリスクになり、残さなすぎれば原因が追えなくなります。調査に使う項目をあらかじめ決めてテンプレート化しておくと、担当者が変わっても同じ品質で対応できます。
運用してみて分かった課題
「たまにしか失敗しない」から気づけない
再現率の低い失敗は「たまたま」で片づけられがちですが、月単位で積み上がると無視できない差になります。週に一度、書き込みの失敗率を確認し、決めておいた基準を超えたときだけ調べる。この運用ルールがあると、感覚ではなく数字で判断できます。小さな異常を早い段階で拾えるようにしておけば、後から大がかりな修正をする場面を減らせます。
複数サイトを1つの基盤で回すと注文が混ざる
同じ仕組みで複数のサイトを運用している場合、注文がどのサイト由来かを示す情報を必ず持たせる必要があります。これが無いと、別サイトの注文を誤って送ってしまい、媒体ごとの成果評価が崩れます。数字が合わないという相談を受けたとき、最初に確認するのはこの項目の有無です。ここが埋まっていないケースが、想像よりずっと多い。
項目を増やしたくなるが、増やさない
運用が進むと「あれも取っておけば分析できたのに」と思う場面が出てきます。ただ、項目を足すたびに管理の手間と確認すべき箇所が増えていく。追加するときは「その項目を、どの判断に使うのか」を先に言葉にしてから決める。使い道が説明できない項目は足さない、というルールにしておくと、仕組みが必要以上に複雑になりません。
導入前のチェックリスト
表を一言でまとめると、購入を止めない、余計なものを受け取らない、どこ由来かを分かるようにする、そして結果を定期的に見る。この4点がそろっていれば、この工程は合格です。
まとめ
Cookie Bridgingは、ブラウザの中にしかない識別情報を、決済後も読み出せる場所へ預けておく工程です。預ける項目は3種類に絞り、決済へ進む操作の直後に書き込む。そして書き込みに失敗しても購入は止めない。この3点を守れば、後工程で購入を送り直すための材料がそろいます。
実装そのものはAIエージェントに任せて組み立てましたが、どこまでを引き継ぐか、失敗したときに何を優先するかという判断は人が決める部分でした。次の記事では、ここで預けた情報を使って、決済完了後にサーバー側から購入を送る仕組みを解説します。