「业务方要导出全量用户手机号做短信召回，你怎么处理？」这道题我放在系列靠后的位置，因为它是唯一一道大部分人第一反应都错得一致的题。
常见回答是一句「这涉及隐私，不能给」。立场没问题，但面试里它几乎没有信息量——它只证明对方知道有个词叫合规，没证明他知道在真实组织里这件事该怎么往前走一步。而且只说「不」，业务目标并不会消失，最后往往是有人从别的地方拷走一份 Excel，比走流程更糟。
本系列第 9/10 篇 · 上一篇：留存曲线不好读，好读的是分组 · 下一篇：讲项目时，我最想听你哪里做错了
先问目的，再谈要不要给
我期待的第一句话是反问：这次召回要触达谁、多少人、达到什么目标。
拆开看，绝大多数「全量导出」其实不需要全量。可能只要近 30 天加购未支付的人，可能只要某个区域、某个会员等级的人，也可能根本不需要拿到明文手机号——在平台内用 Push 或站内信触达，效果还能回流到同一套指标体系里做归因。用内部 ID 加标签分群、由消息平台完成发送、只回传触达和转化结果，业务目标达成了，敏感字段一步都没出域。
这就是最小必要的实际含义：不是把申请砍一半，是重新设计一条字段更少的路径，让对方不需要那份数据也能把事办成。候选人如果能给出两三个替代方案，并说明各自在效果、时效、可归因上的差别，基本已经赢下这题。
确实需要明文时，才轮到下面几问：字段清单能不能再减（只要手机号，还是连姓名、地址、消费记录一起要）；这批人是否都在可触达范围内（有没有关闭通知、退订、处于静默期）；数据给到谁、在哪台机器上用、用完多久删除；审批人是谁、依据是什么。我不会替法务下结论，也不在面试里背条款，我要确认的是这条链路有明确的判断责任人，且每一步可追溯。把「合不合规」交给流程和专业角色，把「怎么让流程跑得动、跑过之后留得下证据」留给自己，这是数据产品经理的分内事。
把边界做成产品能力，而不是口头规矩
只靠人肉盯，权限一定会烂。我更想听对方怎么把边界固化进系统。
权限粒度。库、表、列、行四级要分开设计。手机号、证件号这类高敏字段默认不进 BI 宽表，需要时通过单独的脱敏视图按列授权；区域经理只能看自己区域的行，这是行级；只读账号不该能顺手 SELECT * 把一张明细表拖走。按角色 + 数据域 + 使用场景授权，比「给某某开个只读账号」可靠得多。
授权要有有效期。临时取数权限带自动过期时间，到期回收，不用靠人记得去关。导出动作单独管控：申请单写明用途、字段、行数、去向，审批通过后由系统生成带水印的文件，下载行为进审计日志。日志要能回答「谁在什么时候取走了哪一批数据」，而不是只记录一句「导出成功」。
脱敏要分场景。展示层掩码（138****1234）和存储层加密是两件事，能看不等于能拿；测试环境不得使用生产明文，造数据要用合成或不可逆变换；应用日志、报错堆栈、埋点属性里不要顺手带上个人信息——第 2 篇写事件字典时，这一步就该拦住。用于跨系统匹配的场景，尽量用哈希或内部 ID 而不是明文。
治理资产要能被查。字段分级分类字典、表与字段的血缘、每张表的 owner、敏感字段的下游引用清单，这些平时像文档工作，出事时决定你能否在半小时内说清影响范围。我还会加一个和前面几篇一脉相承的东西：敏感字段使用情况的定期复核，把长期无人访问的授权收回来。
有个加分点很少有人提：同意不是一次性的。用户撤回授权、注销账号之后，已经派生出去的副本、离线文件、下游宽表里的对应行怎么处理，删除链路能不能真的走到尽头。只管「给不给」不管「收不收得回」，是很多治理方案最薄弱的一段。
边界的表达方式也是考点
最后一问我会追：「那你最后怎么回复业务方？」
我最不喜欢的两种，一种是硬邦邦的「不行」，另一种是「我去申请一下，应该没问题」——后者把风险含糊过去了。合格的回复是三句话：现在这版全量明文导出我不会直接给，原因是字段和范围超出了这次召回的需要；我这边有两个替代方案，分别能覆盖多少触达量和什么归因能力，今天可以给你评估；如果确实需要明文，走申请单，写清用途、范围、有效期和销毁方式，由指定角色审批后由平台侧执行。
这段话里没有一句价值观宣言，但边界、责任和推进路径都在。数据治理做到最后，考验的往往不是能不能拒绝，是能不能在守住边界的同时，把业务的事办成。
面对这类需求，我会先问清楚这次要触达多少人，再决定需要哪些字段。
评论