前幾天有點划水，因為沒有相關資料繼續做

今天，朋友提供了一份 Spotify 聆聽紀錄。

前面已經完成 Spotify 匯入器，但主要使用合成資料測試。現在終於有真實匯出檔，可以確認同一套程式遇到實際紀錄時，還能不能正常工作。

這份資料也讓我重新釐清了整個專案想回答的問題。

我平常主要使用 YouTube Music。看到平台給的聽眾徽章時，我會好奇：我聽 YOASOBI 的程度，放到 Spotify、其他音樂平台的聽眾之中，又會在什麼位置？有沒有可能知道更接近全球範圍的排名？

所以，朋友的 Spotify 應該作為另一位聽眾的資料，和我的紀錄分開保留。後續需要的是跨平台比較的依據。

今天先完成這件事的基礎：讓兩平台真實紀錄進入同一套資料流程，而且保留每筆紀錄屬於誰、來自哪裡，以及哪些資訊仍然不知道。

先用已知答案，確認資料接得起來

Day 8 的第一輪驗證使用兩份合成來源檔，經過各自的匯入器，再送進共同事件層。

YouTube Music 產生八筆事件，Spotify 產生四筆，共十二筆。輸出的每筆事件，都和匯入器產生的內容逐欄相同。來源識別碼、原始名稱、時間語意和資料種類都有保留。

這份合成案例裡，Spotify 的播放毫秒是：

0、12000、null、12000

零代表来源明確記錄了零毫秒，null 則代表不知道。這四筆的觀測時長小計是 24 秒，時長資料覆蓋率是 3／4。

加入八筆沒有時長的合成 YouTube Music 事件後，覆蓋率變成 3／12，完整時長仍然是 null。24 秒只涵蓋有觀測值的部分，不能解讀成總共只聽了 24 秒。

這段流程的 22 項已知答案核對全部通過，確認共同讀入沒有讓未知值變成零，也沒有讓事件無故消失。

朋友的真實 Spotify 資料，直接進原有程式

收到真實資料後，先檢查附檔說明及實際欄位，再使用已完成的匯入前檢查器與 Spotify 匯入器。

這份 ZIP 包含十份音訊歷史 JSON、四份影片歷史 JSON，以及匯出說明。十四份 JSON 合計 101,319 筆來源紀錄，處理結果如下。

來源批次

原始紀錄

匯入的曲目活動

另外列出的 Podcast 單集活動

音訊歷史，10 份

100,811

100,749

62

影片歷史，4 份

508

453

55

合計

101,319

101,202

117

拒絕與無法判定的紀錄都是零。

影片歷史裡也有合法的曲目識別碼，因此程式依來源的資源種類判斷，保留其中的曲目活動。檔名寫著 Video，不足以把整份資料刪除。

這批 101,202 筆曲目事件全部具有合法的觀測播放毫秒，其中 732 筆是明確的零毫秒，也都保留下來。來源還有 16 筆完全重複候選，這裡指同內容第一次出現以外的重複列；它們沒有被自動刪除。

時長覆蓋率達到 100%，表示這批已匯入曲目都有時長。它不證明帳號歷史完整，也不代表已經算出沒有重複的實際收聽總時間。

這次真實資料相容性驗收，沿用既有匯入器就能通過，沒有因此重寫資料模型。

116,605 筆事件進同一套流程，持有人仍然分開

同一天也重新使用先前的 YouTube 原檔，產生 15,403 筆音樂活動，逐筆播放時長繼續保持 null。

加上朋友的 101,202 筆 Spotify 曲目活動，共有 116,605 筆事件進入共同事件層。

這裡特別容易誤會：116,605 是事件筆數。現在的原始資料來自我和朋友兩位資料提供者，不能把事件數當成聽眾人數，更不能把兩人的時長加起來寫成我的收聽量。

共同資料層在原事件外保留批次、持有人代號、真實或合成標記，以及輸入列的位置。我的 YouTube Music 和朋友的 Spotify 各自分組，後面才能逐人計算。

真實資料驗收完成時，Spotify 的歸屬尚待確認，因此當時就先分成兩組。確認是朋友提供後，這個處理方式可以直接沿用。

共同層產生事件 JSON，以及 JSON、Markdown 兩種平台摘要。所有事件欄位全數保留，相同輸入重跑後的檔案內容一致。

同一個欄位名稱，還不夠拿來排名

在目前模型中，YouTube Music 保存來源活動時間，Spotify 保存播放結束時間。就算兩者都能用 UTC 表示，它們也不是相同意義的播放開始時刻。

播放量同樣有差別。我這份 YouTube 匯出沒有逐筆秒數，朋友的 Spotify 則有來源記錄的播放毫秒。

要回答誰聽 YOASOBI 比較多，就得先決定比較什麼，以及雙方是否都有符合規則的資料。不能把我的活動次數和朋友的分鐘數放在同一個排名裡，也不能用歌曲完整長度幫我的紀錄補出播放時間。

把資料接起來，只完成了共同讀取。接下來還要處理相同期間、藝人歸屬、計算單位與比較群體，才有資格談名次。

ChatGPT 今天的工作，也包括修正問題的方向

今天由 ChatGPT 協助檢查既有程式、建立共同事件入口、執行合成測試與真實資料補驗，並整理輸入輸出的對帳結果；本日沒有另外啟動 Codex 工作任務。

真實 Spotify 的十四份檔案，各有十一項核對，涵蓋來源種類、時間、名稱、毫秒、零值、事件對帳與重跑一致性。共同層也確認了全部事件欄位、來源雜湊及持有人隔離。

驗證中還遇到一個小問題：獨立的 HTML 對帳程式沒有明確指定 UTF-8，讓中文與日文欄位看起來不一致。修正核對程式的解碼後，原始網址、標題與頻道比較通過，匯入器本身不用跟著改。

另外，收尾討論也讓我發現，前面的產品規劃過度集中在同一個人的多平台 Recap。今天重新把問題寫清楚：我希望知道一位聽眾放到其他平台聽眾之中的位置。

先前完成的匯入與資料規則仍然需要，但後續工作要先確認排名所需的比較資料，才能讓程式繼續朝這個問題前進。

下一步，先找比較的依據

朋友提供資料，讓我驗證了另一個平台的真實紀錄，但兩個人的資料仍不足以回答全球排名。

下一天會先研究能取得哪些聽眾比較資料：它涵蓋哪些人、哪段時間、用什麼方式計算收聽量，是否只列出前幾名，以及我的 YouTube 紀錄能否用相同規則比較。

取得有限群體的資料，可以先研究在那個範圍內的位置；要把結論推到全球，還需要另外的資料與推論依據。這兩種成果會分開記錄。

今天真正完成的是：兩平台的真實紀錄已成功接入共同流程，來源和持有人沒有混在一起，已知與未知也都有保留。

接下來要把這些可靠的來源事實，接到同樣能說清楚範圍的比較資料上，逐步回答最初那個問題：我聽的音樂，放到平台之外，究竟在什麼位置？