Google Ads API エンティティとレポートデータを取得するには、次のいずれかの方法を使用します。
2 つの方法の主な違いは次のとおりです。
| GoogleAdsService.SearchStream | GoogleAdsService.Search | |
|---|---|---|
| 本番環境コードに適している | はい | はい |
| サービス | GoogleAdsService |
GoogleAdsService |
| シナリオ | オブジェクトとレポートの取得 | オブジェクトとレポートの取得 |
| レスポンス | GoogleAdsRow オブジェクトの Stream |
GoogleAdsRow オブジェクトのページ |
| レスポンスのフィールド | クエリで指定されたもののみ | クエリで指定されたもののみ |
| 1 日の使用上限 | アクセスレベルに基づく 1 日あたりの上限 | アクセスレベルに基づく 1 日あたりの上限 |
SearchStream 対 Search
Search は、レポート全体をダウンロードするために複数のページネーション リクエストを送信できますが、SearchStream は 1 つのリクエストを送信し、レポートのサイズに関係なく Google Ads API との永続的な接続を開始します。
SearchStream の場合、データ パケットのダウンロードがすぐに開始され、結果全体がデータバッファにキャッシュ保存されます。コードは、ストリーム全体が終了するのを待たずに、バッファリングされたデータの読み取りを開始できます。
Search レスポンスの各ページをリクエストするために必要なネットワークの往復時間を排除することで、アプリによっては、SearchStream はページングよりもパフォーマンスを向上させることができます。特に、レポートのサイズが大きい場合に効果的です。
例
この例では、100,000 行で構成されるレポートを調べます。次の表に、2 つの方法の会計上の違いを示します。
| SearchStream | 検索 | |
|---|---|---|
| ページサイズ | 該当なし | 1 ページあたり 10,000 行 |
| API リクエストの数 | 1 件のリクエスト | 10 件のリクエスト |
| API レスポンスの数 | 1 つの連続ストリーム | 回答 10 件 |
パフォーマンスの要因
ほとんどのユースケースでは、次の理由から Search よりも SearchStream をおすすめします。
単一ページのレポート（10,000 行未満）の場合: 2 つの方法の間にパフォーマンスの大きな違いはありません。
複数ページのレポートの場合:
SearchStreamは通常、複数の往復を回避できるため高速です。また、ディスク キャッシュからの読み取りや書き込みはあまり影響しません。
レート制限
両方のメソッドの 1 日あたりの上限は、開発者トークンの標準の上限とアクセス権に準拠します。結果がページングまたはストリーミングされるかどうかにかかわらず、1 つのクエリまたはレポートは 1 つのオペレーションとしてカウントされます。