設定 Analytics 和 Experience Cloud ID

Experience Cloud Identity Service 會取代舊有的 Analytics 訪客 ID 方法。

實作 ID 服務後，此程式碼會在 AppMeasurement 之前執行。ID 服務會擷取 Experience Cloud 和 Analytics ID，因此在 AppMeasurement 載入時，就已有這些值。

當 AppMeasurement 載入時，將會從 ID 服務請求 Experience Cloud 和 Analytics ID 值，並透過每個伺服器呼叫將其傳送至資料收集。由於 ID 服務會判斷訪客 ID，並直接將其傳至 AppMeasurement，因此您必須每個頁面上納入 ID 服務，並在 AppMeasurement JavaScript 檔案之前加以實作。

Analytics ID程式的變更

移轉至 Experience Cloud ID 服務時的主要變更，是現在使用 JavaScript 設定 ID Cookie，而不是使用從資料收集網站伺服器傳回的 HTTP 標題。為了讓您了解這項變更，以下幾節將說明如何使用這兩種方法來設定 Cookie。

HTTP 標題

來自網頁伺服器的 HTTP 回應會在瀏覽器中設定 Cookie。這是 s_vi Cookie 設定的方法。s_vi Cookie 可識別 Analytics 訪客。Cookie 設定後，便會隨所有後續 HTTP 請求傳送給該伺服器。

當請求傳送至 Adobe 資料收集伺服器時，會檢查標題中是否有 s_vi Cookie。如果請求中有此 Cookie，便會用來識別訪客。如果請求中沒有 Cookie，則伺服器會產生獨特 Experience Cloud ID、在 HTTP 回應標題中將其設定為 Cookie，並隨請求將其傳回。Cookie 會儲存在瀏覽器中，並在後續有人造訪網站時傳回至資料收集伺服器。如此，即可在訪客每次造訪時識別訪客。

不過，有些瀏覽器 (例如 Apple Safari) 不接受第三方 Cookie。這些 Cookie 是在瀏覽器中，從不同於現行網站的網域設定的。此外，如果訪客之前未造訪過該網域，Safari 也會封鎖第三方網域上的 Cookie。例如，如果您位於 mysite.com 而您的資料收集伺服器是 mysite.omtrdc.net，則瀏覽器可能會拒絕從 mysite.omtrdc.net HTTP 標題中傳回的 Cookie。

為了避免此情況，許多客戶已針對其資料收集伺服器實作 CNAME 記錄。此時，第三方 Cookie 實作策略就有機會派上用場。如果已設定 CNAME 記錄將客戶網域的主機名稱對應至資料收集伺服器 (例如，將 metrics.mysite.com 對應至 mysite.omtrdc.net)，因為資料收集網域現在符合網站的網域，所以可以儲存 Experience Cloud ID Cookie。儲存 ID 服務 Cookie 的可能性會因此而提高。但這會產生一些額外負荷，因為您必須設定 CNAME 記錄，並維護資料收集伺服器的 SSL 憑證。

JavaScript

JavaScript 可讀取和寫入在第一方網域 (現行網站的網域) 中設定的 Cookie。Experience Cloud ID 服務會使用此方法來設定包含所有訪客 ID 的 AMCV_###@AdobeOrg Cookie，使追蹤伺服器的網域不再需要符合網站的網域，即可儲存訪客 ID Cookie。在大多數情況下，這會是您設定 ID 服務 Cookie 時應優先採用的方式，因為可以避免 CNAME 記錄和 SSL 憑證的額外負荷。