App Store Connect API 4.6：INSTALLS 報表停更怎麼辦？2026

定時任務沒有拿到新的 INSTALLS 報表，儀表板卻把缺值畫成零。

最快處理方式：截至 2026 年 11 月 7 日，App Store Connect API 4.6 的變更代表新的 INSTALLS 報表不會繼續產生，但歷史報表仍可下載；先核對 Apple 的報表說明，再保留歷史資料、調整任務與看板，不要把缺報當成 CI 故障反覆重試，也不要未經確認就宣稱其他指標可直接替代。Apple API 4.6 發布說明｜報表可用性說明

適合維護 App Store Connect API 報表下載任務、需要分辨報表變更與認證、網路或程式故障的開發者。
也適合維護 macOS CI 定時任務，或負責發行資料看板、歷史趨勢與資料品質的工程師。

最後核對於 2026 年 11 月 7 日；資料核實自 Apple API 4.6 發布說明、銷售與趨勢報告介面文件及報告可用性說明。若 Apple 更新報表生成狀態、歷史下載規則或公布替代報表，應重新核對本文的處置方式。

先判斷你遇到的是報表狀態，還是下載故障

App Store Connect API 4.6 的 INSTALLS 報表變更，應與一般請求錯誤分開處理。Apple 在 2026 年 11 月 4 日發布 API 4.6；依其版本發布頁，新 INSTALLS 報表不再生成，既有歷史報表仍可下載。這是報表生命週期的變更，不是每次排程都應重試的暫時性錯誤。

排查時先核對請求目標與回應內容。確認程式請求的報表類型仍是 INSTALLS，並閱讀 API 回應、任務日誌及 Apple 對該報表的說明；再分別檢查憑證與權限、網路連線、回應解析及檔案儲存流程。這幾類問題可能造成下載失敗，但不能僅憑「沒有新報表」推定 CI 主機有故障。

表中的「處置評分」是依工程影響與誤判風險作的工作優先級建議，不代表 Apple 對個別任務的判定。銷售與趨勢報告的請求方式應以官方介面文件為準；若歷史報表下載也出錯，請另按文件規定的報告條件與可用性查核。

儀表板必須把缺報和零值分開

「沒有新的報告」不等於「安裝量為零」。若 ETL 流程遇到空回應時自動填入零，儀表板可能產生一段看似真實的下跌；若把前一次資料複製到新日期，又可能造成指標持續不變的假象。這些都不是報表本身提供的數值，而是下游系統對缺值的處理結果。

建議在資料模型中分開保存數值與報表狀態，例如「有資料」、「預期無新報表」、「下載失敗」及「解析失敗」。沒有新報表時，不新增零值紀錄；歷史趨勢仍可顯示已保存的資料，但要標明資料來源及可用範圍。告警也應區分預期狀態與操作故障，避免將報表停止生成的通知當作需要一直重跑的任務失敗。

若看板同時呈現多種 App Store 指標，先核對 Apple 的分析指標定義。不同報告所代表的事件、統計範圍或更新方式可能不同；只因名稱相似，不能推論數值可以互換。

把歷史 INSTALLS 報表納入團隊歸檔

Apple 文件指出，歷史報表仍可下載，但實際可下載範圍應按 Apple 的銷售與趨勢報告可用性說明核對。不要只依賴 API 之後仍能取得舊檔；團隊應把已下載的原始報表納入自己的保存流程，避免未來需要比較時才發現資料只留在單一工作目錄或短期暫存區。

歸檔時保存原始檔及伴隨的來源資訊，至少包括報表類型、請求條件、取得結果、任務執行時間與解析版本。原始資料應與轉換後的看板資料分開，這樣日後更換欄位解析方式時，仍能由來源檔重新處理，而不是拿已彙總的結果冒充原始報表。

對於保留期限、存取權限及備份方式，依團隊的資料治理要求制定，不要把 Apple 的報告可用性期限當成團隊自身的歸檔政策。若你還沒有完整的下載與保存流程，可先從本站的開發者指南整理排程、檔案交付與環境維護需求。

其他指標不能未驗證就補位

業務提出替代資料時，先釐清他要回答的是安裝次數、使用者取得、首次下載，還是其他行為問題，再對照 Apple 對各指標的定義。Apple 提供 App 安裝相關文件，例如App Installs 報告說明與Platform App Installs 說明，但文件名稱或指標名稱相近，不足以證明它們與 INSTALLS 銷售報表具有相同口徑。

你應先把替代方案標示為「待驗證」，再用團隊可取得的資料比較統計對象、涵蓋平台、時間範圍及使用情境。若這些條件未能確認，就在看板上明確標示來源與定義差異，不要把替代值接到舊序列上，製造看似連續、實則口徑變更的趨勢線。Apple 未確認等價關係前，也不要對業務承諾某項分析資料可以一對一補上 INSTALLS。

調整 macOS CI 定時任務並驗收

這個變更不表示 API 呼叫必須由 Mac 執行；若你的下載、轉換及排程流程在其他環境中運作穩定，無須只為報表狀態遷移到 macOS。若目前使用 macOS CI 定時任務，則應把「沒有新報表」納入明確結果分類，避免它觸發無限重試、錯誤告警或下游零值。

可以按以下順序調整並驗收：

• [ ] 檢查程式設定，確認請求目標、報表類型與日期條件，並記錄 API 4.6 後新報表不再生成的預期。
• [ ] 將任務結果拆分為「取得歷史檔」、「預期沒有新報表」與「請求或處理失敗」，避免用單一成功／失敗狀態掩蓋差異。
• [ ] 對預期的無新報表停止重試；只在認證、連線、請求或解析等具體錯誤下執行相應的重試或告警。
• [ ] 確認日誌保留請求目標、回應狀態、錯誤內容及檔案處理結果，並避免將憑證等敏感資料寫入日誌。
• [ ] 修改看板與下游計算，讓缺報維持為無資料狀態，不轉為零，也不自動延伸前一次數值。
• [ ] 使用已保存的歷史報表驗證下載與解析路徑，再觀察一次實際排程結果，分別確認歷史讀取和無新報表處理。
• [ ] 在驗收紀錄中寫清楚：任務執行成功只代表排程與處理流程按預期結束，不代表 Apple 仍會生成新的 INSTALLS 報表。

注意：歷史檔可以成功讀取、CI 任務可以正常結束，與新報表仍會生成是三件不同的事。監控與驗收紀錄應分別呈現，否則任務綠燈容易被誤解成來源資料仍在更新。

若下載、歸檔或其他 macOS 專屬工作需要長時間執行，先評估現有主機的維護負擔與執行環境需求，再參考本站的遠端 Mac 環境與使用資訊。API 報表本身不要求必須使用 Mac；只有當你的流程確實依賴 macOS 工具鏈，或需要一台持續在線的 Mac 執行其他任務時，遠端 Mac 才值得納入選型。

上線前的檢核清單

在改動正式排程前，逐項確認處理結果有可追溯依據：

• [ ] 已將 Apple API 4.6 的變更與一般認證、網路及程式錯誤分開記錄。
• [ ] 已依 Apple 文件核對歷史報表的可用性，並測試團隊保存的歷史檔。
• [ ] 儀表板可分辨零值、缺值、預期無新報表與任務失敗。
• [ ] 重試與告警規則不會把預期中的無新報表視為需要持續重跑的故障。
• [ ] 替代指標已有定義、範圍及口徑核對紀錄，未驗證前沒有接續成同一條趨勢線。
• [ ] 驗收紀錄分開說明「歷史資料可讀」與「新報表不再生成」。

本文處理的核心，是把來源報表的變更、CI 任務狀態與看板資料品質分開管理。若你目前依賴臨時工作站或本地 Mac 維持排程，這類做法可能有主機離線、環境差異與交接維護等限制；但若任務長期重負載、需要實體介面，或目前的非 Mac 環境已足以完成工作，租用遠端 Mac 未必合適。只有在你確實需要持續在線的 macOS 執行環境、又不想為短期或階段性需求自購硬體時，才值得比較 UDPMac 的租用方案與自有 Mac 的維護成本。

常見問題