廣告目標選錯，事件再準也優化不到你要的人

廣告目標選錯，事件再準也優化不到你要的人

太長不看版： 廣告目標決定系統去找哪一種人，轉換事件決定系統怎麼判斷找對了沒。兩者錯配時，系統不會報錯，它會非常有效率地替你帶來一批完全不會付錢的人——而且數據看起來還不錯。更麻煩的是有些組合在建立時就會直接被擋下來，錯誤訊息通常看不出真正原因。另外，在選事件之前要先算一個數字：這個事件一週能發生幾次。低於某個量，選它就是自找學習期跑不完。

---

目標與事件是兩件不同的事

很多人以為「裝好像素、事件會傳、廣告就會優化」。中間漏了一層。

廣告目標是你在建立行銷活動時選的那個東西。它決定系統從哪一個池子裡找人——找愛看影片的人、找愛留資料的人、還是找會掏錢的人。這幾個池子裡的人是不一樣的。

轉換事件是你在廣告組層級指定的那個訊號。它告訴系統：這樣算成功。

兩者的關係是：目標決定範圍，事件決定準星。範圍錯了，準星再準也沒用——你在錯的池子裡精準地撈人。

最常見的錯配

用「開發潛在客戶」類的目標，卻指定一個購買類的事件。

這個組合的問題在於：系統會在「習慣留資料」的人群裡，去找那些會完成購買的人。但這兩群人的重疊度不高。結果是系統找了很久也找不到夠多的正樣本，學習期跑不完，成本一路往上。

更糟的情況是它「學會了」——用一種你不想要的方式。它找到的是那種會走完購買流程但金額極小、或者根本不會回訪的人。數據上是成功的，商業上是失敗的。

反過來的錯配也存在：用銷售類目標卻指定一個很淺的事件（例如瀏覽頁面）。這時候系統會替你帶來大量的瀏覽，成本看起來超低，但沒有任何一筆錢進來。

有些組合會直接被系統擋下來

這是很多人踩過的一個坑：特定的事件只能搭配特定的目標，用錯了會在建立廣告組的當下就失敗。

問題是錯誤訊息通常很技術性，看不出「你的目標選錯了」這件事。第一次遇到的人會以為是權限問題、像素沒共享、或是 API 呼叫的參數寫錯，然後往完全錯誤的方向查半天。

判斷法：如果你的廣告組怎麼建都建不起來，但同一組參數換一個事件就成功了——那不是技術問題，是目標與事件的對應關係不合法。回頭去改行銷活動層級的目標，而不是繼續改廣告組。

有一個延伸的陷阱：廣告組建立之後，轉換事件通常不能直接改。 發現選錯的時候，多數情況要重建廣告組，這也代表學習期要重跑。所以這件事值得在建立前多花五分鐘確認。

選事件前先算這個數字

比對應關係更早該問的問題是：這個事件，一週會發生幾次？

系統需要足夠的正樣本才能學會。樣本太少，它就只能一直在摸索，成本永遠停在高點，而且波動很大。

實務上的估法：

一週預期轉換數 = 日預算 ÷ 預估單次轉換成本 × 7

算出來的數字如果只有個位數，那你選的事件太深了。這時候正確的做法不是加預算硬撐，而是先往上選一個較淺的事件（例如從購買改成加入購物車、從註冊完成改成開始註冊），讓系統先累積到足夠的量、學會找對人，再往下切換。

這是一個很多人不願意做的取捨，因為淺事件的數字「看起來不夠精準」。但一個學不會的深事件，精準度是零。

事件回傳的品質也會影響結果

即使目標與事件都對，還有第三層：你回傳的事件，系統有沒有辦法對上是誰。

事件裡帶的識別資訊越完整，比對品質越高。比對品質高，系統學得越快、找人越準。這個品質是有分數可以看的，而且分數的差異會直接反映在成本上。

兩個實務上最容易漏的點：

第一，只靠瀏覽器端的像素是不夠的。 瀏覽器端會因為各種原因漏傳——網路中斷、使用者提早關閉頁面、瀏覽器限制。建議搭配伺服器端回傳，讓兩邊互補。使用者中途跳去通訊軟體的情境更嚴重，整段識別碼可能直接消失，判斷方法寫在LINE 加好友廣告的成效為什麼算不準。

第二，兩邊都傳的時候必須帶同一組事件識別碼。 沒帶的話，同一次轉換會被算成兩次，你的成本數字會憑空變成一半——然後你會用一個錯誤的成本去做預算決策。

一個容易誤判的現象

「我換了事件之後成效變差了，所以原本的設定是對的。」

不一定。換事件會觸發學習期重跑，重跑期間成效本來就會變差。要判斷新設定好不好，至少要等學習期結束，中間的數字沒有參考價值。

很多人在學習期第三天就受不了改回去，然後又觸發一次學習期。來回幾次之後，這組廣告從來沒有真正跑穩過。

檢查清單

發現成效不對時，照這個順序確認：

1. 行銷活動的目標是哪一個
2. 廣告組的轉換事件是哪一個
3. 這兩者的對應關係合不合法（建不起來就是不合法）
4. 這個事件一週實際發生幾次（個位數就是選太深）
5. 事件是只有瀏覽器端傳，還是兩邊都傳
6. 兩邊都傳時，有沒有帶同一組事件識別碼
7. 目前是還在學習期，還是已經跑穩

前四項是設定問題，改了要重跑學習期。後三項是技術問題，修好之後成效通常會在幾天內反映出來。

如果七項都對、成效還是差，那問題大概在事件觸發之前——也就是使用者根本沒走到那一步。往上一層查到站率。

---

完整的事件架構

從目標與事件的完整對應規則、事件深淺的選擇邏輯、伺服器端回傳的架構，到比對品質分數怎麼拉——這些我們整理成了操作手冊，收在買量實戰包的第 4、5 章，包含可直接匯入的代碼管理容器設定。

買量實戰包的完整內容與價格在這裡。

如果你連「事件」「轉換」這幾個名詞的關係都還沒抓穩，先看免費的廣告追蹤入門。

不想自己處理追蹤架構的話，聯絡我們↗談代操。

---

了解我們的廣告代投服務 →