Firstory 下載數據分析標準(2021.10 更新)
在 Firstory Studio 後台我們提供許多分析數據,協助創作者更了解自己的聽眾群找尋優化的方向。參照國際廣告協會(IAB)針對 podcast 所訂定的標準,我們在系統中盡可能篩除雜訊,並呈現節目在上架發佈後被聽眾下載收聽的狀況。
至於為什麼要「盡可能篩除雜訊」?
這一部分與 Podcast RSS 的技術,與後續收聽平台如 Apple Podcast, Spotify, KKBOX 等發展演進有關。簡單來說,因為每個收聽平台的計算基準及技術運作有差異,當進一步回到 Hosting 平台做最後統整分析時,就必須要有一套相對應 且一致 的篩核標準。這也將使得創作者在與廣告商合作時,有正確的指標協助衡量廣告成效。
為了能夠讓統整數據更貼近真實的收聽狀況,要先釐清聽眾在收聽過程中可能發生的事情:
首先,聽眾可能在起床滑手機時看了朋友用分享了一檔不錯的節目,但因為趕時間他就先把節目存到自己常用的 KKBOX,打算在通勤路上再好好收聽。
考量到通勤路上,可能會經過一些網路不太穩的地方,有時聽眾必須要先下載節目音檔做離線收聽。但如果運氣好,經過的區域都有行動網路那頂多是跨越好幾個 IP 做串流收聽。
然而,有時候節目可能動輒一個多小時,通勤時間不夠聽完一整集時,聽眾必須分天或用零碎的午休時段把它聽完。
這些多元多變的收聽行為,在計算系統中都需要定義清楚才能做分析。例如:該如何判斷怎麼樣的行為屬於「收聽一次」? 被播放平台自動開啟的到底算被收聽嗎? 短時間大量洗播放怎麼辨別?另外,判斷標準也會因為技術優化而調整,好比以前 Apple watch 沒那麼多人使用時,就不會有人想到要去將它當作是計算的一環。
下載數(Downloads)
包含來自所有收聽平台(例如:KKBOX、Apple Podcasts、Spotify)的下載數據,並根據美國互動廣告協會(IAB)規範、過濾各種可能的重複下載所得出的數字,具體來說,一組 IP 及裝置一天聽一個單集只會算做「一次下載數」。
下載數每 3 小時更新一次,另外 Spotify 由於數據形式特殊,會統一在每天「格林威治時間零點到三點(臺灣時間早上八點到十一點)」更新「兩天前的數據」。
Note: 因為計算技術與方式,會隨著不同定義需求而調整。為了能偵測到更真實的收聽狀況, Firstory 會不定時執行小型的技術實驗,並持續更新本文件。
下載與收聽依據
為了記錄一個音檔在發佈後,在不同情境下被收聽的狀態,會針對以下(包含但不限於)媒介作標記與追蹤, Podcast 播放平台、嵌入播放器、第三方播放 App 以及網站等。同時 Firstory 會進一步針對收集到的 HTTP requests 作以下篩選:
IP address : 聽眾收聽情境的轉換,會反映在收聽者的行動、家用等網路 IP 位址。
User-agenet:除了收聽位址,也會針對收聽裝置做紀錄;例如聽眾所使用的瀏覽器/播放器資訊、與裝置的作業系統(iOS, Mac OS, Android ...)
UTC date :Podcast 是跨時區的收聽娛樂,因此若要有效計算就是必要定義出「一天」,而 Firstory 所參照的時間點為格陵威治的 0 ~ 24。
有了相關使用者資訊後,就得進一步去定義收聽時長的標準,防止機器人短時間來點擊播放按鈕灌水的情況發生。目前主流 IAB 認證基準為 - 24 小時內,同一個 IP 位址下與使用置點所下載播放某一集的次數,不論點選 1次 或 20次都只會計算為 1。
其他防止不肖機器產生雜訊的篩選依據為:
Ignore non-playback:篩掉播放平台(如 Apple Podcast)取用前的測試檔。
Ignore bot, spider request:防止機器人網站來索取奇怪的網站來索取。
Ignore cloud service: 針對雲端伺服器 IPs, 第三方伺服器請求做篩選。
Ignore session shorter than 30 seconds:針對播放時長低於30秒的請求做篩選與不計算。
至於為什麼要「盡可能篩除雜訊」?
這一部分與 Podcast RSS 的技術,與後續收聽平台如 Apple Podcast, Spotify, KKBOX 等發展演進有關。簡單來說,因為每個收聽平台的計算基準及技術運作有差異,當進一步回到 Hosting 平台做最後統整分析時,就必須要有一套相對應 且一致 的篩核標準。這也將使得創作者在與廣告商合作時,有正確的指標協助衡量廣告成效。
為了能夠讓統整數據更貼近真實的收聽狀況,要先釐清聽眾在收聽過程中可能發生的事情:
首先,聽眾可能在起床滑手機時看了朋友用分享了一檔不錯的節目,但因為趕時間他就先把節目存到自己常用的 KKBOX,打算在通勤路上再好好收聽。
網路 IP 與裝置
考量到通勤路上,可能會經過一些網路不太穩的地方,有時聽眾必須要先下載節目音檔做離線收聽。但如果運氣好,經過的區域都有行動網路那頂多是跨越好幾個 IP 做串流收聽。
收聽時長與計次參數
然而,有時候節目可能動輒一個多小時,通勤時間不夠聽完一整集時,聽眾必須分天或用零碎的午休時段把它聽完。
這些多元多變的收聽行為,在計算系統中都需要定義清楚才能做分析。例如:該如何判斷怎麼樣的行為屬於「收聽一次」? 被播放平台自動開啟的到底算被收聽嗎? 短時間大量洗播放怎麼辨別?另外,判斷標準也會因為技術優化而調整,好比以前 Apple watch 沒那麼多人使用時,就不會有人想到要去將它當作是計算的一環。
Firstory 主要數據指標:
下載數(Downloads)
包含來自所有收聽平台(例如:KKBOX、Apple Podcasts、Spotify)的下載數據,並根據美國互動廣告協會(IAB)規範、過濾各種可能的重複下載所得出的數字,具體來說,一組 IP 及裝置一天聽一個單集只會算做「一次下載數」。
下載數每 3 小時更新一次,另外 Spotify 由於數據形式特殊,會統一在每天「格林威治時間零點到三點(臺灣時間早上八點到十一點)」更新「兩天前的數據」。
Note: 因為計算技術與方式,會隨著不同定義需求而調整。為了能偵測到更真實的收聽狀況, Firstory 會不定時執行小型的技術實驗,並持續更新本文件。
下載與收聽依據
為了記錄一個音檔在發佈後,在不同情境下被收聽的狀態,會針對以下(包含但不限於)媒介作標記與追蹤, Podcast 播放平台、嵌入播放器、第三方播放 App 以及網站等。同時 Firstory 會進一步針對收集到的 HTTP requests 作以下篩選:
IP address : 聽眾收聽情境的轉換,會反映在收聽者的行動、家用等網路 IP 位址。
User-agenet:除了收聽位址,也會針對收聽裝置做紀錄;例如聽眾所使用的瀏覽器/播放器資訊、與裝置的作業系統(iOS, Mac OS, Android ...)
UTC date :Podcast 是跨時區的收聽娛樂,因此若要有效計算就是必要定義出「一天」,而 Firstory 所參照的時間點為格陵威治的 0 ~ 24。
有了相關使用者資訊後,就得進一步去定義收聽時長的標準,防止機器人短時間來點擊播放按鈕灌水的情況發生。目前主流 IAB 認證基準為 - 24 小時內,同一個 IP 位址下與使用置點所下載播放某一集的次數,不論點選 1次 或 20次都只會計算為 1。
其他防止不肖機器產生雜訊的篩選依據為:
Ignore non-playback:篩掉播放平台(如 Apple Podcast)取用前的測試檔。
Ignore bot, spider request:防止機器人網站來索取奇怪的網站來索取。
Ignore cloud service: 針對雲端伺服器 IPs, 第三方伺服器請求做篩選。
Ignore session shorter than 30 seconds:針對播放時長低於30秒的請求做篩選與不計算。
更新時間: 25/10/2022
感謝!