比較、說明與問答接起來之後，我把產品的入口整理成一條完整流程：匯入原件、選定持有人、整理時間與來源，再將事件交給後面的統計。這一步完成後，原本放在不同檔案裡的活動，終於能走進同一個工作畫面。

我的歷史資料來自 YouTube Music，朋友提供的原件來自 Spotify。我和 ChatGPT 一起整理兩種來源的欄位，再讓 Codex 做出共同事件層。這層負責讓統計程式讀取一致的結構，同時保存每筆事件的來源、持有人與原始資訊。

我想要的跨平台能力很具體：選擇本人，就看到本人的活動；選擇朋友，就看到朋友的紀錄。兩種來源各自整理完成，再由使用者切換檢視。這也成為往後加入新資料的共同入口。

把來源資訊一起帶進產品

共同事件格式保留來源平台、時間、標題、來源識別與持有人。每一筆資料都有可以回到原件的線索，藝人歸屬也能繼續引用對應的證據。

播放時間則依來源提供的欄位保存。Spotify 原件提供播放毫秒時，我保留原值，讓程式直接加總；明確的零與缺少欄位分開處理。YouTube Music 的歷史 Takeout 以活動紀錄為主要量尺，產品保留這個來源特性，讓活動筆數與新的播放觀測分別有清楚的名稱。

共同格式的好處，在後面幾個功能特別明顯。統計、比較、問答與匯出都能從同一份事件集合取得資料，新增來源時也有可以沿用的介面。來源的細節留在事件裡，使用者需要查證時仍然找得到。

月份從時間界線開始整理

這次研究使用八月 UTC 視窗，因此匯入流程先處理時間，再決定事件落在哪個月份。原件若使用 CST，畫面提供明確的時區選項，由使用者確認該檔案代表 UTC+08:00，再套用對應轉換。

這讓月底的事件有一致的判定方式。例如臺灣時間九月一日清晨的活動，換成 UTC 後，可能仍然落在八月。個人資料與外部集合都採用相同的時間界線，月份也就成為可以核對的條件。

匯入完成後，我先檢查本人八月的結果。原件仍是 2,215 筆活動，包含 1,088 筆確認、987 筆排除與 140 筆待確認，目標範圍維持 1,088–1,228。從原件走到工作台，這組數字完整接到了比較與問答。

朋友的 Spotify 則在自己的持有人下呈現來源時長。一般 YouTube 和 YouTube Music 也各自保留來源範圍，畫面另有一般 YouTube 的獨立來源紀錄，整理當期活動與歸屬資訊。這些呈現讓資料主體與分析範圍都容易辨認。

新的播放觀測，也接進共同事件層

歷史匯入接通後，我再把本機測量擴充功能產生的觀測，接到相同的報告流程。擴充功能記錄 YouTube Music 的播放狀態與進度，由本機收集器保存樣本，再依連續播放的規則計算支持的時長。

在測量入口按下保存時，我先指定資料性質、持有人代號、UTC 月份與藝人。程式固定當下收到的原始前綴，挑出整段使用 observer 1.0.2 的 session，產生共同事件，再交給正式的匯入與報告程式。每一個選取步驟都留下來源對照，原始樣本與排除收據也一起保存。

這次 Edge 網站校驗以合成控制資料執行，包含兩首不同歌曲、三段播放。第一首的兩輪分別支持約 178.324 秒與 231.396 秒；第二首支持約 26.997 秒。前兩輪通過本機門檻，第三段則保留自己的短播狀態。暫停、廣告、靜音與跳轉都有對應處理，讓事件時間來自支持的播放區間。

正式事件逐筆取整後，三段合計 436,716 毫秒。匯入器讀到的結果與快照下載一致，也能沿著每列來源對照回到觀測樣本。到這一步，歷史活動與新播放觀測都有了可使用、可追溯的資料入口。

支持時間的計算也有具體條件：相鄰樣本屬於同一段播放，兩端都在播放且維持一般速度，時間與媒體進度彼此相符，才累加對應區間。第一筆樣本先建立基準，之後再以經過時間與進度的較小值記入。這讓共同事件的時長有清楚的形成方式。

每段播放保留來源歌曲識別與播放輪次。歌曲正常結束再重播時，程式依端點證據分開保存新的一輪；換曲時，新的來源識別也建立自己的起點。我能從事件回到這些分段資訊，理解一筆時長實際涵蓋哪段觀測。

從一份原件，走到一份回顧

我把私人原件放在本機程式目錄之外，再以資料夾位置連接工作室。程式、私人資料與示範資料各自有清楚的用途，搬移或重新啟動時，也能沿用同一套匯入流程。

如今，使用者可以匯入自己的資料，確認持有人與時間範圍，選擇藝人，再查看活動、比較、問答及報告。新的測量事件也沿著這條路徑進來。這是我在這一篇完成的成果：把來源整理成共同的聆聽事件，讓後面所有功能都有一個穩定的起點。