在Web SDK中使用第一方裝置ID
Adobe Experience Platform Web SDK會使用Cookie將Adobe Experience Cloud ID (ECID)指派給網站訪客,以追蹤使用者行為。 若要解除瀏覽器對Cookie有效期的限制,您可以設定並管理您自己的裝置識別碼,稱為第一方裝置ID (FPID)。
先決條件 prerequisites
開始之前,請確定您已熟悉身分識別資料在Web SDK中的運作方式,包括ECID和identityMap
。 如需詳細資訊,請參閱網頁SDK🔗中身分資料的概觀。
第一方裝置ID格式需求 formatting-requirements
Edge Network只接受符合UUIDv4格式的ID。 不採用UUIDv4格式的裝置ID將會遭到拒絕。
- UUIDs是唯一的且隨機的,發生衝突的可能性微乎其微。
- UUIDv4無法使用IP位址或任何其他個人識別資訊(PII)進行內建。
- 用於產生UUIDs的程式庫可供各種程式語言使用。
使用您自己的伺服器設定FPID Cookie set-cookie-server
透過您自己的伺服器設定Cookie時,您可以使用各種方法防止Cookie因瀏覽器原則而受到限制:
- 使用伺服器端指令碼語言產生Cookie
- 設定Cookie以回應對子網域或網站上的其他端點發出的API請求
- 使用CMS產生Cookie
- 使用CDN產生Cookie
此外,您應該一律在您的網域的A
記錄下設定FPID Cookie。
document.cookie
方法設定的Cookie,幾乎永遠無法受到限制Cookie持續時間的瀏覽器原則的保護。何時設定Cookie when-to-set-cookie
最好在向Edge Network提出任何請求之前先設定FPID Cookie。 但是,在不可能的情況下,仍會使用現有方法產生ECID,並只要Cookie存在,就當作主要識別碼。
假設ECID最終受到瀏覽器刪除原則影響,但FPID未受到影響,則FPID將成為下次造訪的主要識別碼,並用於在每次後續造訪時設定ECID的種子。
設定Cookie的有效期 set-expiration
當您實作FPID功能時,應謹慎設定Cookie的到期日。 在決定此專案時,您應該考量貴組織營運所在的國家或地區,以及每個地區的法律和政策。
在此決定中,您可能會想要採用全公司的Cookie設定原則,或針對您營運所在地區設定中不同使用者的不同原則。
無論您為Cookie的初始過期時間選取的設定為何,都必須確保加入邏輯,以便在每次發生新的網站造訪時延長Cookie的過期時間。
Cookie標幟的影響 cookie-flag-impact
有各種Cookie標幟會影響Cookie在不同瀏覽器中的處理方式:
HTTPOnly
http-only
無法使用使用者端指令碼存取使用HTTPOnly
標幟設定的Cookie。 這表示如果您在設定FPID時設定HTTPOnly
旗標,則必須使用伺服器端指令碼語言來讀取要包含在identityMap
中的Cookie值。
如果您選擇讓Edge Network讀取FPID Cookie的值,設定HTTPOnly
旗標可確保任何使用者端指令碼都無法存取該值,但不會對Edge Network讀取Cookie的能力產生任何負面影響。
HTTPOnly
旗標並不會對可能限制Cookie存留期的Cookie原則造成影響。 不過,當您設定和讀取FPID的值時,還是應該考慮這個問題。Secure
secure
以Secure
屬性設定的Cookie只會以加密的要求透過HTTPS通訊協定傳送至伺服器。 使用此標幟有助於確保中間人攻擊者無法輕鬆存取Cookie的值。 可能的話,最好設定Secure
旗標。
SameSite
same-site
SameSite
屬性可讓伺服器判斷Cookie是否隨跨網站要求傳送。 屬性可針對跨網站偽造攻擊提供某些保護。 存在三個可能的值: Strict
、Lax
和None
。 請洽詢您的內部團隊,判斷適合您組織的設定。
如果未指定SameSite
屬性,某些瀏覽器的預設設定現在是SameSite=Lax
。
ID階層 id-hierarchy
當ECID和FPID同時存在時,ECID會優先識別使用者。 這可確保當瀏覽器Cookie存放區中存在現有的ECID時,仍會是主要識別碼,且現有的訪客計數不會受到影響。 對於現有的使用者,FPID在ECID過期或因瀏覽器原則或手動程式而被刪除之前,不會成為主要身分。
身分會依下列順序排定優先順序:
- ECID包含在
identityMap
中 - ECID儲存在Cookie中
- FPID包含在
identityMap
中 - FPID儲存在Cookie中
移轉至第一方裝置ID migrating-to-fpid
如果您要從先前的實施移轉至第一方裝置ID,可能很難在低層級視覺化轉換內容。
為了協助說明此程式,請思考先前曾造訪過您網站的客戶的案例,以及FPID移轉對Adobe解決方案中識別該客戶的方式有何影響。
ECID
Cookie一律優先於FPID
。使用第一方裝置ID (FPID) using-fpid
第一方裝置ID (FPIDs)會使用第一方Cookie來追蹤訪客。 使用使用DNS A記錄 (適用於IPv4)或AAAA記錄 (適用於IPv6)的伺服器(而非DNS CNAME或JavaScript程式碼)設定第一方Cookie時,其最有效。
設定FPID Cookie後,便可在收集事件資料時擷取其值並傳送至Adobe。 收集的FPIDs用於產生ECIDs,這是Adobe Experience Cloud應用程式中的主要識別碼。
您可以透過兩種方式使用FPIDs:
- 方法1:為您的Web SDK呼叫設定CNAME,並在資料流設定中包含FPID Cookie的名稱。
- 方法2:在身分對應中包含FPID。 如需詳細資訊,請參閱本檔案中有關在
identityMap
中使用FPID的下一節。
方法1:設定網頁SDK呼叫的CNAME,並在資料流中設定第一方ID Cookie setting-cookie-datastreams
若要從您自己的網域設定FPID Cookie,您必須為網頁SDK呼叫設定您自己的CNAME (正式名稱),然後在資料流設定中啟用First Party ID Cookie功能。
步驟 1.設定Web SDK部署網域 的CNAME
DNS中的CNAME記錄可讓您建立從某個網域名稱到另一個網域名稱的別名。 這可讓第三方服務看起來像是您自己的網域的一部分,因此其Cookie看起來像是第一方Cookie。
範例
假設您要在網站mywebsite.com
上實作Web SDK。 網頁SDK會將資料傳送至Edge Network至edge.adobedc.net
網域。
- 您的網站
mywebsite.com
使用Web SDK網域edge.adobedc.net
傳送資料給Edge Network。 - 由
edge.adobedc.net
設定的Cookie被視為協力廠商Cookie,因為它們並非來自您的mywebsite.com
網域。 根據您的使用者瀏覽器,第三方Cookie可能會遭到封鎖,且您的資料無法送達Edge Network。
- 您建立部署Web SDK的子網域,例如
metrics.mywebsite.com
。 - 您在DNS系統中設定CNAME記錄,使
metrics.mywebsite.com
指向edge.adobedc.net
。 - 當您的網站透過
metrics.mywebsite.com
設定Cookie時,在瀏覽器中,它們將顯示為來自mywebsite.com
(第一方)而非edge.adobedc.net
(第三方)。 這能降低第一方ID Cookie遭到封鎖的可能性,確保資料收集作業更加準確。
使用CNAME啟用第一方資料收集時,將會在對資料收集端點提出請求時傳送您網域的所有Cookie。
若要使用此功能,您必須將FPID Cookie設定在您網域的頂層,而非特定子網域。 如果您在子網域上設定它,Cookie值將不會傳送至Edge Network,且FPID解決方案將無法如預期運作。
步驟 2.為您的資料流啟用 第一方ID Cookie 功能
設定CNAME之後,您必須為資料流啟用 第一方ID Cookie 選項。 此設定可告知Edge Network在查詢第一方裝置ID時參考指定的Cookie,而不是在身分對應中查詢此值。
請參閱資料流設定檔案以瞭解如何設定資料流。
請參閱第一方Cookie的相關檔案,深入瞭解其如何使用Adobe Experience Cloud。
啟用此設定時,您必須提供預期儲存FPID的Cookie名稱。
UUID
。 使用第一方ID功能時,會產生ECID而不使用Visitor ID服務,因此無法同步第三方ID。使用第一方ID時,由於Audience Manager合作夥伴ID同步主要是以
UUIDs
或DIDs
為基礎,因此不支援在合作夥伴平台中啟用的Audience Manager功能。 衍生自第一方ID的ECID未連結至UUID
,使其無法定址。方法2:在identityMap
中使用FPID identityMap
除了將FPID儲存在您自己的Cookie中之外,您也可以透過身分對應將FPID傳送至Edge Network。
以下是如何在identityMap
中設定FPID的範例:
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-42d3-9456-426614174000",
"authenticatedState": "ambiguous",
"primary": true
}
]
}
}
與其他身分型別一樣,您可以在identityMap
中包含FPID與其他身分。 以下是已驗證CRM ID所包含的FPID範例:
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-42d3-9456-426614174000",
"authenticatedState": "ambiguous",
"primary": false
}
],
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
如果FPID包含在啟用第一方資料收集時Edge Network正在讀取的Cookie中,您應該僅擷取已驗證的CRM ID:
{
"identityMap": {
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
下列identityMap
會導致Edge Network的錯誤回應,因為它遺失FPID的primary
指標。 在identityMap
中出現的最後一個ID必須標籤為primary
。
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-12d3-a456-426614174000",
"authenticatedState": "ambiguous"
}
],
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated"
}
]
}
}
在此情況下,Edge Network傳回的錯誤回應將類似於以下內容:
{
"type": "https://ns.adobe.com/aep/errors/EXEG-0306-400",
"status": 400,
"title": "No primary identity set in request (event)",
"detail": "No primary identity found in the input event. Update the request accordingly to your schema and try again.",
"report": {
"requestId": "{REQUEST_ID}",
"configId": "{CONFIG_ID}",
"orgId": "{ORG_ID}"
}
}
常見問題集 faq
以下是有關第一方裝置ID常見問題的解答清單。
植入ID和單純產生ID有何不同?
內建概念是唯一的,因為傳遞至Adobe Experience Cloud的FPID會使用確定性演演算法轉換為ECID。 每次將相同的FPID傳送至Edge Network時,相同的ECID都是從FPID內建的。
何時應該產生第一方裝置識別碼?
若要降低訪客可能的膨脹率,應先產生FPID,再使用網頁SDK提出您的第一個要求。 不過,如果您無法執行此動作,仍會為該使用者產生ECID,並將作為主要識別碼使用。 產生的FPID不會成為主要識別碼,直到ECID不再存在為止。
哪些資料收集方法支援第一方裝置ID?
目前只有Web SDK支援第一方裝置ID。
第一方裝置ID是否儲存在任何Platform或Experience Cloud解決方案上?
一旦使用FPID來植入ECID,就會從identityMap
中捨棄該專案,並取代為已產生的ECID。 FPID未儲存在任何Adobe Experience Platform或Experience Cloud解決方案中。