数据处理协议：更换供应商时会有哪些变化
更换位置数据供应商不只是一个技术决定。下面介绍在迁移过程中，数据处理和隐私方面需要审查的内容。
将 Zapier 或 Make 自动化流程迁移到新的地理编码主机
在 Zapier 或 Make 中构建的自动化，常常在一个更大的工作流中嵌入一个地理编码步骤：新的潜在客户通过表单进入，其地址经过地理编码以检查区域分配，结果再触发链条下游的路由决策。这些工作流常常由没有软件工程背景的人构建，使用的是平台当时提供的某个预构建应用连接器或通用 HTTP 模块，这使得迁移的实际情况与自定义代码库相比有所不同。
如果您当前的地理编码步骤使用的是专用应用连接器，即 Zapier 或 Make 专门为相关提供商构建的第一方集成，那么迁移到没有同等专用连接器的提供商，就意味着要把该步骤改为通用 HTTP 或 webhook 模块，并将其配置为直接调用新提供商的 API。这是自动化构建方式上的真正改变，而不仅仅是更换凭据，值得在触碰企业其他部分所依赖的线上生产自动化之前，先在隔离的测试场景中彻底测试替换步骤。
进行这一切换的具体步骤：
- 在平台的构建器中复制现有的自动化，而不是就地编辑，这样在替换版本完全测试好之前，可用的版本会继续运行
- 用通用 HTTP 模块替换地理编码步骤，并配置新提供商的端点和认证，因为查询参数密钥或
Authorization: Bearer请求头（这里两者都支持）在通用 HTTP 模块中配置起来都很简单，不需要专用连接器 - 在自动化的数据映射步骤中手动映射响应字段，因为通用 HTTP 模块返回的是原始响应数据，需要明确映射到自动化后续步骤所期望的字段，而专用连接器通常会自动完成这种映射
- 用一系列真实输入进行测试，包括不完整的地址或不寻常的格式等边缘情况，因为在无代码工具中，“代码”本身不像脚本那样可以被查看和审阅，这类测试恰恰很容易被跳过
- 将触发器从测试版本切换到复制并验证过的自动化，并且只有在确认新版本已在实时数据上正确运行一小段时间之后，才停用原来的版本
由于兼容主机会重现熟悉的提供商的确切响应结构，如果您原有自动化的地理编码步骤调用的提供商在这里恰好有对应的兼容主机，那么上面第 3 步中的字段映射可能与您原来的连接器内部使用的映射非常相似，这可以显著缩短此次迁移。兼容主机的完整列表见 /compatibility/，在认定必须从零开始映射字段之前，值得先查看一下。
对于业务关键型自动化，在副本中测试而不是直接在线上编辑，这份额外的谨慎值得那一点额外的设置时间，因为出了故障的潜在客户路由自动化往往会很快被发现，而且发现者往往是技术团队以外的人。