官網追蹤碼補裝清單（給負責官網的工程師）

整理：miru（廣告代操）｜依據：2026-09-24 查看公開網頁原始碼與 GTM 容器設定（版本 6），只讀取，沒有送出任何預約、付款或表單 官網：https://www.innerjourneymap.com

先用白話說（給一千）

網站已經有預約頁和課程結帳頁，這份清單主要是在這個基礎上，把「讓廣告看得到成果」的追蹤接上去，另外附幾項跟預約頁體驗、隱私說明有關的建議。

廣告之後會帶人到「預約一對一諮詢」頁（/booking/）。這一頁目前看起來還沒裝追蹤碼，所以有人從廣告進來、送出預約，廣告後台應該還記不下來；付款後的購買紀錄，也有幾個設定看起來要調整。 補好之後可以做到三件事：知道廣告帶來幾筆預約、分得出每筆預約是從廣告／IG／其他地方來的、讓廣告系統照「真的會預約的人」去找相似的人。 所以我們會等預約頁補好、驗收過，再開以「預約」為目標的廣告——數字記得準，之後每一步調整才有依據。

清單項目看起來多，開廣告前要先完成的是第一段的 1、2、3、5 項（第 4 項等靈魂藍圖下架後就不用做；下架前開投的話，仍照第 4 項最後一點處理）；第二段是建議一起處理的，先後順序可以跟工程師討論（其中第 10、11 項可能需要提前，第 1 項有說明）；第三段是我們這邊自己測。你需要決定的幾件事，整理在最後的「分工一覽」。

名詞一句話（工程師可略過） - Meta 像素：Facebook／IG 廣告的追蹤碼（本站 ID 1731594144935808） - GTM：Google 標籤管理工具，統一放追蹤碼的容器（本站 GTM-P8SCG4W8）；GA4（Google 網站分析）透過它載入 - Lead：「有人送出預約／留下聯絡資料」這個事件 - UTM、fbclid：網址後面標示「從哪裡來」的參數；fbclid 是 Meta 在廣告被點時自動加上的 - CAPI：由網站伺服器直接回報給 Meta，不經過瀏覽器

想先請教工程師的四件事

先謝謝你幫忙。這份是我們從公開頁面和 GTM 設定看到的現況，加上建議的做法；網站內部的狀況你最清楚，如果哪裡跟實際情況不同，或你有更順手的做法，直接跟我們說就好。下面四題先回覆的話，後面幾項的做法就比較好定。

1. 預約送出時，伺服器端（/api/booking）目前有沒有另外回報給 Meta（CAPI）？會影響第 2 項做法。
2. GTM 目前是由哪一位負責發布修改？（可能跟寫網站程式的人不同，方便我們知道 GTM 的部分要跟誰對）
3. 目前有沒有預覽或測試環境（和正式站分開的網址）？第 5 項驗收需要它。
4. /api/booking 預約成功時，回傳資料裡有沒有這筆預約的編號？會決定第 2 項的事件編號（event_id）怎麼產生。

以下每項標記：原始碼已確認＝從公開原始碼看得到的現況；待權限後實測＝要開權限、實際走一次才知道。

一、開投前必做

1. /booking/ 補上 Meta 像素與 GTM

• 上線前提（先確認）：Meta 像素有一個「自動進階比對」設定，開啟時會自動讀頁面表單的 Email、電話、雜湊後送給 Meta。若目前是開啟的，像素一裝上 /booking/ 就會送出預約表單的聯絡資料——那麼第 10 項（隱私告知）與第 11 項（隱私權政策揭露 Meta）要在第 1 項上線之前完成；另一條路是先在事件管理工具關掉自動進階比對。開不開要權限開好後才查得到（見第三段第 8 條）。
• 改哪裡：/booking/ 頁面（目前只載入 booking-client.js）
• 改成什麼：跟其他頁一樣載入像素與 GTM，但只選一種掛法。建議統一由 GTM 掛像素，之後加事件不必改頁面程式；若選直接嵌碼，GTM 裡就不要再送同一個像素。GTM 載入後，GA4 也會跟著有。
• 為什麼：這頁目前還記不到「有人進來看」。
• 怎麼驗：在預覽網址上用 Chrome 外掛 Meta Pixel Helper 看 /booking/，頁面瀏覽（PageView）送出 1 次（不是 0，也不是 2）；用 GTM 預覽模式看到 GA4 有送。
• 狀態：現況沒裝原始碼已確認（頁面內沒有像素與 GTM；瀏覽器實測 fbq、dataLayer 都不存在）

2. 預約成功那一刻，送一次 Lead

• 改哪裡：booking-client.js 的送出流程（第 386 行起的 submit 處理）裡，requestJson('/api/booking') 成功回傳後的下一行——也就是 form.reset() 之前、await loadSlots() 之前——立刻送。不要寫在 showBookingSuccess 裡、跟在 successDialog.showModal() 後面：瀏覽器不支援對話框時那段會提早結束，Lead 就漏送

• 改成什麼：

  • 只在這一步送一次 Meta Lead，加一個 GA4 事件（例如 generate_lead）
  • 按下送出時不送；送出失敗（沒選時段、時段被搶、欄位錯誤、服務錯誤）不送
  • 每次送 Lead 都附一個唯一的事件編號（event_id）：/api/booking 有回傳預約編號就用它；沒有的話，送出前在前端產生一組唯一編號（例如 crypto.randomUUID()），放進送給 /api/booking 的資料、存進預約紀錄，Lead 也用同一組
  • 寫法：直接嵌碼時寫 fbq('track','Lead',{},{eventID: 編號})（編號放第四個參數）；走 GTM 時 dataLayer.push({event:'booking_success', event_id: 編號})，GTM 裡用資料層變數讀出來，放進 Meta 標籤的 eventID
  • Lead 與 GA4 事件的參數一律不放姓名、Email、電話、「想討論的問題」原文
  • 網址帶 product／trade 參數的預約，Meta Lead 與 GA4 事件都不送（見第 4 項）
  • 補充：送出中按鈕已經會停用（原始碼已有），把 Lead 放在成功那一步即可，不必另做防連點
  • 為什麼：預約成功是同一頁跳視窗、網址不變，沒有「感謝頁」可以靠網址判斷，只能在程式裡送；event_id 讓日後加上伺服器回報時，Meta 能把同一筆合併、不會算兩次。
  • 怎麼驗：在預覽網址上，我們用 Meta 事件管理工具的「測試事件」加 Pixel Helper 看：成功 1 筆，Lead 1 次、帶 event_id；送出失敗，0 次；連點，仍是 1 次。電腦、手機各測一次（測試預約會先跟一千講好，事後取消）。
  • 狀態：現況送不出 Lead原始碼已確認（booking-client.js 沒有任何追蹤呼叫）；伺服器端有沒有 CAPI 待工程師回覆

3. 把「從哪裡來」寫進預約紀錄

• 改哪裡：全站每頁（可用 GTM 的「所有頁面」自訂 HTML，或加進共用的 light-site.js）＋ /booking/ 頁面程式 ＋ /api/booking 的送出內容 ＋ 預約紀錄或後台

• 改成什麼：

  • 進站時讀網址上的 utm_source、utm_medium、utm_campaign、utm_content、utm_term、fbclid，以及 referrer（上一頁網址），跟著預約一起送出、存進紀錄；後台能看到或匯出這些欄位
  • 任何一頁的網址只要帶 utm_* 或 fbclid，就把它們連同當下的 referrer 存進 sessionStorage（瀏覽器暫存）；之後又帶了新參數就覆蓋，沒帶就保留舊的
  • /booking/ 送出時，先讀網址上的參數，沒有再讀暫存的，一起送出
  • 另外一起送出並存下 Meta 的兩個 cookie：_fbc（廣告點擊編號）和 _fbp（瀏覽器編號），日後做第 13 項伺服器回報時可提高比對率
  • 前提說明：sessionStorage 只在同一個分頁有效，換分頁會遺失；廣告直接導 /booking/ 的主要情況不受影響
  • 參數是空的時候，照常可以預約
  • 為什麼：廣告、一千自己的 IG、之後的 threads 會各用不同標記的連結；紀錄裡有來源，才分得出每筆預約是誰帶來的，也才能跟廣告後台對帳。（廣告會用乾淨的 https://www.innerjourneymap.com/booking/ 加廣告專屬標記，不用現有的預約短網址——那條短網址寫死了 IG 標記和一組點擊編號。）
  • 怎麼驗：用我們給的測試網址（帶測試 UTM 與 fbclid）開預覽頁、送一筆測試預約，後台那筆紀錄看得到正確來源；不帶參數時欄位為空、預約照常成功；網址多帶參數時，頁面照常運作。
  • 狀態：現況送出的內容只有時段、姓名、Email、電話、LINE ID、預約項目、想討論的問題，沒有來源欄位原始碼已確認

4.（靈魂藍圖下架後可略過；下架前開投仍需處理）付款後來排時段的客人

• 現況：付款結果頁 /checkout/result/ 只有靈魂藍圖的兩個方案（soulmap-overview、relationship-blueprint）付款成功後，「預約時段」按鈕會把人導到 /booking/?product=…&trade=…；其他方案（導航先修課 starter、導航升級班 upgrade、靈魂導航學程 master）付款成功後導向「設定密碼並進入課程」（/members/setup-password/），不會進預約頁原始碼已確認，僅限網址帶 RtnCode=1 時。
• 一千已告知靈魂藍圖會拿掉（時間待確認）。/soulmap/ 的付款入口與結果頁的「預約時段」分流一起拿掉後，就不會再有付款客人進預約頁，本項可以略過；下架前若仍開放購買，照下一點處理。
• 如果下架前仍有人購買：讀取 product、trade 兩個參數存進預約紀錄，這類預約不送 Lead（已經付款的客人不是新名單，混進去會讓名單數與每筆成本失真）。

5. 改完先放預覽網址，測過再上線

• 改哪裡：上線前的流程
• 改成什麼：第 1–3 項（第 4 項若靈魂藍圖還沒下架也一起）先改在預覽或測試環境，把網址給我們；我們測完回覆「可以上線」，再發布。GTM 的部分建議先用預覽模式測完再發布新版本，版本說明寫上改了什麼，之後要回頭查會比較方便。
• 為什麼：追蹤碼設錯不會跳錯誤訊息，只會安靜地記下錯的數字；上線前驗一次最省事。
• 怎麼驗：我們照上面每項的「怎麼驗」走一遍，回覆結果清單。
• 狀態：待權限後實測（需要事件管理工具與 GTM 的檢視權限）

二、建議一起做

6. 像素掛法全站二擇一

• 改哪裡：全站頁面 head 裡直接嵌入的像素碼，以及 GTM 裡初始化同一個像素的自訂 HTML 標籤
• 改成什麼：保留一種（建議 GTM，與第 1 項一致），另一份移除。建議在做第 1、2 項之前先定好。
• 為什麼：目前兩處都裝了同一個像素；實測首頁、/about/ 各只送出 1 次頁面瀏覽，目前沒看到重複。但之後加 Lead、購買事件時，如果兩邊都加，一筆就會算兩次。
• 怎麼驗：用 Pixel Helper 逐頁看（首頁、課程頁、結帳頁、付款結果頁），每頁 PageView 1 次。
• 狀態：兩處都裝原始碼已確認；重複送出目前實測沒看到

7. 付款結果頁補 Meta 購買事件（付款成功才送）

• 改哪裡：/checkout/result/
• 改成什麼：在 /checkout/result/ 現有的 rtnCode === "1" 分支裡送購買事件（Purchase），金額用網址上的 TradeAmt、幣別 TWD、事件編號用 MerchantTradeNo（照 fbq 第四個參數 eventID 的寫法）；送出後把這個 MerchantTradeNo 記在 localStorage，下次看到同一個編號就不再送，重新整理才不會重送。付款失敗（RtnCode 不是 1）或網址沒有 RtnCode 時不送。
  • 注意：網址上的付款結果可以被人手動偽造（直接打開 /checkout/result/?RtnCode=1 也會顯示成功），所以正式數字以伺服器收到綠界付款成功通知（ReturnURL，先驗 CheckMacValue 確認是綠界送的）後用 CAPI 回報為準，瀏覽器端只當輔助。
• 為什麼：付款結果頁目前只送頁面瀏覽，廣告後台看不到任何購買。首月廣告以預約為主，所以列建議；如果有廣告直接導去課程結帳，這項就要在開投前做好。
• 怎麼驗：權限開好後，優先用綠界測試環境走一次（不下真單）：付款成功，購買事件 1 次、金額正確；付款失敗，0 次。
• 狀態：現況沒有購買事件原始碼已確認；付款是否會跳到綠界、再回到結果頁待權限後實測（程式看起來很可能如此，未實測）

8. GTM：調整 GA4 購買與開始結帳的觸發條件，移除多送的事件

• 改哪裡：GTM 容器 GTM-P8SCG4W8（目前版本 6）

• 改成什麼：

  • 購買（purchase）：
  • 條件裡的 Page Path 寫成「checkout/result/」，少了開頭的斜線，照設定不會觸發 → 改成「/checkout/result/」
  • 條件另外要求網址包含「?plan=」，只有 plan 排在第一個參數才會命中 → 建議拿掉這個條件，改用 GTM 的「網址查詢參數」變數讀 RtnCode，條件寫成「RtnCode 等於 1」；plan、TradeAmt、MerchantTradeNo 也用同一種變數讀出來帶進事件
  • 加上付款成功判斷（RtnCode=1），並帶金額（TradeAmt）、幣別、訂單編號（transaction_id，避免重新整理時重複算）
  • 若綠界是用 POST 帶回結果、網址上沒有這些資料，建議改由結果頁程式確認付款成功後，把資料推給 GTM
  • 開始結帳（begin_checkout）：目前用「完整網址完全等於」比對 ?plan=starter／master／upgrade。學程方案的網址會多帶 cohort 參數，靈魂藍圖解讀的兩個方案也不在清單內，所以會漏算 → 維持頁面載入觸發，只把條件換成「頁面路徑等於 /checkout/」，方案名稱當參數帶出，不要比對完整網址。
  • 多送的事件：有一個 GA4 事件標籤把 GTM 內部的事件名稱當成事件名稱，每頁會多送一個叫「gtm.js」的事件 → 移除或改正。
  • 為什麼：GA4 的購買數目前看起來會一直是 0，開始結帳會漏算，多出來的事件會混進報表。之後要用 GA4 對帳，這幾項要先對。
  • 怎麼驗：用 GTM 預覽模式逐項看有沒有觸發；在 GA4 即時報表確認不再出現 gtm.js 事件。
  • 狀態：設定內容原始碼已確認（讀取 GTM 容器設定）；實際觸發情形待權限後實測（用 GTM 預覽模式）

9. 結帳網址不帶 Email

• 改哪裡：light-plan-checkout.js 的 checkoutPageUrl（有 Email 時會在結帳網址加上 &email=），以及 /checkout/ 讀取網址 email 來預填欄位的部分
• 改成什麼：checkoutPageUrl 拿掉 &email= 這段（程式裡已經有 sessionStorage 的 light_checkout_email 可以沿用）；/checkout/ 也不要再從網址讀 email。信件、LINE 裡的結帳連結也都不放 email——追蹤碼在頁面一開頭就會把網址送出去，事後再從網址清掉也來不及。
• 為什麼：結帳頁有裝追蹤碼，網址會被一起記錄；Email 放在網址裡，就會跟著送到 Meta 和 Google，GA4 的政策也不允許收這類個人資料。
• 怎麼驗：從各個入口（課程頁、藍圖解讀頁、信件或 LINE 常用的連結）進結帳頁，網址都不含 email。
• 狀態：程式有這個寫法，但站內正常點擊的路徑目前沒觸發（網址只有 ?plan=…）原始碼已確認。如果有信件或 LINE 用帶 Email 的連結導進結帳頁，就會發生。

10. 預約頁電話欄加用途說明與隱私權連結

• 改哪裡：/booking/ 表單
• 改成什麼：電話欄旁加一句用途說明（文字由一千確認），表單下方放隱私權政策連結。電話要不要從必填改成選填，由一千決定。
• 為什麼：目前姓名、Email、電話三欄必填，頁面上還沒有隱私說明。廣告帶來的多半是第一次認識一千的人，先講清楚資料用在哪，填起來比較安心；這也是之後要把名單用在廣告之前的前提（見第 11 項）。
• 怎麼驗：在預覽頁用眼睛確認，連結點得開。
• 狀態：原始碼已確認

11. 隱私權政策補完

• 改哪裡：/privacy-policy/

• 改成什麼：

  • 補上站名與經營者
  • 寫出網站使用 Meta 像素、Google Analytics（透過 GTM）等追蹤工具，以及用途
  • 目前第五條「不提供個人資料給私人企業」的寫法，請跟實際使用追蹤工具的情況對齊
  • 條文細節建議一千請熟悉個資的專業人士確認
  • 為什麼：開頭的站名目前是空白，正文也沒提到 Meta、Google。之後如果要把預約名單用在廣告（例如上傳名單找相似的人，或由伺服器回報雜湊（SHA-256 單向轉碼，不是加密）後的 Email、電話），這項要先完成。
  • 怎麼驗：用眼睛確認。
  • 狀態：原始碼已確認

12. 沒有時段時的頁面顯示

• 改哪裡：/booking/ 的時段區
• 改成什麼：目前沒開放時段時，會顯示「目前尚未開放可預約時段」，客人還沒有下一步可以按。建議加一個下一步（例如加 LINE 詢問，或留候補），內容由一千決定。
• 為什麼：廣告會持續帶人進來，遇到沒有時段的空檔時，有下一步才接得住。
• 怎麼驗：在預覽環境把時段清空，看畫面。
• 狀態：顯示文字原始碼已確認

13.（可選）伺服器端回報給 Meta（CAPI）

• 改哪裡：/api/booking、綠界付款成功通知的接收端
• 改成什麼：預約成功時回報 Lead、付款成功時回報 Purchase，事件名稱要跟瀏覽器端一模一樣、event_id 用同一個（預約用第 2 項的編號，付款用 MerchantTradeNo）。Email、電話先整理格式再做 SHA-256 雜湊：Email 去掉空白、轉小寫；電話轉成含國碼的純數字（例 0912345678 → 886912345678）。另外帶 action_source=website、event_source_url、client_ip_address、client_user_agent，以及第 3 項存下的 _fbc、_fbp（這幾個不用雜湊）。「想討論的問題」這類自由填寫欄一律不傳。付款回報要綁在綠界付款成功通知（ReturnURL），並先驗 CheckMacValue。測試時帶測試事件代碼（test_event_code）。建議在第 10、11 項完成後再做。
• 為什麼：有些人關掉分頁、或瀏覽器擋追蹤時，瀏覽器那端會漏記；伺服器回報可以補上。
• 怎麼驗：在事件管理工具看伺服器來源的事件，以及同一筆有沒有正確合併。
• 狀態：目前有沒有 CAPI，待工程師回覆

14.（選單改版時一起做）直播會員登記頁的追蹤與同意欄

• 改哪裡：一千規劃的新選單中「六堂免費直播 → 導向會員登記可觀看」那一頁（會員登記／註冊流程；實際放在哪、怎麼做，由工程師決定）
• 改成什麼：①登記完成那一刻送一次「完成註冊」事件（Meta 的 CompleteRegistration，GA4 可用 sign_up），同樣帶事件編號、不帶姓名 Email 等原文；「完成」以表單送出成功（或 Email 驗證完成，擇一並固定）為準，只送一次 ②跟第 3 項一樣把來源（utm、fbclid）寫進會員紀錄 ③登記表單加一個獨立、預設不勾的「同意接收課程與活動訊息」勾選欄，跟觀看直播的必要通知分開
• 為什麼：這一頁會成為新的名單入口；記得到、分得出來源，之後才能判斷哪種內容帶來名單。獨立同意欄是日後寄課程資訊的前提；若之後要把名單用在廣告比對，還需要隱私權政策說明這個用途（見第 11 項），同意文字也要涵蓋，建議請熟悉個資的專業人士確認。
• 怎麼驗：新選單在預覽環境時，走一次登記流程（先跟一千講好），確認事件 1 次、紀錄有來源、同意欄預設沒勾。
• 狀態：新選單尚未上線，登記頁實際做法待確認

三、權限開好後由我們實測（全部待權限後實測）

1. 帳號歸屬：像素屬於哪個 Meta 企業管理平台；GTM 的擁有者、發布權限、版本紀錄
2. CAPI：事件管理工具裡有沒有伺服器來源的事件；如果有，同一筆有沒有正確合併、有沒有一直卡在等待中
3. 頁面瀏覽次數：電腦用 Pixel Helper、手機用「測試事件」，逐頁確認 PageView 各 1 次
4. Lead 從頭到尾測一次：先跟一千講好時段，送一筆測試預約（電腦、手機各一次），事後取消。確認成功送 1 次、失敗不送、連點不重複、帶 product 的預約不算
5. 點擊編號：從帶 fbclid 的網址進站後，瀏覽器有沒有產生 _fbc（存放 Meta 點擊編號的小檔案）
6. 付款路徑：每種付款方式會不會離開官網到綠界、回到 /checkout/result/ 時帶了哪些資料、結果頁的事件有沒有觸發（優先用綠界測試環境，不下真單）
7. 網域驗證與事件優先順序：網域驗證建議完成；事件優先順序（彙總事件衡量）Meta 近年調整過規則，是否還需要設定、怎麼設，以設定當下的 Meta 官方說明為準（本清單查詢日 2026-09-24）
8. 自動進階比對是否開啟：決定第 10、11 項要不要提前到第 1 項之前（見第 1 項「上線前提」）。
9. 測試資料扣除：預覽環境若用同一個像素，測試預約、失敗、連點測試的事件都會進正式資料；每次測試記下時間與事件編號，對帳時扣掉。
10. 上線第 1–2 週對帳：Meta 的 Lead 數，對照預約紀錄裡「來源是廣告」的筆數。接近兩倍＝有重複計算；Meta 明顯偏少＝追蹤有斷，先修追蹤，不急著判斷廣告沒效。走 LINE 成交的部分，網頁端追不到，靠對帳表的來源欄補。

分工一覽 - 工程師：第 1–14 項的程式修改（第 4 項靈魂藍圖下架後可略過、下架前開投仍需處理；第 13 項可選），第 5 項給預覽網址；GTM 裡的設定（第 1、2、6、8 項中的 GTM 部分）由有 GTM 發布權限的人做，可能跟寫網站程式的人不同（見待回覆第 2 題） - 一千：決定電話必填或選填、沒時段時的下一步、隱私權政策請專業人士確認；選單改版時程（第 14 項可以跟改版一起做）、靈魂藍圖大概什麼時候拿掉（影響第 4 項要不要做） - 我們（廣告代操）：逐項驗收、第三段實測、上線後對帳