# 如何測試 Instagram Reels 的最佳發布時間

想找出適合上傳 Instagram Reels 的時間，請在自己的帳號測試兩到三個發布時段。將可供比較的 Reels 輪流分配到各時段。接著，在發布後經過相同時間時，比較同一種公開計數。用結果決定下一輪發布排程。提供的證據並未證實，有某個最佳時刻適用於所有帳號。

先準備自己的發布紀錄與一份簡單的工作表。如果你能使用 Instagram Insights，也就是帳號的私人分析報告，可以用這些資料協助選擇可行的時段。請將這些報告與公開計數分開保存。一筆公開指標資料無法顯示你的追蹤者何時在線上。

有讀者詢問[上傳時間是否仍然重要](https://www.reddit.com/r/InstagramMarketing/comments/1ufrd9g/whats_the_best_time_to_upload_reels_on_instagram/)，也有人想知道如何[找出計數與發布時間之間的基本規律](https://www.reddit.com/r/InstagramMarketing/comments/1uwsily/please_recommend_me_a_basic_but_decent_analytics/)。這些問題說明了本指南的用途，但沒有提供經過控制條件的發布時間測試結果。

以下方法會產生兩份實用紀錄：預定發布排程與結果表。你也能據此明確決定下一步：繼續、修改測試，或回報無法得出結論。

## 1. 確定一個帳號、一種計數與一項決策

Reel 是 Instagram 的影片貼文。指標是測量得到的數值，例如公開觀看次數。發布測試貼文前，先選定一個指標。

例如，你可以選擇發布滿 24 小時時的公開 `views`。這是建議的測試規則，並不代表 24 小時就是最佳觀測時間。

發布後經過時間，是指從發布到觀測之間的時間。發布後 24 小時與兩天時的計數，涵蓋的時間長度不同。不要放在同一次比較中。

收集結果前，先寫下這些規則：

1. 寫明要測試的帳號。
2. 說明 Reel 的形式與主題範圍。
3. 選定一種公開計數，並維持相同定義。
4. 選定每次讀取時，距離發布應經過多久。
5. 說明你要做出的發布排程決策。
6. 寫明如何處理缺漏、延遲與不確定的讀值。

請將 `views`、`plays`、`playsInstagram`、`likes` 與 `comments` 分開處理。不要用播放次數取代缺漏的觀看次數。不要將按讚次數加到觀看次數中。觀看次數不等於不重複的觀看人數。

一個實用的決策，可以是從兩個能長期配合的發布時段中選出一個。這項測試無法確立 Instagram 的排序規則，也不會測量觀眾觀看多久、非公開的觸及人數，或區分付費與非付費成效。

## 2. 選擇可行的時段，訂定一致的時間規則

選擇兩到三個符合工作安排的時段。如果加入第三個時段，會讓各組可供比較的貼文太少，就先從兩個時段開始。

清楚定義每個時段。寫明開始時間、結束時間與時區，並說明結束時間是否算在該時段內。例如，可以包含開始時間，但不包含結束時間。這樣就能避免同一個發布時間同時落在兩個相鄰時段。

寫下帳號使用的時區與夏令時間規則。夏令時間會改變部分地區的當地時間與 UTC 之間的對應關係。UTC 是通用的時間標準。發布排程要保留當地發布時間。如果有精確的 UTC 時間，也要一併保存。請用精確時間計算發布後經過時間。

如果測試期間遇到時鐘調整，請遵守事先寫下的規則。不要未加說明，就將依當地時間安排的時段改成固定的 UTC 時段。

帳號擁有者可查看的 Insights 能提供規劃背景，但不能取代測試。請將非公開的受眾資訊保存在帳號擁有者的紀錄中。不要聲稱公開觀看次數能找出受眾在線上的時段。

你可以用[貼文形式與發布頻率指南](/zh-Hant/articles/instagram-%E5%85%A7%E5%AE%B9%E6%A0%BC%E5%BC%8F%E8%88%87%E7%99%BC%E6%96%87%E7%AF%80%E5%A5%8F%E5%AF%A9%E6%9F%A5/)描述目前的發布模式。發布頻率是指你多久發布一次。該指南統計發布活動。本指南則協助你選擇未來的發布時間，並比較之後的結果。

## 3. 將可供比較的 Reels 輪流分配到不同時段與日期

分配是指為每支 Reel 選定發布時段。請在看到成效前，先寫下分配計畫。

在工作條件允許的範圍內，讓預定貼文盡量具有可比性。記錄主題、形式與其他可能影響比較的差異。不要將所有有把握的主題放在同一時段，卻將所有成效不確定的主題放在另一時段。

透過輪替分散這些差異。輪替是指改變各類預定貼文所分配的時段。你也可以使用隨機分配，也就是用隨機方式選擇時段。對小型測試而言，這兩種方法都無法消除所有不確定性。

請依下列順序進行：

1. 列出預計發布的 Reels。
2. 將相似的主題與形式分組。
3. 將這些組別分散到選定的時段。
4. 讓每個時段都分布在預計測試的不同日期。
5. 發布前儲存分配計畫。
6. 記錄每次變更及其原因。

不要讓一個時段只有平日貼文，另一個時段只有週末貼文，除非你原本就要測試這種日期與時段的組合。否則，就無法分開判斷日期與時間的影響。

不要因為某一次結果特別高，就將剩下最有把握的 Reels 移到該時段。請維持原始計畫。如果需要新計畫，請將它標為新的測試期間。

也要記錄宣傳、假日與協作帳號。協作帳號是指參與貼文的另一個帳號。即使輪替分配，這些差異仍可能有重要影響。

## 4. 保存發布排程與觀測紀錄

觀測是指在已知時間讀取並保存計數。請將預定讀取時間與實際讀取時間分開記錄。

下表列出工作表適合使用的欄位。有些採用 Actor 的欄位名稱。Actor 是在託管平台執行的資料收集程式。其他欄位則由你自行建立紀錄。

| 紀錄項目 | 應保存的內容 |
| --- | --- |
| 帳號與測試期間 | 帳號識別資料、測試開始時間、測試結束時間與決策 |
| 時段分配 | 預定時段、預定日期與分配變更 |
| 內容備註 | 主題、形式、宣傳、假日與協作帳號備註 |
| 貼文識別資料 | 已知的直接網址，以及回傳資料中的 `postId` 與 `postUrl`（如有） |
| 發布時間證據 | 帳號擁有者的發布紀錄、`publishedAt`、時區與時間精確度 |
| 觀測計畫 | 選定的指標、目標發布後經過時間與預定讀取時間 |
| 實際觀測 | Actor 讀值的 `scrapedAt`，或手動讀取時記錄的時間 |
| 已保存的計數 | 指標欄位、回傳值、來源與已知精確度 |
| 收集狀態 | 回傳資料中的 `status`、`statusReason` 與 `postMetricStatus`（如有） |
| 比較狀態 | 已納入、延遲、失敗、計數缺漏或時間尚未釐清 |
| 檢查備註 | 排除原因、資料衝突或其他不確定因素 |

檢查發布時間的精確度。只有日期的值，只能指出發布當天，無法確定發布時刻。不要將日期轉成午夜的時間戳記。

需要精確發布時刻時，請另外保留帳號擁有者的發布紀錄。如果該紀錄與公開發布欄位衝突，請保留兩者，並在使用發布後經過時間前釐清衝突。

手動讀取時，請保存來源，並記錄畫面上的計數是精確值還是約數。不要將畫面上經過取整的數字與已保存的精確計數混用，當作兩者的精確度相同。

## 5. 收集選定的公開計數

只要能在預定的發布後經過時間保存同一種公開計數，就能用手動紀錄完成測試。各時段要使用一致的來源。每次都要記錄實際讀取時間。

[Instagram Metrics Scraper](https://apify.com/chronometrica/instagram-metrics-scraper) 的文件說明了如何透過已知內容網址，收集當下的公開指標資料。其公開建置版本 1.0.35 接受將 `mode` 設為 `contentUrls`，並在 `startUrls` 中提供直接網址。提供的公開介面規格已於 2026 年 10 月 25 日查核。本指南沒有進行付費執行。因此，這些證據支持的是文件記載的輸入與欄位說明，而非目前實際執行的結果。請參閱[公開預設建置紀錄](https://api.apify.com/v2/acts/Y7Ib4ARpUHw5Ue8op/builds/default)。

一次執行是指 Actor 運作一次。以下精簡輸入已依公開輸入結構規格查核。該規格定義可接受的輸入欄位。這份輸入尚未實際執行：

```json
{
  "maxItems": 1,
  "mode": "contentUrls",
  "startUrls": ["https://www.instagram.com/reel/DIwcCZgxVZP/"]
}
```

5. 收集選定的公開計數

將範例網址換成測試中一支已知的公開 Reel 網址。請完整取代範例值。如果保留範例網址，再加入自己的網址，就會多出一個無關的收集目標。

`maxItems` 限制回傳指標資料的總筆數。這次只檢查一個網址，因此上限設為 1 合適。收集更多資料時，請檢查上限，避免預定清單遭到截斷。仍須逐一確認每個預定網址有對應結果，或記為缺漏。

[Instagram Reels Performance Tracker](https://apify.com/chronometrica/instagram-metrics-scraper/examples/instagram-reels-performance-tracker) 是一項公開 Task。Task 是已保存的輸入預設組態。其頁面與預設組態的識別資料已查核。本指南沒有透過已登入帳號讀取其已保存的設定，也沒有實際執行。使用前，請檢查這些設定，並取代範例輸入。

Actor 提供當下的公開觀測資料。發布分配、讀取計畫、比較與決策都由你負責。不要假設預設組態會安排讀取時間，或完成這項實驗。

## 6. 比較前檢查每筆預定讀值

Actor 讀值的實際收集時間，請使用 `scrapedAt`。不要用執行開始時間或預定提醒時間取代它。`publishedAt` 則是發布時間的證據。這些欄位的用途不同。

請用已查核的發布時間與觀測時間，計算發布後經過時間。提醒你在 24 小時時收集資料，只是一項計畫，不能證明資料確實在 24 小時時收集。

下方採用精確 24 小時的方法，因此彙總只納入發布滿 24 小時當下的觀測值。提早或延遲取得的讀值，請另列保存。如果工作流程需要容許時間誤差，請在測試前訂明。回報時，應說明比較採用的是發布後的一段時間範圍，並列出實際經過時間。不要稱為精確的 24 小時資料。

請檢查以下異常狀態：

| 狀態 | 必要處理方式 |
| --- | --- |
| 計數缺漏 | 維持未知狀態。不要填入零。 |
| 回傳計數為零 | 如果來源與品質檢查均支持該值，請保留零。 |
| 讀取延遲 | 保存實際發布後經過時間。不要納入指定精確時間的彙總。 |
| 發布時間只有日期 | 除非有其他證據提供時刻，否則應將精確發布後經過時間保留為未釐清。 |
| 收集失敗 | 保存失敗紀錄與回傳的原因（如有）。保留該筆預定貼文，讓讀者仍能看見。 |
| 指標不同 | 不要將該讀值納入選定指標的比較。 |
| 計數精確度不明 | 釐清前，不要納入精確計數的彙總。 |
| 收集目標沒有對應結果 | 保留缺漏並調查原因。不要假設沒有活動。 |

如果回傳資料包含 `status`、`statusReason` 與 `postMetricStatus`，請讀取並保留其值。不要因為有一筆資料，就假設每個指標都可用。

重新執行無法補回先前錯過的讀值。[每月已保存計數指南](/zh-Hant/articles/%E6%AF%8F%E6%9C%88instagram%E8%A7%80%E7%9C%8B%E5%A0%B1%E5%91%8A-%E6%8C%89%E7%99%BC%E5%B8%83%E6%97%A5%E6%9C%9F%E5%88%86%E9%96%8B%E8%88%8A%E8%88%87%E6%96%B0%E8%B2%BC%E6%96%87/)也說明了過去報告時間分界的相同限制。本測試將這項限制套用到每篇貼文預定的發布後經過時間。

## 7. 比較合格貼文，並列出缺漏

合格讀值是指符合測試前所訂規則的讀值。請列出所有貼文，包括不合格的貼文。接著，只彙總各預定組別中的合格讀值。

每個發布時段都要報告：

1. 預定貼文數量。
2. 合格讀值數量。
3. 缺漏或排除讀值的數量與原因。
4. 每一筆合格計數。
5. 計數的中位數。
6. 合格計數的最低值與最高值。

中位數是將計數排序後，位於中間的數值。如果計數筆數為偶數，就取中間兩個數值的平均值。這裡的平均值，是將兩者相加後除以二。

數值範圍會列出最低值與最高值。這能協助讀者判斷，微小的中位數差異是否落在各篇貼文結果的廣泛分布之內。回報中位數時，必須同時提供貼文數量與缺漏情形。

再次檢查分配計畫。某個時段是否分到較多有宣傳的貼文？是否以某個主題為主？收集失敗是否讓某組的某一整類貼文都無法納入？請在結果旁列出這些限制。

差異只描述合格樣本中發生的情況，無法確立發布時間具有普遍適用的效果。

## 8. 逐步解析原創虛構範例

本例的所有內容都是原創虛構。這些是為教學編造的紀錄，不是 Actor 輸出，也不是真實帳號的結果。

這個虛構帳號測試兩個可行的發布時段：A 與 B。它採用發布滿 24 小時當下的精確公開 `views`。虛構的帳號擁有者保有精確發布紀錄。可供比較的主題會輪流分配到兩個時段與測試日期。

原定發布九支 Reels。其中八支有合格的精確 24 小時讀值。第九支只有發布後 25 小時取得的延遲讀值，因此不納入 24 小時彙總。

| Reel | 分配時段 | 實際讀取時距發布多久 | 發布滿 24 小時當下的精確觀看次數 | 比較狀態 |
| --- | --- | --- | --- | --- |
| A1 | A | 24 小時 | 100 | 合格 |
| A2 | A | 24 小時 | 120 | 合格 |
| A3 | A | 24 小時 | 140 | 合格 |
| A4 | A | 24 小時 | 160 | 合格 |
| B1 | B | 24 小時 | 110 | 合格 |
| B2 | B | 24 小時 | 130 | 合格 |
| B3 | B | 24 小時 | 150 | 合格 |
| B4 | B | 24 小時 | 170 | 合格 |
| B5 | B | 25 小時 | 缺漏 | 延遲讀值另行保存 |

B5 缺漏的是未曾觀測到的、發布滿 24 小時當下的精確計數。這不代表零。延遲讀值無法補上這項缺漏。

時段 A 的合格觀看次數排序後為 100、120、140 與 160。中間兩個值是 120 與 140 次觀看：

中位數 A = (120 + 140) / 2 = 130 views。

時段 B 的合格觀看次數排序後為 110、130、150 與 170。中間兩個值是 130 與 150 次觀看：

中位數 B = (130 + 150) / 2 = 140 views。

觀測到的中位數差異為：

140 views − 130 views = 10 views。

以 A 為基準，相對差異為：

10 views / 130 views × 100 = 7.69%。

這項除法會約去觀看次數的單位。這個百分比比較的是兩個中位數，不是人數比例、確定程度，也不是保證能達到的增幅。

| 時段 | 預定貼文數 | 合格讀值數 | 指定精確時間的讀值缺漏數 | 中位數 | 最低值至最高值 |
| --- | --- | --- | --- | --- | --- |
| A | 4 | 4 | 0 | 130 次觀看 | 100 至 160 次觀看 |
| B | 5 | 4 | 1，因讀取延遲 | 140 次觀看 | 110 至 170 次觀看 |

在合格讀值中，B 的觀測中位數較高。兩組的數值範圍重疊，而且 B 缺少一筆指定精確時間的讀值。這個小型虛構樣本無法證明某個發布時間普遍最佳。審慎的下一步，是先重複原定比較，再決定是否長期優先採用 B。

## 選擇下一輪發布排程

當某個時段的結果模式重複出現，足以支持你事先設定的決策，而且發布排程仍然可行，就繼續採用該時段。結論只適用於這個帳號、指標、發布後經過時間與測試期間。提供的證據並未指出，只要達到某個通用的貼文數量，就能確定發布時間的效果。

如果主題、日期、宣傳或缺漏讀值讓比較失去意義，就修改測試。如果現有紀錄不足以支持偏好任何時段，就回報沒有明確差異。無論結果如何，都要保留原始分配計畫與缺漏表。

先寫下兩個可行的時段，再將接下來可供比較的 Reels 分配到這些時段。發布前先訂好觀測計畫。如果使用 [Instagram Metrics Scraper](https://apify.com/chronometrica/instagram-metrics-scraper)，請用上方的精簡輸入檢查一個已知的公開網址。確認回傳的識別資料、時間戳記、計數與狀態後，再依賴這個資料收集方式。

## 來源與延伸閱讀

- [Instagram Metrics Scraper 公開預設建置版本 1.0.35 — 於 2026 年 10 月 25 日查核；僅檢查公開介面規格，未進行付費實際執行測試](https://api.apify.com/v2/acts/Y7Ib4ARpUHw5Ue8op/builds/default)
- [Instagram Reels Performance Tracker — 於 2026 年 10 月 25 日查核；僅確認公開頁面與預設組態存在，未測試已保存的設定或實際執行](https://apify.com/chronometrica/instagram-metrics-scraper/examples/instagram-reels-performance-tracker)
- [讀者關於 Reel 最佳上傳時間的提問 — 發布於 2026 年 6 月 26 日；於 2026 年 8 月 11 日觀測；僅為一則提問，沒有經過控制條件的發布時間測試結果](https://www.reddit.com/r/InstagramMarketing/comments/1ufrd9g/whats_the_best_time_to_upload_reels_on_instagram/)
- [讀者關於基本計數與發布時間規律的提問 — 發布於 2026 年 7 月 15 日；於 2026 年 8 月 11 日觀測；僅為一則提問，沒有產品使用或成效證據](https://www.reddit.com/r/InstagramMarketing/comments/1uwsily/please_recommend_me_a_basic_but_decent_analytics/)