大規模個人化主要是營運問題。五條規則一個人記得住；四個人在一年內寫出的五十條規則就記不住了。沒有一些架構，最後就會出現沒人負責的規則、兩條規則在價格頁面上搶同一個標題，還有某個分群仍看到舊價格，只因為沒人記得那個版本還存在。
本文介紹讓不斷增加的規則保持可管理的架構：命名、登錄表、明確的衝突優先順序、以版位為基礎的範本而非客製頁面、效能檢查，以及權責分工。這些都不複雜，只是必須在規則數量增加之前就建立，而不是之後。
您已經超出現有架構的跡象
- 沒人說得出某位訪客會看到什麼。有人問「醫療業大型企業訪客在首頁會看到什麼？」，要回答這個問題就得打開好幾條規則，可能還不只在一套工具裡。
- 衝突靠運氣解決。兩條規則針對重疊的客群改動同一個元素，勝出者取決於載入順序或建立日期，而不是某人做出的決定。
- 內容變更會變成大搜索。價格或產品名稱一改，就得翻遍每個版本，找出舊措辭藏在哪裡。
- 隨著規則增加，頁面變慢或開始閃爍，卻沒人注意到是從何時開始的。
- 測試停擺，因為維護現有規則就耗盡了所有時間。
減少規則數量有時是正確答案，尤其是當許多規則從未被衡量過時。但更常見的情況是規則本身沒問題，缺少的是檢視與管理它們的方法。
替規則命名，讓名稱就能說明規則
選一種命名模式並在所有地方使用。一個可行的做法：層級、區隔、頁面、元素和版本，依序以連字號連接：
tier-segment-page-element-version
T1-acme-corp-homepage-hero-v2T2-enterprise-healthcare-pricing-proof-v1T3-returning-visitor-blog-cta-v3
級別前綴與下方說明的衝突處理順序相關聯。其餘部分則讓任何人瀏覽規則清單時，不必打開就能看出每條規則的作用。依頁面篩選，就能看到所有可能影響該頁面的規則；依客群篩選，就能看到該客群看到的一切。
建立登記冊
一份試算表就夠了。每條有效規則一列，包含以下欄位：
| 欄位 | 存在的原因 |
|---|---|
| 規則名稱 | 與工具中的名稱完全一致 |
| 目的 | 一句話：「向醫療產業訪客顯示醫療業案例研究，以提高示範預約數」 |
| 負責人 | 該詢問的人，以及負責更新的人 |
| 區隔定義 | 實際條件，讓重疊之處一目瞭然 |
| 頁面與元素 | 改變內容的位置 |
| 包含的事實 | 價格、方案名稱、客戶名稱、產品名稱；當其中任何一項變更時，就搜尋這一欄 |
| 保留組 / 測試狀態 | 已衡量、衡量中，或從未衡量 |
| 最後檢閱 | 日期 |
再搭配兩個習慣。新規則要先向登錄表負責人提出簡短申請（Slack 訊息就可以），在上線前抓出重複的規則。每季檢視一次清單：下架經完整測試後仍無效果的規則、更新過時內容，並合併對重疊分群做同一件事的規則。如果您不想自己建立，我們的個人化操作手冊範本可以當作登錄表；它有一欄專門記錄重疊時的優先順序。
在衝突發生前先決定規則
一位來自目標帳戶清單上大型醫療公司的回訪訪客，可能同時符合帳戶規則、產業加規模規則、產業規則與回訪訪客規則。如果它們全都針對主視覺，就必須有東西來決定。請訂出明確的順序：
- 第 1 級：指名帳戶規則。任何為特定帳戶或帳戶名單打造的規則都優先。這些規則最具體，通常也與進行中的銷售對話相關。
- 第2級：複合分眾。結合兩個以上屬性的規則（大型企業 + 醫療業）優先於單一屬性規則，因為有人決定這個組合值得有自己的訊息。
- 第三層級：單一屬性規則。「所有大型企業訪客」、「所有來自美國的訪客」。作為備援。
- 預設頁面。其他所有人看到的內容，也是爬蟲看到的內容。
在同一層級內，不要讓「最近更新」或載入順序來決定。請在規則登錄表中為同一層級的每條規則指定明確的排序編號，或者更好的做法是，從一開始就避免對重疊區隔的同一元素設定同層級規則。默默的平手裁決機制，正是訪客最後看到沒人預期的版本的原因。
也可以依頁面元素來避免衝突。如果客戶規則負責主視覺區，產業規則負責佐證區塊，同時符合兩者的訪客就能兩者兼得，不會互相衝突。這是最簡單的解法，值得優先嘗試。
用範本和版位取代客製頁面
讓大型規則集負擔得起的模式是：固定頁面版面，並定義幾個可個人化的版位。規則負責填入版位，而不是重新設計頁面。
B2B 首頁的版位範例：
- 主視覺標題（設有字數上限，讓各版本能在手機上完整顯示）
- 主視覺副標題
- 佐證區塊：一排標誌加一則引言
- 主要 CTA 文字與目的地
- 精選客戶案例
如此一來，建立一個版本只需要為五個欄位撰寫文案並挑選一個案例研究，行銷人員不需要設計或工程資源就能完成。這也讓登錄表更有用：您會清楚知道規則可以變更哪些欄位。
這個取捨是真實存在的。您的醫療版本和金融科技版本會看起來很像，因為它們共用同一個版面。對大多數 B2B 網站來說這是可以接受的，因為各區隔真正改變的是訊息。完全客製的處理方式留給少數交易規模足以支撐額外工作的指定帳戶，並接受這些頁面需要另外維護。
隨著規則增加，持續監控效能
一組規則在速度上的成本，取決於決策發生在哪裡。伺服器端或邊緣端的決策會在頁面送出前增加工作量；用戶端腳本則在頁面渲染後增加工作量，並可能造成閃爍。無論哪種，都要實際量測，而不是假設：
- 個人化頁面上的最大內容繪製與閃爍。在 PageSpeed Insights 或實驗室測試中，以限速的行動裝置設定比較個人化版本與預設頁面。如果個人化主視覺是 LCP 元素，而且出現得比預設內容晚，代表決策發生得太遲了。
- 個人化工具的決策時間。大多數工具都會記錄做出決策所需的時間。長期追蹤，並在數字跳升時檢查有什麼變動。
- 備援率。規則失效、改為顯示預設版本的頻率。安靜地退回預設版本總比頁面壞掉好，但備援率偏高，代表訪客沒有看到登錄表上所說的內容。
在每批新規則上線前先記錄基準，這樣出現退步時就能追溯到造成問題的改動。RUM 工具或 Search Console 中的 Core Web Vitals 監控會標示持續性的問題，但前提是已有足夠的真實流量受到影響。
誰負責什麼
| 角色 | 職責 | 通常由誰擔任 |
|---|---|---|
| 個人化負責人 | 登記冊、命名、衝突處理順序、季度檢視、新規則的最終決定權 | 行銷營運或成長主管 |
| 內容創作者 | 為每個客群撰寫版位文案，並保持資訊即時正確 | 產品行銷、內容團隊 |
| 技術導入人員 | 設定規則、排除衝突、效能檢查 | 網站開發人員或技術型行銷人員，視工具而定 |
| 分析師 | 保留組、規則層級結果、標記應淘汰的規則 | 行銷分析師（該職務的工作內容請參閱行銷分析職涯） |
在小團隊中，一兩個人就身兼全部四種角色，只要登記冊存在就沒問題，因為這樣第二個人也能接手工作。唯一不能模糊共享的是負責人角色：如果每個人都負責整套規則，就沒有人會淘汰任何東西。關於大型組織的 RACI、導入階段與治理，請參閱企業個人化導入手冊。
衡量規則，而不只是計畫
計畫層級的保留組能告訴您，整體個人化是否值得保留，但無法告訴您五十條規則中是哪幾條在發揮作用。流量允許時，請為每條第二層與第三層規則設置各自的保留組或 A/B 測試；無法達到可判讀樣本數的規則，請在登錄表中標記為「未衡量」，而不是假設它們有幫助。我們關於衡量個人化 ROI 的文章說明了保留組規模與指標層級。
規則數量增加前的檢查清單
- 所有人都使用的命名規則
- 一份登錄表，記錄每條規則的負責人、目的、區隔、事實內容與測試狀態
- 書面的衝突優先順序，加上依層級劃分的元素負責權
- 至少為首頁和價格頁面準備版位範本
- 效能基準，以及每批規則上線後的檢查
- 一位具名負責人，以及下次季度檢視的日期
實用的第一步：將工具中所有上線中的規則匯出成上述登記冊格式。任何無法填寫完整的規則（不知道負責人、沒有明確目的、不知道是否有效），都列入第一次檢討的清單。如果您在 Markettailor 中設定，它的客群區隔功能會將客群定義集中在一處，讓規則間的重疊更容易被發現。