返回文章列表
分析 & 資料

用於個人化資料的 CRM 網站整合

2026年10月15日
作者:Markettailor 團隊
〈如何將網站個人化資料連結到您的 CRM〉的精選圖片

您的網站個人化工具知道哪些公司造訪您的網站、閱讀了什麼,以及屬於哪些區隔。您的 CRM 知道交易階段、聯絡人和營收紀錄。如果兩者從不交換資料,業務代表打電話給帳戶時不會知道對方剛看了什麼,而您的個人化規則也分不出進行中的商機和冷名單。

差異在第一通電話就會顯現。「我看到您造訪了我們的網站」會被忽略。「您的團隊這週好幾次查看了我們的區隔文件和價格頁」則讓業務代表有話可聊。本文說明第二種說法背後的機制:要同步什麼、如何對應欄位、Salesforce 與 HubSpot 有什麼差異,以及這類專案通常在哪裡出錯。

您的 CRM 實際需要哪些個人化資料

直覺會想把所有東西都推過去:每次頁面瀏覽、每個工作階段、每次客群指派。別這樣做。CRM 是為結構化的關係資料打造的,不是原始點擊流。把頁面瀏覽倒進去會埋沒有用的訊號、耗盡 API 配額,也讓報表更難信任。擴充後的公司欄位還能讓您縮短名單蒐集表單,這是另一項收穫。

有五類資料值得同步。

1. 公司識別

當您的訪客辨識將匿名訪客比對到某家公司時,這筆比對應建立或更新公司記錄。只保留業務或報表會用到的欄位:

  • 公司名稱與網域
  • 產業與員工人數區間(來自資料擴充)
  • 國家或總部所在地
  • 首次在您網站上出現的日期
  • 首次被辨識造訪的來源或管道

少了這個,其他都串不起來。如果 CRM 只在有人填寫表單時才知道某個帳戶,那家公司先前的每一次造訪對業務來說都是看不見的。

2. 分群成員資格

區隔比原始頁面瀏覽數更有用,因為它已經包含了您對這個客戶是誰的判讀。常見的值:

  • 產業區隔(例如「金融科技」、「醫療」)
  • 規模層級(「中型市場」、「大型企業」)
  • 旅程階段(「認知」、「考慮」、「決策」)
  • 興趣集群(「ABM」、「分析」、「隱私」)

分群變動應該快速傳到 CRM。如果某個帳戶在週二從考慮階段進入決策階段,週日才送達的每週批次就太晚了。快速同步通常代表由事件觸發推送,而不是排程拉取;這篇Webhook 與 API 比較說明了各自適用的情境。

3. 單一互動分數

在客戶記錄上同步單一計算後的分數,而不是背後的各項組成。0到100的數字欄位,業務一看就懂,也方便篩選。除了數量之外也要考量新近程度:昨天瀏覽15頁,分數應該高於三個月前瀏覽20頁。如果可以,再加上一個簡短的文字欄位說明原因(「本週看了兩次價格頁」)。附上原因的分數會有人採取行動;原始頁面瀏覽數則會被略過。

4. 關鍵頁面造訪,而不是所有頁面造訪

只同步造訪了顯示購買意圖頁面的紀錄:

  • 價格(時間戳記與次數)
  • 特定功能頁面
  • 案例研究(哪個產業或使用情境)
  • 比較頁與競品頁
  • 整合與文件頁面

將它們記錄為活動或時間軸項目,讓業務代表在通話前快速瀏覽。某人捲動瀏覽過的 47 篇部落格文章清單,並不是有用的背景資訊。

5. 帶有脈絡的轉換事件

表單填寫、預約示範與下載,都應附帶當下的背景資訊:訪客看到哪個個人化版本、屬於哪個客群,以及當時的互動分數。這能告訴業務這筆名單有多熱,以及該從哪個角度開場。

兩種串接方式

直接 API中介軟體(CDP / iPaaS)
運作方式個人化工具呼叫 CRM API 並建立或更新記錄工具將事件傳送至 Segment、Workato、Tray.io 或 CDP,再由它們轉換並分送至 CRM 和其他系統
適合單一目的地、營運團隊小、已有原生連接器目的地很多,或您已在使用 CDP 或 iPaaS
缺點每個新目的地都是一個新的整合;直接受到速率限制影響;CRM API 改變時就會中斷額外成本、多一套要維護的系統、多一層延遲

如果您已經透過 CDP 或 iPaaS 傳送其他資料,個人化資料也用同樣方式傳送。如果 CRM 是唯一的目的地,直接串接比較簡單;為兩個系統的整合建置中介軟體,多半只會多花好幾個月。Markettailor 可以將訪客與公司資料直接同步到 Salesforce 和 HubSpot,不需自訂程式碼即可實現直接串接。

Markettailor 串接頁面,已連接 HubSpot、Salesforce、Slack 與 Google Analytics 4,並顯示追蹤程式碼與近期 CRM 同步活動記錄
Markettailor 設定中顯示的 CRM 與警示整合,以及最近的同步紀錄(範例資料)

欄位對應:每個人都低估的部分

API 連接是簡單的部分。困難的是決定個人化資料如何對應到 CRM 紀錄。做錯了,就會出現重複資料、欄位被覆寫,業務也不再信任資料。

公司比對

您的個人化工具識別的是公司;您的 CRM 中則是帳戶。比對邏輯決定兩者能否對上。以下選項依可靠度由高到低排列:

  1. 共用外部 ID。兩個系統都帶有相同的資料補充 ID(例如 LinkedIn 公司 ID)。最可靠,但前提是兩者都由同一家供應商補充資料。
  2. 網域比對。將訪客的公司網域與 CRM 帳戶上的網站欄位比對。CRM 資料乾淨時效果很好;遇到網站欄位空白,或公司擁有多個網域時就會失準。
  3. 模糊名稱比對。「Acme Corp」=「Acme Corporation」。適合作為備援,但遇到常見名稱時有風險。

實務上,大多數團隊以網域作為主要鍵值,模糊名稱比對作為備援,其餘則交由人工審核佇列處理。在自動化任何下游流程之前,請先用自己的資料衡量每個階段的比對率。

避免重複

  • 先搜尋再建立。一定要先查詢是否有既有記錄。
  • 從僅更新模式開始。前幾週只更新已存在的紀錄。這能在比對造成損害之前,讓您看清它實際上有多準確。
  • 只在超過信心門檻時建立記錄。低信心的比對結果交由人工審核。

跳過僅更新模式,是這類專案在第一週就讓 CRM 塞滿重複帳戶的常見原因,而清理這些資料所花的營運時間,遠多於試跑所需的時間。

自訂欄位

在建立同步之前先設計欄位。以下是帳戶上可行的起始欄位組合(顯示 Salesforce API 名稱;在 HubSpot 中這些是公司屬性):

欄位類型
Personalization_Engagement_Score__c數字,0-100
Personalization_Segment__c選項清單
Buyer_Journey_Stage__c下拉選單:認知、考慮、決策
First_Website_Visit__c / Last_Website_Visit__c日期
Website_Visit_Count__c數字
Top_Content_Interest__c文字

在活動時間軸上記錄價格頁面造訪、關鍵功能頁面造訪、區隔變化與大幅度的分數跳升(例如從 40 升至 75)。

Salesforce 備註

API 配額。Salesforce 將 REST、SOAP 和 Bulk 呼叫計入滾動24小時的配額。根據Salesforce 限制快速參考,配額取決於版本以及授權的數量和類型;Enterprise Edition 起始為每24小時100,000次請求。在決定同步頻率之前,請在「設定 > 系統概觀」中查看您組織的實際數字。要維持在配額內:

  • 批次更新。sObject Collections 端點一次請求最多可更新 200 筆記錄。
  • 依排程(每隔幾小時)推送互動分數,而不是每次變動都推送。
  • 只同步關鍵頁面造訪。
  • 初次回填請使用 Bulk API。

活動類型與權限。建立專屬的「網站個人化」活動類型,讓業務代表能將這些事件與自己的活動分開篩選。將個人化欄位對業務設為唯讀;業務代表不應該編輯互動分數。

第一天就要建立的兩份報表。第一,高互動但沒有進行中商機的帳戶:沒人在經營的銷售管道。第二,依個人化區隔的贏單率,這會回饋到您的區隔策略。

HubSpot 備註

建立一個名為「Website Personalization」的屬性群組,並將所有自訂屬性放在其中。屬性類型可清楚對應:分數與次數用數字、區隔與階段用下拉選單(才能用於清單與篩選)、首次與最近造訪用日期、興趣標籤用單行文字。

針對關鍵頁面造訪與區隔變化,HubSpot 的時間軸事件可讓應用程式將自訂事件類型寫入公司與聯絡人的時間軸。定義一個範本(「網站個人化活動」),以頁面網址、頁面類別與區隔作為屬性。這些寫入仍會計入您應用程式的 API 限制,因此請像在 Salesforce 上一樣批次處理。

資料進入 HubSpot 後,工作流程會將它轉化為行動。例如:

  • 互動分數超過 70:為公司負責人建立任務。
  • 旅程階段變為決策:將主要聯絡人加入一個序列。
  • 目標客戶第三次造訪價格頁:發布到業務的 Slack 頻道。

到了這一步,您的個人化分析就不再只是一個需要有人記得打開的儀表板。

什麼資料多久同步一次

幾分鐘內每 1-4 小時每日批次
表單填寫與展示預約
目標客戶的價格頁造訪
辨識出新公司
互動分數
分群變動
旅程階段變動
造訪次數彙總
興趣標籤
首次/最近造訪日期

所有資料都即時同步會耗盡 API 配額,並讓紀錄充斥更新。所有資料都每日批次處理,則代表目標帳戶的價格頁面造訪要隔一夜才會被看到。上述的拆分方式讓時效性訊號保持快速,其餘資料則以低成本批次處理。

這類專案容易出錯的地方

同步沒人看的資料。在建置任何東西之前,花 30 分鐘分別和幾位業務代表聊聊,問他們在通話前想知道什麼。依他們的答案建置。業務代表找得到的幾個欄位,勝過他們直接捲過的十五個欄位。

沒有所有權規則。當兩個系統都有同一個欄位(例如產業)時,要決定以誰為準。通常 CRM 負責業務維護的資料(交易階段、聯絡人),個人化工具則負責行為資料(分數、區隔、造訪)。沒有這個規則,兩個系統就會不斷互相覆寫。

沒有試跑。以試跑模式對 CRM 執行比對,拉出100筆比對結果並人工檢查。如果錯誤太多,先修正邏輯,再讓任何東西寫入正式環境。

由單一團隊獨自建立。行銷營運知道有哪些資料;業務營運知道業務代表會看哪些欄位。只由行銷建立,資料會落在沒人查看的欄位;只由業務建立,最好的訊號會被遺漏。這場設計會議本身,就是以訪客資料協調業務與行銷的一環。

設定完就不管。每月召開檢討會議,請業務說明用了哪些資料、缺少什麼,然後調整欄位、評分與警示。

如何判斷是否有效

目標由您自己設定,但上線前後都要衡量以下項目:

  • 採用率:過去7天內開啟過個人化欄位或活動的業務比例。
  • 健康度:同步錯誤率,以及您抽查得出的比對準確度。
  • 涵蓋率:近期有網站活動的帳戶中,已填入個人化資料的比例。
  • 跟進速度:從互動激增到第一次業務接觸的時間。
  • 銷售管道:個人化觸發通知後建立的商機。

前三項在第1-4週告訴您管線是否正常運作。後兩項則在接下來幾個月告訴您,它是否改變了業務的行為。

五週導入計畫

  1. 第1週,設計。訪談幾位業務。挑選5-8個欄位。建立自訂欄位。寫下比對邏輯和所有權規則。
  2. 第2週,建置與試運行。串接各系統,以試運行模式執行比對,人工檢查100筆比對結果,修正錯誤。
  3. 第3週,僅更新。在不建立紀錄的情況下開啟同步,持續五個工作天。觀察錯誤和對應問題,並取得兩三位業務的回饋。
  4. 第 4 週,全面啟用。允許建立超過信心門檻的紀錄、設定分層同步排程、建立兩份報表,並告訴業務資料存放在哪裡。
  5. 第5週起。每月與業務檢討;調整欄位、評分與自動化流程。

如果只能做一件事

將公司識別結果與互動分數同步到帳戶記錄上。光是這樣,業務就能知道哪些公司此刻正在研究您。您的訪客識別設定提供公司資料,您的帳戶評分模型定義分數,而 CRM 則是業務本來就會查看的地方。本文其他內容都可以之後再做。