使用 Google Ads API 擷取實體和報表資料的方法有三種。
本指南主要著重於串流 GoogleAdsService 的資料。以下是三種資料擷取方法的高階差異：
| GoogleAdsService.SearchStream | GoogleAdsService.Search | GET 要求 | |
|---|---|---|---|
| 適用於正式版程式碼 | 是 | 是 | 否 (僅限偵錯) |
| 服務 | GoogleAdsService |
GoogleAdsService |
資源專屬服務 (例如 CampaignService) |
| 情境 | 擷取物件和報表 | 擷取物件和報表 | 正在擷取物件 |
| 回應 | GoogleAdsRow 物件的串流 |
GoogleAdsRow 物件的頁面 |
一個物件 (例如 Campaign) |
| 回應的欄位 | 僅限查詢中指定的 | 僅限查詢中指定的 | 已填入所有欄位 |
| 每日上限 | 以存取層級為依據的每日上限 | 以存取層級為依據的每日上限 | 每日 1,000 個要求 |
SearchStream 與搜尋的比較
雖然 Search 可以傳送多個分頁要求來下載整份報表，但 SearchStream 只會傳送單一要求，並啟動與 Google Ads API 的永久連線，無論報表大小為何。
針對 SearchStream，資料封包會在資料緩衝區中快取完整結果，然後立即開始下載。您的程式碼不必等待整個串流完成，就能開始讀取緩衝的資料。
省去要求每個 Search 回應個別頁面的往返網路時間 (視應用程式而定)，SearchStream 可以改善分頁效能，特別是在大型報表上。
範例
例如，請取得包含 100,000 列的報表。下表列出了這兩種方法之間的會計差異。
| SearchStream | 搜尋 | |
|---|---|---|
| 頁面大小 | 不適用 | 每頁 10,000 列 |
| API 要求數量 | 1 項要求 | 10 個要求 |
| API 回應數量 | 1 部連續串流影片 | 10 則回應 |
效能因素
一般來說，我們建議採用 SearchStream 而非 Search，原因如下。
單一頁面報表 (少於 10,000 列)：這兩種方法沒有顯著的效能差異。
針對多頁報表：
SearchStream通常速度會更快，因為避免多次往返讀取，且從磁碟快取讀取/寫入的因素較低。
頻率限制
這兩種方法的每日限制都必須符合開發人員權杖的標準限制和存取層級。無論結果經過分頁或串流處理，單一查詢或報表都會計為一次作業。