解析新書 Table Anatomy

a blog of a web analytics consultant

NEW ARTICLE
Clarityの動画をGA4のデータと連携する方法

Clarityの動画をGA4のデータと連携する方法

Clarityの動画をGA4のデータと連携する方法

これでClarityの動画を再生するURLが作れる。これをGA4でカスタムイベントパラメーターに仕込んでおけばBigQueryにはいるので、あとはカスタムディメンションで表示させるかBQで表示すれば、このセッションどんな挙動とか動画とかで分かるというテクニックを考えている。その手前のClarityの動画のURLのルールについてChat GPT5.2で聞いた答え。これで実際動画が見れたので２０２６年1月現在では使えると思う。でもザルすぎるかもしれないから今後も使えるかはよく分からない。もちろんClarityですでにログとってないと無理。AIでまとめた内容共有してみる

やりたいことを分解すると 「該当セッションの“再生URL”を作る」 と (B)「それをGA/BigQuery側の user_pseudo_id と結合できる形で保存する」 の2段です。

目次

1) まず「Clarityの再生URL（player URL）」の作り方

Clarityの録画再生URLは、少なくとも以下の形で再現できるケースがあります。

再生URL（例）
https://clarity.microsoft.com/player/{projectId}/{userId}/{sessionId}

この {userId} と {sessionId} は、ブラウザ側で Clarity cookie から取れることが多く、

  • _clck の先頭部分 → userId
  • _clsk の先頭部分 → sessionId

としてURLを組み立てる方法が紹介されています。
また、cookieが取れない状況では window.clarity("metadata", ...) で projectId/userId/sessionId を取得してURLを作る例もあります。

注意：Clarityは録画保持が基本30日で、条件により最大13か月保持などの挙動があります。BQにURLだけ保存しても、期限切れで再生できなくなることがあるので、運用設計が重要です。

2) 「共有URL（Share link）」は別物の可能性

Clarityには録画を“共有リンク”として発行し、有効期限を付ける機能があります。
この共有リンクは トークン付きで都度発行 のタイプであることが多く、規則でURLを再現できるのは player URL のほう…という整理が安全です（＝「規則がある」と聞いた話は player URL の話である可能性が高い）。

3) BigQueryに保存する設計（おすすめ）

あなたは「Clarityのid」と「GAの user_pseudo_id」を既に紐づけているとのことなので、BQには最低限これを保存すると強いです。

  • ga_user_pseudo_id
  • clarity_project_id
  • clarity_user_id（_clck由来 or metadata.userId）
  • clarity_session_id（_clsk由来 or metadata.sessionId）
  • clarity_playback_url（上の規則で生成したURL）
  • event_timestamp（いつのセッション/いつ生成したURLか）

BQ側でURLを組み立てる例（SQL）

（すでに clarity_user_id / clarity_session_id が入っている前提）

SELECT
  ga_user_pseudo_id,
  clarity_project_id,
  clarity_user_id,
  clarity_session_id,
  CONCAT('https://clarity.microsoft.com/player/',
         clarity_project_id, '/', clarity_user_id, '/', clarity_session_id) AS clarity_playback_url
FROM your_dataset.your_table;

4) どこで「clarity_user_id / clarity_session_id」を取るか（実務パターン）

パターンA（王道）：クライアントでURLを生成→GA4イベントとして送る→BQへ

  1. ブラウザで _clck/_clsk または clarity("metadata") から playback URL を生成
  2. そのURLを GA4のイベントパラメータ（例：clarity_playback_url）として送信
  3. GA4 BigQuery Export に落ちるので、user_pseudo_idで結合して分析・参照

メリット（肯定）

  • 実装が最短で、BQ側は結合するだけ
  • “該当ユーザーの該当セッション”をほぼ確実に辿れる

デメリット（否定）

  • cookie同意/Consentの影響で取れないセッションが出る（Clarity側の同意やブロッカー等）。
  • URLをGA/BQに持ち込むこと自体がプライバシー観点で監査対象になりやすい（アクセス権/保持期間/目的の明確化が必要）

パターンB：Clarity側の「Identify」で独自IDを付け、録画検索に寄せる

Clarityには identify があり、カスタムユーザーID等はクライアント側でハッシュ化して保存されます。
ただし ハッシュ化されるので、GAの user_pseudo_id と“後から文字列一致でJoin”はできません（Clarity側検索で使う用途向き）。