尧图网页设计 
Talivia访客身份识别与跨域关联实现揭秘distinct_id与Cookie追踪原理【免费下载链接】taliviaOpen-source, self-hosted revenue-first analytics for founders: web analytics, Session Replay, revenue attribution, and customer revenue integrations. datafast alternative项目地址: https://gitcode.com/gh_mirrors/ta/taliviaTalivia 是一款开源、可自托管的收入优先网站分析工具datafast 替代品内置 Web 分析、Session Replay 会话回放与收入归因能力。本文带你深入它的源码揭秘 Talivia 访客身份识别与跨域关联的实现原理两个 Cookie 如何追踪访客、签名的跨域 linker 令牌如何把不同域名下的行为串成一条完整路径以及distinct_id字段又是如何把匿名访客和付费客户关联起来的。一、为什么认出同一个访客这么难大多数分析工具都面临同一个难题访客从www.example.com跳转到shop.example.com或者跳到第三方支付页再跳回来Cookie 是隔离的访客瞬间变成了陌生人。Talivia 用三层机制解决这个问题浏览器侧的双 Cookie 身份访客 ID 会话 ID服务端签名的跨域 linker 令牌_tlvURL 参数distinct_id身份合并把匿名访客与登录用户、支付客户关联下面逐层拆解 。二、第一层两个 Cookie 构成访客 会话双身份追踪脚本 src/tracker/index.js 在页面加载时会读取或生成两个 CookieCookie 名称前缀有效期作用talivia_visitor_idv_365 天标识这个人一年内的回访都算同一个访客talivia_session_ids_30 分钟标识这一次访问超时自动开启新会话// 访客身份一年有效会话身份30 分钟无活动即结束 const visitorMaxAge 365 * 24 * 60 * 60; const sessionMaxAge 30 * 60;几个值得学习的细节隐私友好Cookie 值只是一个浏览器本地生成的随机 IDcrypto.randomUUID()不包含任何个人信息天然适配 GDPR 场景。️安全属性写入时强制SameSiteLaxHTTPS 下自动加Secure。会话切换检测一旦会话 ID 变化脚本会主动刷新跨域 linker 令牌见下一节保证新旧会话的链接都有效。浏览器端只存令牌token不存最终 ID。真正的 ID 由服务端派生这是 Talivia 身份设计的关键一步。三、第二层服务端派生 visitor_id令牌无法被伪造浏览器把v_xxx/s_xxx令牌随事件发送到/api/send接口 src/app/api/send/route.ts服务端在 src/lib/tracking-identity.ts 中做确定性派生// 用「网站ID 令牌 服务端密钥」算出稳定的 UUID v5 export function getTrackingVisitorId(websiteId: string, visitorToken: string) { return uuid(websiteId, visitor, visitorToken); }这里的uuid()底层是UUID v5名称派生哈希掺入了服务端APP_SECRET密钥见 src/lib/crypto.ts。它带来三个好处同一个访客令牌 → 永远得到同一个visitor_id跨会话、跨天都不变没有密钥就算不出这个 ID用户无法通过篡改 Cookie 来伪造或合并他人身份ID 与网站隔离不同网站之间的访客互不干扰首次识别后服务端还会把访客上下文落库ensureVisitorContext/upsertVisitorContext记录首次来源渠道、UTM 参数、落地页等用于收入归因。四、第三层签名 linker 令牌破解跨域追踪这是 Talivia 最有意思的设计。假设主站在main.com支付/活动页在shop.com——两个顶级域Cookie 完全不通。Talivia 的方案是① 配置允许跨域的域名在追踪脚本标签上声明见 WebsiteTrackingCode.tsx/websites/[websiteId]/settings/WebsiteTrackingCode.tsx) 生成的代码script src.../tracker.js >// 访客登录后把 userId 告诉 Talivia talivia.identify(user_12345, { email: userexample.com });② 服务端双写落库updateSessionDistinctId.ts在 PostgreSQL 的session表上回填distinctId让会话与真实用户挂钩ClickHouse 事件表通过 db/clickhouse/migrations/07_add_distinct_id.sql 增加distinct_id列之后每次事件都会带上它随 11_tracking_identity_v2.sql 进入每小时聚合视图供按人查询③ 与收入打通identify时携带的stripeCustomerId、lemonsqueezy_customer_id、polar_customer_id等字段会被upsertCustomerIdentityLink记录配合 Stripe / Lemon Squeezy / Dodo / Polar 等支付集成Talivia 才能算出这个访客到底贡献了多少收入——这正是它收入优先revenue-first定位的核心。另外还有一个巧妙的细节追踪脚本会自动识别 Stripe、Lemon Squeezy、Dodo 的收银台链接在跳转时把会话 ID 塞进支付平台的参数如 Stripe 的client_reference_id这样支付完成跳回网站时收入可以直接归因到这次会话无需任何额外配置。六、总结一张图看懂 Talivia 身份体系浏览器 服务端 ───────────────────────────────────────────── talivia_visitor_id (1年) ──→ uuid(websiteId,visitor,token) → visitor_id talivia_session_id (30分) ──→ uuid(websiteId,session,token) → session_id │ ├─ 点击跨域白名单链接 → 申请 linker JWT5分钟有效 │ URL 加 _tlv 参数 │ 目标站取参 → 验签 → 沿用同一身份 ✅ │ └─ 登录/支付后 identify(userId) → distinct_id 回填会话 客户身份关联 双 Cookie 分工长访客 短会话简单且符合隐私规范️ 服务端密钥派生 ID令牌不可伪造身份不可篡改 签名 linker 令牌5 分钟 TTL 的 JWT 安全穿越域名边界distinct_id匿名行为与真实身份、收入数据缝合Talivia 的设计思路对其他做自托管分析工具的同学非常有参考价值身份令牌放浏览器、权威 ID 留服务端、跨域靠短时效签名令牌——既没有引入第三方 Cookie也没有用指纹识别纯靠令牌 验签就优雅地解决了追踪难题。想动手研究更多细节可以从 src/tracker/index.test.ts 和 src/lib/cross-domain-linker.test.ts 的测试用例入手它们清晰地展示了 linker 签发、过期、伪造拦截的边界行为。【免费下载链接】taliviaOpen-source, self-hosted revenue-first analytics for founders: web analytics, Session Replay, revenue attribution, and customer revenue integrations. datafast alternative项目地址: https://gitcode.com/gh_mirrors/ta/talivia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Talivia访客身份识别与跨域关联实现揭秘：distinct_id与Cookie追踪原理
Talivia访客身份识别与跨域关联实现揭秘distinct_id与Cookie追踪原理【免费下载链接】taliviaOpen-source, self-hosted revenue-first analytics for founders: web analytics, Session Replay, revenue attribution, and customer revenue integrations. datafast alternative项目地址: https://gitcode.com/gh_mirrors/ta/taliviaTalivia 是一款开源、可自托管的收入优先网站分析工具datafast 替代品内置 Web 分析、Session Replay 会话回放与收入归因能力。本文带你深入它的源码揭秘 Talivia 访客身份识别与跨域关联的实现原理两个 Cookie 如何追踪访客、签名的跨域 linker 令牌如何把不同域名下的行为串成一条完整路径以及distinct_id字段又是如何把匿名访客和付费客户关联起来的。一、为什么认出同一个访客这么难大多数分析工具都面临同一个难题访客从www.example.com跳转到shop.example.com或者跳到第三方支付页再跳回来Cookie 是隔离的访客瞬间变成了陌生人。Talivia 用三层机制解决这个问题浏览器侧的双 Cookie 身份访客 ID 会话 ID服务端签名的跨域 linker 令牌_tlvURL 参数distinct_id身份合并把匿名访客与登录用户、支付客户关联下面逐层拆解 。二、第一层两个 Cookie 构成访客 会话双身份追踪脚本 src/tracker/index.js 在页面加载时会读取或生成两个 CookieCookie 名称前缀有效期作用talivia_visitor_idv_365 天标识这个人一年内的回访都算同一个访客talivia_session_ids_30 分钟标识这一次访问超时自动开启新会话// 访客身份一年有效会话身份30 分钟无活动即结束 const visitorMaxAge 365 * 24 * 60 * 60; const sessionMaxAge 30 * 60;几个值得学习的细节隐私友好Cookie 值只是一个浏览器本地生成的随机 IDcrypto.randomUUID()不包含任何个人信息天然适配 GDPR 场景。️安全属性写入时强制SameSiteLaxHTTPS 下自动加Secure。会话切换检测一旦会话 ID 变化脚本会主动刷新跨域 linker 令牌见下一节保证新旧会话的链接都有效。浏览器端只存令牌token不存最终 ID。真正的 ID 由服务端派生这是 Talivia 身份设计的关键一步。三、第二层服务端派生 visitor_id令牌无法被伪造浏览器把v_xxx/s_xxx令牌随事件发送到/api/send接口 src/app/api/send/route.ts服务端在 src/lib/tracking-identity.ts 中做确定性派生// 用「网站ID 令牌 服务端密钥」算出稳定的 UUID v5 export function getTrackingVisitorId(websiteId: string, visitorToken: string) { return uuid(websiteId, visitor, visitorToken); }这里的uuid()底层是UUID v5名称派生哈希掺入了服务端APP_SECRET密钥见 src/lib/crypto.ts。它带来三个好处同一个访客令牌 → 永远得到同一个visitor_id跨会话、跨天都不变没有密钥就算不出这个 ID用户无法通过篡改 Cookie 来伪造或合并他人身份ID 与网站隔离不同网站之间的访客互不干扰首次识别后服务端还会把访客上下文落库ensureVisitorContext/upsertVisitorContext记录首次来源渠道、UTM 参数、落地页等用于收入归因。四、第三层签名 linker 令牌破解跨域追踪这是 Talivia 最有意思的设计。假设主站在main.com支付/活动页在shop.com——两个顶级域Cookie 完全不通。Talivia 的方案是① 配置允许跨域的域名在追踪脚本标签上声明见 WebsiteTrackingCode.tsx/websites/[websiteId]/settings/WebsiteTrackingCode.tsx) 生成的代码script src.../tracker.js >// 访客登录后把 userId 告诉 Talivia talivia.identify(user_12345, { email: userexample.com });② 服务端双写落库updateSessionDistinctId.ts在 PostgreSQL 的session表上回填distinctId让会话与真实用户挂钩ClickHouse 事件表通过 db/clickhouse/migrations/07_add_distinct_id.sql 增加distinct_id列之后每次事件都会带上它随 11_tracking_identity_v2.sql 进入每小时聚合视图供按人查询③ 与收入打通identify时携带的stripeCustomerId、lemonsqueezy_customer_id、polar_customer_id等字段会被upsertCustomerIdentityLink记录配合 Stripe / Lemon Squeezy / Dodo / Polar 等支付集成Talivia 才能算出这个访客到底贡献了多少收入——这正是它收入优先revenue-first定位的核心。另外还有一个巧妙的细节追踪脚本会自动识别 Stripe、Lemon Squeezy、Dodo 的收银台链接在跳转时把会话 ID 塞进支付平台的参数如 Stripe 的client_reference_id这样支付完成跳回网站时收入可以直接归因到这次会话无需任何额外配置。六、总结一张图看懂 Talivia 身份体系浏览器 服务端 ───────────────────────────────────────────── talivia_visitor_id (1年) ──→ uuid(websiteId,visitor,token) → visitor_id talivia_session_id (30分) ──→ uuid(websiteId,session,token) → session_id │ ├─ 点击跨域白名单链接 → 申请 linker JWT5分钟有效 │ URL 加 _tlv 参数 │ 目标站取参 → 验签 → 沿用同一身份 ✅ │ └─ 登录/支付后 identify(userId) → distinct_id 回填会话 客户身份关联 双 Cookie 分工长访客 短会话简单且符合隐私规范️ 服务端密钥派生 ID令牌不可伪造身份不可篡改 签名 linker 令牌5 分钟 TTL 的 JWT 安全穿越域名边界distinct_id匿名行为与真实身份、收入数据缝合Talivia 的设计思路对其他做自托管分析工具的同学非常有参考价值身份令牌放浏览器、权威 ID 留服务端、跨域靠短时效签名令牌——既没有引入第三方 Cookie也没有用指纹识别纯靠令牌 验签就优雅地解决了追踪难题。想动手研究更多细节可以从 src/tracker/index.test.ts 和 src/lib/cross-domain-linker.test.ts 的测试用例入手它们清晰地展示了 linker 签发、过期、伪造拦截的边界行为。【免费下载链接】taliviaOpen-source, self-hosted revenue-first analytics for founders: web analytics, Session Replay, revenue attribution, and customer revenue integrations. datafast alternative项目地址: https://gitcode.com/gh_mirrors/ta/talivia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考