結帳頁推薦怎麼設計：用下次購買提示提升回購率

結帳頁推薦的設計順序是：先分清楚結帳之後有哪幾個頁面，再依「商品跟這筆訂單的關係」挑選推薦品，把顧客已經買下的品項排除，用一組專用折扣碼把下次購買提示做成可以追蹤的活動。推薦放在付款完成之後的位置，結帳流程本身保持乾淨。顧客在填表單與付款時的任務只有一個，把錢付完。位置選對、選品有依據、誘因可歸因，結帳完成頁才會從一張收據變成回購的起點。

重點先看

結帳後的頁面有先後：加購頁接在訂單確認後、感謝頁之前，感謝頁只顯示一次，之後回訪看到的是訂單狀態頁。

選品看關係：互補品配著用、替代品補貨用、趨勢品嘗鮮用，各平台文件都有對應的官方功能。

顧客買過的品項要排除，這在 WooCommerce、Amazon 的官方文件裡有明文，漏掉會直接浪費版面。

下次購買提示從內建再買一次按鈕、付款後即時加購、回訪折扣、訂閱制裡挑一種上線，折扣碼一組活動配一組。

衡量靠專用折扣碼與分群名單，沒有專用碼就說不清哪一張訂單是推薦帶來的。

推薦出現的位置：結帳後的頁面地圖

在 Shopify 開發者文件裡，「在結帳前後提供額外銷售機會」的設計統稱 product offer，原文定義是「一個在顧客完成結帳之前或之後顯示的額外銷售機會」，詳細的頁面結構寫在Shopify 的 product offers 開發文件。放在結帳前的版本需要 Plus 等級方案。可以直接上手的位置是結帳之後那一段。結帳後其實是一串頁面，推薦放的位置不同，顧客看到的時機與能做的事就不同。 因此，不能把「付款完成後可推薦」解讀成每個商店都能立即啟用同一種加購功能；正式商店的存取資格、付款方式限制與訂單修改能力應以當下開發文件核對。

接在付款之後的位置，官方稱為 post-purchase 頁。文件的描述是：這個頁面出現在訂單確認之後、感謝頁之前，能在這裡呈現的活動屬於「修改訂單」型，官方列出的形態包括請顧客把更多商品加進剛成立的訂單、請顧客把一筆捐款加進訂單、以及給加購商品一個折扣價。這個位置的特點是交易剛成立、顧客還在結帳動線裡，加購直接併入原本的訂單，顧客不必再填一次資料。這類擴充在官方文件標示為 beta：開發商店內不受限使用，正式商店需要先申請存取權，導入前以當下官方頁的狀態為準。導入時可先在開發商店驗證選品與文案，再依正式商店的規定申請存取權。

再往後是感謝頁（Thank you page）。開發者文件寫明：感謝頁是顧客完成結帳後看到的最初購買確認，如果顧客之後想回到感謝頁或查詢訂單狀態，看到的會是訂單狀態頁。也就是說，感謝頁是一次性的高注意力畫面，顧客剛付完錢、訂單號碼在眼前，對店家來說這是全店少數能確定「這個人剛買了什麼」的時刻。

感謝頁之後的回訪，落在訂單狀態頁（Order status page）。文件描述顧客會在訂單成立到出貨的過程中重複造訪這個頁面查看進度，而入口之一是訂單確認信裡的連結。這代表訂單狀態頁的流量有一部分是店家自己寄出的信帶回來的，這群人是已付費顧客，回訪時對訂單內容有天然的需求。適合放在這兩個頁面的內容，官方文件列舉了問卷調查、商品評論請求、加購提議、社群分享與下載連結等形態，其中加購提議明確寫了是透過訂單編輯把商品加進原本的訂單。完整的分類整理在Shopify 開發者文件的感謝頁與訂單狀態頁說明。

這裡講的是結帳「之後」的內容設計。結帳「之中」的表單欄位、欄位順序與流程簡化，是另一個主題，站內的WooCommerce 結帳表單客製化教學處理那一段，兩邊的分界線就是付款完成的那一秒。

要在這些頁面加內容，官方文件給了工具的分界。想做的調整若有內建設定，用 Shopify 功能即可。要加區塊、追蹤或其他官方沒有的功能，從 App 商店找現成應用。連應用都做不到的特殊體驗，才交給客製應用。App 區塊能放進哪些頁面，在結帳編輯器的 Apps 分頁點開即可確認。要做追蹤與分析，官方文件寫明提供 web pixels 的應用與感謝頁相容。這套分界的實務含義是內容設計先想清楚要什麼、再挑工具，順序反了會把需求硬塞進不合適的實作裡。

無障礙也在官方的照顧範圍內。文件寫明感謝頁與訂單狀態頁的頁面和區塊依 WCAG（網頁內容無障礙指引）與 VPAT 設計，無障礙更新自動套用，店家不必自行維護這一塊。對推薦內容的含義是：用官方區塊呈現的推薦自帶無障礙基礎，若走客製應用，同等級的可用性要自己驗收。

推薦為什麼要等到付款完成後再出現

把推薦放在結帳線旁邊，是零售業的老技法搬到線上。任職 Amazon.com 的三位作者 Greg Linden、Brent Smith、Jeremy York 在 2003 年的《IEEE Internet Computing》發表了該公司推薦系統的第一手報告，刊登於第 7 卷第 1 期，第 76 至 80 頁，全文可以在IEEE Xplore 的論文頁查到。論文描述購物車推薦功能時寫了一句自我類比：這個功能類似超市結帳隊伍裡的衝動型商品，差別在於他們的衝動品是針對每一位顧客挑選的。超市把衝動型商品放在結帳線，論文講的是購物車裡的推薦。把這個注意力位置對到結帳完成頁，是把類比再延伸一步：推薦內容可以依每位顧客剛下的訂單調整。論文附圖的示例很具體：顧客購物車裡放著程式設計與遊戲物理兩本書，推薦就從這兩本書的相似品出發。

這個比喻還有一層容易被忽略的含義：超市結帳線的商品是固定的，對排隊的每個人一樣。線上結帳後的推薦可以依訂單內容變化，買帳篷的顧客看到睡墊，買印表機的顧客看到墨水。同樣的版面，線上版本的存貨是相關性，而相關性來自顧客自己的行為資料。

結帳流程本身經不起干擾，這有量化背景可查。Baymard Institute 長年彙整購物車放棄率研究，在標題為 50 Cart Abandonment Rate Statistics 的統計頁上，以 50 份研究的數字算出平均放棄率為 70.22%，該頁把收錄的研究逐筆列出，2025 年收錄的研究是 71.72%，2023 年是 79.53%，2022 年是 68.70%，2021 年的 79.30% 是當年三筆研究之一，每個數字標注來源研究與檢索日期、可以自行核對，計法公開在Baymard 的放棄率統計頁。這是從加入購物車到付款完成整段動線的背景數字，不能單獨視為結帳頁放棄率。從這套條件判讀，在付款前加入推薦會增加任務尚未完成時的干擾風險。移到付款完成後，則避開這項風險。

從這個對比可以得出一個簡單的判讀方式：顧客的任務還沒完成時，畫面上出現的推薦是障礙。任務完成後，同樣的推薦變成資訊。顧客付完款的那一刻，購物車清空、需求剛被滿足，這時候出現的「搭著用剛好」的商品或「下次回來用的折扣」，服務的已經是下一輪購物。把頁面性質接上內容策略，還能再推一步：感謝頁只顯示一次，適合放「此刻不做就沒了」的內容，例如加購提議、註冊邀請、下載連結。訂單狀態頁承接結帳後的回訪，適合放「每次查看都有用」的內容，例如訂單進度、再買一次按鈕、與上一筆訂單有關的推薦。從這套條件判讀，內容放哪一頁的判斷就變成顧客會回到這裡幾次。

麥肯錫在 2013 年 10 月發布的零售報告〈How retailers can keep up with consumers〉寫過一個宣稱：Amazon 上消費者購買的商品有 35% 來自推薦演算法，Netflix 上觀看的內容有 75% 來自推薦。這是顧問公司報告裡的宣稱數字，Netflix 那個數字講的是觀看，購買面沒有對應數字，引用時值得把口徑說清楚。報告全文在麥肯錫官網。這兩個數字只說明 Amazon 的購買與 Netflix 的觀看在 2013 年報告中的情況，不能當作電商通案或單一店家的預估值。對店家的實際意義，應回到自家活動的專用折扣碼與報表。

推薦什麼：商品跟這筆訂單的關係

選品的判準可以濃縮成一個問題：這個商品跟顧客剛下的訂單是什麼關係？平台的官方文件把常見的答案分成幾類，各有對應的功能規格。

Shopify 開發者文件對推薦的官方定位寫得直白：對顧客顯示推薦商品讓他們更容易發現新商品，也能幫助增加線上商店的銷售。文件也把「在顧客旅程各階段調整推薦」描述為幫助顧客發現商品的有力做法。同一個顧客在商品頁與結帳後適合看到的內容不同，推薦意圖就是把這種定向策略寫成可設定的規格。

互補品的邏輯是「配著用」。complementary products 在開發者文件裡的定義是：提供與顧客正在互動的商品互補的商品，官方給的例子是加購品，出現在標題為 Pair it with 的區塊。同一份文件寫明，互補推薦需要手動設定，平台不會自動生成，哪些商品互補由店家直接指定。

設定的位置有官方路徑：Shopify 的互補推薦透過 Search & Discovery 應用設定，WooCommerce 引擎用分類篩選加排序條件組出同樣的效果。兩條路殊途同歸，先把「什麼配什麼」的商品知識寫進規則，再讓系統執行。

替代與補貨的邏輯是「同類再買一個」。Shopify 對 related products 的定義是提供與顧客正在互動的商品相似的商品組合，官方例子是可替代品，出現在 You might also like 區塊。與互補推薦相反，related 是平台唯一自動生成的推薦意圖，資料基礎在說明中心的相關商品說明裡寫得具體：常一起被購買的商品、商品描述相似的商品、以及相關選集裡的商品，而且「隨著更多訂單與商品資訊累積，推薦會越來越準」。這對中小店家是好消息：共購資料隨營運自然累積，不必先有海量資料才能開始。區塊的標題與版面由商店的佈景主題決定，每個商品要顯示標題、價格、廠商或簡短描述，可以在外觀設定裡調整。說明中心並提醒一個商品頁面上的相關商品區塊一次只能有一個。兩種意圖的官方分類整理在Shopify 的推薦意圖開發文件。

趨勢品的邏輯是「最近多人買」。WooCommerce 官方的 Product Recommendations 擴充讓店家建立所謂的 engine（推薦引擎），用自訂的篩選與排序條件產生推薦，再把產生的推薦部署到店內不同位置，擴充要求 WooCommerce 3.3 以上版本。篩選決定候選商品的池子，排序決定誰排在前面，部署位置決定顧客在哪裡看到。推薦在背景依需求生成，用意在節省伺服器資源，官方文件說這讓擴充在各種主機環境正常運作。理解這個分工，後面配置範例的每個欄位就都有了著落。官方在感謝頁的教學指南裡示範的排序條件包括：依顧客評分由高到低、依熱銷程度由高到低並指定最近 7 天這類時間區間、依商品新舊由新到舊。把這幾個條件疊起來，產生的就是這個分類裡近期熱銷的新品。指南全文在WooCommerce 的感謝頁推薦指南，WooCommerce 引擎的完整文件則在官方的Product Recommendations 說明文件。

官方指南還示範了同一套引擎的其他用法。商品缺貨時，在缺貨頁放同分類裡有庫存、依評分排序挑出的替代品，讓開不了單的頁面變成推薦位置。商品頁放分類交叉推薦，讓逛某類商品的顧客看到搭配分類的品項，也能放「You May Also Like」的趨勢品推薦，這是官方指南列出的商品頁趨勢品加購形態。分類頁則能放該分類裡的熱銷與特價。這些範例的共同點是推薦跟著顧客當下的瀏覽情境走，引擎與部署位置是同一套系統，換的是篩選條件與出現的頁面。

關係	顧客心理	官方功能出處	典型位置
互補品	配著剛買的東西一起用	Shopify complementary（Pair it with，手動設定）	商品頁
替代與補貨	同類的下次再買	Shopify related（You might also like，自動生成）	商品頁
趨勢品	看看最近多人買什麼	WooCommerce 引擎的評分、熱銷、新舊排序條件	感謝頁、分類頁

除了這幾類，訂單狀態頁上還有一個更直白的位置：Shopify 的客製化選項文件寫明，訂單狀態頁預設就有一個 Buy again（再買一次）按鈕，店家可以從結帳編輯器把它隱藏。這個按鈕背後的假設是回訪顧客可能想重複購買同一樣東西，對消耗品、耗材、定期會用完的商品，這是不花設定成本的回購提示：開啟、隱藏或恢復都在結帳編輯器操作，新店上線時值得先確認這一條。

買過的要排除：官方文件裡的共同檢查

把已購品項從推薦裡排除，這件事在各平台文件裡有直接或間接的明文。WooCommerce 官方指南在這件事上寫得直白：存在於訂單裡的商品會被排除在產生的推薦之外。Amazon 則在客服頁面自述了同一個機制的邊界：有時候顧客還是會被推薦已經買過的商品，很可能是因為推薦的是另一個版本，例如平裝書與 Kindle 版，官方寫明「我們一般會把其他版本從你的推薦中篩掉，但少數標題仍可能穿過篩選」，連規模等級的推薦系統都在處理已購排除的漏網，自營商店的推薦清單更應該把這件事當成上線前的必要檢查。

Amazon 的客服頁還揭露了推薦的資料來源與變動性：系統檢視顧客購買過的商品、顧客告訴系統自己擁有的商品、以及顧客評分過的商品，再把這些活動與其他顧客的活動比較，據此推薦。而推薦會隨著新購買、新評分以及其他相似顧客的興趣變化而定期改變，原文在Amazon 客服的推薦說明頁。Amazon 甚至把控制權交給顧客本人：在改善推薦的頁面上，顧客可以用開關把特定品項排除在推薦考量之外（例如買來送禮的東西），也可以還原標記過「沒興趣」的商品，這份文件在Amazon 的改善推薦頁。這兩頁對店家的啟示是把「為什麼推薦這個」想清楚：送禮的購買不代表個人興趣，一次性的代買不該觸發後續推薦，這類判斷在自營商店裡要靠名單分群與活動設計來近似。

推薦演算法在做什麼：可以解釋給店員聽的版本

Amazon 那篇 2003 年的報告價值在於把推薦演算法講清楚了。論文提出的方法叫 item-to-item collaborative filtering（品項對品項協同過濾），核心一句話是：這個演算法配對的是相似商品，對顧客買過與評分過的每一個商品，分別找出相似商品，再把這些相似商品合併成推薦清單，省掉了先找相似顧客的步驟。所謂相似商品的依據，是顧客傾向一起購買的品項組合，演算法用離線運算先把這張相似品項表建好，線上環節只做查表。

用店的語言翻譯這張表：它記錄的是買某個商品的人也買了什麼的共購統計，而且是對每一個商品分別記錄它的相似品。顧客下單後，系統拿訂單裡的商品去查表，查回來的品項再合併、排序，就成了推薦清單。資料越多，表就越完整，這也呼應前面推薦會越來越準的官方說明。

論文摘要也把當時的常見解法點了名：傳統協同過濾、群集模型與搜尋式方法，而品項對品項的作法與它們的差異就在線上運算量：前述的離線建表讓線上環節只剩查表，顧客再多、目錄再大也不影響回應速度。報告的結尾對零售業做了一個預期：推薦演算法會在線上與線下被更廣泛地用於定向行銷，作者點名實體郵件、折價券這類線下形式也在內。這份原始報告後來仍有更新。2017 年的版本延續原始報告主題，並把焦點放在 Amazon 成長後推薦系統經歷的變化。

這個設計裡與小店家有關的部分，論文寫明，線上環節的運算量與商品目錄大小、顧客總數脫鉤，只取決於使用者買過或評分過多少商品。演算法在資料稀少時表現良好，少到兩三個品項也能產出高品質推薦。論文說的「兩三個品項」，是單一使用者已購買或評分的紀錄。它不能證明新店只有少量總訂單時，整體推薦仍會準。可保留的結論是，item-to-item 在單一使用者資料有限時仍可產出高品質推薦。Shopify 則只說 related recommendations 會隨更多訂單與商品資訊變得更準。論文也如實列出它面對的工程條件：數千萬顧客、數百萬品項、半秒內回應、新顧客資訊極少、老顧客資訊過量、資料隨時在變。單一店家不會遇到這種規模，但即時回應、隨新資料更新正是結帳後推薦該有的行為：顧客剛下單，畫面上的推薦就該反映這筆訂單。

論文裡的個人化描述適合原味引用：在 Amazon，他們用推薦演算法為每一位顧客個人化線上商店，商店會依顧客興趣徹底改變，對軟體工程師顯示程式書、對新手媽媽顯示嬰兒玩具。作者寫的是，定向內容的點閱率與轉換率高於橫幅廣告與暢銷榜等非定向內容。原文沒有給百分比，也沒有比較 post-purchase 與其他頁面位置。其中兩位作者後來在 2017 年的《IEEE Internet Computing》發表了二十年版回顧，摘要寫道 Amazon 以個人化與推薦聞名，推薦幫顧客發現原本找不到的商品，該文可在Amazon Science 的出版頁查到。

下次購買提示的形態與規格

「提示顧客下一次購買」有幾種成熟形態，從平台內建的功能到完整的訂閱制度，需要的設定與營運投入不同，從輕到重排列如下。

平台內建的下次購買按鈕是起步點。前面提過 Shopify 訂單狀態頁預設的 Buy again 按鈕，對店家來說這是零設定成本的起點，先確認它沒有被關掉，再考慮更重的設計。

即時加購活動接在付款後。post-purchase 頁上的三種官方形態（加購、折扣加購、捐款）共通的規格是直接併入原訂單，顧客不用重新結帳，捐款形態與加購共用這套機制，差別只在內容。這種活動的選品原則跟前節相同，適合放互補品與低單價的加購品。

背後有一條技術分界先記著：Shopify 開發者文件寫明，感謝頁上的 UI 擴充在顯示的當下，訂單還沒有建立完成，訂單編號已經可用，而 UI 擴充不能直接修改訂單，要改訂單的活動（例如把加購商品併進原訂單）必須走 post-purchase 擴充的專用機制，訂單狀態頁的加購提議是官方列出的另一形態，走訂單編輯的通道。這條分界解釋了為什麼付款後立刻加購是獨立的功能類型：它操作的是一張剛成立、還在變動中的訂單。

回訪折扣是針對下次購買設計的。Shopify 的 Shop app 行銷自動化提供一個可直接照抄的官方範本：在 Shop 頻道啟用直接銷售後，店家可以建立 post-purchase offer，給回訪顧客一個 App 內使用的折扣，官方並且規定同時只能有一個進行中的 offer。折扣的型態有三種：免運費、固定金額、百分比。可見性的結束條件也寫得明確：折扣碼條件用完（例如每人限用一次）、折扣碼過期或刪除、自動化停用或刪除，三者任一成立就不再顯示。

限制也先記下：折扣碼無法限定只適用特定顧客、顧客群、選集或商品。活動的背景圖官方建議用 933 x 480 像素避免裁切。折扣碼也不是設了就固定：官方文件寫明，只要自動化持續啟用，折扣碼可以隨時替換，活動不必重開。文件還給了一條衡量紀律，原文寫「為了準確追蹤，請建立一個只用於該 post-purchase offer 自動化的折扣碼」，細節在Shopify 說明中心的 Shop 行銷頁。

訂閱制把下次購買制度化，讓提示變成不必提示。WooCommerce 官方的Subscriptions 擴充讓顧客以每週、每月或每年的週期訂閱商品並自動扣款，整合超過 25 種金流，失敗扣款會自動重試（官方對這項能力的說明是避免因扣款失敗而損失收益），需要人工付款的訂戶也有手動續訂的選項，系統自動開立發票與收據，訂戶可以自行升級、降級、暫停或取消方案，自行更新配送地址與付款方式，也能為單一商品設定多種方案，官方定位是「把一次性購買轉為經常性收益」。同一款商品開出不同配送週期讓顧客依用量自選，是這個定位的具體用法。

對墨水、咖啡豆、保養品、寵物食品這類用得完的商品，訂閱把回購從店家的行銷動作變成顧客的預設狀態：「記得回來買」這件事從店家手上移到系統手上，顧客設定一次，後續的回購由排程完成。代價是金流與物流要能撐住週期性出貨。對課程等非耗材型商品，回購要換一種做法，靠下一波新品與續購方案承接；線上課程的回購波段規劃拆解了募資、波段與回購三段怎麼接。

配套的營運功能官方也一併處理：內建訂閱信件涵蓋續訂收據、待付款發票、扣款重試等關鍵事件。報表追蹤經常性收益與活躍訂戶數。訂戶可以把訂閱當禮物送人，官方對這項功能的定位是觸及新顧客、讓經常性收益成長。

電子報把結帳後的注意力延長到信箱。訂單確認信是顧客在交易後會查看的文件，信裡的訂單狀態連結把顧客帶回訂單狀態頁，頁面上的推薦與折扣因此獲得第二次曝光。從結帳完成到下一封信之間的自動化串接，細節交給站內的EDM 行銷完全指南，這裡不重複。如果要把瀏覽或點擊事件接到後續信件，還需另行查證所選系統的追蹤與自動化規格。

這些形態共通的骨架是「對的時機出現一個夠小的行動」。行為設計把提示（prompt）列為觸發行動的要素之一。剛完成購買的顧客已經跨過一次付款門檻，下一次購買缺的可能只是一個具體的提示：折扣碼、再買一次按鈕，或一封對的信。提示怎麼設計才有效，站內的福格行為模型 B=MAP有完整拆解。至於折扣碼本身要怎麼設（滿額、免運、百分比之間的取捨），WooCommerce 優惠券設定教學講的是那一層。

假設商店走一遍：從一筆訂單到回購活動

用一家假設的登山用品店走一遍流程，說明各個規格怎麼接起來。假設這家店的主力商品是三季帳，客單價中等，回購集中在睡墊、露營燈、修補包這類配件與耗材。

第一步先確認頁面本身。感謝頁與訂單狀態頁的內容區塊在結帳編輯器裡管理，app 區塊能加到哪些頁面，可以在編輯器的 Apps 分頁逐一確認。假設的店家在這裡先做一件事：確認訂單狀態頁的 Buy again 按鈕是開的。

第二步設定推薦內容。照 WooCommerce 官方指南的配置骨架：建立一個 Order 類型的 engine，篩選把候選池限定在互補的配件分類，排序條件疊上評分由高到低、熱銷程度取最近 7 天、以及新商品優先，部署位置選訂單收到的頁面、顧客資料之後的區塊，可見條件設成訂單包含帳篷分類時才顯示，版面用預設的一列四個商品。顯示標題會出現在推薦商品上方，欄與列的數量可以調整，標題的寫法跟訂單連起來比通用標題更貼合情境，例如「搭配你的新帳篷」。這套配置的結果是：買帳篷的顧客在感謝頁看到配件分類裡最近評分與銷量表現好的品項，而訂單裡已經有的品項自動被排除。官方提醒要照單全收：engine 儲存後就不能改類型，要改就重建。第一次在前端檢視時推薦還沒生成，管理員會看到生成中的訊息，屬正常現象，若推薦整個不顯示，官方文件指出常見原因是頁面快取。

第三步設計下次購買提示。延續同一個假設：店家想讓買帳篷的顧客在裝備需要補充時回來買營柱與修補包。可操作的形態包括在訂單狀態頁放配件推薦、給回訪顧客一組專用折扣碼、以及對耗材直接推訂閱。Shop 的回訪折扣可選免運費、固定金額或百分比。這家假設商店的第一版選固定金額，並用活動專用碼追蹤。這是範例選擇，不代表官方的選擇規則。衡量與名單接在後面。

把這家假設商店的設定整理成檢查點：結帳流程中沒有插入推薦、感謝頁有一個推薦區塊、訂單狀態頁有 Buy again 與配件推薦、推薦清單排除了已購品項、折扣碼是活動專用、訂閱方案只開在真正會用完的耗材上。剛起步的店家從清單開頭做起即可，檢查點的順序就是導入的順序，每一項獨立成立，做完一項再下一項。全部做完再回頭看報表，調整才有依據。

結帳後推薦怎麼衡量：一組折扣碼對一個位置

衡量從折扣碼的紀律開始。Shopify 文件那句「一個自動化配一組專用折扣碼」背後的道理跨平台通用：折扣碼就是歸因標籤，結帳後活動的碼與官網橫幅的碼、電子報的碼分開，看報表時才能說清楚每一張訂單從哪個位置來。沒有專用碼的回購折扣等於花錢買了不知道來源的訂單，對單店經營者來說是純粹的盲區。把碼分開可以比較各位置的折扣碼使用訂單。活動是否獲利，仍要另算成本與毛利。

頁面層追蹤需另行確認事件規格。Shopify 文件只明示，提供 web pixels 的應用與感謝頁相容。實際能不能記錄推薦曝光、點擊與對應報表欄位，要依所選應用的規格確認。挑應用前先把要追蹤的事件列成清單，逐項對照規格，缺了哪項就換一家。

名單把衡量往前推一層。誰在多久之前買過什麼、金額多少、最近一次互動是什麼時候，這幾個欄位構成回購名單的基本盤，RFM 把這些欄位整理成可操作的分群框架，操作細節在站內的RFM 分析實戰。這裡只比較各區隔的活動結果，不預設哪個區隔要用較強折扣。各區隔適合哪種形態的提示，從分群結果與商品結構判讀，是活動設計的輸入。

衡量時，專用折扣碼用來辨識該自動化的使用訂單。回購率與平均訂單金額可另行觀察。回購率指既有顧客再次下單的比例，平均訂單金額指單筆訂單的平均價值。進行前後比較時，先固定觀察範圍、指標定義、計算方式與資料來源，再讀活動前後的變化。

衡量回購還可參考顧客終身價值。這個指標的計算與判讀，站內的顧客終身價值一篇有完整處理。活動前後的變化本身不等同因果證明。觀察時把同期的大事一併記錄，促銷檔期與流量來源的變動會影響前後對比，條件一致時的變化才有判讀價值。

上線前值得先排除的錯誤

付款頁應優先維持完成付款的單一任務。在付款完成前加入額外選項，會增加干擾風險。推薦可放到付款完成後的頁面。付完錢之後的每個頁面才是推薦的版面。

推薦已購品項同樣浪費版面。這個錯誤的來源，一種是沒設定排除規則，把店內熱銷硬塞進感謝頁，熱銷裡正好有顧客剛買的那個。另一種是版本型商品（不同容量、不同版本）仍可能穿過篩選，以另一個版本出現在推薦裡。WooCommerce 的訂單內排除與 Amazon 的版本篩選自白，前一節都引過，這裡的檢查動作是對著上線後的感謝頁截圖逐項核對。

版面塞滿是隱性的同款錯誤。官方文件對商品頁的規定是相關商品區塊一次只能有一個，這條規格背後的版面紀律可以借鏡到結帳後的頁面：加購、問卷、追蹤邀請、推薦全擠上同一個畫面時，每個訊息分到的注意力就少，取捨本身是設計的一部分。

折扣碼混用讓成效歸不了因。全站通用的一組大折扣碼同時出現在結帳後活動、首頁橫幅與電子報裡，報表會把各位置的成效合併成一筆糊帳，等於放棄了評估結帳頁推薦還要不要繼續投資的能力。專用碼的紀律不花成本，缺的只是事前一步。

漏看平台現況會讓活動上不了線。post-purchase 擴充的 beta 狀態與正式店申請、Shop 折扣同時只能一個進行中、WooCommerce engine 儲存後不可改類型、頁面快取對推薦顯示的影響：這些規格細節在導入時逐一核對官方頁，文件會更新，文中的規格以查證當天為準。

結帳頁推薦的工作，說到底就是讓剛付完款的顧客在對的頁面看到跟這筆訂單有關係的下一個商品，並且讓店家自己事後說得清楚那張訂單是怎麼來的。位置、關係、排除、提示、歸因，各就各位之後，回購率的分析才有素材。從確認 Buy again 按鈕存在開始，結帳完成頁就能從空白收據變成回購引擎的第一格。