MeetROAS 與 Keitaro:自備頁面、分流與 PWA 安裝追蹤

MeetROAS 編輯團隊 · 發布

Keitaro 可代管投手自備的頁面,或追蹤外部網站;Campaign 能做分流,但 Tracking Script 接法本身不支援頁面/offer 分流。MeetROAS 提供代管安裝頁與適用 Campaign 的旅程 A/B。兩邊都需要目的地回報註冊,PWA 安裝則要核對實際事件證據。

保留既有頁面,還是建立安裝旅程?

Keitaro 讓投手帶入自備頁面,選擇由追蹤器代管或接入外部網站,再把 Campaign 流量分配到不同頁面與 offer。MeetROAS 提供代管 PWA 安裝頁,並追蹤安裝到首次開啟的旅程。 兩邊都需要目的網站回報完成的業務結果。先確定訪客應該使用哪個頁面,再選工具。

Lander 是點廣告後看到的頁面;offer 是推廣的服務及其目的地;PWA 是可以安裝並從裝置重新開啟的網頁應用程式。普通 HTML 頁面加上追蹤碼,不會因此自動變成可安裝的應用程式。

假設同一位投手在推廣語言學習會員服務。她已有設計師做好的 HTML 頁面,也有正常運作的註冊網站。她想比較兩種訴求,再決定是否需要桌面圖示入口。這包含兩個決定:怎麼接入現有頁面,以及是否建立安裝旅程。

Keitaro:先選頁面接法,再設定分流

投手可以把頁面和素材整理成 ZIP,上傳為 Keitaro Local landing page,由追蹤器提供頁面。設計、內容及連結仍由團隊供應與維護;代管不代表替她設計頁面或建立 PWA 功能。

若頁面已在其他主機上運作,Keitaro 的頁面選項也有外部轉址頁與網站整合。外部 Tracking Script 可以從既有網站記錄點擊及轉換。但這個接法的官方文件明列:它本身不支援分配 landing page、offer,也不負責轉址到它們。貼上這段碼,與把廣告導向會分配流量的 Campaign 連結,是不同設定。

若使用 Campaign 連結做測試,她可以在 flow 裡放兩張 lander,依 landing page/offer 分流功能設定比例。相同權重的目標是長期接近均分,小樣本不保證各半;也要核對訪客綁定與篩選條件,才能解讀比較。

這適合要保留自訂頁面、願意維護整合的團隊。先選具體接法,再驗證該接法能怎麼分流。

MeetROAS:供應內容,使用代管安裝頁

同一個會員服務可以用 MeetROAS Campaign建立代管安裝版面。投手供應應用程式資料、文案、圖片與目的網站;平台提供 Campaign 頁面和安裝旅程,會員站的註冊及服務仍由團隊負責。若安裝沒有實際用途,也能使用直達網站 Campaign。

要比較兩種平台提供的頁面體驗,符合條件的非主 Campaign 支援旅程 A/B。投手設定版本與共同目標;這個流程並不是上傳設計師任意製作的 HTML ZIP。測試前先確認 Campaign 適用條件與方案容量。

支援的實驗可以在 A/B 報表看到歸屬到版本的註冊及安裝結果。Campaign 成效則另有安裝點擊等階段總數。不能用 Campaign 總數推論是哪個版本帶來結果;要看真正的版本列及資料涵蓋起點,不能把開始收集前的事件當成完整實驗紀錄。

兩種設定能看到哪一步,包含安裝嗎?

投手的問題Keitaro 設定MeetROAS 設定
誰提供頁面?投手提供 Local 檔案或外部網站平台供應安裝版面;投手供應內容及目的地
哪裡做分流?Campaign flow 或頁面/offer 權重;Tracking Script 本身不是分流器適用 Campaign 的旅程 A/B 版本
什麼證明已註冊?目的地帶原始點擊身分回報完成結果目的地帶原始點擊身分回報完成註冊
什麼證明已安裝?自建 PWA 的埋點及事件對應要供應證據代管旅程的安裝證據與首次開啟追蹤,受瀏覽器涵蓋限制
Keitaro 由投手自備頁面並接入分流;MeetROAS 提供安裝版面。兩邊都需要會員站回報完成註冊。
頁面及資料責任示意。Tracking Script 接法本身不是分流器;安裝訊號與註冊回報必須分開驗證。

Keitaro 的 postback 文件說明以原始點擊 ID 接回結果;conversion types可以記錄自訂事件,建立新類型需 Expert 或以上版本。團隊可以為自建 PWA 埋點,把安裝與開啟對應成分開事件。這是需要實測的整合工作,不能因此說 Keitaro 無法量測安裝,或已自動量到每次安裝。

在 MeetROAS,點安裝按鈕、瀏覽器的安裝完成訊號與首次開啟,也是不同觀察。安裝證據可以來自瀏覽器完成事件,也能由首次開啟補上,因此兩種數字不一定是互斥人群。MDN 明列 `appinstalled` 的瀏覽器支援有限。兩邊都不能把未觀測到的瀏覽器動作當成完成證明;會員站的完成註冊仍要接上 MeetROAS 的目的地事件回報。

看完同一個案例,下一步怎麼調整?

假設每個訴求都有 1,000 次符合條件的進站,每次進站都觀察七天註冊結果。以下是虛構教學數字:A 有 120 次往下一站的點擊、40 次註冊;B 有 180 次點擊、30 次註冊。B 比較會吸引點擊,A 卻帶來較多完成註冊。偏向 A 之前,先確認註冊定義、成熟時間與樣本量可比;若 B 的註冊回報缺漏,結果是不可比較,不是零。

用 Keitaro,投手先核對 lander/offer 報表及目的地 postback,再調整頁面、往下一站的連結或 Campaign 權重。用 MeetROAS,則看適用的版本結果;若安裝路徑有很多安裝點擊卻很少首次開啟,就先實測安裝指引與開啟體驗,再考慮更換流量來源。完成轉交或點出連結,本身不代表註冊網站已載入。

一致使用點擊身分與 UTM 標籤,用真實手機走一次旅程,逐一核對對應報表,之後一次只改一個變因。自訂 HTML 不可取代時,先試 Keitaro 的具體接法;若要省下的是建立與量測安裝頁的工作,則試代管旅程。另一種追蹤器的分流模型可看 Binom 比較,遷移前再按追蹤器選擇清單驗收。

資料來源