用户协议与隐私政策的字数设计 - 法律要求与可读性的平衡
用户协议和隐私政策是服务提供者与用户之间的法律合同文件。然而，其字数逐年膨胀，有调查显示，阅读主要服务的完整用户协议平均需要 30 分钟以上。在确保法律全面性的同时，将字数控制在用户实际能够阅读的范围内，是法务部门和 UX 团队需要协作解决的难题。本文将基于国内外法律要求，介绍字数设计的实践方法。
主要服务的用户协议 - 字数现状
首先来看看实际服务公开了多少字数的用户协议。以下数据调查了各服务日语版用户协议的字数。
| 服务 | 用户协议字数 | 预计阅读时间 | 章节数 | 最后更新 |
|---|---|---|---|---|
| Apple (媒体服务) | 约 35,000 字 | 约 44 分钟 | 30 以上 | 2024 年 |
| Google (服务条款) | 约 12,000 字 | 约 15 分钟 | 15 | 2024 年 |
| Amazon (使用条件) | 约 18,000 字 | 约 23 分钟 | 20 以上 | 2024 年 |
| X (原 Twitter) | 约 15,000 字 | 约 19 分钟 | 12 | 2024 年 |
| LINE | 约 20,000 字 | 约 25 分钟 | 25 | 2024 年 |
| Mercari | 约 22,000 字 | 约 28 分钟 | 20 以上 | 2024 年 |
Google 的用户协议相对较短 (约 12,000 字)，是因为将各服务特有的条件分离到了单独的文件 (附加使用条款) 中。这种"分层方法"是后文将介绍的有效字数设计策略。而 Apple 的媒体服务用户协议超过 35,000 字，是因为将 iTunes、App Store、Apple Music、Apple TV+ 等多个服务的条件整合在了一份文件中。
用户协议为何越来越长 - 结构性原因
用户协议字数膨胀的背后存在法律和商业层面的结构性因素。
- 法律风险规避：律师基于"未写明的事项视为未达成一致"的原则，试图覆盖所有风险场景。结果是连发生概率极低的事件也被详细描述，导致字数增加
- 监管复杂化：需要遵守的法规不断增加 - GDPR、个人信息保护法、电信事业法、特定商业交易法等。逐一披露各法规要求的事项，字数必然增加
- 服务多功能化：单一平台提供支付、消息、内容分发、广告等多种功能，每种功能都需要特定的使用条件
- 诉讼应对：反复进行"补丁式修订"，将过去诉讼中争议的事项添加到用户协议中，导致文件膨胀
- 国际化扩展：为适应多个法域 (日本、欧盟、美国等)，需要添加各法域特有的条款
这些因素相互作用，持续推高字数。然而字数越多，用户的阅读完成率越低，"同意但未阅读"成为常态。接下来介绍的分层方法正是为了解决这一矛盾。
分层方法 - 字数问题的实践解决方案
分层方法 (Layered Approach) 是将法律文件分为多个层级，根据用户的关注程度逐步提供信息的手法。GDPR 前言 (Recital 58) 也将其推荐为"透明信息提供"的手段。
| 层级 | 名称 | 推荐字数 | 内容 | 展示方式 |
|---|---|---|---|---|
| 第 1 层 | 摘要 (Summary) | 500-1,000 字 | 最重要条款的通俗摘要 | 直接显示在同意界面 |
| 第 2 层 | 概要 (Overview) | 2,000-5,000 字 | 各章节要点的列表整理 | 手风琴 UI 展开 |
| 第 3 层 | 全文 (Full Text) | 10,000-30,000 字 | 法律上完整的用户协议全文 | 链接到单独页面 |
第 1 层的摘要不是具有法律约束力的文件，而是帮助用户理解的辅助材料。添加"本摘要仅供参考，具有法律效力的仅为全文"的注释，可以在规避法律风险的同时提高可读性。
这种方法与商务邮件字数设计中"在标题传达要点，在正文补充细节"的结构本质相同。用户的注意力是有限的，需要将最重要的信息优先呈现。
GDPR 的字数相关要求
GDPR (欧盟通用数据保护条例) 对隐私政策的撰写方式提出了具体要求。虽然没有直接规定字数的条文，但以下原则间接影响字数设计。
| GDPR 条文 | 要求 | 对字数的影响 |
|---|---|---|
| 第 12 条第 1 款 | 以简洁、透明、易懂且易于获取的形式提供信息 | 需要避免冗长的法律用语，使用通俗表达 |
| 第 12 条第 1 款 | 使用清晰、通俗的语言，特别是面向儿童的信息 | 需要最小化专业术语的使用并添加说明 |
| 第 13 条 | 披露数据控制者身份、处理目的、法律依据、保存期限、数据主体权利等 | 需要披露的项目多，需要一定的字数 |
| 第 14 条 | 对非直接从本人获取的个人数据也需提供信息 | 存在第三方数据获取时需要额外说明 |
| 前言 39 | 使自然人能够了解个人数据的收集、使用、查阅和处理 | 需要用非技术人员也能理解的语言解释技术处理内容 |
GDPR 的"简洁易懂"要求与"披露所有必要信息"要求本质上是矛盾的。为解决这一矛盾，欧洲数据保护委员会 (EDPB) 推荐分层方法。在第 1 层提供简洁摘要，在第 3 层提供法律上完整的全文，可以同时满足两项要求。
日本个人信息保护法与隐私政策字数
日本的个人信息保护法 (2022 年修订) 虽然没有像 GDPR 那样深入规定撰写方式，但明确规定了需要披露的事项。
- 利用目的的明确与公布 (第 21 条)：尽可能明确个人信息的利用目的并通知或公布。"用于营销"这样模糊的描述不够，需要具体到"用于商品推荐展示"
- 第三方提供相关事项 (第 27 条)：向第三方提供个人数据时，需明示提供对象范围、提供的数据项目和提供方式
- 保有个人数据相关事项的公布 (第 32 条)：公布经营者名称、利用目的、披露等请求程序和投诉联系方式
- 安全管理措施 (第 23 条)：公布为保护个人数据安全所采取措施的概要 (2022 年修订新增)
满足这些要求的隐私政策至少需要 3,000-5,000 字。加上 Cookie 使用、访问分析工具、广告投放服务合作等 Web 服务特有的事项，8,000-15,000 字是常见范围。
提高可读性的文案技巧
提高法律文件的可读性不仅需要减少字数，还需要在文章结构和表达上下功夫。新闻稿字数设计中使用的许多技巧也适用于法律文件。
| 技巧 | 改善前 | 改善后 | 字数变化 |
|---|---|---|---|
| 转为主动语态 | "您的个人信息由我方收集" | "我方收集您的个人信息" | 更简洁清晰 |
| 消除双重否定 | "我方并非不承担责任" | "我方承担责任" | 大幅缩短 |
| 使用列表 | "收集姓名、地址、电话号码、电子邮件地址及出生日期" | "收集以下信息：姓名 / 地址 / 电话 / 邮箱 / 出生日期" | 可读性大幅提升 |
| 集中定义 | 在各条款中重复"本服务是指……" | 在开头的定义章节统一定义，之后引用"本服务" | 消除重复 |
| 具体化标题 | "第 5 条 (其他)" | "第 5 条 (数据保存期限与删除)" | 仅看标题即可了解内容 |
法律文件特有的"应当""包括但不限于""尽管有前款规定"等表达，有时为了法律准确性是必要的，但过度使用会严重降低可读性。与法务部门协商，找出可以改用通俗表达的部分，逐步改善是现实的做法。
隐私政策结构模板
以下是有效的隐私政策结构及推荐字数。
| 章节 | 推荐字数 | 内容 | 优先级 |
|---|---|---|---|
| 引言 | 200-400 字 | 政策目的、适用范围、最后更新日期 | 必须 |
| 收集的信息 | 500-1,000 字 | 收集的数据类型、收集方式 | 必须 |
| 利用目的 | 300-800 字 | 各数据的具体利用目的 | 必须 |
| 第三方提供 | 300-600 字 | 提供对象、提供的数据、法律依据 | 必须 |
| 数据保存与删除 | 200-400 字 | 保存期限、删除标准和方法 | 必须 |
| 用户权利 | 300-600 字 | 披露、更正、删除、停止使用的请求方法 | 必须 |
| Cookie 与追踪 | 300-600 字 | 使用的技术、退出方法 | Web 服务必须 |
| 安全管理措施 | 200-400 字 | 技术性和组织性的数据保护措施 | 必须 |
| 儿童隐私 | 100-300 字 | 年龄限制、监护人同意 | 相关服务必须 |
| 政策变更 | 100-200 字 | 变更时的通知方式、生效日期 | 必须 |
| 联系方式 | 100-200 字 | 数据保护负责人联系方式 | 必须 |
按照此模板，隐私政策总字数约为 2,600-5,500 字。与博客文章的最佳字数相比，大约相当于一篇普通博客文章的篇幅。在这个范围内，用户阅读全文是现实可行的。
法律文件设计相关的书籍可在 Amazon 上找到。从法务和 UX 两个角度学习，可以实现更实用的文件设计。
用户协议的 UI 设计与字数的关系
用户协议的字数设计不仅与文件内容相关，还与展示它的 UI 设计密切关联。同样 10,000 字的用户协议，展示方式不同，用户的阅读完成率会有很大差异。
- 可滚动文本框：在同意界面嵌入小文本框，通过滚动阅读全文。阅读完成率极低 (估计不到 5%)。欧盟消费者保护指令可能判定此方式"透明度不足"
- 手风琴 UI：按章节可折叠展开的 UI。用户可以只展开感兴趣的章节阅读。阅读完成率部分提升 (感兴趣章节的阅读率 20-30%)
- 分步形式：将用户协议分为多个步骤，每步显示 1-2 个章节。将每步控制在 500-1,000 字，有案例将阅读完成率提升至 40-50%
- 高亮 + 全文链接：将重要条款 (数据利用目的、第三方提供、解约条件) 高亮显示，全文通过链接提供。高亮部分的阅读率超过 60%
分步形式与高亮方式的组合是目前最有效的 UI 模式。每步显示 500-1,000 字的摘要，为想了解详情的用户提供全文链接。
法律文件的多语言对应与字数变化
全球化服务需要以多种语言提供用户协议。语言间的字数变化会影响布局和 UI 设计。
| 语言 | 相对日语 10,000 字的比例 | 备注 |
|---|---|---|
| 英语 | 约 120-140% | 单词数少但含空格后字数增加 |
| 德语 | 约 140-160% | 复合词较长，字数大幅增加 |
| 法语 | 约 130-150% | 冠词和介词多，比英语更长 |
| 中文 (简体) | 约 80-90% | 汉字信息密度高，字数减少 |
| 韩语 | 约 95-105% | 与日语字数大致相当 |
| 阿拉伯语 | 约 110-130% | 从右到左书写，需要 UI 布局镜像 |
德语版超过日语版 1.5 倍并不罕见。设计分层方法第 1 层 (摘要) 时，应以字数最多的语言为基准设计布局，其他语言留出空白余量。
用户协议的更新频率与字数变迁
用户协议不是一次性创建就结束的，会随着法律修订、功能增加、诉讼应对等定期更新。每次更新都会添加条款，字数持续增长是常态。
从主要服务的更新频率来看，每年 1-2 次更新是标准。Google 大约每年进行一次大规模修订，Apple 则配合新服务发布随时更新。当出现日本个人信息保护法修订 (2022 年施行) 或欧盟数字服务法 (2024 年施行) 等重大法律变更时，众多服务会同时修订用户协议。
为抑制字数增长，更新时不仅要"添加"，还要同时进行"整理"。具体来说，以下方法有效：
- 合并重复条款：整合过去修订中添加的类似条款，消除冗余
- 删除已停止服务的条款：删除已终止服务相关的条款
- 分离到附加文件：将服务特有的条件分离为附加使用条款，控制基本用户协议的字数
- 审查定义：整理定义章节，删除未使用的定义术语
衡量阅读完成率的方法
改善用户协议字数设计的起点是衡量当前的阅读完成率。Web 服务的用户协议页面可以追踪以下指标。
| 指标 | 测量方法 | 参考标准 |
|---|---|---|
| 页面停留时间 | 访问分析工具 | 达到全文阅读所需时间的 30% 以上为良好 |
| 滚动深度 | 滚动事件追踪 | 滚动超过 75% 的用户比例 |
| 手风琴展开率 | 点击事件追踪 | 比较各章节展开率，识别高关注章节 |
| 同意所需时间 | 同意按钮点击时间 - 页面显示时间 | 3 秒以内推定为"未阅读即同意" |
| 跳出率 | 访问分析工具 | 用户协议页面跳出率高说明字数可能是障碍 |
如果绝大多数用户在 3 秒内就点击同意，意味着用户协议实际上没有被阅读。这种情况下需要 UI 层面的改善，如引入分层方法或高亮显示重要条款。本质的解决方案不仅是减少字数，而是将结构转变为用户"想要阅读"的形式。