应禁止将用户敏感信息直接拼入事件名，因其会导致信息泄露、数据污染、合规违规及安全攻击风险；须通过前端拦截、服务端脱敏、哈希泛化等前置措施实现去标识化。

因为这会直接导致敏感信息泄露、埋点数据污染、合规风险激增，甚至被用于反向识别或攻击。

敏感信息可能随事件名暴露

用户输入常含身份证号、手机号、邮箱、地址、订单号等高危字段。若未经识别与过滤就拼进事件名称（如 user_click_138****5678 或 search_submit_张三_北京市朝阳区XX路1号），这些明文片段会完整记录在埋点日志、数仓表、BI看板甚至第三方分析平台中，脱离权限管控范围。

破坏数据治理与下游使用安全

事件名称是数据管道的关键元信息，常被用于自动化分表、指标聚合、A/B实验分流、异常检测建模等场景。一旦混入原始用户数据：

• 数仓ETL脚本可能因非法字符（如空格、斜杠、中文）报错或截断
• 标签系统误将手机号当用户ID做关联，引发身份混淆
• 算法模型在训练时“记住”真实身份特征，造成隐私泄露风险

违反主流合规要求

GDPR、CCPA、《个人信息保护法》均明确要求对可识别自然人的信息实施去标识化处理。将用户输入直接用作事件名，属于典型的“未采取必要技术措施防止信息泄露”，审计时会被认定为重大违规项。监管处罚案例中，已有企业因埋点字段携带完整手机号被处以高额罚款。

替代方案建议

应建立前置脱敏层，而非依赖后端清洗：

• 前端SDK统一拦截含敏感模式的输入（如11位数字+连号特征），替换为泛化标识（如 user_click_phone_masked）
• 服务端接收后、落库前调用脱敏框架（如Microsoft Presidio）进行实体识别与遮蔽
• 对必须区分行为类型的场景，改用哈希+盐值生成不可逆标识（如 search_submit_hash_abc123），确保无法还原原始内容