關於 Adobe Target Recommendations 活動的常見問答 (FAQ) 清單。
當您針對包含某數值的自訂屬性執行目錄搜尋時,結果會將自訂屬性視為字串類型,而非數值。
目前,沒有可讓客戶變更屬性類型的功能。若要變更,開啟客戶問題,指出需要將類型從字串變更為數值的屬性。
時間範圍和結果會因更新項目的方式而異。
來源 | 詳細資料 |
---|---|
透過 mbox 或 API 更新項目屬性 |
|
透過摘要更新項目屬性 |
|
透過 Target UI 或 API 從目錄中刪除項目 |
|
透過 mbox 或 API 在目錄中新增項目 |
|
透過摘要在目錄中新增項目 |
|
匯入摘要檔案之後,或是透過 API 或 mbox 收到實體更新之後,將會在 60 分鐘以內反映下列變更:
如果某個項目之前已排除但現在應該納入,該項目將會納入下一次演算法執行 (12-24 小時)。
發生此狀況是因為 Target 會在線上和離線兩個狀態下讓排除生效。 如果新排除某個項目,線上排除很快就會生效。 如果新納入某個項目,線上排除很快就會消失,但離線排除要等到下一次演算法執行後才會消失。
如果之前已納入某個項目,但現在應該將其排除,則會根據上面討論的「項目屬性更新…」時間行來排除該項目,這取決於摘要來源 (透過 mbox/API 為 15 分鐘或透過摘要為 12-24 小時)。
在下一個演算法執行作業發生之前 (在 12 至 24 小時內),不會反映下列變更:
在摘要檔案的狀態從「匯入項目」變更為「準備搜尋索引更新」時,摘要檔案會視為已匯入。更新可能需要 60 分鐘以上的時間才會反映在目錄搜尋使用者介面中;在摘要狀態變更為「更新完成」時,目錄搜尋處於最新狀態。即使目錄搜尋尚未處於最新狀態,您的網站仍會在上方所列的時間範圍反映更新。 最新目錄搜尋索引更新時間會顯示在目錄搜尋頁面上。
促銷活動設定的變更最多可能需要五個小時的時間才會反映在網站上。
其他條件設定的變更可能要等到下一次演算法執行後才會反映在網站上。
隨著每 12-24 小時執行一次演算法,使用者的行為會以彙整方式併入離線演算法處理中。
在 JavaScript 中使用逸出值。引號 ( " ) 會破壞陣列。下列程式碼片段是逸出值的範例:
#set($String='')
#set($escaper=$String.class.forName('org.apache.commons.lang.StringEscapeUtils'))
<script type="text/javascript">
console.log("$escaper.escapeJavaScript($entity1.name)")
console.log("$escaper.escapeJavaScript($entity2.name)")
console.log('$escaper.escapeJavaScript($entity3.name)')
names.push("$escaper.escapeJavaScript($entity4.name)")
</script>
可用的條件取決於目前類別。建立推薦選件時,演算法選擇器會根據類別 ID 來顯示條件。
如果您套用此條件的位置不含類別 ID,則某些條件不會出現在演算法選擇器中。
如果您使用的位置有類別 ID 存在於 mbox 中,則條件選擇器會包含所有適用的條件。
Target 的篩選不相容條件設定可控制演算法選擇器的智慧型篩選。
此設定僅適用於可視化體驗撰寫器 (VEC) 中建立的活動。此設定不適用於表單式體驗撰寫器中建立的活動 (Target 沒有位置環境定義)。
若要存取「篩選不相容的條件」設定,請按一下「建議 > 設定」:
如果「未」啟用「篩選不相容的條件」設定,Target 就不會篩選「演算法選擇器」中的演算法,且所有演算法都會顯示。
如果「篩選不相容的條件」設定已啟用,則在 VEC 活動中,Target 會從選取的位置讀取 entityId 和 categoryId,然後根據 currentItem|currentCategory
來顯示演算法 (如果該位置上有各自的值)。 因此,依預設,演算法選擇器中只會顯示所選位置的相容演算法。
如果篩選不相容的條件設定已啟用,您仍可在選取條件時取消選取「相容」核取方塊,以檢視不相容的演算法。
下列清單包含 Target 未顯示「相容」核取方塊的特殊情況:
如果您看到一個集合原先不是零而現在變成零,請考量下列資訊:
您可以重新儲存集合,檢查數字是否會更新。再次儲存,集合會重新執行所有使用該集合的演算法。
您所看的環境對嗎? 請移至 /target/products.html#recsSettings 仔細檢查 (如下所示)。
索引是最新的嗎? 移至 /target/products.html#productSearch 並檢查索引是幾小時以前編列的(例如「3小時前已編列索引」)。 您可以視需要重新整理索引。
您是否更動過摘要或資料層,而導致實體不再符合收集規則? 請確定「大小寫」相符 (區分大小寫)。
摘要執行成功嗎? 是否有人變更了 FTP 目錄、密碼等?
Target 會儘可能讓傳送的更新(在客戶的頁面/應用程式上)儘快進行。 然而,Target 還是必須在 UI 上為行銷人員提供一些表示法。 Target 不會為了等待 UI 更新同步而延遲傳送更新。 您可以使用 mboxTrace 查看當請求進來時系統中有什麼。
屬性加權有兩種形式:「標準屬性加權」和「內容相似度屬性加權」。
「標準屬性加權」適用於大部分 (但不是全部) 條件類型 (不只是「內容相似度」)。這種加權會給某些屬性值更多權重。在下列範例中,輸出推薦中會多一些 Nike 產品。
「內容相似度屬性加權」僅適用於「內容相似度」條件。
此型別的加權比較動態,且以目前的「建議索引鍵」(目前檢視的專案)為基礎。 在以下範例中(品牌x 16),如果訪客檢視的是Nike運動鞋,則更有可能向該訪客建議其他Nike產品(不一定只是運動鞋)而非競爭者的運動鞋。 如果訪客在檢視 Adidas 運動鞋,則很可能向該訪客建議 Adidas 產品。
Target 有時會因為可用的建議數量不夠而無法顯示建議。
每個條件產生的值數量是設計中指定之實體數量的三倍。產生 3 倍的值之後會套用執行階段篩選 (例如、詳細目錄、mbox 屬性比對),最後在傳送時可能會少於 3 倍的值。若要減少這種情況發生,請隱藏其他實體來增加設計中的實體數量。
可以在設計開始時使用以下 JavaScript 來增加請求實體的數量。在此範例中,請求的實體計數為 30 (3x10)。
#foreach($entity in $entities)
#if( $foreach.count > 10 )
#break
#end
#set ($foo = $entity.id)
#end
Target 會在應用程式層級施加 50 MB 的限制;但只有在您傳遞 application/x-www-form-urlencoded
內容類型標頭時才會施加該限制。
您當然可以嘗試在單一呼叫中傳送 50,000 個產品。如果失敗,您應該將其分成幾個批次。Adobe 通常建議客戶將其呼叫分成 5,000 或 10,000 個產品批次,以降低系統負載造成逾時的可能性。
根據 mbox 參數建立 Recommendations 條件、促銷活動或範本測試規則時,mboxParameter
不再提示您輸入 mboxName
。mbox 名稱現在是可選項目。此變更可讓您使用多個 mbox 中的參數,或參考尚未記錄在 Edge 上的參數。
若要選取需要的參數:
不論使用哪一種方法,mbox 和參數之間並沒有任何連結。條件、促銷活動或範本測試規則將根據傳遞該參數之所有 mbox 的參數運作。
如果編輯現有條件、促銷活動或範本測試規則,則篩選條件將顯示建立期間提供的 mbox 名稱。
請確定對象有唯一的名稱。若您為對象指定了與現有對象相同的名稱,則無法儲存舊版 Recommendations 活動 (2016 年 10 月以前建立的 Recommendations 活動)。
摘要的 CSV 檔案上傳對於資料列數量或檔案大小並沒有嚴格限制。但是,作為最佳作法,Adobe 建議將 CSV 檔案大小限制為 1 GB,以避免檔案上傳處理期間失敗。若檔案大小超過 1 GB,最好將其分割成多個摘要檔案。自訂屬性欄數的上限為 100,而自訂屬性限制為 4096 個字元。在 Target 限制頁面上有提供必要欄長度的其他限制。
在查詢字串中,您可以傳遞要從推薦中排除之實體的實體 ID。例如,您可以排除已在購物車中的項目。
若要啟用排除功能,請使用 excludedIds
mbox 參數。此參數指向逗號分隔的實體 ID 清單。例如, mboxCreate(..., "excludedIds=1,2,3,4,5")
。要求建議時會傳送值。
只會針對目前的 Target 呼叫執行此排除;後續 Target 呼叫不會排除項目,除非再次傳遞 excludedIds
值。 若要在每個頁面將購物車中的項目自推薦中排除,繼續在每個頁面傳遞 excludedIds
值。
如果排除太多實體,則推薦會以沒有足夠實體可填入推薦範本的情況來處理。
若要排除 entityIds
,請將 &excludes=${mbox.excludedIds}
權杖附加至選件內容 URL。擷取內容 URL 時,目前的 mbox 請求參數會替代必要參數。
依預設,新建立的建議會啟用此功能。必須儲存現有的建議來支援動態排除的實體。
若請求的演算法和重要組成沒有提供推薦,則會回傳 NO_CONTENT。一般而言,此情況會在備份於演算法中停用且下列一個或多個陳述為真時發生:
結果尚未準備好。
此情況一般會在首次儲存一個新建立的活動之時、或在活動中使用的集合、條件或促銷活動的設定發生變更之後。
對於所請求的演算法/主要組合,結果已完成,但在最近的邊緣伺服器尚未被快取。
此請求會起動快取作業,因而此問題應會在重新載入數個頁面和/或幾分鐘的時間內解決。
結果已完成,但不適用於所提供的索引鍵值。
此情形一般發生是在請求某項目的推薦時發生,且該項目是在最近一次演算法執行後加入目錄並會在下一次演算法執行後解決。
部分範本顯示被停用,而且結果不足以將範本填滿。
此情形一般在你有動態包含規則其該規則積極從可能的結果中篩選許多項目的時候發生。為避免此情況,請啟用備份,並且請勿將包含規則套用至備份,或在序列中使用較不積極的篩選條件。
當訪客起始工作階段時,工作階段 ID 會繫結至單一邊緣機器,而暫時設定檔快取會儲存在這部邊緣機器中。 來自相同工作階段的後續要求會讀取此設定檔快取,包括最近檢視的項目。
當工作階段結束時 (通常會在 30 分鐘沒有活動後到期),工作階段狀態 (包括最近檢視的項目) 會保存在相同地理邊緣中較永久的設定檔儲存空間。
之後來自不同裝置的後續工作階段就可以存取這些最近檢視的項目,前提為新的工作階段透過相同的 Marketing Cloud ID (MCID)、Experience Cloud ID (ECID) 或 CustomerID/mbox3rdPartyId 繫結至客戶設定檔。
如果訪客同時有兩個作用中工作階段,某台裝置上最近檢視的項目並不會更新另一台裝置上的最近檢視的項目,除非這些裝置被強制共用工作階段 ID。 此問題有可能的解決辦法,但 Target 無法直接支援跨多台裝置的工作階段 ID 共用。 客戶必須自行管理此 ID 共用。
如果訪客在某台裝置上很活躍,然後幾分鐘後於另一台裝置上很活躍,還是會發生此行為。 第一台裝置的工作階段不會在 30 分鐘後到期,而且在設定檔狀態寫入永久狀態並進行處理之前,最多可能會延遲五分鐘。 在測試此行為時,請等候 35 分鐘讓工作階段到期,並儲存設定檔。
如果訪客未同時擁有兩個作用中工作階段,只要工作階段已結束,某台裝置上最近檢視的項目就會更新另一台裝置上的最近檢視的項目。 在測試此行為時,請等候 35 分鐘讓工作階段到期。
Recommendations Premium 不支援在 Recommendations Classic 中建立的演算法。您也許可以在 Target Premium 中使用舊版演算法;但是,當在 Target Premium UI 中停用或刪除活動時,演算法可能會產生同步問題。如需這兩個解決方案之間差異的詳細資訊,請參閱 Target Premium🔗中的 Recommendations Classic versus Recommendations 活動。
一些媒體和出版業客戶想確保推薦項目僅包含最新的文章或影片。例如,Target 客戶使用以下方法,推薦 60 天內的文章:
publish date > today's date minus 60 days
。實體屬性 | 範例 |
---|---|
issueDate | 2021218 |
lastViewDate | 2021701 |
parentCategory | commentary |
publishDate | 20210113 |
publishDateDisplay | 2021 年 1 月 13 日 |
此範例也可以使用參數比對並將 priorDate60
值作為 mbox 參數傳遞來完成。
下列是 Recommendations 活動的已知問題: