重新導向選件 - A4T 常見問題集
此主題包含使用Adobe Analytics做為Adobe Target (A4T)的報表來源時，經常詢問關於重新導向選件問題的回答。
Analytics for Adobe Target (A4T)支援重新導向選件嗎？ section_46B8B03ED4D542C6AD875F5F61176298
搭配A4T使用重新導向選件有何最低需求？ section_FA9384C2AA9D41EDBCE263FFFD1D9B58
您的實作必須符合下列最低需求：
- Experience Cloud 訪客 ID 服務: visitorAPI.js 版本 2.3.0 或更新版本。
- Adobe Analytics: appMeasurement.js 版本 2.1。
- Adobe Target: at.js 版本 1.6.2 或更新版本。
含有重新導向選件的頁面和訪客重新導向的頁面上，皆必須包含這三個程式庫。
為何 A4T 與 Analytics 之間有時會有資料差異?
在 A4T 活動中使用重新導向優惠方案時，如何將流量分佈的差異減至最低？ discrepancies
在設定Analytics for Target (A4T)的活動中使用重新導向選件時，有限數量的客戶報告流量分佈的差異程度較高。
考慮以下事項：
-
Target和Analytics呼叫順序不正確可能會導致較高的變異程度。
Target呼叫必須在來源頁面（其中發生重新導向）和目的地頁面（其中重新導向結束）上的Analytics呼叫之前。
-
請務必在A4T重新導向活動中使用重新導向選件。
-
如果來源頁面上有多個Target位置要求（發生重新導向），Adobe建議您對第一個Target位置要求執行重新導向活動。
在前Target個位置要求上執行重新導向活動，可減少其他Target個位置要求上發生任何活動資格並被計入報表中的機會。 被重新導向的訪客不需要計入其他活動的報表中，因為他們看不到體驗。
為何有時會統計原始頁面和重新導向頁面上的頁面檢視? section_B8F6CC2190B84CF08D945E797C5AF07B
使用at.js 1.6.3版或更新版本時，計算兩個頁面上的頁面檢視次數並不是問題。 此競爭條件只會影響使用舊版本的客戶。Target 團隊會維護兩個版本的 at.js: 最新版本和次新版本。請視需要升級at.js，以確保您執行的是支援的版本。
如果您使用不支援的較舊 at.js 版本，可能會發生競爭條件，而可能導致 Analytics 呼叫在重新導向於第一個頁面上執行前引發。此情況可能會導致計算原始頁面和重新導向頁面上的頁面檢視次數。 此情況導致第一頁有額外的頁面檢視，使訪客從未真正「看過」這第一頁。
由於程式碼在頁面上的執行位置，建議使用表單式撰寫器建立重新導向活動，以提高頁面重新導向的速度。 另外，對於重新導向會傳回原始頁面的每個體驗，即使是預設體驗，也最好建立重新導向選件。為每個體驗建立重新導向選件，可確保在發生錯誤計數時，它會在所有體驗中發生。 報告和分析對測試仍然有效。
您可能想要將重新導向選件用於活動中的所有體驗 (包括預設 (控制) 體驗) 的一個原因是，想要對所有體驗設定相同的條件。例如，如果預設體驗沒有重新導向選件，但其他體驗有重新導向選件，沒有重新導向選件之體驗的速度會有沿用的優勢。建議僅將重新導向選件用於臨時案例，例如測試。不建議將重新導向選件用於永久案例，例如個人化。決定「獲勝者」後，您應移除重新導向以改善頁面載入效能。
可視化體驗撰寫器 (VEC) 和表單式體驗撰寫器皆有支援嗎? section_FDA26FE7909B48539DA770559E687677
是的，只要您使用內建的重新導向選件，這兩種撰寫器就皆支援。
如果使用您自己的自訂程式碼，務必填入與重新導向 URL 相關的兩個新參數 (adobe_mc_sdid 和 adobe_mc_ref，說明如下)。
有哪些新的查詢字串參數加入重新導向 URL 中? section_BA73E8B3CFCC4CBEB5BE3F76B2BC8682
下列查詢字串引數已與重新導向選件相關聯：
| table 0-row-2 1-row-2 2-row-2 | |
|---|---|
| 參數 | 說明 |
adobe_mc_sdid |
adobe_mc_sdid引數會將補充資料ID (SDID)和Experience Cloud組織ID從預設頁面傳給新頁面。 這些ID允許A4T將預設頁面上的Target要求與新頁面上的Analytic要求「拼接」起來。在URL中傳遞sdid （針對混合式應用程式或從一個應用程式傳遞至網站或從一個網站傳遞至另一個網站）的預期格式為`ex. adobe_mc_sdid=SDID=123 |
adobe_mc_ref |
adobe_mc_ref 參數會將預設頁面的轉介 URL 傳給新頁面。與AppMeasurement.js 2.1版（或更新版）一起使用時，Analytics會在新頁面上將此引數值當作轉介URL。 |
在 VEC 和表單式體驗撰寫器中使用重新導向選件，且頁面上實作訪客 ID 服務時，這些參數會自動加入重新導向 URL 中。如果在 VEC 和表單式撰寫器中使用您自己的自訂重新導向程式碼，務必隨著自訂程式碼傳遞這些參數。
我的 Web 伺服器從 URL 中刪除這些參數，怎麼辦? section_0C2DDB72939F4875B6D0428B8DCB38E5
adobe_mc_sdid和adobe_mc_ref）加入允許清單。如果不使用 A4T 來處理重新導向活動，且不想在 URL 中多出這些額外的參數，怎麼辦? section_9E608D75FF9349FE96C65FEDD7539F45
使用自訂編碼重新導向，如果：
- 您沒有使用A4T來處理重新導向活動
- 您已實作訪客ID服務
- 您不希望這些引數自動新增至URL
然而，最佳作法是在 URL 中保留 adobe_mc_ref 參數，才能正確地向 Analytics 報表轉介者資訊。
在我的實作中，adobe_mc_ref和adobe_mc_sdid引數為何經過兩次URL編碼？ section_5EFE5F012B944C40865731EA18E7E79E
如果您使用A4T和重新導向選件，Target會將adobe_mc_ref和adobe_mc_sdid引數附加至URL。 這些值皆已完成 URL 編碼。一切通常皆沒問題，不過，某些客戶可能有負載平衡器或 WEB 伺服器，會嘗試將查詢字串參數再多編碼一次。
因為編碼兩次，當訪客 API 嘗試將 adobe_mc_sdid 值解碼時，就無法擷取 SDID 值並產生新的 SDID。此程式會導致傳給Target和Analytics的SDID值不正確，且您在Analytics報表中看到重新導向分割不平均。
Adobe建議您洽詢IT團隊，確定adobe_mc_ref和adobe_mc_sdid已加入允許清單，因此這些值絕不會轉換。
為何必須將轉介URL傳給新頁面？ section_91AB8B0891F6416CBF7E973DCAF54EB5
假設訪客按一下www.google.com上的連結來前往您的首頁(www.mysite.com/index.html)，其中重新導向活動正在運作，接著便重新導向新頁面(www.mysite.com/index2.html)。
先前，新頁面上的Analytics要求會報告轉介URL為www.mysite.com/index.html而非www.google.com。 這會導致 Analytics 中與轉介 URL 有關的報表不正確 (例如，「行銷通路」報表)。報表已喪失您是從www.google.com前往網站的事實。
若使用at.js版本0.9.6 （或更新版本）和AppMeasurement.js 2.1 （或更新版本），新頁面上的Analytics要求會報告轉介URL為www.google.com。
我可以使用自訂/HTML 重新導向選件嗎? section_E49F9A83A286488C8F1098A040203D7E
Adobe Experience Platform Web SDK是否支援A4T的重新導向選件？ platform
下列常見問題集提供搭配Platform Web SDK使用A4T和重新導向選件的詳細資訊。