下面给出一套可直接用于技术评审的标签有效期决策矩阵、字段口径和回收状态机。由于本轮没有可公开的第一方项目材料，文中的标签名称和规则场景均为演示示例，不代表真实客户项目或行业统一默认值。
设置用户标签有效期前，先分清四个不同对象
“用户标签有效期”不是现行法规中的统一术语，也没有适用于所有标签系统的行业标准定义。为了让研发、数据、运营和合规人员使用同一套口径，可以把它定义为：某个标签值或标签成员资格，在既定业务目的和规则条件下，仍适合用于当前判断的时间范围。
实际设计时至少要区分四个对象。
- 标签定义生命周期：标签规则本身处于草稿、已审核、生效、下线、失效还是删除状态。
- 标签值新鲜度：当前标签值使用的最新源数据距现在已经过去多长时间。
- 标签成员资格有效期：某个用户从什么时候开始满足标签条件，什么时候不再满足。
- 底层数据保存期限：原始事件、用户属性、中间表、历史快照和派生标签允许保存多久。
这四个对象不能互相替代。标签任务暂停后，旧标签值可能仍可查询；成员资格过期后，下游系统可能仍保留此前同步的结果；画像页面看不到标签，也不能证明原始事件和历史快照已经删除。
公开产品文档也显示，不同系统会采用不同状态定义。易观方舟的标签生命周期文档区分上线、下线、生效、失效和删除，其中下线主要表示停止周期更新，失效表示不能继续用于应用场景，删除才涉及任务和历史结果处理。该行为只代表其文档所述产品规则，不能推广为统一标准。
GrowingIO 4.1用户标签文档则区分实时事件触发、离线计算、暂停调度、删除标签和历史数据存储设置，并提示切换为只保存最新数据后，已有历史数据仍可能存在。这进一步说明，停止计算和清理历史结果需要分别验收。
需要补充标签分类、标签加工和画像应用基础时，可查看标签体系建设与用户画像建模。本文只处理标签什么时候仍然有效、什么时候应退出，以及旧结果如何回收。
不同标签应该选择哪一种失效机制
用户标签有效期的核心不是选择一个天数，而是找到最能反映业务事实变化的失效条件。下表是一份可用于需求评审的决策矩阵。表中的标签名称和时间窗口均为演示场景。
| 标签类型 | 演示对象 | 适合的生效与失效机制 | 主要验收点 |
|---|---|---|---|
| 权威状态型 | 会员状态、订单状态、合同状态 | 由业务数据库或明确的状态变更事件覆盖旧值；不依赖自然衰减猜测状态 | 权威数据源是否唯一；取消、退款、到期等反向事件是否能够立即撤销旧值 |
| 滚动行为型 | 最近30天活跃、近期购买用户 | 每次计算时回看指定时间窗口；窗口外行为自动退出当前结果 | 使用事件发生时间还是接收时间；退款、重复事件和迟到数据是否参与计算 |
| 衰减评分型 | 内容兴趣强度、购买意向分 | 行为发生后逐步降权，分数低于阈值时失效；明确负反馈可以直接降权或撤销 | 行为权重、衰减函数、半衰期、分数上限和失效阈值是否经过第一方数据验证 |
| 一次性成员型 | 某次活动目标人群 | 在规定时间生成一次成员名单，到期后停止使用，并单独执行画像库和下游成员回收 | 人群对象过期后，用户档案、缓存和外部目的端是否仍保留旧成员 |
| 合规状态型 | 营销同意、退订状态、账号注销状态 | 以授权记录、用户请求或权威处理状态为准；撤回、注销等事件优先于普通调度周期 | 是否停止不再具有合法依据的处理；派生标签、缓存和下游系统是否同步处置 |
状态型标签不适合单纯依靠时间到期。例如“退款完成”应由订单系统的权威状态决定，而不是等待标签在若干天后自然失效。时间条件可以作为漏处理监控，但不能代替状态事件。
近期行为标签更适合滚动窗口。“最近30天购买过”表示每次判断都从当前时间向前回看30天，而不是用户首次购买时打上标签，再永久保留。窗口长度属于业务规则，不是法规或行业默认值。
兴趣和意向标签可以使用衰减评分，因为这类标签表达的是强度而不是确定状态。正式研究表明，用户偏好和对象流行度会随时间变化，建模时考虑时间因素具有合理性，可参考ACM收录的时间动态推荐研究。但这项研究不能证明所有业务都应使用同一种衰减函数，也不能直接给出通用半衰期。
合规状态不能沿用普通营销标签的续期逻辑。用户已经退订、撤回同意或完成账号注销后，不能因为后来又产生了一次普通浏览事件，就自动把原状态恢复为“可营销”。
固定有效期、滑动有效期和行为衰减怎样计算
有效期配置必须同时记录源数据时间、计算时间和状态变化时间。只保存“任务最后运行时间”，无法证明标签使用的是新数据。
标签数据年龄
建议使用以下口径：
标签数据年龄＝当前时间－source_max_event_time
source_max_event_time表示本次标签计算实际使用的最新源事件时间。如果任务今天重新运行，却只读取了上周的数据分区，计算时间虽然很新，标签依据仍然陈旧。
计算延迟
计算延迟＝tag_calculated_at－source_max_event_time
这个指标用于判断源事件已经产生后，经过上报、接收、清洗和计算，多久才反映到标签结果。它会直接影响运营名单、推荐结果和风险判断的时效。
固定有效期
expire_at＝valid_from＋固定时长
固定有效期适合生命周期边界明确、续期需要重新审批或重新生成的成员资格。新的普通行为不应自动修改原到期时间，除非规则明确规定重新创建或续期。
滑动有效期
expire_at＝last_qualified_event_time＋有效时长
每发生一次符合条件的新行为，就重新计算到期时间。Google Analytics的数据保留设置中也存在“发生新活动后重置用户标识符到期时间”的产品机制，详见Google Analytics数据保留说明。这只能说明固定到期和活动续期是两种不同机制，不能把Google Analytics的保留规则写成用户标签行业标准。
指数衰减演示口径
当前权重＝初始权重×2^（－距行为发生时间÷半衰期）
该公式只适合作为演示口径。半衰期、初始权重、行为累积方式和失效阈值需要使用企业自有业务数据验证。内容收藏、完整播放、快速跳过和明确选择“不感兴趣”不应使用相同权重。
行为标签所依赖的事件名称、事件属性、统计窗口和去重规则，可结合用户行为分析解决方案进一步定义。有效期规则无法补救事件口径本身不一致的问题。
标签过期后，怎样完成状态变化与下游回收
标签回收不能只设计一个“已过期”字段。更稳妥的方式是建立状态机，把数据过时、规则到期、业务撤销和物理删除分开记录。
建议的主状态流转为：
草稿 → 已审核 → 生效 → 待更新
标签进入生效状态后，可以根据实际原因转入以下状态：
- 过时：源数据年龄超过业务允许范围，但还不能确认用户真实状态已经失效。
- 过期：已到达规则预设的
expire_at。 - 撤销：收到退款、取消、退订、授权撤回或其他明确否定事件。
- 替换：旧标签值被新的状态、规则版本或身份合并结果覆盖。
- 冻结：因数据质量、权限、安全或合规问题暂停使用。
这些状态随后应进入：
下游回收中 → 已回收 → 已归档或已删除
“过时”不等于“过期”。例如标签计算任务失败，导致源数据已经三天没有更新，此时可以把标签标记为过时并暂停使用，但不能直接推断用户已经不符合业务条件。
“撤销”也不等于“删除”。订单退款后，原购买标签应退出当前运营人群，但相关订单记录是否需要继续保存，应根据合同履行、财务、争议处理和其他合法目的单独判断。
mParticle创建人群的官方文档明确区分实时人群和一次性人群，并说明一次性人群过期后，此前写入用户档案的成员资格可能仍然保留。在该产品规则下，人群对象过期和用户档案成员回收是两个动作。其他平台是否采用相同逻辑，需要分别核实。
下游回收至少应覆盖画像库当前值、分群成员表、接口缓存、推荐或运营系统、导出文件以及依法允许接入的外部目的端。系统需要同时发送成员新增和成员移除结果，并对失败任务进行重试和对账。
从SDK上报到标签回收，哪些故障会留下旧标签
标签有效期依赖完整的数据链路。上游事件没有准确到达，后续再严谨的失效规则也可能得到错误结果。企业自有业务场景中的排查可以按以下顺序进行。
- 检查事件触发：确认状态变化、退款、取消、授权撤回等事件是否真实触发，关键属性是否为空，事件时间是否使用了错误的客户端本地时间。
- 检查SDK上报：确认离线缓存是否成功补发、重试是否产生重复事件、匿名ID是否被异常重置，以及登录前后身份是否正确关联。
- 检查接收与去重：确认事件时间和接收时间没有混用，乱序事件不会用旧状态覆盖新状态，服务端是否存在稳定的幂等键。
- 检查清洗规则：确认退款、撤回、取消等否定事件已经进入计算链路，时区、事件名称和属性枚举没有发生未同步的变更。
- 检查用户ID合并：匿名用户与登录用户合并后是否重新计算标签，账号解绑或多人共用设备时是否错误继承标签。
- 检查计算任务：任务成功是否只是技术状态成功，实际读取的数据分区是否最新，迟到事件是否回补，规则版本修改后是否重算受影响成员。
- 检查下游移除：确认标签下线后，已有成员是否从画像库、缓存、接口和下游系统退出，而不是只停止新增。
- 检查用户权利流程：确认撤回同意、账号注销、更正和删除请求是否能够传播到派生标签及其下游副本。
建议至少监控四个指标：
过期未回收率＝到期时间已过但状态仍为有效的成员数÷到期时间已过的成员总数下游残留率＝上游已失效但下游仍可查询的成员数÷上游已失效成员数互斥状态冲突率＝同时拥有两个互斥标签值的用户数÷至少拥有其中一个标签值的用户数计算延迟＝tag_calculated_at－source_max_event_time
指标阈值必须根据具体业务时效和风险等级设定，不能写成统一验收标准。转化率发生变化，也不能直接证明有效期调整产生了因果效果，还需要排除活动、渠道、价格、人群规模和样本选择等影响。
上游事件时间、用户ID、属性字段、缓存重试和数据质量规则，可通过SDK数据采集解决方案补足。数据采集应限定在企业自有业务场景中，并遵循明确目的、透明告知、合法授权、最小必要、数据脱敏、权限控制和安全措施。
用户标签有效期与个人信息保存期限怎样划清边界
标签退出当前运营人群，不代表与该标签有关的数据已经完成删除。反过来，原始事件达到保存期限后，也需要评估基于这些事件生成的派生标签是否仍有合法、明确且必要的处理目的。
《中华人民共和国个人信息保护法》将收集、存储、使用、加工、传输、提供、公开和删除均纳入个人信息处理活动，并要求个人信息保存期限原则上为实现处理目的所必要的最短时间。处理目的不再必要、保存期限届满或个人撤回同意等情形，还可能触发删除义务。
能够关联到已识别或可识别自然人的行为标签、偏好标签、状态标签及其底层数据，可能属于个人信息处理的一部分。不能因为系统使用匿名ID，就直接断言相关数据不属于个人信息；还需要结合企业掌握的其他信息、关联方式和实际识别能力判断。
《个人信息保护合规审计管理办法》的审计指引将保存期限或确定方法、到期后的处理方式，以及是否符合最短必要原则列为检查事项。该要求不能直接换算成某类用户标签的固定保存天数。
《网络数据安全管理条例》还涉及账号注销、删除或匿名化，以及在技术上暂时难以删除时停止除存储和必要安全保护之外处理的要求。标签系统不能只停止新事件采集，却继续使用旧标签开展不再具有合法依据的分析或营销。
标签用于个性化推荐、商业营销、价格判断或其他可能对个人权益产生影响的自动化决策时，还需根据实际场景核对透明度、公平性、拒绝方式和非个性化选项。涉及医疗健康、金融账户、行踪轨迹、生物识别、特定身份或不满14周岁未成年人信息时，应由法务、个人信息保护和安全负责人进行专门评估。
企业在形成内部规则时，应避免以下表达：
- 用户标签可以永久保存。
- 静态标签永远不会变化。
- 行业统一规定行为标签保留30天。
- 匿名ID一定不属于个人信息。
- 标签过期就代表底层数据已经删除。
- 用户撤回同意后只需停止新数据采集。
更稳妥的写法是：“通常应根据标签用途和状态变化频率确定”“在完成合法授权、透明告知和最小必要评估的前提下”“在该产品当前版本的规则下”以及“该时间仅为演示配置，不是行业标准”。网站自身的信息处理边界可参照隐私政策与信息保护说明，具体项目仍应由内部法务、安全和研发团队共同复核。
上线前应完成哪些字段和审核动作
一个可以验收的标签规则，不能只有标签名称和计算条件。需求文档或标签字典至少应记录以下字段：
- 标签ID、标签名称、业务目的和标签类型。
- 底层数据来源、权威状态源及是否涉及个人信息或敏感个人信息。
valid_from、expire_at、source_max_event_time、tag_calculated_at和invalidated_at。- 更新模式、固定或滑动有效期、滚动窗口、续期事件和立即失效事件。
- 衰减函数、半衰期、失效阈值及其第一方验证记录。
- 标签状态、失效原因、规则版本和最后复核日期。
- 所有下游系统、成员移除方式、历史结果保存方式和删除或匿名化规则。
- 规则负责人、技术审核人、合规审核人及变更记录。
上线前还应完成一次端到端验证：构造一个符合条件的演示用户，使标签生效；触发新行为，检查是否按照规则续期；触发退款、取消或撤回事件，检查是否立即失效；等待或模拟到期时间，确认画像库和所有下游系统都完成成员移除。
当前缺少可公开的事件字典、标签配置截图、排查记录和真实项目流程，因此不能把上述方法描述为本站已经完成的客户实践。正式发布前，建议补充经过脱敏的标签字典、一次旧标签残留排查记录、规则评审表，以及账号注销或授权撤回进入标签系统的流程说明。
适用范围与最后核实日期
本文适用于企业自有业务场景中的用户标签设计、行为分析、画像管理和标签回收，不适用于未经授权的数据采集、跨业务目的追踪、竞争对手数据抓取、非法采集通讯录或滥用设备标识。
本文引用的法律法规和公开产品文档最后核实日期为2026年7月28日。产品能力、页面内容和平台规则可能调整，发布前应再次访问原始来源核对。易观方舟和GrowingIO的引用仅用于说明产品状态模型可能不同；mParticle的引用仅用于说明在其产品规则下，人群过期与成员回收可能分离；Google Analytics的引用仅用于说明固定到期和活动续期是两种不同的数据保留机制。
法律与合规内容仅作一般信息说明，不能代替针对具体业务、数据类型和处理目的的法律意见。涉及个人信息、敏感个人信息、自动化决策、账号注销或用户撤回同意时，应由内部法务、个人信息保护负责人、安全团队和研发负责人共同复核。
实际落地时，不要先讨论“应该设多少天”。先选取一个真实标签，补齐权威数据源、生效事件、失效事件、时间字段、下游系统和删除边界，再用演示用户完成一次从打标到回收的全链路验证。只有旧标签能够按预期退出所有使用系统，有效期规则才算真正完成。
纠错方式：[待填写纠错邮箱或联系入口]。