目的地啟用工作流程中的身分處理

此頁面說明身分識別如何匯出至不同目的地型別的特殊性，並教導您如何根據目的地找到哪些身分識別可供匯出。

目錄中的每個目的地都略有不同，因此沒有針對所有目的地進行一刀切的設定。 不過，有一些模式可指導目的地的設定及其身分需求，如下節所述。

以檔案為基礎的目的地 file-based

針對以檔案為基礎的目的地 （例如Amazon S3、SFTP、大部分的電子郵件行銷目的地，例如Adobe Campaign、Oracle Eloqua、Salesforce Marketing Cloud），這些目的地中的身分設定大多是開啟的，這表示您不需要在批次啟用工作流程的選取屬性步驟中選取任何身分。

如果您選擇將身分新增至檔案匯出，請注意，在匯出中只能選取身分名稱空間中的單一身分。 當您選取要匯出的身分時，會自動選取它作為必要屬性和重複資料刪除索引鍵。

作為因應措施，如果這些身分已作為屬性擷取到Experience Platform中，則可以將更多身分新增到匯出。 請參閱以下範例，其中除了身分名稱空間Phone_E.164之外，還選取要匯出的XDM屬性電子郵件地址。

從身分對應匯出身分與將身分匯出為XDM屬性 — 差異 identity-map-or-attribute

根據您是從身分對應中選取匯出身分識別，還是從已當作屬性擷取到Experience Platform中的身分識別，匯出記錄的數目可能有所不同。 當您從身分對應選取身分時，合併原則在匯出的記錄數目中也扮演重要角色。

例如，假設您從兩個不同的資料集中有下列設定檔片段，這些片段將合併到單一客戶設定檔中：

設定檔片段一

設定檔片段二

合併的設定檔如下所示：

匯出行為會因您選取匯出IdentityMap: Email或xdm: personalEmail.address而有所不同。

如果客戶啟用IdentityMap: Email，匯出的檔案中將有兩個記錄，一個用於email1，另一個用於email2。

但是，如果客戶啟用xdm: personalEmail.address，則記錄中只會出現email2，因為email attribute欄位只包含email2。 這些情況可以解決不同的使用案例，您可能會想要啟用某個客戶檔案中的所有電子郵件地址，或僅啟用該客戶檔案中最新的電子郵件地址。

結果是，您匯出的記錄數量取決於您選擇的合併原則，以及您在匯出中是否選取身分或屬性。

API型串流目的地 streaming-destinations

🔗以Destination SDK建置的API型串流目的地 （例如Facebook、Google Customer Match、Pinterest、Braze及其他）只支援匯出的特定ID。 如需可匯出至每個目的地的特定身分詳細資訊，請閱讀每個目的地檔案頁面中的​ 支援的身分 ​區段（例如，請參閱Pinterest目的地頁面中的支援的身分割槽段）。

但是請注意，您可以彈性地使用來自私人圖形或屬性中的資料做為身分。 這表示您可以將XDM屬性對應至目的地所需的身分欄位。 請參閱以下的Pinterest目的地範例，其中XDM屬性personalEmail.address對應到必要的Pinterest身分pinterest_audience。

依賴協力廠商Cookie整合的Advertising目的地 third-party-cookie-destinations

依賴第三方Cookie的Advertising目的地（例如： Google Ads、Google Ad Manager、Google DV360、Bing、The Trade Desk）不需要客戶在啟用工作流程中選取ID。 對於這些目的地，在設定啟用工作流程時，Experience Platform會自動尋找由Experience CloudID服務建構的身分比對資料表，並匯出所有適用於設定檔且受目的地支援的身分。

這些目的地需要透過Experience CloudID服務或Experience PlatformWeb SDK進行ID同步。

如果您使用Experience PlatformWeb SDK，但頁面上未實作舊版Experience CloudID服務，則您必須確保已啟用相關網站的資料流，以允許同步協力廠商ID，如設定資料流檔案中所述。

如上述連結的檔案所述，在設定資料串流時，您必須確定已啟用​ 協力廠商ID同步 ​滑桿。 大部分客戶會將container_id欄位保留空白（預設為0）。 如果您的舊版Audience Manager實作使用特定容器ID （但請注意，這將是極少數的客戶），則您只需變更此值。

企業目的地 enterprise-destinations

Enterprise目的地 (Amazon Kinesis、Azure Event Hubs、HTTP API)不需要資料匯出中的特定ID，因為這些是專為企業整合使用案例所設計。 不過，您可以視需要從身分對應將身分匯出為XDM屬性或來自身分對應。 檢視匯出至HTTP目的地🔗的資料範例，其中包含personalEmail.address XDM屬性，以及身分對應中的身分ECID和email_lc_sha256 （雜湊電子郵件地址）。

Personalization目的地 personalization-destinations

Personalization （或edge）目的地 (例如：Adobe Target、Custom Personalization)不需要在啟用工作流程中選擇任何身分，因為整合是設定檔查詢。 使用者端（Target、Web SDK或其他）會查詢Edge，並提取它需要的設定檔資訊以進行站上個人化。

後續步驟 next-steps

閱讀本檔案後，您現在瞭解如何找出個別目的地支援或所需的身分識別。 您現在也知道身分選取如何適用於每個目的地型別。

接下來，您可以閱讀目的地型別中哪些匯出設定是共有的、開發人員可以在個別目的地層級進行設定，以及使用者可以在啟動工作流程中編輯哪些設定。

您也可以簽出目錄中的所有可用目的地。