同步受众成员关系
使用数据仓库、CRM 或应用程序决定人群包含哪些人，然后将选择结果应用到 Bird 受众。已发布的受众 API 存储静态成员关系。此集成模式使成员关系与评估您所设条件的源系统保持一致，无需在发送流程中另建一套规则。
开始之前
您需要一个有名称的 Bird 受众、相应的联系人记录，以及文档所述受众操作的访问权限。确定哪个源系统负责选择人群，以及谁可以更改选择条件。在对营销活动受众运行集成之前，先使用一个小型测试人群。
记录纳入条件、排除项和评估时间。对于下周续订的客户群体，请指定时区，以及源系统记录续订完成后如何处理。选择结果必须具有足够的可复现性，以便调查意外出现的成员。
确定所选记录对应的联系人
- 获取源系统的结果，并在集成中记录其评估时间或修订版本。
- 通过批量联系人操作创建或更新相应的 Bird 联系人。明确选择如何使用源标识符进行匹配。
- 检查每个条目的结果。在集成的核对记录中保留其源 ID 和得到的 Bird 联系人 ID。
- 在将某个人视为已同步之前，先解决标识符冲突。包含成功条目的请求仍可能包含失败条目。
将记录添加到已知受众时，联系人批次接受 audience_ids。适用时可用它添加成员；移除成员仍需要单独做出成员关系决定。导入中没有包含某个人，并不表示要将其移出受众或删除其联系人记录。
核对并处理新增和移除的成员
通过列出受众的联系人读取现有成员关系，并按照分页逐页获取。将 Bird 联系人 ID 与已确定对应联系人的源选择结果进行比较。
| 差异 | 操作 |
|---|---|
| 源系统已选中，受众中不存在 | 将联系人添加到受众 |
| 受众中存在，源选择结果中不存在 | 如果源系统负责管理该受众，则移除成员关系 |
| 两者中均存在 | 保留成员关系 |
| 未能确定源记录对应的联系人 | 完成刷新前进行调查 |
不要仅因源导出不完整就移除某个人。在计算要移除的成员之前，确认源选择结果完整，包括最后一页。也应避免在集成负责管理的受众中进行无关的手动成员关系编辑，除非您有明确的策略来保留这些编辑。
完成刷新
根据差异应用更改后，检查失败的操作，并重新读取受影响的成员关系。当成员关系与预期的源选择结果一致时，将刷新标记为完成。在集成中存储结果，使下次运行能够区分已完成的刷新和中断的刷新。
如果流程中途停止，请从已记录的工作继续，或根据当前受众重新计算差异。添加已有成员会保持原有成员关系。移除成员会改变该受众的成员关系，联系人记录和同意状态不受影响。
在自动重放结果不确定的请求之前，重新检查该操作当前的幂等性和响应约定。请求被接受、各条目的结果和最终核对结果应分别观察。
将受众用于发送
在相应的营销活动流程中使用已完成的选择结果。记录受众上次刷新的时间，并在发送前检查广播当前的估计值。成员关系刷新后，联系人详情、偏好和屏蔽记录仍可能发生变化。
对于电子邮件广播，估计范围会从总成员数缩小到有地址的成员，再缩小到可发送的成员。最终投递结果需要单独观察。分析结果时，将源人群、发送上下文和业务结果定义放在一起。
故障排查
- 意外移除成员： 检查源导出是否不完整，或是否有另一个写入方在更改同一受众。
- 每次运行都出现同一个失败的联系人： 解决源标识符冲突或无效属性问题，不要一直默默跳过。
- 离开分群后仍保留在受众中： 确认您的集成既执行添加，也执行移除。
- 可发送人数较少： 检查地址、偏好和屏蔽记录，无需再次添加人员。