YITH WooCommerce 外掛採購：資料與續約成本

想像一個場景：一間做客製化設備的商店，客人詢價要靠信件往返三天才拿到報價，等不及的直接轉向別家；一間同時接批發與零售的店，兩種客人看到同一個價格，批發客開口要數量折扣，零售客嫌貴離開；到了年底，後台躺著一排年度授權帳單，扣款時間比大多數訂單還準時。三個畫面指向同一個源頭：買外掛之前，機制沒有被拆開來看。

這些決策多半從一張功能清單開始走偏。外掛市場實在太大：依 W3Techs 的 CMS 統計，WordPress 是目前最普及的內容管理系統；依 W3Techs 的電商平台調查，WooCommerce 則是市佔最高的開源電商系統。市場大而雜，每張清單都在比功能數量，沒有人替你比「用不用得到」，清單式採購跟著失效。

於是三個誤解一直流傳：同廠牌的外掛一起裝就不會出事；免費版只是付費版的縮小版；功能表愈長的愈值得買。三句話各錯一處。相容只保證共存，不保證自動分工；免費與付費的界線是設計出來的，位置經過挑選；用不到的功能算不上資產，它是每年續約時要再付一次的負債。真正值得拿來比較的變數有兩個：這款外掛把多少資料與規則寫進你的商店結構，以及一年之後，你還願不願意為它續約。功能容易被模仿，資料結構換掉則要重建規則、轉換資料，代價由落地深度決定。

快速重點：挑 YITH 的判斷軸不是功能多寡，而是資料落地深度與續約成本。把規則與資料寫進結構層的動態定價、會員、詢價，才值得認真考慮年費；通知與收藏類多半有免費替代，先懂機制再下單。

你買的是功能，還是資料落地？

多數人比外掛的方式，是把兩張功能表並排放，看誰打勾的格子多。這個方法漏掉了最重要的變數：功能寫在哪一層。同樣是「有這個功能」，一款只是在畫面上多一顆按鈕，另一款把你的商品、會員與價格規則整批搬進自己的資料結構。前者替換成本低，說換就換；後者用了半年，商店已經離不開它。採購該問的第一個問題是資料落在哪裡，第二個才是功能做什麼，順序反了，之後每一年都在替錯誤的順序付錢。

把落地分成三級，判斷會變得具體。設定層：外掛只存放設定值，停用移除後多半就結束，畫面大致恢復原狀，這一級的外掛本質是租來的呈現工具，表現不如預期就換，搬遷負擔通常不大。名單層：它替你收集資料，例如缺貨通知（Waitlist）留下的 email 名單、願望清單（Wishlist）存下的商品清單，換外掛時名單要搬，但格式單純，搬遷通常做得起來。結構層：它把規則對應寫進商店的核心流程，會員等級對應哪些商品、折扣規則怎麼疊、禮物卡餘額剩多少，這些東西離開原本的外掛，多半要重做一次。

用這三級回頭檢查「功能表愈長愈值得買」，問題就清楚了。功能表不會告訴你哪些功能落在設定層、哪些落在結構層，更不會提醒你，閒置的功能一樣佔著年度授權的席位，續約帳單不會因為你沒在用就打折。以呈現為主的外掛落在設定層，篩選做得順手就用，不順手就換，通常不值得為它背年費；會員與定價類剛好相反，值得年費的原因不在功能多，在資料會長在上面。買外掛等於簽一份長期維護關係，關係有多深，由資料落地那一級決定。

後續每一節都在用這把尺：付費牆、重複通知、折扣疊加、會員搬遷，都用「資料寫到多深」重新解釋一次。看懂三級，讀任何外掛的銷售頁都會多一層過濾網，銷售頁列的每一條功能，你都能追問一句：它把什麼寫進我的商店？答不出來的，先當設定層看待。

免費版的邊界，是商業設計

免費版常被當成付費版的縮小版，這是第二個誤解。它其實是行銷漏斗的入口，付費牆的位置經過挑選；YITH 這類外掛商常見的畫法，是卡在自動化與規則化這一環：名單你收得到，自動寄送要付費；單一規則做得出來，規則之間的組合要付費。實際界線依產品而異，對照表要逐款讀。廠商把你能手動完成的事留在牆前，把會隨規模變痛的事放在牆後，這條線畫在哪裡，反映的是對客戶成長曲線的預期。

YITH 的 Waitlist 缺貨通知把界線畫得最清楚。依 WordPress 外掛庫的官方說明，免費版可以收集缺貨名單，並手動寄出預設的補貨信，補貨當下自動寄送屬於付費版功能。翻成白話：名單你免費拿，規模化寄送你付錢。這條界線本身就是採購教材，補貨頻率一季一次，手動寄得完；天天補貨、名單持續長，自動化才開始值那筆年費。

評估任一款外掛，動作不是打開功能表數格子，而是讀官方的免費與付費對照表，把每一條界線翻譯成同一個問句：被卡住的這件事，手動能不能替代？能替代，接著問一年發生幾次、單次工時多長、出錯代價多大。一年個位數次、每次幾分鐘的事，多半不值得用年費解決；天天發生，或單次出錯會賠上報錯價、漏出貨的，自動化才開始划算。頻率只是初篩，工時與錯誤成本仍要攤開來算；單筆金額大的生意，低頻自動化也可能值得買。

還有第三個選項常被忽略：什麼都不裝。有些症狀的解法是把流程寫清楚，不是安裝東西。免費版最合理的用法是當驗證工具：在測試站確認相容與流程，真的撞到天花板再升級，那時你買的是被驗證過的需求。

兩套通知打到同一個人

第一個誤解現在可以拆了。同廠牌等於不會出事？相容在技術上的承諾很窄，窄到接近只是共存：兩款外掛可以同時啟用而不報錯，而且就連這一點，同廠牌的組合也要在測試站實際驗證過才算數。它不承諾分工，兩套流程不會自動知道對方存在，更不會替你決定這封信由誰來寄。把「同一家的所以沒事」當採購理由，等於接了兩台印表機到同一部電腦，然後假設它們會自己分工。

換一個常見的現場：商品補貨那天，行銷端的電子報對追蹤該分類的訂戶發補貨通告，網站端的補貨通知外掛同一刻對留下 email 的客人寄補貨信。一位兩邊名單都在的客人，十分鐘內收到兩封標題相似的信。兩套流程都沒有故障，它們都照設計運作。要拆開重複，先替每個事件指定唯一的發信者，其他系統對同一事件保持靜默；上線前用測試帳號實際收一次信，確認只收到一封、退訂之後兩邊都停。

拆開機制看，重複寄信不是意外，是集合交集的必然。一套通知流程由三個環節組成：觸發條件、收件者集合、寄送時機。兩套系統各自定義收件者集合，收藏功能看的是清單裡有這個商品的人，補貨通知看的是訂閱了這個商品的人，兩個集合本來就會有同一個人。觸發條件這一環也一樣，兩邊監聽的都是庫存狀態變化，事件只有一個，等著動作的流程有兩套。在兩款通知都啟用、觸發條件都成立時，沒有去重協調，交集裡的客人就會各收到一封，而且兩封信的退訂連結各走各的，客人退了一邊，另一邊照寄。

這一層的採購問題不在預算，在流程設計。通知類外掛的價值在設定紀律，不在品牌：誰觸發、誰寄送、退訂走哪裡，三件事決定客人收到的是貼心還是騷擾。同樣的思考搬到別處也成立，優惠券與定價外掛都會改價格，表單與客服系統都會發信，組合之前先指定主要流程。混用可以，但分工要有人負責，而那個人是做設定的你。收藏功能的設定細節，可以接著讀願望清單外掛的完整比較，幾款工具的選擇邏輯在那邊攤得比較開。

結帳金額是怎麼算出來的

動態定價類的外掛常被描述成「什麼促銷都做得出來」，這種說法漏掉了重點。結帳金額是一個計算結果：條件成立，套用規則，依優先順序疊加。三段式裡最危險的是第三段，規則之間預設不會自動互斥，怎麼疊依設定與優先順序而定，疊加方式直接決定毛利。你以為設了兩條偶爾用的規則，它們同時成立的那一刻，折扣深度可能是兩條一起算。而且這件事在後台不容易看出來，規則列表只顯示各條規則的設定，顯示不了它們碰頭時的計算順序。

入門這款外掛，最穩的路徑是官方文件。依 YITH 動態定價的說明文件，數量折扣、滿額購物車折扣到贈品規則都有專章，文件另設規則優先順序與排除清單的段落，產品頁功能表也把能否讓多條促銷累加列為設定項。介面會改版，機制的骨架很少變。

疊加的數學要看例子才會痛。想像一個場景：商品單件定價一千元，客人一次買三件，店裡有兩條規則，甲是會員一律九折，乙是滿兩千五百元現折三百（示意）。甲先套用，三千元打九折成兩千七百元，乙檢查金額仍高於門檻，再折三百，結帳兩千四百元。順序倒過來，乙先以原始金額折三百，兩千七百元再打九折，結帳兩千四百三十元。三十元的差距不是門檻造成的，兩種順序下乙檢查的金額都還在兩千五百元之上；差距來自固定減項與百分比折扣的套用順序，先折三百再打九折，那三百元也被九折壓成兩百七十元，少省三十元。順序由規則的優先順序與設定決定，不由直覺決定。

這也是直接影響成交價的功能，一律先在測試站模擬幾張訂單、走完結帳才上線的原因。確認哪些規則互斥、哪些累加、優先順序誰先誰後，三件事看完才知道促銷的底線在哪裡。規則還少的時候，原生優惠券的能力範圍可能已經夠用，先讀WooCommerce 優惠券設定全解再決定要不要上規則引擎；規則開始變多，先看懂條件式折扣的整體邏輯，再跟著YITH 動態定價的逐步設定教學做一遍，設定時少走回頭路。

同一層還要補一個常被忽略的角色：成本。依 YITH 官方產品說明，Cost of Goods 把進貨成本寫進後台，讓訂單與報表多一個毛利維度可以看。要留意的是它停留在報表層：折扣規則不會因為成本欄位存在就自動收手，品項貼著成本賣、甚至賠售，促銷照樣跑得下去，差別只在於能不能在事前看到。成本資料一旦寫進去，換外掛就得連同資料一起搬，它不炫，但折扣疊加之後帳對不對得起來，靠的就是這個欄位。

看不到價格，和買不到，差兩層

與價格有關的控制常被混成一團談，實際上是三層不同的機制。顯示層控制畫面出現什麼；存取層控制誰能取得內容與購買資格；價格層控制誰用什麼價格買。三層各自獨立設定，也各自獨立出錯，後果還不一樣：該顯示的沒顯示，客人漏看；該擋的沒擋，客人買到不該開放購買的東西。

顯示層：把價格換成一顆詢價按鈕

YITH 的 Request a Quote 可以在商品頁用詢價按鈕取代價格與購物車，客人把品項收進詢價清單，一次送出規格與數量。這是顯示層的置換：購買流程沒有關掉，畫面入口換成另一個動作，後台收到的是結構化清單，規格與數量直接綁定商品，核價少一層人工轉譯，出錯空間跟著縮小。同一層還有 Catalog Mode 型錄模式，把整家店切成純展示，適用情境不同，設定方法在型錄模式的設定教學裡有完整整理。

一張詢價單距離訂單還有多遠？這是評估報價流程該用的尺。YITH 產品頁的官方 FAQ 明確回答過這題：詢價單裡的商品價格就是原價，不能與自動化的數量折扣併用，相容清單同樣排除動態定價類外掛。這條界線的意義是：報價流程與折扣引擎是兩套機制，不會自動疊加。客人要求在報價上再套一層促銷，你以為系統會自己算，實際上要人工核對，把界線看清楚，才不會在報價確認那一刻發現金額對不上。詢價單的欄位與送出條件怎麼安排，詢價表單的完整設定流程有逐步說明。

存取層與價格層：會員資格連動兩種規則

Membership 的特殊之處，在於一個會員方案同時牽動兩種規則。依 YITH 官方產品頁的整合說明，它與 Dynamic Pricing 相容，能把「擁有某個方案」拿來當促銷規則的條件，例如把固定回購的常客收進一個專屬方案，讓回饋折扣只對方案成員生效（示意）；兩款外掛是分開販售的授權，不是買一套就送一套。建立方案後，商品權限與折扣規則仍然要分開設定：誰看得到哪些商品是一份設定，誰用什麼價格買是另一份，兩份都設好並一起測過，分級銷售才真的成立。資料落地這麼深，遷移前的盤點就要列清楚：有效會員名單、到期日、每個方案的權限內容，以及這些對應關係能不能匯出轉換。

再對照兩種常被混為一談的機制，界線更清楚。累點與購物金是回購誘因，處理的是買過的人為什麼再買，購物金與累點回饋的制度設計屬於這一類，它不決定誰看得到商品。測驗、作業與完課進度則是教學管理，線上課程外掛的比較才是那一側的主場；Membership 可以限制內容逐步釋出，搭配課程可以，拿它當課程系統就錯了位置。

免費路線存不存在？存在，但成本要算完整。WordPress 免費的角色管理工具能做基本分類，難的是特定角色看得到特定商品、同時用特定價格買這種連動，自行串接的工時通常比買一套成熟外掛貴。會員權限控制的完整比較把免費與付費路線的成本攤開來看，決定之前值得讀一次。

禮物卡為什麼是負債

禮物卡外掛看起來最無害，版面漂亮、節慶檔期好賣，機制上卻是帳務性格最重的一種。客人付錢的那一刻你收到現金，對應的義務是未來讓他兌換商品，這筆錢在帳上屬於負債，不屬於收入，直到卡片被兌換或依規則退款，負債才消除。逾期作廢這條路，在付費販售的禮券上走不通：依 商品（服務）禮券定型化契約的應記載及不得記載事項，業者發行的禮券不得記載使用期限，履約義務不會因為卡片過期就消失；店家自行無償發放的促銷優惠券，一般不適用這份規範，有效期才由店家自訂，兩種卡的帳務性格必須分開看。賣得愈多，帳上掛著的未履約義務愈大，方向跟其他功能剛好相反。多數外掛是賣斷功能，禮物卡是預收未來的履約，兩者對現金流的意義完全不同。

評估 YITH 的 Gift Cards 這類外掛，看的不是卡片版面，重心在餘額資料與履約流程：餘額怎麼儲存、部分使用怎麼結算、退款時卡片怎麼處理、優惠券的逾期作廢規則由誰定義。每一條規則都在決定負債何時消失，寫錯任何一條，對帳時就會多一塊對不起來的數字。退貨流程也要想清楚：客人用現金買卡、再用卡消費，退款時退現金還是退回卡片，負債消除的時間點就跟著不同。

用落地三級定位，卡片餘額屬於結構層，搬遷優先級比照會員資料。換一套禮物卡外掛，等於把未兌換的負債搬家，資料搬不乾淨，客人手上有卡、你帳上沒有紀錄，兩邊都難受。採購判斷回到同一個框架：把規則與資料寫進結構層的，年費要連同長期維護責任一起算，禮物卡是最標準的註腳。

篩選網址是資產還是雜訊

YITH 的 Ajax Product Filter 讓客人用屬性縮小商品範圍，過程不重新載入頁面，這個體驗是加分。篩選器本身沒有對錯，麻煩出在它的附屬品：每一組篩選條件可能生成一個網址，而這些網址要不要開放索引，取決於外掛的索引設定，能力邊界以官方文件為準；這裡談判斷法，不談設定步驟。

網址能被搜尋引擎收錄，跟它值不值得當成著陸頁來經營，是兩件事。某個尺寸、顏色與庫存狀態的交集，真的有人這樣找，那是資產；沒有人找的組合，只是另一頁的近似內容，數量一大就變成雜訊，有價值的那幾頁反而被淹掉。判斷的依據不在外掛，在你的資料：站內搜尋紀錄與客服問題會告訴你，客人真正用來做決策的屬性是哪幾個，留下少數維度，其餘收合，避免條件比結果還多。收合不是刪掉屬性，是把它從篩選列收進商品頁，該找的人還是找得到。

順序也重要。商品頁本身的搜尋基礎先顧好，商品頁的搜尋能見度優化是地基；地基穩了，再挑少數確實有搜尋需求的組合來經營。順序反了，投入的內容還沒變成資產，就先成為雜訊的一部分。這一節的採購結論也單純：篩選外掛留在設定層，用得順就留著；索引問題需要專門處理時，再把它納入搜尋策略一起看。

授權到期那天會發生什麼事

年度授權是 YITH 付費外掛的基本形式：一次購買附一年期的版本更新、問題修正與支援服務，之後按年自動續約。多數人只盯著價格，沒注意到有效授權同時是三樣東西的鑰匙：更新、下載與支援。依 YITH 的授權政策，這三項權益與授權狀態綁定，支援只涵蓋完成授權啟用的網站；續約與關閉自動續約的操作，YITH Help Center 的續約說明有逐步交代。站點數的計算方式也要問清楚，一個網域算一個授權，還是子站各算一個，答案直接影響總成本。授權是鑰匙，不是買斷，值得在按下結帳前想一遍。

授權過期之後，政策寫明失去的是更新、下載與技術支援。已裝在站上的外掛本體一般不會被遠端停用，但這是機制推論，官方並未承諾到期後的運作狀態。可以確定的是風險結構：WordPress、WooCommerce、PHP 與金流環境都會持續升級，停止更新的外掛與新環境之間的相容風險只會累積，不會消失。把到期當天還能跑當成長期策略，等於把維護成本延期，還加上利息。特別是結帳與定價這種核心流程，賭它不壞的代價，通常是壞在最忙的檔期。核心流程的授權因此要優先續，邊緣功能的授權才有議價空間。

退款政策是另一條要先讀的界線。依 YITH 官方退款政策，購買後三十天內可以申請全額退款，逾期不受理；授權續約的款項明文不在退款範圍，自動續約可以在扣款前自行關閉。例外也寫得明白：同一款產品退過一次不再受理；退款以三款不同外掛為上限，第四款起不受理，確有多授權需求，可先聯絡官方評估專案例外。這個窗口保護的是第一次購買的決策，不保護之後每一年的續約。把退款當成首購的風險控制很合理，把它當成先買再說、不行就退的常態流程，第二年就會發現規則不是這樣讀的。

付款前，過三個檢查點

• 自動續約：確認扣款方式與關閉續約的管道，別等帳單出現才回頭找設定。
• 退款條件：確認申請期限與排除範圍，續約款項不在保障內。
• 授權權益：確認更新、下載與支援各自綁定什麼狀態，到期後各發生什麼變化。

三個檢查點都過了再付款。價格、可建置的站點數與方案細節，一律以結帳頁當下刊出的內容為準，寫死的數字都會過期。

續約季的決策順序建議固定。先問這款外掛解決的問題，值不值得每年付一筆更新與支援費來換：直接影響毛利的，例如每天都在算折扣的定價引擎，續約價值通常較高；行銷效果存疑、報表從來沒人打開的，先降級成待觀察名單。再問依賴：長期沒有人使用的功能，退訂前先挪到測試站關閉一輪，確認沒有資料或串接還依賴它，之後才談取消續約或換工具。順序錯了，代價是取消之後才發現，某段資料或某條規則還鎖在裡面。這份盤點每年固定時間做一次，比到期前一週才倉促決定可靠。

裝之前量一次，裝之後再量一次

每多啟用一款外掛，網站確實多背東西：前端腳本、樣式、後端查詢。但多背多少，不能從外掛數量推算，兩款輕量的可能比一款重量級的更吃資源，取決於啟用了哪些功能、跑在哪些頁面。可靠的做法只有量測：裝之前先把商品頁、購物車、結帳三個關鍵頁面的載入與回應數據存檔，裝完在同一環境再量一次。憑印象說感覺變慢，討論就沒有基礎。量測紀錄也是將來評估停用哪款外掛的證據，回頭看數據，比回想可靠。

量測的尺要對著真實訪客，看載入與互動實際花掉的時間，而不是只看伺服器端的回應數字；量測條件也要固定，同樣的頁面、同樣的環境、前後各一次，比較出來的差異才有意義。

另一個風險藏在模板。有些外掛會接管前端版面輸出，商店若用大幅修改過的電商主題，畫面便可能變形，主題相容性的確認方法值得在安裝前先讀；主題更新之後，關鍵頁面也要再測一輪，相容不是一次性的檢查，是每次大更新的例行公事。

上線前的驗收以流程為單位：在測試環境跑完瀏覽、加車、結帳、收到通知信的完整路徑，通知的觸發與退訂各測一次，金流端的折扣金額逐筆核對。YITH 外掛之間有整合時要一起測，出問題的常是接縫，不是單一功能。一次只裝一款、逐項記錄，問題才歸得了因；一次裝五款再除錯，等於把變因攪在一起，到頭來只能全拆重來。

收斂成三個問題再下單

走完這些機制，採購決策可以收斂成三個問題。第一，資料會落在哪一層？設定層的東西替換成本低，結構層的東西要當長期關係看。第二，規則會累積多少？規則集隨營運長大，今天的三條促銷，兩年後可能是三十條（示意），管理成本一開始就要算進去。第三，一年之後你還願意續約嗎？這題不用憑感覺回答，前兩題誠實算完，答案自然浮出來。

用三問對照前面的案例池：動態定價、會員、詢價落在結構層，規則會累積、直接影響成交價與銷售流程，三問全過，值得年費。通知與收藏停在名單層，免費版先行、撞到天花板再升級，這個結論由機制推導而來，跟品牌偏好無關。禮物卡與成本類外掛補上兩個常被忽略的機制點：帳務與毛利，它們的價值不在畫面，在數字對不對得起來。

也別忘了第三個選項：報價回覆寫成 SOP、商品資料整理到客人不必再問、客服回覆建成範本。工具解決的是規模化之後的痛，規模還沒到的痛，先靠流程。

地基還沒跑通的商店，先讀WooCommerce 完整架站教學把核心流程走穩；還在評估生意模型的，從電商創業完整指南看起；要把店裡的工具盤放到更大的地圖上對照，再翻WooCommerce 必裝外掛總覽。

回到開頭的結論，補上但書：功能容易被模仿，資料結構難搬，難搬不是不能搬，是規則要重建、資料要轉換，成本隨落地深度放大。外掛會改版，清單會過期，機制的骨架壽命比兩者都長，明年用同樣的判斷軸看這個市場，結論不會差太多。