返回文章列表
ABM 與客群區隔

依職稱個人化您的 B2B 網站(角色對應指南)

2026年10月15日
作者:Markettailor 團隊
多元背景的 B2B 採購委員會成員一起在螢幕上檢視網站

一家3,000人公司的資安主管、產品經理和採購分析師,在同一週打開您的網站。他們屬於同一個採購委員會,正在評估同一個產品,看到的卻是同樣的首頁、同樣的案例研究和同樣的示範表單。資安主管想要您的 SOC 2 報告,產品經理想知道團隊是否真的會用,採購則想知道價格。依職稱個人化網站,就是讓他們每個人都先看到能回答自己問題的頁面。

這件事也比聽起來困難,而大多數指南都跳過了困難的部分。產業與公司規模幾乎可以從第一次瀏覽頁面時的 IP 查詢免費取得。職稱則不然:它屬於個人,而在大多數 B2B 網站上,這個人是匿名的。本指南談的是如何誠實地進行依職務個人化。內容包括該使用哪些職務分類、如何將雜亂的職稱對應到這些分類、職務資料實際從哪裡來(以及不會從哪裡來)、每個頁面要改什麼,以及如何判斷是否有效。

為什麼角色很重要,又為什麼常被忽略

B2B 採購是集體決策。Forrester 2024 年的買家旅程調查發現,一項採購決策平均有 13 人參與。每個人都帶著不同的問題閱讀您的網站。帳戶層級個人化能辨識出有一家德國物流公司的人在造訪,卻把該公司的每個人都當成同一位讀者。角色這一層,才能區分財務長與工程師。

團隊略過它有一個實際的原因:資料很少。反向 IP 查詢辨識的是公司,不是個人。只有當某人已經在您的 CRM 中、透過針對該職稱的活動進入,或是行為透露出身分時,您才會知道他的職稱。因此職務個人化永遠只能觸及少數工作階段,計畫必須圍繞這個事實設計,而不是假裝每位訪客都能被標記。

我們的立場:在產業或規模個人化已經上線後,才值得加入角色個人化,而它在三個頁面上最有價值(首頁、價格頁、Demo 表單)。不要從它開始,也不要建立二十個人物誌。

最值得優先區隔的四種角色

四個群組就能涵蓋採購委員會的分工方式。再多的話,每個區隔的流量就太少,無法衡量。

角色典型職稱想知道閱讀正確的 CTA
經濟決策者CEO、CFO、握有預算的副總花費多少、回報多少、合約長什麼樣子價格、ROI 內容、附成果的客戶案例價格與 ROI 試算表、與資深業務代表通話
技術評估者CTO、資安主管、架構師、工程經理架構、串接整合、資安、資料處理文件、API 參考、資安與信任頁面架構概覽、不含推銷的技術簡報
實務工作者分析師、營運經理、專員這能讓我這週輕鬆一點嗎?要花多久學會?功能頁面、教學、截圖、說明中心產品導覽、沙盒環境或錄製的 Demo
內部支持者總監、資深經理、團隊主管、產品經理我能在內部說服大家嗎?我的團隊會得到什麼?比較頁、同業客戶案例、投資報酬率資料內部提案資料包、參考客戶通話

內部支持者是大多數網站最照顧不周的角色。這個人不是簽約的人,卻是撰寫內部電子郵件、推動合約簽下的人。給他們可以轉寄的東西(一頁摘要、比較表、資安常見問題),往往是整個計畫中成本最低的勝利。

職稱與類別對應表

困難的不是撰寫規則,而是把您實際從 CRM、表單填寫與資料供應商(ZoomInfo、Apollo、6sense 等)收到的自由文字職稱,對應到上述四個類別。請以下表作為起始分類,並依您的市場調整。

類別C 級高階主管與副總總監與部門主管經理 & 主管個人貢獻者
經濟決策者CEO、CFO、COO、CRO、營收長、總裁、財務副總、營運副總、採購副總財務總監、採購總監、營運總監、財務主管、採購主管財務經理、採購經理、採購專員、品類經理採購專員、財務分析師(具採購權限)
技術評估者技術長、資訊長、資安長、首席架構師、資料長、工程副總、技術副總、資安副總、IT 副總、資料副總、平台副總工程總監、平台總監、基礎架構總監、資安總監、工程主管、平台主管、資安主管工程經理、技術主管、架構師、解決方案架構師、資安工程經理資深工程師、Staff 工程師、首席工程師、資安工程師、DevOps 工程師、SRE
實際使用者/終端使用者(在這個層級很少見)(在這個層級很少見)行銷經理、營運經理、業務營運經理、RevOps 經理分析師(行銷、業務、商業、資料)、專員、協調員、助理、研究員、初階/中階工程師
內部支持者 / 影響者行銷副總、產品副總、客戶成功副總(非經濟決策者時)行銷總監、產品總監、需求開發總監、成長總監、行銷主管、產品主管、成長主管資深經理、產品經理、資深產品經理、專案經理、團隊主管(很少從這裡開始)

關於這張表有一點要注意:同樣的職稱在不同產品中代表不同意義。如果您銷售的是行銷軟體,行銷副總就是您的經濟決策者,而不是內部支持者。使用這張表之前,請依您產品所服務的職能重新排序各列。

如何處理模稜兩可的職稱

很多職稱無法乾淨地歸類。以下預設規則涵蓋常見情況:

  • 沒有明確職能的「X 總監」:預設為內部擁護者。職稱籠統的總監,比較常是在內部提案,而不是簽約的人。
  • 員工不到 50 人公司的「X 主管」或「副總」:視為經濟決策者。在這種規模下,部門主管通常握有預算。
  • 資深與主任級工程師或分析師:實務使用者,除非公司規模在30人以下,這時權力結構夠扁平,可以把他們視為技術評估者。
  • 產品經理:擁護者。他們很少握有預算,但經常主導廠商評估。
  • 顧問和約聘人員:依職稱中的職能歸類(「Marketing Consultant」歸為實務使用者)。他們有影響力,但很少是購買者。
  • 小公司的老闆或創辦人:經濟決策者。
  • 空白或籠統的職稱(「Employee」、「Member of Technical Staff」、「Engineer」):放入未對應類別,這些工作階段改依行為判斷。

將對應關係保存為個人化工具或 CDP 中的單一查詢表,而不是在每條頁面規則中重複撰寫邏輯。這樣行銷只需在一個地方修改類別,更換資料供應商時也不必重寫整套分類。

角色資料實際上從哪裡來

避免使用「選擇您的職務」彈出視窗。大多數訪客會直接關掉,有些人出於好奇點了別的職務,而您為每個人都增加了摩擦。請改用以下來源,大致依可信度排序:

來源運作方式可靠性注意事項
已知聯絡人的 CRM 記錄在表單填寫或電子郵件點擊後,以 Cookie 比對到的回訪訪客高:職稱已存檔職稱會過時;至少每年從資料供應商更新一次
廣告活動目標設定UTM 顯示訪客來自針對某一職務的廣告或電子郵件(例如依職能鎖定的 LinkedIn 廣告活動)中到高鎖定範圍外流;同事會轉傳連結
網站上的行為工作階段中閱讀的頁面,透露出訪客正在問的問題中等,頁面越多越好需要兩次以上頁面瀏覽才能判斷
個人層級辨識供應商第三方聲稱能將匿名訪客比對到個人差異很大,主要涵蓋美國在 GDPR 下這屬於個人資料處理,需要合法依據;對歐盟流量啟用前請先確認

公司層級的訪客辨識可以搭配這些方式使用:它無法告訴您個人的職稱,但能告訴您公司,讓您將職務與產業和規模結合。我們的將網站個人化資料連結到 CRM 文章說明了如何將已知聯絡人的職稱回傳給網站。

推斷職務的行為規則

對匿名訪客而言,行為是主要訊號。起步時,簡單的規則勝過複雜的模型,因為您能解釋並檢查它們:

  • 在單一工作階段中瀏覽價格或 ROI 內容兩次以上:經濟決策者。
  • 瀏覽文件、API 參考或資安頁面兩次以上:技術評估者。
  • 瀏覽兩次以上功能頁面、教學或產品導覽:實際使用者。
  • 案例研究加上比較或替代方案頁面:內部支持者。
  • 其他情況:不指定角色,顯示預設版本。

當來源彼此衝突時,請使用優先順序而不是取平均:CRM 中的職稱優先於廣告活動情境,廣告活動情境又優先於行為。只有在行為訊號強烈且近期時,才應該覆寫 CRM 職稱(一位已知的「行銷經理」這週讀了四頁 API 文件,在這次採購中扮演的就是技術評估者)。我們關於B2B 網站行為區隔的文章更深入介紹了評分方式。

上線前,先用現實檢驗您的規則。拿上一季填寫 Demo 表單的聯絡人,查看他們轉換前瀏覽了哪些頁面,比較您的規則會指派的角色與他們的真實職稱。如果規則對其中許多人判斷錯誤,請在任何人看到個人化頁面之前先修正規則。

依角色調整每個頁面的內容

職務個人化不代表每個頁面都要寫四遍。在每個頁面上更改兩到四個元素,其餘保持不變。

首頁

變更主視覺標題、主打佐證與主要 CTA。範例文案(說明用,針對虛構的分析產品):

角色主視覺標題顯示的實證主要 CTA
預設掌握哪些帳戶已準備好購買標誌列預約展示
經濟決策者查看您的網站已經在創造哪些銷售管道來自財務或營收主管、談論成果的引言查看價格與 ROI 試算表
技術評估者只需一個 script 標籤,不必更動您的技術架構資安認證、整合工具標誌閱讀架構總覽
實務工作者一個下午建立您的第一個分眾日常工作流程截圖體驗產品導覽
內部支持者您的團隊這一季能交付的項目類似團隊的案例研究取得內部提案資料包

我們的首頁個人化攻略涵蓋首頁的其他部分。請在您已經個人化的元素上加入角色維度,而不是另外開闢新元素。

價格頁

這是各角色需求差異最大的地方。經濟決策者想知道合約期間的總成本,以及說服他人的理由,因此要以年度檢視與 ROI 試算表開場。技術評估者想知道每個方案包含什麼:API 限制、SSO、資料落地、支援等級。實際使用者想知道每個方案實際上能做什麼。內部支持者則需要可以拿給財務部門的東西:一份附有商業理由與兩個參考客戶的一頁摘要。

對所有角色顯示的價格本身要保持一致。調整呈現方式沒問題;但讓同一家公司的不同人看到不同數字,一旦他們互相比對,就會迅速失去信任。更多內容請參閱我們關於B2B 價格頁面個人化的文章。

產品與功能頁面

產品頁面需要改寫的地方最少。調整首屏的內容即可:為技術評估者提供架構圖和整合清單,為實際使用者提供工作流程截圖和教學,為經濟決策者和內部支持者提供類似公司以成果為主軸的案例研究。第一輪先讓功能清單本身保持不變。

示範表單

表單是不匹配代價最高的地方。經濟決策者想知道誰會參加通話、要花多久時間。技術評估者往往想要技術會議或文件,而不是業務通話。實際使用者則想不開會就看到產品。在標準預約示範旁提供適合各角色的替代選項(例如給評估者的「技術簡報」選項),就能留住原本會離開的人。

實作範例:一個帳戶、三位訪客

示意範例。一家600人的物流軟體公司正在評估一套報表工具。兩週內,該公司有三個人造訪:

  1. 訪客 A 來自鎖定財務職務的 LinkedIn 活動,並看了兩次價格頁。角色:經濟決策者(活動與行為兩者一致)。價格頁優先呈現年度成本檢視與 ROI 試算表。
  2. 訪客 B 是匿名訪客,閱讀了 API 參考文件、資安頁面與整合清單。角色:技術評估者(依行為判斷)。下次造訪時,首頁主視覺會切換為「無需變更您的技術堆疊」版本,展示表單則提供技術簡報。
  3. 訪客 C 是已知聯絡人(一年前填過網路研討會表單),職稱為「Senior Product Manager」。角色:內部支持者(依 CRM 職稱)。他們會看到同業客戶案例,以及內部提案資料包的 CTA。

同時,公司層級辨識顯示同一家客戶在兩週內有三個人造訪,這是採購小組訊號,無論角色為何,業務都應該知道。角色改變的是每個人看到的內容;客戶層級的觀點則決定業務何時介入。我們關於客戶評分的文章說明了後半部分。

60天導入計畫

  1. 第 1 到 10 天:推斷角色。載入職稱對照表、串接 CRM 職稱、撰寫行為規則,並以上一季的預約示範資料回測。
  2. 第11至25天:首頁。每個角色一個主視覺、佐證與 CTA 版本,再加上一個持續看到預設內容的保留組。上線前請用 A/B 測試計畫確定成功指標。
  3. 第 26 到 40 天:價格頁面。只調整包裝方式與主要 CTA。價格文案會直接影響商業結果,所以第一輪修改要小。
  4. 第 41 至 55 天:產品頁面。首屏的強調重點,以及功能清單下方的客戶案例。
  5. 第 56 至 60 天:檢討。將每個職務區隔與其保留組比較。保留在可信樣本下勝出的版本,淘汰其餘版本,並決定下一個要製作新內容的職務。

如果您的流量不大,就縮小計畫:一個職務、一個頁面、一個月。首頁上的技術評估者是很好的第一個測試對象,因為行為訊號很明確,而且內容通常已經存在於您的文件中。

毀掉角色式個人化的常見錯誤

角色太多。人物誌文件常列出十個以上的角色。每多一個角色,流量就被切得更細,直到什麼都無法衡量。第一季四個角色就很夠了。

沒有預設體驗。大多數工作階段永遠不會被標上角色。預設頁面本身就必須夠好;角色版本是在其上加值,而不是取代它。

只改文案卻不改 CTA。用財務風格的標題搭配「立即開始建置」,等於前功盡棄。行動呼籲必須符合該角色的下一步。

把每次造訪都當成第一次。第四次造訪的 CFO 已經看過您的推銷了。除了依職務,也要依造訪次數調整,例如從 ROI 試算表轉為直接提供會議邀約。

只看職務、沒有公司背景。50 人新創公司的財務長和 5,000 人大型企業的財務長,關心的事情不同。將職務與至少一個公司屬性面向結合;我們的依公司規模個人化指南是很自然的基礎層。

忽視隱私。向訪客顯示「歡迎,財務部的 Jane」會讓人毛骨悚然,而在歐盟,視您取得資料的方式而定,還可能違法。請低調地依角色個人化:改變強調的重點,但絕不宣告您知道什麼。

如何衡量

在區隔層級衡量。全站轉換率會因許多與角色版本無關的原因而變動。每週追蹤以下指標:

  • 每個角色區隔相對於自身保留組的轉換率。沒有提升的角色需要新的版本。
  • 職務涵蓋率:獲得職務標籤的工作階段比例。涵蓋率低會限制影響力;突然大幅上升通常代表某條規則變得太寬鬆。
  • 標籤準確度:每月比對推斷的角色與之後轉換者的職稱。
  • 下游品質:來自個人化工作階段的潛在客戶,轉為合格商機的比率是否高於保留組的潛在客戶。

Markettailor 的分群功能可讓您依 CRM 欄位、廣告活動參數與頁面行為定義角色分群,並將各分群的轉換率與保留對照組比較。無論使用什麼工具,衡量設計都比工具本身更重要。

從一個角色和一個頁面開始

挑選技術評估者,為他們撰寫一個首頁主視覺,並與預設版本對照測試一個月。如果勝出,再加入價格頁或第二個角色。如果沒有,您就以一個標題的代價,學到了這群受眾沒有在問哪個問題。

想看看職務分眾如何與公司層級識別結合,應用在您自己的流量上,請從我們的價格頁預約導覽。