独立阅读页 · 7日留存提前推演 · 2026-07-07 · 评审讨论版

7日留存埋点方案分级

这份文档把“通过漏斗提升 7 日留存”的推演结果整理成开发可讨论的三个版本：MVP 基础版、中等版、完整理想版。阅读时先看业务漏斗，再看每个版本需要记录什么事实。

核心结论：本项目最终主指标建议使用“7日有效消费回访率”。也就是匿名首访用户在首次访问后 24-168 小时内回来，并对单个视频完成累计真实播放 240 秒以上。MVP 阶段如果只能用播放进度粗算，对外看板必须标成“估算有效消费”。
已同步 Markdown 最新版 · 当前 HTML 包含运营防误解提醒、双路径图示、口径冻结规则、事件字段字典、验收标准与评审防线。

1. 目标与边界

这次不是泛泛做“数据埋点”，而是围绕一个明确目标：判断匿名首访用户是否在 7 日内真的回来看片，并定位他们卡在哪一步。

运营先读：本文里的“7 日”不是自然日 D7，也不是“第 7 天当天回来”。它指的是用户首次有效访问 T0 后的 24-168 小时观察窗口。

主指标：
7日有效消费回访率 =
首访 T0 后 24-168 小时内，回来并完成单个视频有效消费的用户数
÷
匿名首访用户数
图示 1：7 日窗口不是自然日 D7
T0 匿名首访用户第一次有效访问，生成观察起点。
0-24 小时 仍算首日内行为，不进入 7 日回访主窗口。
24-168 小时 主分析窗口：真实回访、找片、播放、有效 / 估算有效消费都在这里判断。
168 小时后 不进入 7 日主指标，可作为更长周期辅助分析。
概念 大白话 本次怎么定
匿名首访用户 第一次被我们识别到的新浏览器身份 P0 先用 anonymous_id，不是身份证意义上的真人，也不是运营语境里的“真实新用户”
7日窗口 首访以后过了一段时间再回来 主用精确小时：T0 后 24-168 小时；不是自然日 D7，自然日只做辅助报表
有效消费 回来后真的看够了一个视频 P1 口径为单个视频累计真实播放时间 >= 240 秒；P0 只能叫“估算有效消费”
开发内容 需要系统记录事实，而不是让前端直接报结论 事件记录事实，留存状态由后端或数据任务计算

边界：这份是 7 日留存提前推演的独立阅读页。字段名和事件名可作为对接示例，但上线前仍需要开发确认现有系统能力、命名规范、采集方式和性能影响。

1.1 运营版防误解提醒

容易误解的词 不要这样理解 本文固定理解
7 日 自然日第 7 天，或 D7 当天回来 首访 T0 后 24-168 小时窗口
首访用户 一个真实新用户、一个真人 匿名首访用户，即第一次被识别到的 anonymous_id
有效消费 播放进度到 240 秒就一定真实看了 240 秒 P0 是“估算有效消费”；P1 用真实播放心跳才接近真实观看
找片回访 所有回访都必须先搜索或翻列表 搜索、筛选、标签、女优、榜单等站内找内容行为才算找片回访
直接消费回访 没有找片，所以算找片失败 收藏、历史、SEO、外链直接进详情并播放，是另一条高意图路径
cohort 成熟 D1 就能看完整 7 日留存 一批用户还没过完 7 天观察期，所以结果还没最终定稿

2. 7日消费回访漏斗总览

  1. 入口来源：用户第一次从 SEO、direct、外链、分享、站群还是投放进来。
  2. 匿名首访用户：某天第一次来的有效匿名用户，是后续所有留存率的分母。
  3. 时间窗口：主看首访后 24-168 小时内，避免跨零点误判。
  4. 真实回访：用户真的回来，不是浏览器恢复、后台打开或预加载。
  5. 找片回访：回来后搜索、点卡、翻页、筛选、点女优、点标签等。
  6. 直接消费回访：用户没有站内找片动作，但从收藏、历史、SEO、外链或继续观看入口直接进详情并消费。
  7. 进入详情：找片后或直接入口成功打开一个正常视频详情页。
  8. 开始播放：用户主动点击播放，正片播放器成功进入播放状态。
  9. 有效消费：单个视频累计真实播放达到 240 秒。
  10. 续看：有效消费后继续点击另一个不同视频。

2.1 回访路径图示

找片回访路径

匿名首访用户 -> 真实回访 -> 搜索 / 筛选 / 标签 / 女优 / 榜单 -> 进入详情 -> 播放 -> 有效 / 估算有效消费

这条路径看的是：用户回来后，站内找内容能力是否接住了需求。

直接消费回访路径

匿名首访用户 -> 真实回访 -> 收藏 / 历史 / SEO / 外链 / 书签 -> 直接进入详情 -> 播放 -> 有效 / 估算有效消费

这条路径不是“没有找片”，而是用户带着明确目标回来，通常是高意图路径。

路径 图示 运营理解
找片回访路径 匿名首访用户 -> 真实回访 -> 搜索 / 筛选 / 翻页 / 标签 / 女优 / 榜单 -> 进入详情 -> 播放 -> 有效 / 估算有效消费 用户回来后还在站内找内容，后续要看搜索、列表、标签、女优、榜单能不能接住需求。
直接消费回访路径 匿名首访用户 -> 真实回访 -> 收藏 / 历史 / 继续观看 / SEO / 外链 / 书签 -> 直接进入详情 -> 播放 -> 有效 / 估算有效消费 用户已经带着明确内容目标回来，不应被算成“没有找片”或“找片失败”。
漏斗层级 产品 / 运营能懂的人话 判断口径 事件示例（给开发） 字段示例（记录信息）
入口来源 用户第一次是从哪里来的。 只看用户首访那一次的来源，把 SEO、direct、外链、分享、站群、投放等分开。 page_view、session_start source_channel、source_detail、referrer、utm_*、landing_type
匿名首访用户 某天第一次来的匿名新身份。 某天第一次出现的有效 anonymous_id，排除爬虫、预加载、异常请求；不是身份证意义上的真人。 session_start、page_view anonymous_id、occurred_at、visitor_type
时间窗口 首访后多久回来算回访。 主用精确小时：首访 T0 后 24-168 小时；自然日做辅助报表。 所有访问和行为事件都要带时间 first_seen_at、occurred_at、hours_since_first_visit
真实回访 用户真的回来过，不是假打开。 24-168 小时内出现新访问，并有前台停留或主动行为证据。 session_start、page_view、page_heartbeat anonymous_id、session_id、foreground_seconds_total
找片回访 用户回来后开始找想看的片。 真实回访后发生搜索、点卡、点女优 / 标签 / 合集 / 榜单、翻页、筛选、排序等行为。 search_submit、list_interaction interaction_type、target_type、keyword_normalized、result_count
直接消费回访 用户回来后没有站内找片，但直接进入可播放视频。 真实回访后首个有效内容页来自收藏、历史、继续观看、SEO、外链、浏览器书签或站外分享，并进入详情或播放。 page_view、content_start entry_route=direct_content、source_channel、landing_type、content_id
进入详情 用户找到了一个候选视频并打开详情页。 找片后或直接入口成功打开正常视频详情页，不含 404、下架、异常外跳。 page_view page_type=detail、content_id、http_status、canonical_url
开始播放 用户真的把正片播放起来。 进入详情后主动点击播放，并且正片播放器成功进入播放状态。 content_start content_id、start_method=play_click、content_type=video
有效消费 用户看够了一个视频。 P0 只能算“估算有效消费”：播放进度跨过 240 秒；P1 才用真实播放心跳判断累计真实播放 >= 240 秒。 video_progress、video_heartbeat content_id、progress_seconds、milestone=240s、is_seeked
有效消费后续看 用户看够后继续点下一个内容。 有效消费后继续点击另一个不同视频；离开不算失败，只是不算续看。 next_content_click、list_interaction.card_click source_content_id、target_content_id、recommend_type、module_id、position

3. 三个版本怎么理解

MVP 基础版

目标是先跑出主指标和基础漏斗，不追求把失败原因拆到最细。

  • 能认人、认会话、认时间窗口。
  • 能看真实回访、找片、详情、播放、240 秒有效消费。
  • 能粗看哪里漏，但不强行断言 loading、广告劫持等具体原因。

P1 中等版

目标是把“没消费”的原因拆清楚一层，支持产品和开发定位问题。

  • 补播放器状态和内容状态。
  • 补真实播放心跳，替代 P0 进度粗口径。
  • 补广告误触、异常外跳的弱判断。

P2 完整理想版

目标是形成完整分析体系，支撑推荐、搜索、内容供给和广告治理。

  • 形成完整用户路径分析和多次有效消费分析。
  • 按模块、位置、内容、女优、标签、搜索词拆贡献。
  • 建立数据质量、异常归因和看板闭环。

4. 优先级总表

优先级 能力 为什么必须 / 值得做 达到什么程度算可用
P0 匿名用户识别 没有它就无法把首访和回访串成同一个用户。 同浏览器多次访问能拿到稳定 anonymous_id。
P0 会话和时间窗口 要判断是否在首访后 24-168 小时内回来。 每次访问有 session_id、occurred_at，能计算 hours_since_first_visit。
P0 入口来源和落地页 SEO、direct、外链、站群用户不能混在一起解释。 首访能记录来源、落地 URL、页型、设备。
P0 页面前台可见 / 停留 判断真实回访，排除浏览器恢复、后台打开、预加载。 能记录前台停留秒数，或至少有页面可见心跳。
P0 找片行为 判断用户回来后是否带着找片需求。 能记录搜索、点卡、翻页、筛选、排序、点女优 / 标签 / 合集 / 榜单。
P0 直接消费入口 避免把收藏、历史、SEO、外链直接进详情的高意图用户误判为“没有找片”。 详情页能记录 entry_route、landing_type、来源渠道和 content_id。
P0 详情页正常打开 找片后有没有被送到可消费候选视频。 详情页 page_view 有 page_type=detail、content_id、http_status。
P0 播放成功 点击播放不等于播放成功，要知道正片是否真的播起来。 能记录 content_start，代表正片进入播放状态。
P0 估算有效消费粗口径 MVP 阶段先用播放进度估算用户是否可能看够一个视频。 video_progress 至少包含 240 秒里程碑；对外看板必须标成“估算有效消费”。
P1 真实播放心跳 P0 进度口径会被拖进度条骗高。 video_heartbeat 能累计真实播放秒数，暂停、loading、后台不计。
P1 播放器失败原因 详情到播放掉得多时，需要知道是 loading、报错还是用户没点。 能记录 loading、playing、error、buffering 等播放器状态。
P1 广告误触 / 异常外跳弱判断 成人站广告容易影响消费和留存。 能记录广告点击、目标域名、快速返回、异常外跳候选。
P2 完整路径和模块归因 后续要优化搜索、推荐、女优、标签、合集和广告位置。 能按模块、位置、内容、搜索词、标签、女优拆贡献。

5. MVP 基础版

MVP 的目标不是解释所有原因，而是先让“7日估算有效消费回访率”跑起来，并能看到用户主要卡在哪一层。

MVP 交付标准：能每天生成匿名首访用户 cohort，并计算 24-168 小时内真实回访、找片、直接消费、详情、播放、估算有效消费和续看。

P0：估算有效消费

开始播放 -> 播放进度跨过 240 秒 -> 估算有效消费

优点是实现快，能先跑漏斗；风险是拖进度条、后台播放、卡顿等会让数据偏高。

P1：真实有效消费

正片播放中 -> 前台可见 + 时间真实推进 -> 真实播放累计 240 秒

更接近真实观看，暂停、loading、后台、拖动跳过都不计入真实播放时间。

MVP 必做项 产品人话 判断口径 事件示例（给开发） 字段示例（记录信息） 不做什么
认人 知道是不是同一个浏览器用户。 同一个浏览器身份在首访和回访中能被串起来。 session_start、page_view anonymous_id 不追求跨设备真人识别。
认访问 知道这是一次新的访问，而不是同页刷新。 一次连续访问归为同一个会话，过一段时间再来生成新会话。 session_start session_id、anonymous_id、occurred_at 不做复杂跨端会话合并。
认时间 能算首访后过了多少小时。 主指标按首访 T0 后 24-168 小时判断。 所有访问和行为事件都要带时间 first_seen_at、occurred_at、hours_since_first_visit 不只依赖自然日。
认来源 知道用户首次从哪里来。 只取首访来源作为 cohort 拆分维度，后续来源可辅助分析。 page_view、session_start source_channel、source_detail、referrer、utm_* 不把 direct 直接当品牌回访。
认真实回访 排除明显假打开。 24-168 小时内有新访问，并且页面被前台看到或有主动行为。 page_view、page_heartbeat session_id、foreground_seconds_total、visibility_state 不精细判断每种假回访原因。
认找片 知道用户回来后有没有找内容。 真实回访后发生搜索、翻页、筛选、排序、点卡、点女优或点标签等行为。 search_submit、list_interaction interaction_type、target_type、keyword_normalized 不先做复杂意图分类。
认直接消费 知道用户是否绕过站内找片，直接进入详情或播放。 真实回访后首个有效内容页来自收藏、历史、继续观看、SEO、外链、书签或分享。 page_view、content_start entry_route、landing_type、source_channel、content_id 不把这类用户归为“找片失败”。
认详情 知道是否成功打开视频详情页。 找片后打开正常的视频详情页，且页面不是 404、下架或异常跳转。 page_view page_type、content_id、http_status 不细拆所有异常页原因。
认播放 知道正片是否真的播放成功。 用户主动点击播放后，播放器进入正片播放状态。 content_start content_id、start_method、content_type 不细拆 loading / error / buffering。
认估算有效消费 知道单个视频是否可能看够 240 秒。 单个视频达到 240 秒播放里程碑；P0 先接受进度口径偏粗，但对外必须叫“估算有效消费”。 video_progress content_id、progress_seconds、milestone=240s、is_seeked 不把 P0 进度口径包装成真实观看。

MVP 可产出的核心指标：

  • 匿名首访用户数
  • 7日真实回访率
  • 7日找片回访率
  • 7日直接消费回访率
  • 找片后进入详情转化率
  • 详情到播放转化率
  • 播放到估算有效消费转化率
  • 7日估算有效消费回访率
  • 7日找片未消费率

6. 中等版

中等版的目标是从“知道漏在哪层”，升级到“知道大概为什么漏”。它适合 MVP 跑通后第二阶段建设。

增强能力 解决的问题 判断口径 事件示例（给开发） 字段示例（记录信息） 能多回答什么
真实播放心跳 P0 用进度条会被拖动骗高。 只累计正片播放中、页面前台可见、播放器时间真实推进的秒数。 video_heartbeat content_id、play_state、is_foreground、accumulated_play_seconds 哪些用户真的看够 240 秒。
播放器状态 进入详情后没播放，不知道是没点还是播不起来。 从用户点击播放开始，记录播放器进入 loading、playing、buffering、error 等状态。 play_click、player_state_change、content_start player_state、error_code、buffering_seconds、content_id 播放失败、卡顿、报错占比。
内容状态 详情页打开但视频不可播，不能算正常候选内容。 进入详情时标记内容是否正常、可播放、下架或缺资源。 page_view、content_status_view content_status、is_playable、content_id、unavailable_reason 内容库问题还是前端承接问题。
搜索结果状态 用户搜了但没消费，不知道是无结果还是结果差。 每次搜索都记录是否有结果、结果数量和关键词类型。 search_submit、search_result_view result_count、search_result_state、keyword_type 番号、女优、标签、泛词分别是否接得住。
广告误触候选 广告是否打断找片或播放。 广告点击后快速外跳、快速返回或路径中断，先标记为“疑似”，不直接断言。 ad_impression、ad_click、page_return ad_slot_id、target_domain、return_seconds、is_external_jump_candidate 哪些广告位可能伤害留存。
模块归因 不知道用户从哪个模块进入详情或续看。 用户点击内容时记录它来自搜索结果、首页楼层、同女优、同题材或其他模块。 list_interaction、card_click、next_content_click module_id、position、recommend_type、source_page_type 搜索结果、首页楼层、同女优、同题材哪个更有效。

中等版关键变化：MVP 先做结果状态，中等版开始拆原因。但仍然要谨慎，广告劫持、loading 等建议先用“疑似”口径，不要过度断言。

7. 完整理想版

完整理想版适合在 MVP 和中等版跑出价值后建设。它不是第一版就要完成的任务，而是目标架构。

完整能力 产品价值 需要的数据基础
完整用户路径 看用户从首访到回访、找片、播放、续看的完整路径。 所有事件有统一用户、会话、页面、内容、时间字段。
多次有效消费分析 看用户是否一周内多次满足，不只是看一次。 按不同 content_id 统计有效消费次数。
推荐模块评估 知道相关推荐、同女优、同题材哪个更能带来续看。 recommend_type、module_id、position、目标内容后续消费。
搜索供给诊断 知道用户搜什么找不到，哪些词带来有效消费。 搜索词最终分类、结果状态、点击结果、后续播放和有效消费。
内容供给诊断 知道哪些女优、标签、合集、榜单能沉淀回访用户。 内容、女优、标签、合集、榜单与消费结果打通。
广告治理闭环 知道哪些广告位影响找片、播放、有效消费。 广告曝光、点击、外跳、快速返回、广告位与用户路径串联。
数据质量看板 发现埋点丢失、前后端不一致、异常流量污染。 事件去重、前后端对账、异常访问规则。

8. 开发前置问题清单

开会不要先问“这些字段能不能埋”。更好的问法是：为了判断首访后 24-168 小时内是否回来、找片、播放和有效消费，现有系统已经能记录哪些事实？哪些现在没有？

模块 要问开发的问题 为什么要问 优先级
用户识别 现在有没有 anonymous_id？怎么生成？存在多久？ 没有它就认不出同一个用户，算不了留存。 P0
用户识别 清缓存、无痕、换浏览器后会不会生成新 ID？ 评估匿名留存低估和新用户高估。 P0
会话识别 现在有没有 session_id？新 session 规则是什么？ 区分同一次访问和过几天又来。 P0
会话识别 能不能按“30 分钟无活动切新 session”实现？新标签页、多标签、跨午夜怎么处理？ session 规则不冻结，真实回访口径会乱。 P0
时间记录 所有事件有没有准确 occurred_at？用什么时区？ 要算 24-168 小时窗口。 P0
时间记录 事件时间能不能统一存 UTC？报表能不能按默认展示时区生成 cohort 日期？ 避免跨天、T+1、cohort 日期对不上。 P0
首访时间 能不能记录或计算 first_seen_at？ 这是所有 7 日窗口的起点。 P0
有效首访 能不能排除 bot、预加载、异常页面、内部访问和无匿名 ID 访问？ 避免首访分母被污染。 P0
来源识别 能不能区分 SEO、direct、外链、分享、站群、投放？ 不同来源质量不能混看。 P0
页面浏览 page_view 是后端记还是前端记？能不能带 http_status？ 要排除异常页面，并尽量抗拦截。 P0
页面浏览 http_status 能不能优先来自服务端日志或边缘日志？前端状态只能做补充吗？ 前端不一定知道真实 HTTP 状态。 P0
全局字段 事件能不能带 site_id、domain、env、版本、设备、浏览器、系统、实验分组？ 方便排查站群、多域名、灰度、A/B 和版本问题。 P0/P1
前台可见 有没有页面前台可见 / 心跳记录？ 判断真实回访，排除后台打开。 P0
找片行为 搜索、点卡、翻页、筛选、排序、点女优 / 标签 / 合集 / 榜单现在有没有记录？ 判断用户是否回来找片。 P0
进入详情 视频详情页 page_view 能不能带 content_id？ 要把进入详情和具体视频对应起来。 P0
进入详情 能不能知道内容是否下架、不可播放、空详情？ 避免异常详情页被算正常候选。 P1
播放开始 有没有 content_start 或播放成功事件？点击播放和播放成功能不能区分？ 点击只是意图，播放成功才算开始消费。 P0
播放失败 播放器有没有 loading、error、buffering 状态？ 中等版需要拆没播放原因。 P1
有效消费 video_progress 有没有 240 秒节点？ P0 需要粗算有效消费。 P0
有效消费 能不能识别拖进度条 is_seeked？后续能不能做 video_heartbeat？ 防止 P0 进度口径被拖动骗高。 P1
续看 详情页相关推荐、同女优、同题材点击有没有记录？能不能带来源和目标视频？ 判断看够后是否继续探索。 P0/P1
广告异常 广告点击有没有广告位、广告类型、跳转域名？能不能识别快速外跳 / 快速返回？ 判断广告干扰，但 P0 只做疑似。 P1
数据加工 事件最后存在哪里？能不能按用户、会话、页面、内容串起来？ 漏斗需要跨事件、跨天计算。 P0
看板产出 D0 cohort 什么时候成熟？未成熟 cohort 是否展示？是否允许预测值？ 7 日主指标必须等 168 小时窗口结束，不能提前当正式结果。 P0
性能影响 埋点会不会影响 SEO 核心页面加载？ SEO 页性能优先级最高。 必问

9. 关键字段与事件大白话

这里不是完整字段字典，只解释评审时最容易被问到的字段和事件。记住一句话：事件记录发生了什么，字段记录这件事的上下文。

事件名到底是什么？

事件名 = 系统给“用户动作”或“系统状态变化”起的名字。

它不是指标，也不是字段。它只回答一个问题：刚刚发生了什么？

用户实际行为 事件名示例 大白话
用户打开网站，开始一次访问 session_start 一次访问开始了
用户打开了一个页面 page_view 用户看到了一个页面
用户提交了一次站内搜索 search_submit 用户搜了一次东西
用户点击播放后，正片真的播起来 content_start 正片开始播放成功
视频播放进度跨过 240 秒 video_progress 播放进度到了某个节点
视频正在真实播放，持续上报播放秒数 video_heartbeat 视频还在真实播放中 
一条埋点数据可以这样理解：

事件名：content_start
意思：正片开始播放成功

字段：
anonymous_id = A123
session_id = S456
content_id = V789
occurred_at = 2026-07-05 10:00:00
page_type = detail

翻成人话：
匿名用户 A123，在这次访问 S456 里，于 2026-07-05 10:00，
成功播放了视频 V789。

评审时可以这样讲：事件名是动作标签，字段是动作上下文。我们不是让开发直接上报“这个用户留存了”，而是先记录一串事实事件，再由数据层计算留存。

字段：记录这件事的上下文

字段示例 大白话 为什么需要 缺了会怎样
anonymous_id 浏览器的临时身份牌。 认出同一个匿名用户。 只能看访问次数，算不了留存。
session_id 一次访问的编号。 区分同一次访问和后续回访。 刷新、重复打开、回访会混在一起。
occurred_at 事件真实发生时间。 判断是否在 24-168 小时内。 留存窗口会算错。
first_seen_at 这个用户第一次来的时间。 作为精确小时窗口的起点。 无法按 T0 计算 7 日。
source_channel 用户来源大类。 分辨 SEO、direct、外链、站群、分享。 只能看全站平均，定位不了来源问题。
content_id 视频内容 ID。 把点击、详情、播放、有效消费串起来。 无法判断是不是同一个视频。
http_status 页面响应状态码。 排除 404、500 等异常页。 异常页会被算成正常详情。
foreground_seconds_total 页面在前台被真实看到的秒数。 辅助判断真实回访。 后台打开、浏览器恢复可能被误算成回访。
progress_seconds 视频进度到了多少秒。 P0 粗算是否跨过 240 秒。 跑不出 MVP 有效消费。
accumulated_play_seconds 真实播放累计秒数。 P1 精确累计真实播放。 P0 口径可能被拖动骗高。
module_id 用户点击内容时所在的模块。 判断首页、搜索、同女优、同题材等模块的贡献。 看不到哪个模块真正带来消费。

事件：记录用户或系统发生了什么动作

事件示例 大白话 为什么需要 缺了会怎样
session_start 一次新的访问开始了。 判断用户是不是 24-168 小时内再次回来。 回访和刷新会混在一起。
page_view 用户打开了一个页面。 记录入口、详情、异常页等关键页面。 漏斗缺少页面层，无法判断用户到哪一步。
page_heartbeat 页面在前台被看见的心跳。 证明不是后台打开或浏览器恢复。 假回访会污染数据。
search_submit 用户提交了一次站内搜索。 最明确的找片信号。 看不到用户想找什么。
list_interaction 用户在列表、标签、女优、合集、榜单上做动作。 记录浏览式找片。 只知道搜索，不知道用户怎么逛。
content_start 正片开始播放成功。 判断是否进入消费。 只能知道进详情，不知道有没有看。
video_progress 视频播放进度跨过某个节点。 P0 粗算是否跨过 240 秒。 跑不出 MVP 有效消费。
video_heartbeat 视频正在真实播放的心跳。 P1 精确累计真实播放。 P0 口径可能被拖动骗高。
next_content_click 详情页里点了下一个视频。 判断推荐、同女优、同题材是否接住。 看不到有效消费后的下一步。

10. 口径冻结规则

这一章的作用是把“怎么算”说死。评审时如果不先冻结这些边界，开发、产品、运营会各按自己的理解取数，最后同一个指标会出现多个版本。

10.1 7 日窗口边界

问题 冻结规则
T0 是什么？ T0 = 该 anonymous_id 第一次有效 session_start 的 occurred_at。如果上线前没有历史 ID，埋点上线后的第一次有效访问先进入“埋点启动 cohort”。
主窗口怎么取？ 主窗口使用精确小时：occurred_at >= T0 + 24h 且 occurred_at < T0 + 168h。下边界包含 24 小时，上边界不包含 168 小时。
用哪个事件判断窗口？ 每一层用该层自己的达成事件时间判断。真实回访主看新 session_start 的时间；如果历史数据没有 session_start，才允许用首个有效回访行为兜底。有效消费看达到 240 秒的 video_progress 或 video_heartbeat 汇总达成时间。
167 小时 50 分回来，168 小时 05 分达到 240 秒，算不算 7 日有效消费？ 主指标不算。真实回访算，因为 session_start 在 168 小时内；7 日有效消费不算，因为达到 240 秒的时间已经超过窗口。
为什么不按 session_start 把整次会话都算进来？ 因为主指标叫“7 日内完成有效消费”。如果按 session_start 拖长，会把第 8 天的消费算进第 7 天，口径会偏高。
是否保留宽松辅助口径？ 可以保留一个辅助指标：7日窗口内回访且同 session 完成有效消费用户数。但它不能替代主指标，报表上必须单独命名。

10.2 Session 规则

session 是一次连续访问。它决定“用户是不是重新回来”，所以必须先冻结。

问题 冻结规则
多久无活动算新 session？ 同一 anonymous_id 连续 30 分钟没有有效活动，再发生新访问或主动行为时生成新 session_id。
什么叫有效活动？ page_view、page_heartbeat、search_submit、list_interaction、play_click、content_start、video_progress、video_heartbeat、next_content_click 等能证明页面或播放器仍在被使用的事件。广告自动曝光不算有效活动。
新标签页是否新 session？ 同一浏览器 30 分钟内打开新标签页，默认沿用同一个 session_id，但生成新的 page_view_id。如果距离上次有效活动超过 30 分钟，则新标签页生成新 session_id。
同一浏览器多标签同时打开怎么处理？ 多标签共享同一个 anonymous_id 和当前 session_id，每个标签页有自己的 page_view_id。播放累计要按 content_id + player_id + time_bucket 去重，避免多标签重复计时。
跨午夜是否切 session？ 不因为跨午夜自动切 session。session 只由 30 分钟无活动、新匿名身份、或显式新会话规则触发。
页面一直开着跨过 24 小时，算回访吗？ 不算主回访。主回访必须出现新的 session_id。同一长 session 跨过 24 小时后继续播放，只进入“长 session 辅助分析”，不进入 7 日回访主指标。

10.3 时区规则

问题 冻结规则
事件时间怎么存？ 所有事件的 occurred_at、received_at 统一存 UTC 时间。
报表按哪个时区展示？ 面向业务查看的 cohort 日期、日报日期、T+1 产出日期统一按 Asia/Tokyo 展示；如果内部团队固定按 Asia/Shanghai 开会，可在看板增加一个展示时区切换，但主口径只保留一个默认展示时区。
7 日窗口按哪个时间算？ 7 日窗口按 UTC 时间戳做小时差计算，不按自然日切分。展示时再转换为报表时区。
cohort 日期怎么归属？ cohort 日期按 T0 转换到默认报表时区后的日期归属。不要用服务端收到时间 received_at 归 cohort。
T+1 怎么理解？ T+1 产出按默认报表时区计算。例如默认 Asia/Tokyo，则 2026-07-04 的日报在 2026-07-05 中午前产出。

10.4 有效首访定义

T0 不是任何一次请求都能触发，必须是“有效首访”。否则爬虫、预加载、内部访问会污染分母。

条件 冻结规则
非 bot / 爬虫 is_bot=false，且不命中基础爬虫、监控、压测、SEO 抓取识别规则。
非预加载 不能只存在预加载、预渲染、缓存探测或无用户可见证据的请求。
页面正常状态 首访落地页应为正常页面，http_status 优先使用服务端或边缘日志确认，2xx / 可业务承接状态才进入有效首访。
前台可见或主动行为 至少满足前台可见累计 >= 10 秒，或发生一次主动行为。仅有 page_view 不直接进入有效首访分母。
非内部访问 排除公司内网、测试账号、测试域名、灰度压测流量和开发调试访问。
匿名 ID 可用 必须能生成或读取 anonymous_id。没有 anonymous_id 的访问只能进入流量质量排查，不进入留存分母。

10.5 真实回访阈值

判断项 冻结规则
最小成立条件 同一 anonymous_id 在 24-168 小时内出现新的 session_id，并满足“前台可见累计 >= 10 秒”或“发生主动行为”之一。
心跳频率 page_heartbeat 在页面可见且窗口聚焦时每 5 秒上报一次。后台、失焦、锁屏不累计前台秒数。
几个心跳算有效？ P0 口径：至少 2 个有效心跳，或汇总 foreground_seconds_total >= 10。如果发生主动行为，可不强依赖 10 秒停留。
主动行为包括什么？ search_submit、list_interaction、content_start、video_progress、next_content_click、筛选、排序、翻页、点击内容卡等。
主动行为不包括什么？ 单纯 page_view、广告自动曝光、自动加载、预加载、浏览器恢复、后台页面恢复。
长 session 跨窗口怎么处理？ 如果没有新的 session_id，即使页面跨过 24 小时后继续播放，也不算主回访。可单独进入“长 session 跨窗消费”辅助分析。

10.6 匿名首访用户识别规则

项目 冻结规则
ID 生成方式 用户第一次访问且本地没有 ID 时，由前端生成随机 UUID，写入第一方 Cookie；服务端只接收和校验，不反推出真实身份。
存储位置 P0 使用第一方 Cookie；如站点需要兼容，可同时写入 localStorage 作为辅助恢复，但最终以 Cookie 中的 anonymous_id 为准。
有效期 建议 180 天滚动有效期。用户再次访问时刷新有效期。
跨子域规则 同一产品主域下的子域可共享，例如写入 .example.com；不同主域、镜像站、站群不能默认合并，除非有明确站群 ID 映射。
清缓存 / 换浏览器 生成新的 anonymous_id，按新匿名用户处理。报表备注这是匿名留存的天然低估风险。
无痕模式 每次无痕会话可能生成新 ID，按新匿名用户处理，不做强行合并。
上线前老用户 埋点上线第一天看到的用户不一定是真新用户，需标记 cohort_source=tracking_start。正式新用户 cohort 建议从埋点稳定后第 8 天开始看。

10.7 有效消费累计规则

问题 冻结规则
主口径 单个 anonymous_id + content_id 在 7 日主窗口内累计真实播放时间 >= 240 秒。多个不同视频不能合并。
是否允许跨 session 累计同一视频？ 允许，但只累计同一个 content_id 在同一 7 日主窗口内的真实播放秒数。达到 240 秒的时间必须仍在窗口内。
倍速怎么算？ 主口径按真实观看时间累计，不按媒体进度累计。2 倍速观看 120 秒，即真实播放 120 秒，不等于 240 秒有效消费。
拖进度条怎么算？ 拖动跳过的区间不计入真实播放。只累计拖动后继续播放产生的真实秒数。P0 的 video_progress 需要标记 is_seeked 风险，P1 用 video_heartbeat 校准。
暂停 / loading / buffering 不计入真实播放时间。
后台 / 失焦 / 锁屏 不计入真实播放时间。
多标签页播放 同一用户同一内容多标签页同时播放时，需要按 content_id + player_id + time_bucket 去重，避免重复累计。
自动播放 / 前贴片广告 当前产品没有自动播放和前贴片广告，因此主口径不处理这两类；如未来新增，需要单独重开口径。

10.8 直接消费回访分支

直接消费回访不是“找片失败”，而是另一种高意图路径。

路径 应该怎么归类
收藏 / 历史 / 继续观看进入详情 直接消费回访
SEO 或外链直接落到视频详情页 直接消费回访
浏览器书签直接打开详情页 直接消费回访
站内搜索、筛选、标签、女优、榜单后进入详情 找片回访
直接进详情后又返回列表继续找 同时拥有直接消费入口和后续找片行为，分析时可拆路径顺序

11. 冻结版事件字段字典

这一章不是“示例”，而是评审时可先冻结的事件字段字典。开发可以调整命名，但不能改变字段要表达的事实。

图示 5：事件如何串成 7 日留存指标
anonymous_id 串起 session_start -> page_view -> search / list / direct_content -> content_start -> video_progress / heartbeat
分母 匿名首访用户数：第一次有效 session_start 的 anonymous_id。
分子 在 24-168 小时内真实回访，并完成有效 / 估算有效消费的匿名首访用户数。

11.1 全局必填字段

所有关键事件都建议带以下字段。高频心跳事件可以做轻量化，但必须能通过 anonymous_id、session_id、page_view_id 和时间串回主链路。

字段 大白话 必填范围
event_id 单条事件的唯一编号 除心跳外的所有关键事件
event_name 事件名 所有事件
site_id 站点 ID 所有事件
domain 当前访问域名 所有事件
env 环境，例如 prod / staging / test 所有事件
app_version 前端应用版本 所有事件
build_version 构建版本 所有事件
anonymous_id 匿名用户 ID 所有事件
session_id 本次访问 ID 所有事件
page_view_id 本次页面浏览 ID 页面、找片、播放相关事件
occurred_at 事件真实发生时间 所有事件
received_at 服务端收到时间 服务端落库时生成
device_type 设备类型，例如 mobile / desktop / tablet 所有事件
browser 浏览器 所有事件
os 操作系统 所有事件
is_bot 是否爬虫或异常自动流量 所有事件
experiment_id 实验 ID 命中实验的事件
ab_group A/B 分组 命中实验的事件
source_channel 来源大类 session_start、page_view 必填
page_type 页面类型 page_view、页面内行为事件必填
content_id 视频内容 ID 详情、播放、消费、续看相关事件必填
is_backfill 是否补报 允许补报的事件必填

site_id、domain、env、版本、设备、浏览器、系统、实验字段不是为了让第一版报表更复杂，而是为了后续排查灰度、站群、多域名、A/B 实验和版本问题。没有这些字段，指标波动时很难判断是产品问题、流量问题还是发布问题。

11.2 事件字段字典

事件名 触发时机 上报端 必填字段 可选字段 去重键 失败重试 是否允许补报
session_start 新会话开始时。通常是首次打开、超过会话间隔后回来、或新标签页形成新会话。 前端触发，服务端落库 event_id、anonymous_id、session_id、occurred_at、source_channel、landing_url referrer、utm_*、entry_route、device_type event_id；兜底 anonymous_id + session_id 本地队列最多重试 3 次，最长 24 小时 允许，必须保留原始 occurred_at
page_view 页面正常打开并完成基础渲染；详情页需能带内容信息。 前端触发，服务端或边缘日志补充状态 event_id、anonymous_id、session_id、page_view_id、occurred_at、page_type、url、http_status content_id、canonical_url、landing_type、entry_route、http_status_source event_id；兜底 page_view_id 本地队列最多重试 3 次，最长 24 小时 允许
page_heartbeat 页面可见且窗口聚焦时，每 5 秒上报一次。 前端 anonymous_id、session_id、page_view_id、occurred_at、heartbeat_seq、visibility_state、focus_state foreground_seconds_delta page_view_id + heartbeat_seq 不做跨会话重试，避免高频补发污染 不允许跨会话补报
search_submit 用户主动提交站内搜索。 前端 event_id、anonymous_id、session_id、page_view_id、occurred_at、search_id、keyword_normalized keyword_type、keyword_length、source_page_type event_id；兜底 search_id 本地队列最多重试 3 次 允许
search_result_view 搜索结果返回并展示给用户。 前端 / 服务端均可 event_id、anonymous_id、session_id、search_id、occurred_at、result_count、search_result_state top_result_content_ids、keyword_type event_id；兜底 search_id + result_page_no 本地队列最多重试 3 次 允许
list_interaction 用户在列表、标签、女优、合集、榜单、搜索结果中点击、翻页、筛选、排序。 前端 event_id、anonymous_id、session_id、page_view_id、occurred_at、interaction_type、target_type target_id、module_id、position、filter_key、sort_type event_id 点击类重试；曝光类不强制重试 点击类允许，曝光类不建议补报
content_status_view 详情页打开后，系统确认内容是否正常、可播放、下架或缺资源。 服务端优先，前端补充 event_id、anonymous_id、session_id、page_view_id、occurred_at、content_id、content_status、is_playable unavailable_reason、resource_type event_id；兜底 page_view_id + content_id 服务端重试 允许
play_click 用户主动点击播放按钮。 前端 event_id、anonymous_id、session_id、page_view_id、occurred_at、content_id、player_id button_position、start_method event_id 本地队列最多重试 3 次 允许
content_start 正片播放器真正进入播放状态。点击播放不等于该事件。 前端播放器 event_id、anonymous_id、session_id、page_view_id、occurred_at、content_id、player_id、start_method、content_type media_duration、initial_quality event_id；兜底 content_id + player_id + occurred_at 本地队列最多重试 3 次 允许
player_state_change 播放器进入 loading、playing、buffering、pause、error 等状态。 前端播放器 event_id、anonymous_id、session_id、page_view_id、occurred_at、content_id、player_id、player_state error_code、buffering_seconds、network_type event_id error / playing 关键状态重试，高频 buffering 可采样 关键状态允许
video_progress 播放进度跨过关键里程碑，例如 30、60、120、240 秒。 前端播放器 event_id、anonymous_id、session_id、page_view_id、occurred_at、content_id、player_id、milestone、progress_seconds is_seeked、playback_rate、media_time anonymous_id + content_id + milestone + session_id 本地队列最多重试 3 次 允许
video_heartbeat 正片真实播放中，每 5 秒或按播放器能力批量上报真实播放秒数。 前端播放器 anonymous_id、session_id、page_view_id、occurred_at、content_id、player_id、play_seconds_delta、is_foreground、play_state media_time_start、media_time_end、playback_rate content_id + player_id + occurred_at_bucket 会话内短队列重试，不跨会话集中补发 不允许跨会话补报
next_content_click 用户从详情页推荐、同女优、同题材等模块点击另一个视频。 前端 event_id、anonymous_id、session_id、page_view_id、occurred_at、source_content_id、target_content_id module_id、position、recommend_type event_id 本地队列最多重试 3 次 允许
ad_impression 广告位展示给用户。 前端 event_id、anonymous_id、session_id、page_view_id、occurred_at、ad_slot_id ad_type、creative_id event_id；兜底 page_view_id + ad_slot_id + time_bucket 不强制重试 不建议补报
ad_click 用户点击广告。 前端 event_id、anonymous_id、session_id、page_view_id、occurred_at、ad_slot_id、target_domain ad_type、creative_id、click_position event_id 本地队列最多重试 3 次 允许
page_return 用户外跳后回到本站，或从后台恢复到前台。 前端 event_id、anonymous_id、session_id、page_view_id、occurred_at、return_from return_seconds、previous_target_domain event_id 本地队列最多重试 3 次 允许

11.3 补报规则

补报是为了解决弱网、短时断网、页面关闭前未发出等问题，不是为了改变用户行为发生时间。

规则 说明
补报必须保留原始 occurred_at 7 日窗口按原始发生时间算，不按 received_at 算。
补报必须带 is_backfill=true 后续排查数据延迟和异常峰值时需要识别。
超过 24 小时的客户端补报不进入主指标 可以入明细日志，但不进入留存主报表，避免延迟数据反复改历史。
高频心跳不跨会话补报 心跳丢失会影响精度，但集中补发更容易制造假播放和假停留。

11.4 http_status 来源规则

http_status 不建议完全相信前端，因为 SPA、CDN 缓存、服务端错误页、边缘回源异常都可能让前端拿不到真实状态。

来源优先级 规则
第一优先级 服务端访问日志或边缘日志中的真实 HTTP 状态。
第二优先级 业务后端返回的页面状态或内容状态，例如正常、下架、不可播放、空详情。
第三优先级 前端可感知的页面状态，仅作为补充字段，不作为唯一真相。
字段建议 增加 http_status_source，取值可为 edge_log、server_log、backend_status、frontend_detected。
对账要求 详情页正常打开、404、下架、不可播放等核心状态，必须能被服务端或边缘日志抽样验证。

12. 数据验收与隐私合规

12.1 数据验收标准

验收项 MVP 门槛 说明
关键事件上报成功率 session_start、page_view、content_start、video_progress >= 98% 用前端发送数、服务端接收数、服务端日志三方对账。
必填字段完整率 P0 必填字段 >= 99% anonymous_id、session_id、occurred_at、page_view_id、content_id 等关键字段不能大量为空。
重复事件率 <= 0.5% 按去重键检查重复上报。
前后端页面对账误差 <= 3% page_view 与服务端访问日志对账。
播放事件链路完整率 play_click -> content_start -> video_progress 可串联率 >= 95% 不要求每次点击都播放成功，但能串起来的链路不能断。
报表产出时效 T+1 中午 12:00 前产出昨日 cohort 和漏斗 7 日指标需要等待窗口结束，但过程指标可以每日滚动看。
异常流量过滤 有基础 bot、爬虫、预加载、内部访问过滤规则 过滤规则必须可解释，不要黑盒改数。
口径回放能力 支持按 anonymous_id 抽样回放完整路径 评审和排错时能证明指标不是拍脑袋。

验收原则：如果 P0 关键事件或必填字段没有达到门槛，不建议上线“7日有效消费回访率”正式看板；可以先以灰度看板观察。

12.2 看板成熟规则

7 日主指标不能在 D1 就当成完整结果看。运营版解释是：一批用户还没过完 7 天观察期，所以结果还没最终定稿。看板必须标记 cohort 是否已经完整观察。

图示 4：一个 cohort 什么时候才算看完 7 天
D0 这批匿名首访用户进入 cohort。
D1-D6 只能看过程指标，比如真实回访、找片、播放。
D0 + 168h 7 日观察窗口结束，主指标开始接近完整。
+ 12h 缓冲 等待补报和数据加工完成，看板标记为已成熟。
问题 冻结规则
D0 cohort 什么时候成熟？ D0 cohort 的 7 日主指标在 D0 结束 + 168 小时 + 数据延迟缓冲 后成熟。数据延迟缓冲建议先取 12 小时。
未成熟 cohort 能不能展示？ 可以展示，但必须标记为“未完整观察”或“观察中”，不能和成熟 cohort 混在同一条趋势里直接比较。
是否展示预测值？ MVP 不展示预测值，避免误导。中等版以后如要展示，必须单独命名为“预测值”，并和实际值分开。
过程指标怎么展示？ D0 后可以每日滚动展示真实回访、找片、进入详情、播放等过程指标，但 7 日有效消费回访率必须等窗口成熟。
历史数据会不会回刷？ 允许在成熟前回刷；成熟后只允许因去重、补报、异常流量规则修正而回刷，并需要有版本记录。
看板默认筛选 默认只看 env=prod、is_bot=false、非内部访问、有效首访 cohort。测试环境和灰度流量必须可单独筛选。

12.3 隐私与合规边界

边界 冻结规则
真实身份 不采集真实姓名、手机号、邮箱、证件号等真实身份信息。
匿名 ID anonymous_id 只作为随机匿名标识，不使用不可重置设备指纹强行识别真人。
搜索词 不记录敏感明文原始词到宽权限表；如业务必须分析搜索词，使用规范化词并限制访问权限。
IP 和设备信息 IP 不进入普通分析宽表；如安全风控需要，单独存储、脱敏或缩短保留周期。
播放行为 播放行为只用于产品分析、内容供给和体验优化，不对外暴露单用户明细。
日志保留周期 原始明细建议保留 90 天；聚合指标可保留 12-18 个月。最终以公司合规要求为准。
内部权限 单用户路径明细只给必要角色开放；运营和产品默认看聚合报表。

13. 评审防线

你可以这样讲

我们不是先拍脑袋列埋点，而是先拆 7 日消费回访漏斗。每一层都拆成产品定义、判断口径、事件字典、字段字典和验收标准。主成功指标是 7日有效消费回访率，中间层用于诊断用户卡在哪里。

不要这样讲

不要说“有 page_view 就算回访”“点播放就算播放”“进度到 4 分钟就一定看了 4 分钟”。这些都会被挑战。正确说法是：P0 粗判，P1 精细校准。

评审挑战 建议回答
为什么不用自然日 D7？ 保留自然日做辅助报表，但主分析用精确小时，避免 23:50 首访、00:10 回来被误算为次日留存。
这里的 7 日是不是自然日第 7 天？ 不是。本文 7 日指首访 T0 后 24-168 小时窗口，不是自然日 D7，也不是第 7 天当天回来。
匿名首访用户是不是新真人？ 不是。它只是第一次被我们识别到的 anonymous_id。同一个真人换浏览器、清缓存、无痕模式都可能变成新的匿名身份。
跨午夜要不要切 session？ 不切。session 按 30 分钟无活动切，不按自然日切。跨午夜自动切会制造假回访。
167 小时 50 分回来，168 小时 05 分看够 240 秒算不算？ 主指标不算 7 日有效消费，但算 7 日真实回访。因为有效消费的达成事件发生在 168 小时外。可以另设宽松辅助口径，但不能混进主指标。
页面一直开着，25 小时后继续播放，算回访吗？ 不算主回访。主回访必须有新的 session_id。这种情况进入长 session 辅助分析。
停留 15 秒就算成功吗？ 不算。它只算真实回访，用于过滤假打开。成功要看是否有效消费。
点标签也算找片，会不会太宽？ 点标签只算找片行为，不算成功。后面还要看是否进入详情、播放、有效消费。
用户直接从收藏或 SEO 进详情播放，没有找片，算失败吗？ 不算找片失败。它属于直接消费回访分支，应单独统计。这个路径往往代表高意图用户。
点内容卡为什么不直接算进入详情？ 点击只是意图。详情页正常打开才算进入详情，中间可能加载失败、广告外跳、404 或埋点丢失。
点播放按钮不就算播放了吗？ 不算。点击是意图，正片播放器进入播放状态才算开始播放。
P0 的 240 秒是不是用户真实看了 240 秒？ 不能这么说。P0 只是播放进度估算，所以看板应标成“估算有效消费”。P1 用真实播放心跳后，才更接近真实观看。
为什么 240 秒算有效消费？ JAV 长视频不适合用百分比。知识库已有口径用绝对时长，初始 240 秒，后续按真实分布校准。
多个视频各看 1 分钟，能合成有效消费吗？ 不能。有效消费按单个视频判断。多个短试看更像多轮试片，应该进诊断池。
loading、广告劫持你们能知道吗？ P0 不直接断言具体原因，只标记结果状态。P1 通过播放器状态、广告跳转、快速返回等信号细分原因。
D1 能不能看 7 日留存？ 不能当正式结果。D1 只能看过程指标，7 日有效消费回访率要等 D0 cohort 完整观察 168 小时并加数据延迟缓冲后才成熟。

最终建议：第一阶段先做 MVP，把主指标和基础漏斗跑起来；第二阶段补中等版能力，拆清楚没消费的原因；完整理想版作为后续数据体系目标。