大家好，上個禮拜我以取材的名義參加了一個台北 podcast hosting 供應商 Firstory 公司所舉辦的活動，想替自己的節目吸收一點新知，並且思考如何可以將這些議題內容套用自己成立的 podcast 頻道「Newbie Homemade Mashup Lab」上；議程話題包含針對節目型態的探討，以及針對平台功能的探討等等，這次我就針對其中一項平台功能的議題著手實做看看。
將大綱分成以下數個部分：
- Podcast 廣告板位概觀
- 以第三方角度檢視
- 實作上的限制
- 結語
1. Podcast 廣告板位概觀
網路社會與現實社會一樣，服務人的平台就會衍生成廣告板位 (e.g., 載人的捷運車廂裡面有廣告、電商網站的橫幅廣告等等)，而針對 podcast 生態系中的平台而言，不難想像其板位大概會落在(不限於)兩種地方: 頻道或 EP 的介紹頁面 & 實際的節目內容中。
介紹頁面中的廣告其實不難理解，參照下圖。
另外一種廣告板位就是本次想要討論的「節目內容插入廣告」了，請先參考我的頻道中，某一集 EP 的內容：
在這集中，前 8 秒播放內容是我預先錄好的「節目開頭襯樂」，使用「Google翻譯」的文字轉語音功能，將節目的名稱唸出，接著才正式進入節目內容本身。請參考實際的襯樂連結(中文版 / 英文版)。
雖然這個例子是以節目一開始的襯樂形式存在，但針對內容較長的節目而言，這種類型的廣告板位可以安插在任何的時間段落中，例如節目中的某個特定秒數之後、節目的結尾、或者一個節目安插多個廣告。
在這種廣告形態下，頻道主無須為了不同的廣告板位重新製作多組原始音檔並上傳，所有包含廣告的音檔都將由廣告平台(可由 Hosting 供應商或者第三方)負擔後製與上傳的責任。
目前在我的頻道中，收聽各 EP 會有 5% 的機率聽到這樣的開頭襯樂，上面的範例 EP 則是例外，為了展示所以特別將機率調整成 100%，且會隨著聽眾的所在地調整襯樂的版本，位於台灣的聽眾將收聽到中文版襯樂，其他地區則是英文版，這些機率與範例未來有可能重新調整。
2. 以第三方角度檢視
上個段落提到為了方便頻道主，廣告平台將負責所有包含廣告音檔的各集 EP 製作與上傳這樣的責任，Hosting 供應商基於本身存放著所有頻道主的音檔、可以相對方便解決這樣的問題，但由於我不是 Hosting 供應商，所以只能從第三方的角度切入。
第三方所要面臨的第一個問題就是要「拿回聽眾收聽 EP 的控制權」，這句話講起來跟看起來都很難理解，可以解釋為聽眾在按下某個 EP 的播放鍵時，播放器 APP 將會啟動該集 EP 的網址，進而收聽到網址提到的音檔。
一個音檔網址的控制權最初歸於 Hosting 供應商，但隨著資料紀錄的緣故，大多數 Hosting 供應商都允許在單集中插入第三方前綴碼，若您看過我之前的文章，就知道我們可以在前綴碼這個部分，以接管單位的名義取得該音檔的控制權，也就呼應了原本難懂的「拿回聽眾收聽 EP 的控制權」這件事。
實際的做法是: 當由我們自己製作的第三方前綴碼接管網址後，無論後面還有多少第三方的前綴碼服務，最終都一定會是 EP 在 Hosting 供應商的網址，再度參考我之前的另一篇文章，我們將這樣的網址再度進行拆分。
Newbie Homemade Mashup Lab 其中一集的實際收聽網址，接管單位是自己。
第 1 個部分:
https://
第 2 個部分:
podcast.mohohan.com/track/
第 3 個部分:
chtbl.com/track/99CED3/track.fstry.me/p/fbnmxysm/rss.soundon.fm/rssf/3ef665f1-1091-42de-bedd-7ab16c84fbc6/feedurl/d4d9c8c5-8421-424c-b097-105d3f037ce8/rssFileVip.mp3?timestamp=1605844818736
第 2 個部分現在被我們所開發的第三方服務接管，此時除了常規性的紀錄聽眾基本資料之外，還需要在這個階段就分別下載「插入廣告或襯樂的規則」、「廣告或襯樂的音檔」、「第 3 個部分的實際 EP 音檔內容」。
接管單位在記錄聽眾的基本資料後，取消了原本的放行流程，首先下載所有的必要資源，利用「插入廣告或襯樂的規則」決定插入什麼廣告、在何時插入廣告、在那些 EP 中插入廣告、依照收聽地決定顯示甚麼廣告等等，絕大多數的規則都可以自訂。
有了規則之後才下載對應的「廣告或襯樂的音檔」以及「實際 EP 音檔內容」，將這幾個音檔依照規則合併之後再直接放送給聽眾。
控制權在自己單位的網頁身上能做到許多功能，且這些功能的原理與實作方式也都不會太難，但跟所有產業生態系一樣，podcast 生態系的技術層面也有很多隱藏的眉角會隨著新功能的導入而衍生。
3. 實作上的限制
表列出我在實作過程碰到的問題，有些問題甚至還會環環相扣:
1: 紀錄來源：
對於接管單位為自己的平台來說，我們可以取得聽眾實際的收聽地點，但對於之後的第三方服務或 Hosting，所有的音檔已不再是由我們「放行」給聽眾下載，而是由我們「下載」給聽眾，因此其他服務所取得的聽眾資訊都會來自於「我們」而不是「實際的聽眾」；雖然對於造訪時間這樣的資訊沒有影響，但對於聽眾國別、使用的 APP 等等資訊就會有嚴重的誤導，這些問題可以透過由我們下載的行為中，額外添加「請求轉發」解決之，也就是我們需要以「取得來的聽眾資訊」的名義下載音檔，這樣才會在剩餘的單位留下正確的聽眾數據。
2: 聽眾體驗：
原先的機制由我們「放行」給聽眾下載，所以聽眾從按下播放鍵到實際收聽節目會需要等待一定的時間，假設為 5 秒好了；現在機制如果改為由我們「下載」給聽眾，假設時間依然為 5 秒，但額外要加入「下載襯樂或廣告音檔」、「轉檔」等等時間，可能就會需要到 10 秒，這對於像我一樣的音樂性頻道(單集時間短)或許還好，但對於訪談性質的頻道(大多都 30 分鐘以上)將會很明顯地讓聽眾等待時間變長。
針對這個問題可以使用「快取」或者「分區返回」解決，「快取」就是第一個聽眾會花很多時間等待我們製作含廣告的單集音檔，我們將它上傳到快取空間，好讓往後的聽眾可以不用再等待下載與轉檔的時間就可以直接聽到內容，但它衍生的問題就是往後聽眾的數據就不會再被記錄下來(因為我們沒有重新從 Hosting 下載單集音檔)；「分區返回」就是與聽眾的 APP 協調，不要全部的音檔都下載完畢才播放，可以邊播放前面下載好的部份邊下載後面的部分，但它會衍生「邊轉檔邊下載」的問題，當我們正在使用軟體把取得的音擋切分、轉換、合併時，軟體都會把正在處理中的音檔放在暫時工作區並且不讓其他 APP 下載。
再繼續針對「快取」問題探討，我們可以一樣導入快取讓聽眾第一時間收聽到內容，且在這個當下，背景向 Hosting 發出下載音檔的信號(但沒有真的花時間與頻寬下載)，這樣針對我們而言，縮短了聽眾的收聽空白時間，也保留了他們在各大平台上的紀錄數據。
「分區返回」的解決方式就比較麻煩了，以第三方服務而言，除了要能改寫轉檔軟體，使得在轉檔過程中也要能夠被其他 APP 動態取得內容之外，還需要有足夠高規格的硬體設備，這樣在聽眾多的時候才可以同時負責不同聽眾的分別的「下載」、「轉檔」、「分區返回」需求，非常不經濟。以 Hosting 角度切入則會比較輕鬆，Hosting 由於有較多的硬體資源與音檔存放空間，所以可以在聽眾收聽前就預先將大批的單集按照不同的廣告型態轉檔完畢，直接省略「下載」與「轉檔」的時間消耗。
3: 音檔格式：
不同 APP 或者使用瀏覽器聽 podcast 感覺好像都差不多，但其實針對不同轉檔軟體所產生的音檔格式都不一樣，有些軟體轉檔之後的結果會造成瀏覽器版本可以收聽，但 APP 版本無法收聽；有時會發現轉檔完畢後，不同收聽裝置所顯示的音檔秒數不同，有時也會發現音檔無法暫停或者無法選擇想要開始收聽的秒數等等，此時建議最後在轉檔後可以自己先利用各大 APP 聽過一遍，等到確認都可以正常收聽後才正式導入該軟體。
4. 結語
這些好用的功能未來一定也會納入各大 Hosting 供應商的開發版圖中，藉以滿足各種廣告主與頻道主的媒合需求，且相較於以第三方名義開發，直接於 Hosting 原生支援廣告板位的功能一定也比較省錢。
謝謝收看。
相關資源