首次接觸歸因將貢獻分配給最早記錄到的有效接觸點；末次接觸歸因則分配給指定成果發生前的最後一個有效接觸點。 兩者都無法還原影響旅客的全部經歷。租車業者應先分清楚「如何認識服務」與「從哪裡回來完成預訂」。
本文結合Google公開說明，以及2026年9月14日檢視的Orcar預訂與付款歸因設計。設計說明並非正式環境資料完整性稽核，也不是管道成效報告。主題插圖為概念表達，並非真實顧客旅程。
1. 先定義接觸點，再選模型
「首次」限於可觀察的歷史與有效性規則。旅客可能先在私人通訊中得到推薦，之後才開啟可測量的連結。最後一次造訪、最後一次帶標籤的互動，以及最後一次非直接點擊，也可能是不同接觸點。
Google Analytics區分使用者、工作階段及事件範圍。First user source描述觀察到的使用者開發來源，Session source描述工作階段來源；事件範圍的歸因則為重要事件分配貢獻。變更報表歸因模型不會改動使用者或工作階段範圍的維度。 [1][3]
Google已於2023年11月移除首次點擊報表模型，不能再把它列為目前GA4選單中的選項。First user維度仍存在，而自建系統的首次接觸紀錄又是另一個概念。 [4]
同意選擇、封鎖儲存、清除Cookie與更換裝置都可能中斷可觀察歷史。缺少的早期接觸點應保留為未知，不要繞過隱私選擇來重建路徑。
2. 造訪三次，預訂仍只有一筆
以下是虛構範例，不是Orcar顧客紀錄。同一瀏覽器先經合作方文章的標籤連結進站，之後透過搜尋廣告返回，最後直接輸入網址付款。假設兩個帶標籤的接觸點仍有效，且都已串接到同一筆預訂。
| 觀點 | 本例的歸因對象 | 說明內容 |
|---|---|---|
| 首次有效接觸 | 合作方文章 | 觀察到的發現管道 |
| 最後一次非直接點擊 | 搜尋廣告 | 最後有效的非直接回訪 |
| 字面上的最後造訪 | 直接造訪 | 付款工作階段如何開始，不一定等於歸因管道 |
| 業務成果 | 一筆符合條件的已付款預訂 | 各觀點共同描述的去重結果 |
Google的歸因模型通常不把貢獻分給直接造訪，除非整條路徑都是直接造訪。因此，直接回來付款不代表預訂必然歸給直接流量。自建模型的規則須另外說明。 [4]
文章與廣告並沒有各自新增一筆預訂。把首次與末次接觸的預訂數相加，會重複計算同一筆成果。
3. Orcar預訂設計呈現的差別
經文件確認的實作會在瀏覽器分別建立首次與末次接觸資料。建立預訂及建立付款時，都會傳送歸因與分析工作階段資訊至伺服器。建立付款可能更新預訂的歸因資訊；付款完成時，預訂可能連結至付款工作階段。
所以，開始預訂與完成付款時可取得的資訊可能不同。後續回訪可能增加新證據。比較前應確認報表採用哪個時點的紀錄，以及哪種成果時間。名為「首次接觸」的欄位，未必是某個人一生首次認識品牌的不變紀錄。
文件中的流量開發漏斗以連結至測量工作階段的付款確認預訂作為最後一步，不只依賴瀏覽器的付款成功事件。這是設計描述，不是所有正式預訂皆完整串接的保證。嘗試付款與確認已付款是不同成果。
4. 以同一批租車預訂比較
判斷管道成效之前，請統一以下口徑：
- 成果：選擇付款確認預訂或已完成租賃，去除重複，不混用狀態。
- 時間：說明依造訪日、付款日或取車日分組，並列出時區與資料截止時間。
- 有效歷史：記錄回溯期與直接流量規則。Cookie保存期限不等同於報表的歸因回溯期。 [3]
- 紀錄時點：使用建立預訂、建立付款或事後核對時的歸因資料。
- 涵蓋率：同一成果群組中，已連結工作階段的預訂除以全部符合條件的預訂；連結成功但來源標籤缺漏的部分也應單列。
- 金額：使用相同幣別與退款規則。付款金額、退款後淨營收與貢獻利潤不可混為一談。
保留未連結預訂的獨立分類。串接改善可能讓可歸因預訂增加，卻不代表行銷變得更有效。核對識別碼應限制存取，旅客姓名、證件資訊與預訂存取權杖都不應放進活動標籤。
5. 讓分歧成為下一個驗證問題
某管道常見於首次接觸卻少見於末次接觸，可能先介紹服務，再讓旅客透過其他管道回來。反向模式則可能協助旅客完成決策。兩者都是假設，不是新增需求的證明。
以兩套規則比較同一批預訂，保留未知部分，並在適當權限內檢查路徑。要聲稱移除管道就會失去其歸因預訂，需要對照實驗或其他可靠的因果設計。可參考租車成效衡量指南。
QR推廣指南著重確認掃碼至預訂每一階段的證據；本文則是在成果已串接後分配貢獻。規劃國際旅客開發與預訂流程的業者，可查看Orcar租車合作夥伴介紹。
常見問題
首次或末次接觸哪個更準確？
直接回訪會清掉先前來源嗎？
未串接的預訂可以算成自然搜尋嗎？
來源