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