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
感謝！