CRM 會碰到哪些資料那篇把資料分成身分、交易、互動、同意四類。其中「互動」這一類有一個特性：它不會自己出現。
訂單不管有沒有人規劃，結帳時一定會寫進資料庫。但「會員看了哪個商品」「把東西加進購物車又拿掉」「點了 EDM 裡的哪個連結」，如果當初沒有人決定要記，這些行為發生完就消失了。
所以行銷問「能不能撈出近 30 天看過商品、但沒結帳的會員」，工程師的回答常常是：撈不出來，因為我們沒記。
這一篇講的就是「記」這件事。
埋點：決定在哪裡記一筆
「埋點」是指在網站、APP 的程式裡，選定某些時機送出一筆紀錄。例如：
- 商品頁載入完成時，送一筆「看了商品」
- 按下加入購物車時，送一筆「加入購物車」
- 結帳成功時，送一筆「完成購買」
每一筆紀錄叫一個事件。事件至少要有三樣東西：
- 發生了什麼：事件名稱，例如
add_to_cart - 是誰：使用者的識別碼
- 細節：例如哪個商品、多少錢、從哪個頁面來
實體店面沒有程式可以埋點，靠的是結帳時讓會員出示會員卡或報手機號碼。這一步就是把「這筆消費」跟「這個會員」接起來的時機，沒做到，店面的消費就是匿名的。
事件要先有規格
埋點最常見的問題不是漏埋，而是每個人埋得不一樣。前端工程師 A 把加入購物車叫 addToCart，APP 工程師 B 叫 cart_add，半年後有人要撈名單，發現同一件事有兩種名字、欄位也不一樣。
所以埋點之前要先有一份規格，常被叫做 tracking plan。它就是一張表：
| 事件名稱 | 什麼時候送 | 必帶欄位 | 誰會用 |
|---|---|---|---|
view_item | 商品頁載入完成 | 商品編號、分類、價格 | 行銷：撈「看過沒買」 |
add_to_cart | 按下加入購物車 | 商品編號、數量 | 行銷：購物車提醒信 |
purchase | 結帳成功 | 訂單編號、金額、商品清單 | 行銷、財務對帳 |
sign_up | 註冊完成 | 註冊管道 | 行銷：新會員歡迎信 |
事件名稱不用自己發明。GA4 有一份建議事件清單，電商相關的包括 view_item、add_to_cart、begin_checkout、purchase、refund，通用的包括 sign_up、login、search（Google Analytics 說明：建議事件）。照著用，換工具時比較好對應。
規格表最右邊那欄「誰會用」很重要。每個事件都要能說出是哪個名單、哪張報表在用它。說不出來的事件，通常只是在增加資料量。
我遇過這種情況。發現名單撈不出來之後才補埋點，但補上之前的那段時間，資料就是沒有了。埋點只能從現在開始記，沒辦法回頭補。這也是為什麼 tracking plan 要在需求出現之前先想過一輪：等到行銷問了才埋，第一檔活動一定撈不到。
匿名訪客怎麼接回同一個會員
這是埋點裡最容易出錯的地方。
一個人第一次來網站，還沒登入，系統不知道他是誰，只能先給他一個隨機的識別碼。他看了三個商品，加了一個進購物車，然後才登入。登入之後，系統知道他是會員編號 12345。
問題是：登入之前那三筆「看了商品」，算不算 12345 的？
追蹤工具的術語是這樣分的：還不知道身分時用匿名 ID（anonymousId），知道身分後用使用者 ID（userId），後者是「永遠不變的客戶識別碼，像資料庫的 ID」（RudderStack 文件：identify）。登入那一刻送出的 identify 事件，就是把兩者接起來的時機。
設計上要掌握一個原則：登入那一刻，要把「匿名 ID 對應到哪個使用者 ID」這組關係記下來。 有了這組關係，下游的資料倉儲或 CDP 才能把登入前的紀錄合併到同一個會員。沒記下來，登入前的行為就永遠是一個陌生人的。
（各家工具在登入時會不會自動回頭合併匿名紀錄，做法不同，要看你用的工具文件。上面的原則是不依賴工具的做法。）
使用者 ID 本身也有規則。GA4 規定送出的 User-ID「不得包含第三方可用來判斷使用者身分的資訊」（Google Analytics 說明：User-ID）。所以不能直接拿 email 或手機號碼當 ID，要用系統內部的會員編號。
記之前：要先告知
埋點記下來的是個人的行為，會員登入後，這些紀錄就連到了一個可識別的人。
個人資料保護法第 8 條規定，直接向當事人蒐集個資時，要明確告知 6 件事，包括蒐集的目的、個資的類別、利用的期間、地區、對象與方式（全國法規資料庫：個人資料保護法第 8 條）。
實務上，這代表隱私權政策和註冊條款，要寫得出「我們記哪些行為、拿來做什麼」。tracking plan 的「誰會用」那一欄，剛好就是這份說明的素材：每個事件拿來做什麼，本來就應該寫得出來。
（這段是依法條原文整理，不是法律意見。實際要告知到什麼程度，要問法務。）
AI 和 MCP 的角色
埋點和 AI 的關係有兩個方向。
AI 幫忙查： 行銷問「上週加入購物車但沒結帳的會員有幾個」，AI 透過 MCP 查事件資料。這時候 tracking plan 就是 AI 的說明書：MCP 工具要把事件名稱和欄位的意思一起提供給 AI，AI 才知道「加入購物車」對應的是 add_to_cart，而不是自己猜。
AI 幫忙檢查規格： tracking plan 是一份規格，實際送出的事件是不是照規格來，可以讓 AI 比對。例如找出規格裡沒有的事件名稱、缺必帶欄位的事件、同一件事有兩種名字。這種比對很適合交給 AI，因為它是重複、枯燥、但規則明確的工作。
有一件事不能交給 AI：決定要不要新增一個事件。 每多記一種行為，就多一種個資要告知、要保管。這個決定要由人來做，而且要能回答「誰會用」。
相關主題
- CRM 會碰到哪些資料
- 下一篇：企業系統之間怎麼交換資料