plan-4ging

2026/03/30

backend #web#cookie#jwt

異なるドメイン間での流入元特定/データ連携

同一ドメイン内では使えた仕組みがそのまま使えないケースが多い

Referer の省略/制限
HTTPS → HTTP の遷移や Referrer-Policy の設定によって、Refererが送られない

Cookie の分離
ブラウザは Cookie をドメイン単位で管理するため、site-a.com の Cookie は site-b.com には送られない

localStorage / sessionStorage の分離
Web Storage もドメインをまたいで読み書きできない

特定/連携方法

UTM パラメータ

Google Analytics が定めた流入元を識別するためのクエリパラメータ
URL に付与するだけで実装できる

https://site-b.com/landing?
  utm_source=site-a
  &utm_medium=banner
  &utm_campaign=summer2024

カスタムクエリパラメータ

自社サービス間の連携専用の識別子をクエリパラメータとして使用する

https://site-b.com/landing?
  ref_service=service_a
  &ref_feature=dashboard
  &ref_user_token=abc123

Prefix を統一することで区別しやすくなる

ref_service   → 送り元サービスの識別子
ref_feature   → 送り元の機能・画面
ref_plan      → 送り元ユーザーのプラン

Referer

リクエストの直前にいたページの URL

補助的な流入元把握に使えるが、以下ケースなど送られない場合もあるため信頼性は低い

  • HTTPS → HTTP の遷移（セキュリティ上の理由で省略）
  • rel="noreferrer" が付いたリンク（<a href="..." rel="noreferrer">）
  • Referrer-Policy の設定（no-referrer・origin・strict-origin 等）
  • ブックマーク・アドレスバーからの直接アクセス
  • 一部のプライバシー保護ブラウザ・拡張機能

ワンタイムトークン

UTM パラメータやカスタムクエリパラメータでは URL に露出してしまうユーザー ID・プラン・権限などの機密情報を、安全にドメイン間で引き渡す手法
双方のサービスが同じ Redis を参照できることが前提条件（または Redis を持つ側が専用 API を用意）

① 送り元（site-a.com）がバックエンドでトークンを生成し
　 ユーザー ID などの機密情報を Redis に一時保存する（有効期限 5分など）

② トークンだけを URL に付与して受け取り先（site-b.com）にリダイレクト
　 https://site-b.com/landing?token=abc123xyz
　 ↑ URL に user_id や plan は一切含まれない

③ 受け取り先がトークンを取り出し Redis に問い合わせて情報を復元する

④ 取り出したトークンを即座に削除（ワンタイム性を保証）

JWT トークン

Redis を使わずに JWT に情報を埋め込む手法であり、ステートレスな構成になる
ただしトークンの即時無効化ができない点に注意

Cookie / localStorage

同一の親ドメイン（.example.com）を共有している場合に、Cookie のドメイン指定でサブドメイン間の状態を共有できる

# site-a.example.com → site-b.example.com の場合
# Domain=.example.com を指定することで両方から読める

localStorage

同一ドメイン内でのページを跨いだ複数ステップの情報保持に活用する

各手法の比較・使い分け

手法向いている用途
UTM パラメータ流入元の分析・マーケティング計測・GA 連携
カスタムクエリパラメータ（ref_service 等）サービス間の流入元判定・画面出し分け・内部システム連携
Referer ヘッダー補助的な流入元把握
ワンタイムトークンユーザー情報・権限の安全な引き渡し
JWT トークン軽量な情報引き渡し・ステートレス構成
1st Party Cookieサブドメイン間での状態共有
localStorage同一ドメイン内での複数ステップの保持
Back