產品接起來之後，我先整理最基本的一件事：畫面上的每個數字，到底在量什麼？我手上有自己的 YouTube Music 活動、朋友的 Spotify 播放資料，以及外部帳戶在 ListenBrainz 留下的 listen。它們都能描述聽歌行為，也各自提供不同的細節。

我請 ChatGPT 協助整理這些名詞，再交給 Codex 實作成資料欄位與比較條件。這一步讓整個產品更容易使用：使用者選到一份來源時，可以直接看見它的持有人、期間和單位，接著用合適的方式理解結果。

活動筆數、播放時間與合格次數

第一把量尺是活動筆數。我的八月 UTC 原件有 2,215 筆活動，能讀到時間、標題和來源連結。經過藝人歸屬判定，得到 1,088 筆確認、987 筆排除、140 筆待確認，因此目標活動範圍為 1,088–1,228 筆。這把量尺適合描述歷史原件留下多少活動，以及其中多少和目標藝人有關。

第二把量尺是播放時間。朋友的 Spotify 原件有播放毫秒欄位，產品依照該持有人的紀錄加總時間。新做的本機測量也採用播放過程中的時間資訊，讓這類資料有直接的時間依據。歌曲長度則放在另一個欄位，用來描述曲目和計算門檻；這樣閱讀時，每個數字的用途都很清楚。

第三把量尺是符合指定門檻的次數。Last.fm 官方規則對 scrobble 提出曲目超過 30 秒，以及播放半首或四分鐘、取較早者的條件。ListenBrainz 提交文件也列出半首或四分鐘、取較短者的規則。外部來源以保留提交紀錄呈現；本機測量則可以依保存的播放進度，逐段檢查自己的門檻。

本機播放時間還有自己的接收規則。同一段播放的相鄰樣本，需要連續、處於播放狀態、保持一般速率，且播放器進度與經過時間相符，才會累計時間。暫停、靜音、廣告和拖動進度都有相應處理。這樣一來，每段小計都能回到實際樣本，也能看見哪個時間區間進入了計算。

這三把量尺各自回答一個問題。把它們整理成產品欄位之後，使用者就能按需求選擇：想看歷史活動，讀筆數；想看花了多少時間，讀毫秒或分鐘；想看播放是否達到門檻，讀逐段判定。

比較條件和數字一起顯示

有了量尺，下一步是把比較條件補齊。產品將持有人、藝人、期間、來源與計算單位一起保存。八月 UTC 的外部固定集合，就和八月 UTC 的個人活動一起比較；切換月份或藝人時，介面會重新核對相應的來源與證據。

我很喜歡這個操作方式，因為它把研究中的選擇變成可以看見的產品行為。使用者選定期間後，活動總數、目標範圍、可用比較和說明會一起更新。需要補充來源的條件也會直接出現在畫面，接下來該匯入什麼資料就有了具體方向。

同一份紀錄還能讀出不同面向。例如在八月保留紀錄中，我的目標活動佔比為 49.12%–55.44%，外部帳戶 meze 為 28.63%–37.35%。前者的下界高於後者上界，表示這兩份紀錄的目標活動組成有清楚差異。文章和畫面都用「活動佔比」描述它，讓比較緊扣這次採用的量尺。

用實驗看見量尺的差別

虛擬七天實驗提供了一個直覺例子。五位假設觀測者依照明列的 UTC 日期、曲長和播放事件產生資料，再交給本機規則累計。假設觀測者 A 七天的播放小計為 1,274,000 毫秒，也就是 21 分 14 秒；在這五份實驗資料中，時間位置為 4／5，已確認達到門檻的次數位置則為 3／5。

時間和次數出現不同位置，正好展示兩把量尺各自關注的事情。長一點的播放會增加時間，跨過門檻的播放會增加合格次數。操作時切換模式，就能直接看見同一組事件如何形成不同結果。這份實驗以 synthetic 標示保存，曲目歸屬和歷史八月活動則使用各自的資料脈絡。

實際網站短段校驗也讓我把單位轉換處理得更細。三段播放測量合計 436,717.337 毫秒，正式匯出採用逐段向下取整，得到 436,716 毫秒。差額 1.337 毫秒和原小數都留在 metadata，報告可以追查這次轉換如何完成。

合格次數也採用逐段紀錄。系統先累計該段可支持的播放時間，再套用明列門檻，保存判定和依據。重播由播放段落區分，曲長更新則有一致的處理方式。回頭檢查時，我能從一次合格判定，逐步找到門檻、時間小計和原始樣本。

從資料匯入，到計算，再到顯示單位，這些細節都接在同一條流程中。我可以放心地把不同來源放進產品，因為每份資料都有自己的持有人和量尺，每次比較也帶著相應條件。下一篇，我會繼續介紹外部樣本如何擴展，以及它們怎麼成為可以重跑的比較資料。