客户同步

Tajo 通过两种方式把客户数据送入 Brevo：持续同步（已连接平台的变更源源不断流入 Brevo）和批量迁移（从 Mailchimp、Klaviyo、HubSpot、Salesforce、Shopify、WooCommerce、Stripe 等平台进行满负荷、可断点续传的迁移）。两者跑在同一套引擎上，并共享一条没有商量余地的性质：同意要逐条记录被证明，绝不被假定。

同意如何判定

每条记录在进入营销受众之前，都要先通过一道 fail-closed 的同意闸门：

判定	会发生什么
同意已被证明（例如 Mailchimp 的 `subscribed`、Klaviyo 的 `SUBSCRIBED`、Shopify 的营销同意）	导入到你选择的 Brevo 列表中
明确拒绝（已退订、已选择不接收）	不会被丢弃：会作为黑名单联系人带入 Brevo，并记入禁止联系名册，因此新平台绝不会给他们发信
因送达能力被抑制（硬退信、垃圾邮件投诉，例如 Mailchimp 的 `cleaned`、Klaviyo 的 `HARD_BOUNCE`/`SPAM_COMPLAINT`）	同样作为黑名单带过去，并标记为粘性：日后在另一个平台上的选择接收，绝不会解除一次退信或投诉
未被证明（完全没有同意信号）	拒绝。“我们无法证明同意”和“存在同意”永远不是同一个结论

“拒绝”和“未被证明”的区别很重要：一次退订是必须在迁移中存活下来的决定；而一个缺失的字段根本算不上决定。

各平台的同意来源

平台	同意证据	抑制信号
Mailchimp	成员状态 `subscribed`	`unsubscribed`（选择不接收）、`cleaned`（硬退信）
Klaviyo	档案上的营销同意 `SUBSCRIBED`	带原因的抑制列表（`UNSUBSCRIBE`、`USER_SUPPRESSED`、`HARD_BOUNCE`、`INVALID_EMAIL`、`SPAM_COMPLAINT`）
Shopify	`email_marketing_consent.state` / `accepts_marketing`	明确的 `not_subscribed`
HubSpot	订阅状态（批量 API，每次调用 100 个联系人）	`hs_email_optout`
Salesforce	无法从 Sales Cloud 批量证明，身份可以迁移，但受众入组保持关闭	`HasOptedOutOfEmail`、`EmailBouncedDate`
WooCommerce / Stripe	不从购买行为推断，一条客户记录不等于营销同意	无

迁移过程中的冲突解决

当来源与 Brevo 对同一个地址的判断不一致时，按你选择的模式解决：

最新决定胜出（默认）：同意决定带有更新时间戳的一方胜出。没有可解析时间戳的一方，永远输给有时间戳的一方；两边都没有时间戳时，可触达程度更低的状态胜出。
事实来源：由你为本次迁移指定权威平台（“以来源为准”或“以 Brevo 为准”）。如果你的工作区已经声明了记录系统，该平台会自动成为默认权威。
在所有模式下：硬退信和垃圾邮件投诉是送达能力的事实，而不是偏好；它们绝不会因为一次更新的选择接收而被解除抑制，而且引擎拒绝处理的每一个冲突都会被计数并报告，绝不会被悄悄跳过。

满负荷下的可靠性

基于游标的抽取会带着检查点走完整张来源表（10 万以上联系人）；崩溃后从最后一个完成的批次恢复，重试也绝不会重复写入（每条记录都有幂等键）。
写入 Brevo 使用批量导入 API（每块 10,000 个联系人），并处在 Brevo 的速率限制之内；抑制状态随导入一起送达，因此不存在“先可触达、后被抑制”的窗口。
每次运行都会报告哪些动了、哪些没动：已导入的联系人、带过去的明确拒绝、已传播的抑制、被搁置的冲突，以及每条记录的失败原因。

迁移之后同步带来什么

迁移完成后，同样这些连接会让 Brevo 保持最新：平台 webhook（Shopify、WooCommerce、WordPress、Mailchimp）近乎实时地送来变更，轮询型来源则按计划刷新。在来源侧观察到的退订会翻转账本中的同意状态，并留下何时、来自何处、依据什么证据的审计轨迹。

配置

在 Tajo 中连接来源平台（按连接器使用 API key 或 OAuth）。
连接 Brevo 并选择目标列表。
选择冲突解决模式（或采用默认值）。
运行迁移；在启用自动化之前，先查看报告，其中包括被搁置的冲突。

同意与抑制的处理无法通过配置关闭。没有任何设置能把已退订的联系人当作可发信联系人导入。