Campaign Standard：在設定檔中傳送記錄檔不相符
在極少數的情況下，Campaign Standard可以在實際上不屬於該設定檔的設定檔中顯示傳送記錄專案。 這可能會造成傳遞或電子郵件事件與收件者不正確關聯的印象，即使基礎資料庫記錄未損毀。 當收件者設定檔和測試設定檔在各自的來源表格中碰巧共用相同的內部識別碼值時，問題通常限於UI/查詢行為。
說明 description
客戶回報，真實收件者設定檔的「傳送記錄檔」檢視會顯示屬於個別測試設定檔的電子郵件事件。 有些顯示的事件發生在建立真實設定檔之前，這清楚說明記錄無法合法地屬於該收件者。
調查顯示：
- 真實設定檔和測試設定檔是獨立的實體，在功能上並無連結。
- 在出現非預期的記錄專案的受影響傳送中，實際收件者並非目標收件者。
- 真實收件者的追蹤資料保持不變。
- 主要在傳送記錄檔檢視和查詢預覽行為中觀察到了非預期行為，而不是作為廣泛資料庫汙染的證據。
- 這會造成客戶的混淆，因為UI指出傳送歷史記錄不準確，並引發報表和受眾分析可能受影響的疑慮。
解決方法 resolution
根本原因
此問題是由以下兩者之間罕見的內部ID衝突所造成：
- 儲存在設定檔/收件者資料集中的收件者設定檔，以及
- 儲存在種子成員資料集中的測試設定檔。
兩種設定檔型別都會將記錄檔資料寫入broadLogRcp表格，該表格會將相關的設定檔或測試設定檔識別碼儲存在相同的profileId欄中。 當收件者和測試設定檔剛好具有相同的內部ID值時，針對傳送記錄的查詢會傳回兩個實體的專案。
發生此狀況的原因：
- 新的收件者設定檔會從nmsRecipientId序列取得ID。
- 測試設定檔會從xtkNewId序列取得ID。
- 在此案例中，收件者是在其產生的ID碰巧符合現有的測試設定檔ID時建立的。
- 因此，UI和相關查詢路徑會擷取所有符合該內部ID的傳送記錄列。 由於UI中顯示的電子郵件地址是從傳送記錄位址欄位中取得，因此使用者可以在收件者的傳送記錄歷史記錄中看到測試設定檔電子郵件，即使基礎收件者資料本身並未混合或損毀。
工程部門將此評估為低機率的邊緣案例，而非可能會廣泛發生的問題。
解析度
建議的解析度選項包括：
- 刪除並重新建立受影響的測試設定檔。 這被視為更乾淨的更正動作，因為重新建立的測試設定檔會收到新的內部ID。 未來對該測試設定檔的傳送將不再出現在真正收件者的傳送記錄檔下。
- 必要時手動清除歷史傳送記錄列。 如果擔心歷史記錄可見性，可以手動移除與過時測試設定檔位址關聯的舊列。 只有在您想要消除已寫入的不相符歷程記錄，才能正常保留移除該歷程記錄時，才需要這樣做。
recommendation-more-help
experience-cloud-kcs-help-kbarticles