上一篇文介紹 Web Analytics 時，我們可以利用 Sources 觀察使用者從哪裡進入網站，例如 Organic Search、Paid Search、Social、Referral，或者自己加上的 UTM。

這些資訊很適合用來觀察不同流量來源，但如果把問題改成：

這個使用者到底是被哪個來源帶來的？

事情就會變得複雜很多。

舉例來說，使用者可能先在 X 上看到有人介紹產品，當下沒有點擊；隔天自己搜尋品牌名稱，點進 Google Ads，最後完成註冊。

看到 X 上的貼文
→ 搜尋品牌名稱
→ 點擊 Google Ads
→ 註冊

從 Web Analytics 來看，這次 Session 來自 Paid Search，這個結果本身沒有問題。

但如果我們想知道「是哪一個來源帶來這次註冊」，就會出現另一個問題：如果沒有一開始看到 X 上的貼文，使用者可能根本不會搜尋品牌名稱。

這就是 Attribution（歸因）想處理的事情。

Attribution

Attribution 的目的，是將 Conversion 分配給前面的流量來源或接觸點。

最簡單的做法可能是 Last Touch，也就是把 Conversion 算給最後一次來源。在前面的例子裡，結果就是 Google Ads。

也可以使用 First Touch，把功勞算給最早的來源；或者使用 Multi-touch Attribution，將功勞分配給多個 Touch。

這些做法都可以成立，只是它們分別回答不同的問題。

如果使用 Last Touch，我們會看不到前面的 X；如果使用 First Touch，又會忽略最後確實把使用者帶進網站的 Google Ads。Multi-touch 可以同時保留兩者，但接著就需要決定每一個 Touch 應該分到多少比例。

而且實際情況通常比這個例子更麻煩。

使用者可能是在 Podcast 聽到產品、朋友在 Discord 推薦、同事口頭提到，甚至是在另一台裝置先看到內容。這些接觸點很可能完全不會出現在 Referrer、UTM 或 Cookie 裡。

所以就算 Tracking 本身都正常，我們也不一定有足夠資料還原整段 User Journey。

Attribution is a lie

PostHog 在一篇介紹 Startup Marketing 的文章中，直接把其中一節命名為 Attribution is a lie。

文章裡使用的例子也很接近前面提到的情況：使用者先看到 X 上的內容，之後搜尋品牌、點進 Google Ad，再完成註冊。Analytics 最後會把這名使用者歸因給 Google Ad，但 PostHog 認為真正的起點其實是前面的 X。

他們的建議是把 Attribution 當成一個 7/10 的問題，而不是 10/10。

也就是說，Attribution 當然值得做，但不一定需要為了追求更精準的答案，建立非常複雜的 Multi-touch Attribution 系統。

這個觀點滿值得注意，尤其對工程師來說，很容易直覺地把問題理解成「資料還不夠完整」，然後繼續增加 Tracking、Cookie、Identifier 或 Attribution Model。

但如果有些 Touch 本來就沒有被觀察到，再複雜的模型也只能處理現有資料。

直接問使用者

PostHog 在同一篇文章中還提出一個非常簡單的做法：在 Signup Flow 加上一個 Optional 的文字欄位：

Where did you hear about us?

依照他們的經驗，大約有 5–10% 的使用者會填寫。他們也把這個欄位視為非常高 Signal 的 Marketing Data。

例如 Web Analytics 可能看到：

Channel: Paid Search
Referrer: google.com

但使用者自己填寫：

Saw it on X

這兩個結果其實不衝突。

前者是在描述這次 Session 怎麼進入網站；後者則是在詢問使用者自己記得從哪裡知道產品。

PostHog 在文章中也給了兩個很實際的判斷方式：

1. Attribution 的 Signal 很明顯時可以相信；模糊時就不要過度解讀。
2. 如果 Attribution Data 和「Where did you hear about us?」一致，可以相信這個結果；如果不一致，他們會偏向相信使用者填寫的答案。

這是 PostHog 自己在 Marketing 上的做法，不代表 Self-reported Attribution 一定比較準。

使用者可能記錯，也可能只記得最近一次看到產品的地方，而且只有一部分人會回答。因此它比較適合拿來補充原本的 Attribution，而不是直接取代 Referrer 或 UTM。

這邊比較值得注意的是自由輸入，而不是先做成固定選項。

如果選項只有：

Google
X
Facebook
YouTube
Other

那麼 Podcast、Discord、朋友推薦，甚至一些我們根本沒想到的來源，都很容易被塞進 Other。

自由輸入雖然比較難直接整理成漂亮的圖表，但也比較有機會看到原本不知道的來源。

Attribution 要回答什麼？

回到上一篇文的 Sources，可以看到一個很重要的差異。

Web Analytics 很適合回答：

這次 Session 從哪裡進來？

Attribution 則試著回答：

這次 Conversion 應該算給哪個來源？

而「使用者為什麼會知道我們」，又可能是第三個問題。

如果把三者混在一起，就很容易因為 Dashboard 上顯示 Google Ads 帶來很多 Conversion，就直接認為這些使用者都是因為廣告才知道產品。

實際使用時，UTM、Referrer、Channel 等資料仍然很有價值，只是需要知道它們能回答到哪裡。

如果產品有 Signup 或 Onboarding，也可以考慮增加 Self-reported Attribution，拿來補充 Web Analytics 看不到的部分。

這樣做不會得到一個完美的 Attribution Model，但通常已經足以讓我們知道哪些來源值得繼續觀察。

下一篇文，我們先回到產品開發本身。

當功能已經完成，但我們還不想直接開放給所有使用者時，可以怎麼處理？

這就是 Feature Flag。

參考資料

• https://newsletter.posthog.com/p/the-stuff-nobody-tells-you-about

如果你願意花 30 秒留下回饋，我會用這些意見來調整後續文章：分享你的意見