O4.08.1Proximate reporting entry设计
举报入口需就近于问题内容
别名: 就近举报 · in-context reporting · report entry placement
概念解释
举报入口的位置决定举报率与举报质量：入口就近于问题内容（内容旁的长按菜单、省略号菜单），用户才能带着上下文准确举报；藏在帮助中心或设置深处的举报，变成需要额外动机才能完成的寻宝——真实举报流失，系统里剩下的多是别的东西。
机制
就近性的价值是上下文绑定：从内容旁发起的举报自动携带内容 ID、作者、时间与界面状态，分类更准、核查更快；从帮助中心发起的举报要求用户自行描述「在哪里看到了什么」，描述损耗直接转化为核查成本。就近性还影响即时性——看到问题的那一刻举报动机最高，任何延迟都让动机衰减。入口的完整结构是三层：内容级（每条内容的菜单）、账号级（个人主页）、申诉级（对处理结果不服）——缺任何一层就堵死一类用户。显眼度要与滥用权衡：过于显眼鼓励恶意举报，过于隐蔽降低真实举报率；基准是「找得到，但不在主路径上」。
边界
就近不等于一键无分类：不做分类的一键举报会把有效信号淹没在垃圾里，「入口近、分类精」是组合要求。多模态场景的就近形态不同：视频要带时间点定位，直播要配时间戳快照机制，否则「举报的那一刻」无法固定证据。跨端形态可以不同（移动长按、桌面悬停），但三层入口的功能必须在每个端等价存在。
怎么落地
- 举报入口挂内容级菜单首层，自动携带内容上下文，全程不要求用户复述「在哪里看到的」。
- 分类用用户语言（垃圾、欺诈、骚扰、侵权、涉及未成年人），先粗分后细分；分类选项的措辞进文案评审。
- 验证：举报漏斗分析——入口曝光到提交的转化率、分类完成率、因「找不到入口」放弃的比例；末项用入口改版前后对比来度量改进。