谁控制发送层？
先决定使用平台托管发送，还是企业自有的服务商账户。
比较之前
不要只比较当前套餐价格。
两种平台对成本、基础设施控制权和故障责任的组合方式不同，应使用真实旅程和预计联系人及发送规模进行评估。
成本随什么增长？
比较存储联系人、发送额度、add-on 和直接服务商费用。
谁来修改 customer journey？
检查角色、审批步骤以及对外部集成的依赖。
哪些内容需要重建？
联系人可以导出；journey、集成和历史数据需要分别评估。
运营模式对比
比较责任边界，而不仅是功能。
下表聚焦会直接影响日常工作和总体运营成本的差异。
决策维度
Mailchimp · 一体化平台
eMailBase · BYO SaaS
部署方式
Mailchimp 以 SaaS 形式同时管理应用和发送基础设施。
SaaS 应用连接由企业自行管理的发送服务商账户。
发送基础设施
发送层由 Mailchimp 运营；IP 选项和限制取决于当前套餐与资格。
可连接多个服务商，并按账户管理凭据、quota 和信誉。
成本与扩展
成本取决于套餐、存储联系人、发送额度和 add-on。
Workspace 定价与发送服务商直接收取的费用分开。
自动化
Customer Journeys 可由 audience、campaign、集成和 API 活动触发。
多分支 canvas 使用条件、等待、API 事件和邮件行为。
数据管理
Audience、tag、segment 和客户档案位于 Mailchimp 生态内。
档案、tag 和事件贯通 segmentation、automation 和报表。
访问控制
角色、席位和访问级别取决于账户套餐。
每个 workspace 可管理 Sub-users、role 和限定范围的 API key。
API 与集成
提供 Marketing API、webhook 和广泛的集成生态。
REST API 与 webhook 用于同步联系人、事件、campaign 和 workflow。
送达率运营
Mailchimp 运营发送基础设施，并提供域名认证指导。
企业保留服务商账户；eMailBase 集中展示 DNS、退信和服务商状态。
所有权与迁移
受支持的数据可导出；journey 和集成通常需要重建。
数据可导出且服务商账户仍归企业所有；automation 仍需重新梳理。
Mailchimp 的信息已参考 Mailchimp 帮助中心, 开发者文档. 功能、限制和价格可能调整，请在决策前再次核实。
结合场景作出选择
没有适合所有团队的唯一答案。
应根据希望平台代管的范围，以及团队需要保留的基础设施控制权作出选择。
你更看重一体化生态，并不想单独配置发送服务商。
- 希望同一供应商管理应用和发送层。
- 现有流程依赖 Mailchimp 集成。
- 按套餐计费适合预计规模。
你希望将营销软件与发送基础设施分离。
- 希望发送账户和发件信誉由企业掌控。
- 不同业务负载需要多条发送路线。
- 需要事件驱动 workflow 和更细的团队权限。
迁移计划
分层迁移，不要过早停用原系统。
所需时间取决于数据量、现有自动化、集成数量以及内部审批流程。
- 01
盘点
确认负责人、联系人、同意记录、抑制名单和正在运行的旅程。
- 02
连接
配置发送服务商、访问权限和所需的 DNS 记录。
- 03
重建与测试
先迁移一个高优先级 workflow，并验证触发器、退出条件和 webhook。
- 04
切换流量
待退信、退订和报表数据稳定后，再逐步提高发送量。
迁移常见问题
离开 Mailchimp 前需要确认的问题。
把迁移成本、历史数据和对现有生态的依赖一并纳入评估。
Mailchimp 将应用与发送基础设施打包提供；eMailBase 提供 SaaS 应用，同时允许企业连接并管理独立的发送服务商账户。
不应这样假设。请导出受支持的数据，梳理触发器、分支和等待时间，并在新平台逐一重建和测试。
使用相同的联系人规模、发送量、用户数和 add-on 需求，并把集成与运营投入计入。
建议先选择一个范围清晰的旅程和小规模 audience，待投递事件、退订和报表核对稳定后再扩大。
迁移前先验证
用真实 campaign 验证 BYO 模式。
连接一个发送服务商并导入小规模数据，在长期决策前比较 workflow、退信处理和报表。