我回來補完這個系列了。前十九篇累積了資料整理、藝人歸屬判定和外部比較，這次我想把它們接成一條完整流程：開啟產品，選擇自己的資料、藝人與期間，看懂結果，再把報告帶走。Day20 到 Day30 會依照這次完成的十一個主題，記錄這個產品如何收尾。

最初吸引我的問題很生活化：我到底有多常聽某位藝人？和其他留下聽歌紀錄的帳戶相比，我落在哪個位置？一路做到現在，這個問題已經長出一套具體的資料處理方法，也有自己的操作介面。回來之後，我請 ChatGPT 協助整理研究脈絡，再由 Codex 把匯入、計算、解釋和執行入口整合起來。

從自己的資料開始

畫面的起點是我自己的八月 UTC YouTube Music 活動。原件共留下 2,215 筆，其中 1,088 筆確認屬於目標藝人，987 筆排除，另外 140 筆保留為待確認。這三類合起來，剛好對回原始活動總數。

我把目標活動呈現為 1,088–1,228 筆。下界採用已確認的 1,088 筆，上界再加上 140 筆待確認活動。讀者因此可以同時看見已經支持的結果，以及進一步查證可能涵蓋的範圍。這份歷史原件採用活動筆數作為量尺；新的播放測量則另外記錄時間，兩種結果在畫面上各自有清楚的名稱。

介面分類欄位保留「確認、排除、未知」三種狀態。文章中的待確認活動，就是畫面裡的未知項目；點回這些資料時，會知道它們來自哪份原件。保存結果時，狀態和筆數也會跟著一起輸出，方便我繼續研究。

這個設計也讓查證有了方向。想縮小範圍，就從那 140 筆待確認活動往下看：來源連結、錄音資訊或藝人署名，哪一項證據能夠支持歸屬？數字因此接回實際資料，而使用者可以理解每一步整理對結果的影響。

把比較做成可選擇的功能

這次我把外部固定帳戶集合從 35 個擴展到 113 個。保留原本的資料，再接入新增的 78 個帳戶，讓比較有更多實際紀錄可以使用。新增帳戶在八月 UTC 共有 103,217 筆去除分頁重疊後的保留紀錄，資料接收、分類和報告都接進同一條流程。

產品提供兩種集合選擇。第一種採用事先固定的 77 個來源正值帳戶，加上本人共有 78 份紀錄；第二種使用全部 113 個外部帳戶，加上本人共有 114 份。這裡的單位是固定帳戶與本人的紀錄集合，觀測期間和藝人條件也一起顯示。

位置也採用區間，將每份資料的確認數與待確認數一起放進計算。使用者可以看到，在這組已保存資料容許的情境之中，自己的位置如何變動。原本 35 個帳戶的基線報告也保留下來，方便回頭核對擴展前後的集合和結果。

一次選擇，接起整份報告

實際操作時，先選資料來源與持有人，再選藝人、期間和比較集合。我的 YouTube Music 與朋友的 Spotify 會建立各自的資料集；來源提供哪些欄位，就用相應的量尺呈現。每一次切換，都會重新產生統計、比較和說明。

我最在意的是畫面各部分能夠互相接上。活動總數來自匯入事件，目標範圍來自歸屬判定，位置來自目前選定的集合，文字說明則引用這份計算。最後匯出的 HTML、JSON 和 CSV 也帶著相同的選擇條件，讓結果從畫面走到檔案時仍然容易理解。

前面研究過的署名連接詞解析，也整理成可單獨查看的敏感度分析。在原 35 個帳戶基線中，四筆新增排除讓最近邊界帳戶的上界從 1,127 調整為 1,123，而位置區間保持一致。這個小案例讓我看到，產品能把一項規則的效果落到具體欄位，再展示它對最終結果的影響。

把新的測量也接進來

為了取得更細的播放過程，我另外完成本機瀏覽器擴充功能，記錄 YouTube Music 播放器的狀態、進度與時間。這條路徑有自己的短段校驗、正式紀錄和保存快照入口，讓歷史活動分析與新的播放測量可以在同一個產品裡使用。

我也建立了五位假設觀測者的虛擬七天實驗，以明列的日期與播放事件，完整走過累計、期間切換、比較與匯出。實驗資料有自己的標示，適合拿來熟悉操作，也讓七天累計的行為可以立即重跑。

最後，我把這些入口整理成正式整合版 1.2。單一啟動器接起回顧、播放測量和虛擬實驗，私人資料放在程式與 Git 外，保存快照則串起原件、版本篩選、匯入和報告。從使用者角度看，現在可以一路完成「資料進來、結果算出來、說明讀懂、報告帶走」。

這就是我回到 Day20 的成果：前面累積的研究，已經有了可以開啟、操作和保存的產品。接下來十篇，我會依序拆開它的量尺、來源、說明、測量與交付，帶大家走完這條流程。