Campaign Standard：在配置文件中发送日志不匹配
在极少数情况下，Campaign Standard可以在实际上不属于该配置文件的配置文件中显示发送日志条目。 这会造成这样一种印象：投放或电子邮件事件与收件人关联不正确，即使基础数据库记录未损坏。 当收件人用户档案和测试用户档案在各自的源表中共享相同的内部标识符值时，问题通常限于UI/查询行为。
描述 description
一位客户报告说，真实收件人用户档案的“发送日志”视图显示了属于单独测试用户档案的电子邮件事件。 某些显示事件发生在创建真实用户档案之前，这清楚地表明记录不能合法地属于该收件人。
调查显示：
- 真实配置文件和测试配置文件是独立的实体，在功能上并无关联。
- 在出现意外日志条目的受影响投放中，实际收件人并非目标受众。
- 对于实际收件人，跟踪数据保持一致。
- 主要在发送日志视图和查询预览行为中发现意外行为，而不是作为广泛数据库污染的证据。
- 这给客户带来了困惑，因为UI表明投放历史记录不准确，并引发了对报告和受众分析可能受到影响的担忧。
解决方法 resolution
根本原因
此问题是由以下对象之间罕见的内部ID冲突引起的：
- 存储在用户档案/收件人数据集中的收件人用户档案，以及
- 存储在种子成员数据集中的测试用户档案。
两种配置文件类型都将日志数据写入broadLogRcp表，此表将相关的配置文件或测试配置文件标识符存储在同一个profileId列中。 当收件人和测试用户档案刚好具有相同的内部ID值时，对发送日志的查询会返回两个实体的条目。
为什么会出现这种情况：
- 新的收件人配置文件从nmsRecipientId序列获取ID。
- 测试配置文件从xtkNewId序列获取ID。
- 在本例中，创建收件人的时候，恰好是它生成的ID与现有的测试用户档案ID匹配。
- 因此，UI和相关查询路径会检索与该内部ID匹配的所有发送日志行。 由于UI中显示的电子邮件地址来自发送日志地址字段，因此用户可以在收件人的发送日志历史记录中看到测试用户档案电子邮件，即使基础收件人数据本身并未混合或已损坏。
Engineering将此评估为概率较低的边缘案例，而不是一个可能会广泛重现的问题。
分辨率
建议的解决方法选项包括：
- 删除并重新创建受影响的测试用户档案。 这被视为更干净的更正操作，因为重新创建的测试用户档案会收到新的内部ID。 将来对该测试用户档案的投放将不再显示在实际收件人的发送日志下。
- 如果需要，手动清除历史发送日志行。 如果涉及历史日志可见性，则可以手动删除与过时的测试配置文件地址关联的旧行。 只有在您想要消除已写入的不匹配历史记录，然后正常保留删除它时，才需要这样做。
recommendation-more-help
experience-cloud-kcs-help-kbarticles