Google Ads API のエンティティとレポートデータを取得するには、次のいずれかの方法を使用します。
2 つの方法の大まかな違いは次のとおりです。
| GoogleAdsService.SearchStream | GoogleAdsService.Search | |
|---|---|---|
| 本番環境のコードに適している | ○ | ○ |
| サービス | GoogleAdsService |
GoogleAdsService |
| シナリオ | オブジェクトとレポートの取得 | オブジェクトとレポートの取得 |
| レスポンス | GoogleAdsRow オブジェクトのストリーム |
GoogleAdsRow オブジェクトのページ |
| レスポンスのフィールド | クエリで指定されたもののみ | クエリで指定されたもののみ |
| 1 日の利用時間の上限 | アクセスレベルに基づく 1 日の利用時間の上限 | アクセスレベルに基づく 1 日の利用時間の上限 |
SearchStream と検索
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 つのオペレーションとしてカウントされます。