联系人与同意

一份经得起追问的名单，而不只是一份你拥有的名单

任何人都能存下一万个电子邮件地址。真正重要的问题——监管机构、服务商和你自己的良知会用略有不同的措辞问出的那个问题——是每个地址从何而来，以及你凭什么可以给它写信。ClickSomo 把这一点变成已存储的事实，而不是需要你事后重建的东西。

身份即电子邮件地址

每个地址、每个项目仅一个联系人，由数据库强制保证，而不是靠运气。地址在写入时规范化，而不是在读取时——若在读取时规范化，这条约束就只是个摆设，会让 Anna@ 和 anna@ 同时混进来。

电话号码存在时以 E.164 格式存储，但电话号码是属性，不是身份。这里没有身份解析图，没有合并协议，也没有合并的审计记录，因为每个联系人都来自一个本身已带有地址的渠道：导入、表单、订阅，或你自己的代码。

display_name 按原样保存，从不拆分成部分。拆分姓名是 bug 工厂——"van der Berg"、"Kim Min-jun"、单名、头衔，以及一切非英语的姓名顺序约定——而拆错的名字会以 "Dear van," 的形式出现在合并标签里，这比完全不个性化还糟。

结构化的姓名部分只存在于本身已分开提供它们的来源。任何东西都不会推导它们。而且某人自己输入的姓名绝不会被后来碰巧观察到不同信息的 CSV 覆盖，因为“最后写入者胜”会让最马虎的导入获胜。

一个联系人保存的内容

同时限定于租户和项目

同意台账

每个联系人每个渠道一行——电子邮件、短信、信件、推送——每行携带一个状态、一个合法依据、一个来源、证据、时间戳和司法辖区。某渠道没有依据行的联系人，在该渠道上不能被发送任何东西。不是“被标记”。是不能。

有人主动提出。一次表单提交并保存了证据、一次双重确认、一个他们自己勾选的复选框。这是最强的依据，也是表单唯一能产生的依据。

CSV 导入所能达到的最好结果。电子表格无法记住某人同意过什么，因此绝不允许它声称对方同意过——重新上传同一个文件也不会升级它。

你给他们写信是因为你们双方都参与其中的某件事。服务提醒、续订通知，那种收不到反而会恼火的东西。

在活动发送之前，你会看到其受众的依据构成：这些人中有多少是主动同意的，有多少是在合法利益下触达的，有多少是基于合同。这一个数字阻止掉的糟糕发送，比任何警告横幅都多。

为什么这对你来说比必要的更严格：这其实不是针对你。批量发送的信誉是共享资源，一个粗心的列表会毒害同一基础设施上所有发送者的水源。每个租户的投诉率和退信率都受到监控，超过阈值的账户会在这里被限速——在服务商对所有人一锅端之前。

四种入口

没有服务令牌的摄取通道，也没有兄弟产品悄悄写入你的联系人。如果你想把某人加进列表，是这四条路径之一把他们放进去的。

逐列映射，写入时规范化，做 MX 检查以便在硬退信之前发现失效和拼错的域名，并以你明确设置的依据落地。导入会获得一个 ID，它创建的每个联系人都指向这个 ID。

与其他一切由同一文档渲染，带验证、蜜罐和速率限制。一次提交是唯一能合法产生 consent 的路径，因为它是唯一本人就在场的路径。

仪表盘设计器发布页面；页面上的表单以你自己的凭据提交到这里。同样的验证，同样的同意处理，无需维护第二个集成。

使用你自己的 token 调用 POST /v1/contacts，采用 upsert 语义，支持幂等键。你的应用已经知道谁注册了；这是从这一事实通往漏斗的最短路径。

细分是一棵存储下来的谓词树，覆盖联系人的字段、属性、标签、列表归属和行为，编译为 SQL 并连同计数一起缓存。运算符都是常见的——等于、不等于、属于、不属于、以…开头、以…结尾、包含、已设置、未设置——并用 and、or 和 not 以任意深度组合。

使用前先预览。该端点返回真实的联系人，所以“究竟有谁在里面”这个问题靠看就能回答，而不是发出去之后才知道。

细分随后身兼数职：作为营销活动的受众、作为漏斗分支上的条件，也作为独立的触发器——segment_enter 会在某人符合条件的那一刻启动一次运行。

安静的常客细分预览 · 412

编译为 SQL计数已缓存，答案实时

抑制是项目级和全局的：硬退信、投诉、退订、手动条目和角色地址。它们会在发送时被检查，然后在发送服务内部再检查一次。

第二次检查才是关键。一个包含三天等待的漏斗，意味着有三天的时间窗口，期间某人可能退订；而一个在消息入队时检查抑制的系统照样会把邮件发给他们。在发送时检查，是尊重退订与只是记录退订之间的区别。

删除也是同样的方式：删除请求会在这里移除联系人及其消息历史，并通过家族其他成员共用的同一条内部通道，送达每一个持有副本的兄弟服务。只需在一个地方提出请求，也只发生一件事。