1. 我能開啟報表，不代表其他使用者也能

Day 29 把 Gemini 的分類結果與設備診斷分開，也規劃了從摘要追查回報與版本的路徑。接下來，報表要交給值班人員與維護者使用，我需要確認的就不只是數字：對方能不能開啟？看見的內容是否符合工作需要？發現異常時，知道找誰處理嗎？

我規劃先在查看模式核對頁面與控制項，再以不同使用者身分測試。值班人員需要必要的摘要與追查資訊，維護者則可能需要修改來源與公式；兩者不必取得相同權限。

Data Studio（原 Looker Studio）提供查看與編輯等分享權限，組織管理政策也可能限制分享方式。我會先確認對象與用途，再決定權限。以下仍是交付設計，尚未實際分享或完成使用者身分驗證，不能因為已有報表連結，就認為其他人已能使用。

2. 報表權限與資料憑證分開選

即使使用者有權限開啟報表，圖表仍可能無法取得資料。報表權限決定誰能查看或編輯，資料憑證則決定以誰的身分存取來源。

官方提供三種方式：Owner's Credentials 使用憑證擁有者的授權；Viewer's Credentials 使用各使用者自己的憑證；Service Account Credentials 使用服務帳戶。服務帳戶方式目前限 BigQuery 來源，並有組織與管理員設定條件。我需要依實際環境選擇，不能假設每個帳號都能使用。

選擇擁有者憑證時，我尤其要確認報表提供的欄位與範圍是否適合分享。下拉選單讓使用者選 Q17，只是分析操作，不能當成隔離其他設備或敏感原文的安全措施。

我的驗收會同時檢查「應該看得到」與「不應該看得到」的內容。若需要限制資料，必須另行設計並驗證存取控制，不能只靠隱藏圖表或預設篩選。

3. 更新了畫面，不代表新事件已到齊

報表能開啟之後，下一個問題是：畫面上的數字有多新？

我會分開標示來源資料的截止資訊、採用的分析版本，以及報表刷新資訊。最新事件時間只能說明目前收到了哪筆事件，不能證明較早的事件都已到齊；Gemini 分類來源也可能仍有未分析或未驗證的回報。

官方的 data freshness 設定控制查詢結果的重用：相同查詢在條件允許時可從記憶體取得結果；超過設定期限或出現新的查詢時，則向來源取得資料。因此，切換篩選即使仍在期限內，也可能產生新查詢。

這個設定不能補回上游漏傳的事件，也不能讓尚未完成的分類自動完成。我會讓使用者看見資料限制，並依工作需要訂定更新要求；本系列的儀表板仍是分析與追查工具，不能寫成已建成即時告警系統。

4. 用查詢紀錄觀察用量，不用點擊數猜費用

多人使用後，查詢量可能增加，但不能直接用「人數乘上點擊數」估算費用。例如，第一位使用者查看 Q17 的告警數時，系統查出結果；其他使用者查看相同範圍時，如果符合更新與存取條件，Data Studio 就可能直接顯示先前查好的結果，不必再向 BigQuery 查詢。因此，多一次開啟或點擊，不一定增加一次查詢；切換日期或設備範圍，則可能需要重新取得資料。

我規劃利用 BigQuery 的 INFORMATION_SCHEMA.JOBS 查看實際查詢紀錄，核對處理量、計費量、快取、錯誤與時間：

查詢這個檢視需要相應權限，且執行地區須與檢視的地區一致。我也要先辨認哪些查詢來自報表，不能把專案全部工作都算成儀表板用量。

這裡還要分清兩種情況：Data Studio 直接顯示先前結果時，可能不需要向 BigQuery 發出新查詢；若已向 BigQuery 發出查詢，BigQuery 也可能使用自己的查詢結果快取，這才是 cache_hit 要觀察的內容。

最後，計費資料量仍不等於最終帳單。按量計費與容量計費需要用不同方式核對，部分資料安全設定也會讓處理量或計費量欄位無法顯示。我會先用查詢紀錄了解實際用量，再配合計費方式與帳單確認費用。

5. 先量瓶頸，再選改善方式

如果報表變慢或處理量偏高，我先定位問題，不急著增加加速資源。可能需要檢查查詢欄位、時間範圍、重複轉換與資料連接，再比較修改前後的查詢紀錄。

官方建議只讀取必要欄位，並在分區表上使用適當分區條件，讓查詢略過不需要的分區。報表選了日期，並不自動證明底層查詢已做到這件事；我仍要核對來源查詢與實際處理量。

摘要資料也要保留必要的識別資訊。依 Day 28 的定義，若要跨日重算不重複設備數，就不能為了縮小資料，只留下每日設備總數而丟掉設備識別碼。

BI Engine 是官方提供的加速方案之一，但在這裡仍只是候選方案。我要先取得瓶頸與用量證據，再評估支援條件、費用與效益，不預先宣稱已啟用或一定能節省多少成本。

6. 交接的不只是連結，還有定義與責任

如果只交出連結，接手的人遇到數字不同，仍不知道是資料更新、篩選改變，還是公式被修改。我因此規劃把報表、來源與驗收依據一起保存。

交接內容至少包含指標定義、每筆資料代表什麼、去重方式、採用版本、日期與控制項範圍、資料憑證、SQL 比較基準，以及尚未驗證的項目。普通邏輯檢視可以整理查詢規則，但不代表安全隔離已自動完成。

責任也需要落到具體工作：資料維護者追查缺漏與重複；報表維護者核對來源、公式與篩選；審核負責人確認 Gemini 分類與回覆內容。人員或權限異動時，還要重新檢查來源是否能持續存取。

官方說明指出，報表分享不會自動分享可重複使用的資料來源；嵌入式來源則可能隨報表讓編輯者使用與修改。所以，交接時要把來源類型與編輯權限說清楚，避免接手者改了共用設定，卻不知道哪些報表受到影響。

7. 回顧三十天：從資料處理到可以追查與交接的應用

回看整個系列，我想保留的是一條能檢查的路徑：從 N201 的文字，找到選定的 Gemini 分類結果與草稿審核版本，再依可靠關聯查看 Q17 的設備事件。

在設計情境中，E501 是觸發、E502 是恢復、E503 是再次觸發。這些紀錄能協助整理發生順序，卻不能直接證明感測器故障；分類為告警處理，也不能讓回覆自行承諾修復時間。每一層都有自己的驗收責任。

這三十天的文章，從雲端資料處理逐步走到 Gemini 分析與儀表板應用。資料清洗需要處理重複、缺漏與品質；資料搬運需要確認寫入與失敗處理；Gemini 的情緒判讀、內容分類與回覆生成，需要保留版本、檢查依據並經過適當審核；儀表板則要明確定義數字、分母、時間與篩選範圍。最後，還要把權限、更新、成本與維護責任納入交付。

對我而言，這個系列最重要的學習，是每次轉換都要留下可核對的依據。資料成功入表，不代表內容正確；Gemini 回覆自然果斷，不代表判斷有據；圖表顯示數字，也不代表解讀合理。把這些界線說清楚，才能讓使用者知道數字怎麼來、能支持什麼判斷，並讓接手的人有依據地持續維護。

參考資料

1. Invite others to your reports
2. Data credentials
3. Manage data freshness
4. JOBS view
5. Optimize query computation