このページは Cloud Translation API によって翻訳されました。

検索広告 360 の転送

検索広告 360 用 BigQuery Data Transfer Service を使用すると、検索広告 360 のレポートデータを定期的に読み込むジョブのスケジュールと管理を自動化できます。

サポートされるレポート

検索広告 360 用 BigQuery Data Transfer Service は、Search Ads 360 Reporting API v0 をサポートしています。

検索広告 360 v0 のレポート

検索広告 360 レポートが BigQuery Data Transfer Service のテーブルとビューに変換される仕組みについては、検索広告 360 レポートの変換をご覧ください。

レポートオプション	サポート
Supported API version	v0
繰り返しの頻度	毎日、データ転送が最初に作成される時刻（デフォルト）時刻を構成できます。
更新ウィンドウ	過去 7 日間（デフォルト）構成可能（最大 30 日）マッチテーブルのスナップショットは 1 日に 1 回取得され、最後の実行日付のパーティションに保存されます。マッチテーブルのスナップショットは、バックフィルや、リフレッシュウィンドウによって読み込まれた日には更新されません。
最大バックフィル期間	上限なし
MCC アカウントごとのお客様 ID 数	2,000 通 BigQuery Data Transfer Service では、検索広告 360 マネージャーアカウントごとに最大 2,000 個のお客様 ID がサポートされます。

古い Search Ads 360 Reporting API を使用する検索広告 360 の転送ガイドについては、検索広告 360 の転送（非推奨）をご覧ください。

検索広告 360 の転送からのデータ取り込み

検索広告 360 から BigQuery にデータを転送すると、データは日付でパーティション分割された BigQuery テーブルに読み込まれます。データが読み込まれるテーブルパーティションは、データソースの日付に対応します。同じ日付の複数の転送をスケジュールすると、BigQuery Data Transfer Service により、対象の日付のパーティションが最新のデータで上書きされます。同じ日に複数回の転送やバックフィルを実行しても、データは重複せず、他の日付のパーティションに対する影響はありません。

更新ウィンドウ

更新ウィンドウとは、データ転送が行われたときにデータ転送でデータが取得される日数です。たとえば、更新ウィンドウが 3 日であり、毎日転送が行われる場合、BigQuery Data Transfer Service は過去 3 日間のソーステーブルからすべてのデータを取得します。この例では、毎日転送が発生すると、BigQuery Data Transfer Service は、当日のソーステーブルのデータのコピーを含む新しい BigQuery 宛先テーブルパーティションを作成し、バックフィル実行を自動的にトリガーして、過去 2 日間のソーステーブルのデータで BigQuery 宛先テーブルパーティションを更新します。自動トリガーされたバックフィル実行は、BigQuery Data Transfer Service コネクタで増分更新がサポートされているかどうかに応じて、BigQuery の宛先テーブルを上書きするか、増分更新します。

データ転送を初めて実行する際に、更新ウィンドウ内で利用可能なすべてのソースデータを取得します。たとえば、更新ウィンドウが 3 日であり、データ転送を初めて実行する場合は、BigQuery Data Transfer Service によって 3 日以内のすべてのソースデータが取得されます。

更新ウィンドウは TransferConfig.data_refresh_window_days API フィールドにマッピングされます。

更新ウィンドウの期間外のデータ（過去のデータなど）を取得する場合や、転送の停止やギャップからデータを復元する場合は、バックフィル実行を開始またはスケジュールできます。

制限事項

検索広告 360 データ転送の構成可能な最大頻度は、24 時間に 1 回です。デフォルトでは、転送を作成したときに転送が開始されます。しかし、データ転送の開始時間は、転送を作成するときに構成できます。
BigQuery Data Transfer Service は、検索広告 360 の転送中の増分データ転送をサポートしていません。データ移転の日付を指定すると、その日付で使用できるすべてのデータが転送されます。

始める前に

検索広告 360 のデータ転送を作成する前に、以下の作業を完了しておきます。

BigQuery Data Transfer Service を有効にするために必要なすべての操作が完了していることを確認します。
検索広告 360 のレポートデータを保存する BigQuery Data Transfer Service データセットを作成します。
Pub/Sub の転送実行通知を設定する場合は、pubsub.topics.setIamPolicy 権限が必要です。メール通知を設定するだけの場合、Pub/Sub の権限は必要ありません。詳細については、BigQuery Data Transfer Service の実行通知をご覧ください。
プロジェクトで Search Ads 360 Reporting API へのアクセスを有効にします。

必要な権限

データ転送を作成するユーザーに、次の必要な権限が付与されていることを確認します。

BigQuery Data Transfer Service:
- データ転送を作成する bigquery.transfers.update 権限
- 抽出先データセットに対する bigquery.datasets.get と bigquery.datasets.update の両方の権限
bigquery.transfers.update 権限、bigquery.datasets.update 権限、bigquery.datasets.get 権限は IAM 事前定義ロール bigquery.admin に含まれています。BigQuery Data Transfer Service での IAM ロールの詳細については、アクセス制御をご覧ください。
Google Cloud:
- プロジェクトに対して検索広告 360 からデータをダウンロードするための serviceusage.services.use 権限
IAM 事前定義ロール editor、owner、serviceusage.serviceUsageConsumer には serviceusage.services.use 権限が含まれています。Service Usage の IAM ロールの詳細については、アクセス制御のリファレンスをご覧ください。
検索広告 360:
- 転送構成で使用される検索広告 360 お客様 ID またはクライアントセンター（MCC）アカウントに対する読み取りアクセス権。

検索広告 360 のデータ転送を作成する

検索広告 360 レポートのデータ転送を作成するには、検索広告 360 のお客様 ID またはMCC アカウントが必要です。次のオプションのいずれかを選択します。

コンソール

Google Cloud コンソールの [データ転送] ページに移動します。

[データ転送] に移動
[転送を作成] をクリックします。
[ソースタイプ] セクションの [ソース] で、[Search Ads 360] を選択します。
[転送構成名] セクションの [表示名] に、データ転送の名前（例: My Transfer）を入力します。転送名には、後で修正が必要になった場合に識別できる任意の名前を使用できます。
[スケジュールオプション] セクションで:
- [繰り返しの頻度] で、データ転送を実行する頻度のオプションを選択します。[日数] を選択した場合は、有効な時刻を UTC で入力します。
  - 時間
  - 日数
  - オンデマンド
- 必要に応じて、[すぐに開始可能] を選択するか、[設定した時刻に開始] を選択して開始日と実行時間を指定します。

[転送先の設定] セクションの [データセット] には、データを保存するために作成したデータセットを選択します。

[データソースの詳細] セクションで、次の操作を行います。
[お客様 ID] に検索広告 360 のお客様 ID を入力します。
省略可: ID マッピングテーブルを取得するには、[Agency ID] と [Advertiser ID] の両方を入力します。

省略可: [Custom Floodlight Variables] フィールドに、データ転送に含めるカスタム Floodlight 変数を入力します。カスタム Floodlight 変数は、転送構成のお客様 ID で指定された検索広告 360 アカウントに所有されている必要があります。このパラメータは、JSON 配列形式の文字列入力を受け取り、複数のカスタム Floodlight 変数をサポートできます。JSON 配列の各項目には、次のパラメータが必要です。

id: カスタム Floodlight 変数の数値 ID。この ID は、検索広告 360 でカスタム Floodlight 変数を作成すると割り当てられます。id を指定した場合、name は必要ありません。
name: 検索広告 360 のカスタム Floodlight 変数のユーザー定義名。name を指定した場合、id は必要ありません。
cfv_field_name: ユースケースに基づくカスタム Floodlight 変数フィールドの正確な名前。サポートされている値は、conversion_custom_metrics、conversion_custom_dimensions、raw_event_conversion_metrics、raw_event_conversion_dimensions です。
destination_table_name: カスタム floodlight 変数を含める BigQuery テーブルのリスト。BigQuery Data Transfer Service がこれらのテーブルのデータを取得する場合、転送では、クエリにカスタム Floodlight 変数が含まれます。

bigquery_column_name_suffix: ユーザー定義のわかりやすい列名。BigQuery Data Transfer Service は、標準フィールド名の後に接尾辞を追加して、さまざまなカスタム Floodlight 変数を区別します。ユースケースに応じて、BigQuery Data Transfer Service は BigQuery 列名を次のように生成します。

	指標とセグメントとしてのカスタム Floodlight 変数	コンバージョンリソースの未加工のイベント属性としてのカスタム Floodlight 変数
`metrics`	`metrics_conversion_custom_metrics_bigquery_column_name_suffix`	`metrics_raw_event_conversion_metrics_bigquery_column_name_suffix`
`dimension`	`segments_conversion_custom_dimensions_bigquery_column_name_suffix`	`segments_raw_event_conversion_dimensions_bigquery_column_name_suffix`

2 つのカスタム Floodlight 変数を指定する [Custom Floodlight Variable] エントリの例を次に示します。

[{
  "id": "1234",
  "cfv_field_name": "raw_event_conversion_metrics",
  "destination_table_name": ["Conversion"],
  "bigquery_column_name_suffix": "suffix1"
},{
  "name": "example name",
  "cfv_field_name": "conversion_custom_metrics",
  "destination_table_name": ["AdGroupConversionActionAndDeviceStats","CampaignConversionActionAndDeviceStats"],
  "bigquery_column_name_suffix": "suffix2"
}]

省略可: [Custom Columns] フィールドに、データ転送に含めるカスタム列を入力します。カスタム列は、転送構成のお客様 ID で指定された検索広告 360 アカウントが所有している必要があります。このフィールドは、JSON 配列形式の文字列入力を受け取り、複数の列をサポートできます。JSON 配列の各項目には、次のパラメータが必要です。
- id: カスタム列の数値 ID。この ID は、カスタム列が作成されるときに割り当てられます。id を指定した場合、name は必要ありません。
- name: 検索広告 360 のカスタム列のユーザー定義名。name を指定した場合、id は必要ありません。
- destination_table_name: カスタム列を含める BigQuery テーブルのリスト。BigQuery Data Transfer Service がこれらのテーブルのデータを取得する場合、転送では、クエリにカスタム列フィールドが含まれます。
- bigquery_column_name: ユーザー定義のわかりやすい列名。これは、destination_table_name で指定された宛先テーブルのカスタム列のフィールド名です。列名は、BigQuery の列名の形式要件に従い、テーブルの標準スキーマ内の他のフィールドや他のカスタム列に対して一意である必要があります。
2 つのカスタム列を指定する Custom Columns エントリの例を次に示します。
```
  [{
    "id": "1234",
    "destination_table_name": ["Conversion"],
    "bigquery_column_name": "column1"
  },{
    "name": "example name",
    "destination_table_name": ["AdGroupStats","CampaignStats"],
    "bigquery_column_name": "column2"
  }]
  
```
省略可: [テーブルフィルタ] フィールドに、含めるテーブルのカンマ区切りのリストを入力します（例: Campaign, AdGroup）。特定のテーブルを除外するには、このリストの先頭に - 文字を配置します（例: -Campaign, AdGroup）。デフォルトでは、すべてのテーブルが含まれています。
省略可: [ウィンドウの更新] に 1～30 の値を入力します。設定しない場合、更新期間はデフォルトで 7 日間に設定されます。

[サービスアカウント] メニューで、Google Cloud プロジェクトに関連付けられたサービスアカウントからサービスアカウントを選択します。ユーザー認証情報を使用する代わりに、サービスアカウントを転送に関連付けることができます。データ転送でサービスアカウントを使用する方法の詳細については、サービスアカウントの使用をご覧ください。
- フェデレーション ID でログインした場合、転送を作成するにはサービスアカウントが必要です。Google アカウントでログインした場合、転送用のサービスアカウントは省略可能です。
- サービスアカウントには必要な権限が付与されている必要があります。
省略可: [通知オプション] セクションで、次の操作を行います。
- 切り替えボタンをクリックしてメール通知を有効にします。このオプションを有効にすると、転送の実行が失敗した場合、転送管理者にメール通知が送信されます。
- 切り替えボタンをクリックして、Pub/Sub 通知を有効にします。[Cloud Pub/Sub トピックを選択してください] で、トピック名を選択するか、[トピックを作成] をクリックします。このオプションで、Pub/Sub の転送実行通知を構成します。
[保存] をクリックします。

bq

bq mk コマンドを入力して、転送作成フラグ --transfer_config を指定します。次のフラグも必要です。

--data_source
--target_dataset
--display_name
--params

次のフラグは省略可能です。

--project_id: 使用するプロジェクトを指定します。このフラグが指定されていない場合は、デフォルトのプロジェクトが使用されます。
--service_account_name: ユーザーアカウントの代わりに、検索広告 360 の転送認証に使用するサービスアカウントを指定します。

bq mk \
--transfer_config \
--project_id=PROJECT_ID \
--target_dataset=DATASET \
--display_name=NAME \
--data_source=DATA_SOURCE \
--service_account_name=SERVICE_ACCOUNT_NAME \
--params='{PARAMETERS,"custom_columns":"[{\"id\": \"CC_ID\",\"destination_table_name\": [\"CC_DESTINATION_TABLE\"],\"bigquery_column_name\": \"CC_COLUMN\"}]","custom_floodlight_variables":"[{\"id\": \"CFV_ID\",\"cfv_field_name\": [\"CFV_FIELD_NAME\"],\"destination_table_name\": [\"CFV_DESTINATION_TABLE\"],\"bigquery_column_name_suffix\": \"CFV_COLUMN_SUFFIX\"}]"}'

ここで

PROJECT_ID（省略可）: 使用するプロジェクトを指定します。このフラグが指定されていない場合は、デフォルトのプロジェクトが使用されます。
DATASET: 転送構成のターゲットデータセット。
NAME: 転送構成の表示名。データ転送名には、後で修正が必要になった場合に識別できる任意の名前を使用できます。
DATA_SOURCE: データソース - search_ads。
SERVICE_ACCOUNT_NAME（省略可）: データ転送の認証に使用されるサービスアカウント名。サービスアカウントは、転送の作成に使用した project_id が所有している必要があります。また、必要な権限がすべて付与されている必要があります。

PARAMETERS: 作成される転送構成のパラメータを JSON 形式で指定します。例: --params='{"param":"param_value"}'。customer_id パラメータを指定する必要があります。

table_filter: データ転送に含めるテーブルを指定します。このフラグが指定されていない場合、すべてのテーブルが含まれます。特定のテーブルのみを含めるには、値のカンマ区切りのリスト（Ad, Campaign, AdGroup など）を使用します。特定のテーブルを除外するには、除外する値の先頭にハイフン（-）を付けます（例: -Ad, Campaign, AdGroup を使用すると、3 つの値がすべて除外されます）。
custom_columns: レポートのカスタム列を指定します。このパラメータは、JSON 配列形式の文字列入力を受け取り、複数の列をサポートできます。JSON 配列の各項目には、次のパラメータが必要です。
- CC_ID: カスタム列の数値 ID。この ID は、カスタム列が作成されるときに割り当てられます。
- CC_DESTINATION_TABLE: カスタム列を含める BigQuery テーブルのリスト。BigQuery Data Transfer Service がこれらのテーブルのデータを取得する場合、データ転送では、クエリにカスタム列フィールドが含まれます。
- CC_COLUMN: ユーザー定義のわかりやすい列名。これは、destination_table_name で指定された宛先テーブルのカスタム列のフィールド名です。列名は、BigQuery の列名の形式要件に従い、テーブルの標準スキーマ内の他のフィールドや他のカスタム列に対して一意である必要があります。
custom_floodlight_variables: 転送でカスタム Floodlight 変数を指定します。このパラメータは、JSON 配列形式の文字列入力を受け取り、複数のカスタム Floodlight 変数をサポートできます。JSON 配列の各項目には、次のパラメータが必要です。
- CFV_ID: カスタム Floodlight 変数の数値 ID。この ID は、検索広告 360 でカスタム Floodlight 変数を作成すると割り当てられます。
- CFV_FIELD_NAME: ユースケースに基づくカスタム Floodlight 変数フィールドの正確な名前。サポートされている値は、conversion_custom_metrics、conversion_custom_dimensions、raw_event_conversion_metrics、raw_event_conversion_dimensions です。詳細については、カスタム Floodlight 指標をご覧ください。
- CFV_DESTINATION_TABLE: カスタム floodlight 変数を含める BigQuery テーブルのリスト。BigQuery Data Transfer Service がこれらのテーブルのデータを取得する場合、データ転送では、クエリにカスタム Floodlight 変数が含まれます。
- CFV_COLUMN_SUFFIX: ユーザー定義のわかりやすい列名。BigQuery Data Transfer Service は、標準フィールド名の後に接尾辞を追加して、さまざまなカスタム Floodlight 変数を区別します。ユースケースに応じて、BigQuery Data Transfer Service は BigQuery 列名を次のように生成します。

	指標とセグメントとしてのカスタム Floodlight 変数	コンバージョンリソースの未加工のイベント属性としてのカスタム Floodlight 変数
`metrics`	`metrics_conversion_custom_metrics_bigquery_column_name_suffix`	`metrics_raw_event_conversion_metrics_bigquery_column_name_suffix`
`dimension`	`segments_conversion_custom_dimensions_bigquery_column_name_suffix`	`segments_raw_event_conversion_dimensions_bigquery_column_name_suffix`

たとえば、次のコマンドは、お客様 ID 6828088731 とターゲットデータセット mydataset を使用して、My Transfer という名前の検索広告 360 データ転送を作成します。転送では、カスタム floodlight 変数も指定します。このデータ転送はデフォルトのプロジェクトで作成されます。

bq mk \
--transfer_config \
--target_dataset=mydataset \
--display_name='My Transfer' \
--data_source=search_ads \
--params='{"customer_id":"6828088731", "custom_floodlight_variables":"[{\"id\": \"9876\", \"cfv_field_name\": \"raw_event_conversion_metrics\", \"destination_table_name\": [\"Conversion\"],\"bigquery_column_name_suffix\": \"suffix1\" }]"}'

コマンドの初回実行時に、次のようなメッセージが表示されます。

[URL omitted] Please copy and paste the above URL into your web browser and follow the instructions to retrieve an authentication code.

メッセージの指示に従って、認証コードをコマンドラインに貼り付けます。

API

projects.locations.transferConfigs.create メソッドを使用して、TransferConfig リソースのインスタンスを指定します。

検索広告 360 の転送を手動でトリガーする

検索広告 360 の転送を手動でトリガーすると、マッチテーブルのスナップショットが 1 日に 1 回取得され、最後の実行日付のパーティションに保存されます。手動転送をトリガーしても、次のテーブルのマッチテーブルスナップショットは更新されません。

Account
広告
AdGroup
AdGroupCriterion
任意の ID マッピングテーブル
アセット
BidStrategy
Campaign
CampaignCriterion
ConversionAction
キーワード
NegativeAdGroupKeyword
NegativeAdGroupCriterion
NegativeCampaignKeyword
NegativeCampaignCriterion
ProductGroup

検索広告 360 のクライアントセンター（MCC）アカウントのサポート

検索広告 360 の MCC アカウントを使用すると、個別のお客様 ID を使用する場合と比較していくつかのメリットがあります。

複数のお客様 ID のレポートのために、複数のデータ転送を管理する必要はありません。
すべてのお客様 ID が同じテーブルに保存されるため、お客様間のクエリの作成が簡単になります。
MCC を使用すると、同じ 1 つのジョブで複数のお客様 ID が読み込まれるので、BigQuery Data Transfer Service の読み込み割り当て量の問題が緩和されます。

お客様 ID に固有の複数の検索広告 360 データ転送を設定されているお客様は、検索広告 360 MCC アカウントに切り替えることをおすすめします。方法は次のとおりです。

検索広告 360 データ転送を MCC アカウントまたはサブ MCC アカウントのレベルで 1 つ設定します。
バックフィルのスケジュールを設定します。
個々のお客様 ID 固有の検索広告 360 の転送を無効にします。

検索広告 360 の MCC アカウントについて詳しくは、検索広告 360 リニューアル版の MCC アカウントについてと MCC アカウントとアカウントのリンク方法をご覧ください。

例

次のリストは、特定の検索広告 360 の MCC アカウントにリンクされているお客様 ID を示しています。

1234567890 - ルート MCC アカウント
- 1234 - サブ MCC アカウント
  - 1111 - お客様 ID
  - 2222 - お客様 ID
  - 3333 - お客様 ID
  - 4444 - お客様 ID
  - 567 - サブ MCC アカウント
    - 5555 - お客様 ID
    - 6666 - お客様 ID
    - 7777 - お客様 ID
- 89 - サブ MCC アカウント
  - 8888 - お客様 ID
  - 9999 - お客様 ID
- 0000 - お客様 ID

MCC アカウントにリンクされたお客様 ID が各レポートに表示されます。BigQuery Data Transfer Service の検索広告 360 レポート構造について詳しくは、検索広告 360 レポートの変換をご覧ください。

お客様 ID 1234567890 の転送構成

ルート MCC アカウント（お客様 ID 1234567890）の転送構成では、次のお客様 ID を含むデータ転送実行が生成されます。

1111（サブ MCC アカウント 1234 を介して）
2222（サブ MCC アカウント 1234 を介して）
3333（サブ MCC アカウント 1234 を介して）
4444（サブ MCC アカウント 1234 を介して）
5555（サブ MCC アカウント 567 およびサブ MCC アカウント 1234 を介して）
6666（サブ MCC アカウント 567 およびサブ MCC アカウント 1234 を介して）
7777（サブ MCC アカウント 567 およびサブ MCC アカウント 1234 を介して）
8888（サブ MCC アカウント 89 を介して）
9999（サブ MCC アカウント 89 を介して）
0000（個別のお客様 ID）

お客様 ID 1234 の転送構成

サブ MCC アカウント 123（お客様 ID 1234）の転送構成では、次のお客様 ID を含むデータ転送実行が生成されます。

1111
2222
3333
4444
5555（サブ MCC アカウント 567 を介して）
6666（サブ MCC アカウント 567 を介して）
7777（サブ MCC アカウント 567 を介して）

お客様 ID 567 の転送構成

サブ MCC アカウント 567（お客様 ID 567）の転送構成では、次のお客様 ID を含むデータ転送実行が生成されます。

5555
6666
7777

お客様 ID 89 の転送構成

サブ MCC アカウント 89（お客様 ID 89）の転送構成では、次のお客様 ID を含むデータ転送実行が生成されます。

8888
9999

お客様 ID 0000 の転送構成

お客様 ID 0000 の転送構成では、個別のお客様 ID のみを含むデータ転送実行が生成されます。

0000

データに対するクエリを実行する

データが BigQuery Data Transfer Service に転送されると、取り込み時間パーティション分割テーブルにそのデータが書き込まれます。詳細については、パーティション分割テーブルの概要をご覧ください。

自動生成されたビューを使用せずに、テーブルでクエリを直接実行する場合は、そのクエリで _PARTITIONTIME 疑似列を使用する必要があります。詳細については、パーティション分割テーブルのクエリをご覧ください。

検索広告 360 のサンプルクエリ

次の検索広告 360 のサンプルクエリを使用して、転送されたデータを分析できます。このクエリは、Looker Studio などのビジュアリゼーションツールでも表示できます。

次のクエリの例では、BigQuery Data Transfer Service を使用して検索広告 360 データに対するクエリの実行を開始しています。これらのレポートでできることに関するその他のご質問については、検索広告 360 の技術担当者にお問い合わせください。

キャンペーンの掲載結果

次のサンプルクエリは、過去 30 日間の検索広告 360 キャンペーンのパフォーマンスを分析します。

SELECT
  c.customer_id,
  c.campaign_name,
  c.campaign_status,
  SUM(cs.metrics_clicks) AS Clicks,
  (SUM(cs.metrics_cost_micros) / 1000000) AS Cost,
  SUM(cs.metrics_impressions) AS Impressions
FROM
  `DATASET.sa_Campaign_CUSTOMER_ID` c
LEFT JOIN
  `DATASET.sa_CampaignStats_CUSTOMER_ID` cs
ON
  (c.campaign_id = cs.campaign_id
  AND cs._DATA_DATE BETWEEN
  DATE_ADD(CURRENT_DATE(), INTERVAL -31 DAY) AND DATE_ADD(CURRENT_DATE(), INTERVAL -1 DAY))
WHERE
  c._DATA_DATE = c._LATEST_DATE
GROUP BY
  1, 2, 3
ORDER BY
  Impressions DESC

次のように置き換えます。

DATASET: データセットの名前。
CUSTOMER_ID: 検索広告 360 のお客様 ID

キーワード数

次のサンプルクエリは、キャンペーン、広告グループ、ステータスごとにキーワードを分析します。

  SELECT
    c.campaign_status AS CampaignStatus,
    a.ad_group_status AS AdGroupStatus,
    k.ad_group_criterion_status AS KeywordStatus,
    k.ad_group_criterion_keyword_match_type AS KeywordMatchType,
    COUNT(*) AS count
  FROM
    `DATASET.sa_Keyword_CUSTOMER_ID` k
    JOIN
    `DATASET.sa_Campaign_CUSTOMER_ID` c
  ON
    (k.campaign_id = c.campaign_id AND k._DATA_DATE = c._DATA_DATE)
  JOIN
    `DATASET.sa_AdGroup_CUSTOMER_ID` a
  ON
    (k.ad_group_id = a.ad_group_id AND k._DATA_DATE = a._DATA_DATE)
  WHERE
    k._DATA_DATE = k._LATEST_DATE
  GROUP BY
    1, 2, 3, 4

次のように置き換えます。

DATASET: データセットの名前。
CUSTOMER_ID: 検索広告 360 のお客様 ID

ID マッピングテーブル

検索広告 360 リニューアル版のエンティティ（顧客、キャンペーン、広告グループなど）の ID 空間は、検索広告 360 従来版では異なります。検索広告 360 従来版 API と検索広告 360 リニューアル版 API のデータを結合することを必要とする既存の検索広告 360 の転送ユーザーの場合は、転送構成で有効な代理店 ID と広告主 ID を指定すると、BigQuery Data Transfer Service を使用して ID マッピングテーブルを転送できます。

サポートされるエンティティには、legacy_id と new_id の 2 つの列があり、それぞれ検索広告 360 の旧バージョンと新バージョンのエンティティの ID マッピングを指定します。 AD、CAMPAIGN_CRITERION、CRITERION エンティティの場合、検索広告 360 リニューアル版ではグローバルに一意の ID がないため、new_secondary_id も指定されます。ID マッピングテーブルは次のとおりです。

IdMapping_AD
IdMapping_AD_GROUP
IdMapping_CAMPAIGN
IdMapping_CAMPAIGN_CRITERION
IdMapping_CAMPAIGN_GROUP
IdMapping_CAMPAIGN_GROUP_PERFORMANCE_TARGET
IdMapping_CRITERION
IdMapping_CUSTOMER
IdMapping_FEED_ITEM
IdMapping_FEED_TABLE

クエリの例

次のクエリでは、ID マッピングテーブルを使用して、新しい ID スペースにある新旧の検索広告 360 データ転送のテーブル間で、キャンペーンごとの指標を集計します。

SELECT CustomerID, CampaignID, Sum(Clicks), Sum(Cost) FROM
(SELECT
  cs.customer_id AS CustomerID,
  cs.campaign_id AS CampaignID,
  cs.metrics_clicks AS Clicks,
  cs.metrics_cost_micros / 1000000 AS Cost
FROM
  `DATASET.sa_CampaignStats_CUSTOMER_ID` cs
WHERE cs._DATA_DATE = 'NEW_DATA_DATE'
UNION ALL
SELECT
  customer_id_mapping.new_id AS CustomerID,
  campaign_id_mapping.new_id AS CampaignID,
  cs.clicks AS Clicks,
  cs.cost AS Cost
FROM
  `DATASET.CampaignStats_ADVERTISER_ID` cs
LEFT JOIN
  `DATASET.IdMapping_CUSTOMER_ADVERTISER_ID` customer_id_mapping
ON cs.accountId = customer_id_mapping.legacy_id
LEFT JOIN
  `DATASET.IdMapping_CAMPAIGN_ADVERTISER_ID` campaign_id_mapping
ON cs.campaignId = campaign_id_mapping.legacy_id
WHERE cs._DATA_DATE = 'OLD_DATA_DATE')
GROUP BY
1, 2
ORDER BY
1, 2

次のように置き換えます。

DATASET: データセットの名前。
CUSTOMER_ID: 検索広告 360 のお客様 ID
ADVERTISER_ID: 検索広告 360 の広告主 ID
NEW_DATA_DATE: 検索広告 360 リニューアル版テーブルのデータ日付
OLD_DATA_DATE: 検索広告 360 従来版テーブルのデータ日付

次のクエリでは、ID マッピングテーブルを使用して、従来版とリニューアル版の検索広告 360 データ転送のテーブル間でキャンペーンごとの指標を集計します。

SELECT CustomerID, CampaignID, Sum(Clicks), Sum(Cost) FROM
(SELECT
  customer_id_mapping.legacy_id AS CustomerID,
  campaign_id_mapping.legacy_id AS CampaignID,
  cs.metrics_clicks AS Clicks,
  cs.metrics_cost_micros / 1000000 AS Cost
FROM
  `DATASET.sa_CampaignStats_CUSTOMER_ID` cs
LEFT JOIN
  `DATASET.IdMapping_CUSTOMER_ADVERTISER_ID` customer_id_mapping
ON cs.customer_id = customer_id_mapping.new_id
LEFT JOIN
  `DATASET.IdMapping_CAMPAIGN_ADVERTISER_ID` campaign_id_mapping
ON cs.campaign_id = campaign_id_mapping.new_id
WHERE cs._DATA_DATE = 'NEW_DATA_DATE'
UNION ALL
SELECT
  CAST(accountId AS INT) AS CustomerID,
  CAST(campaignId AS INT) AS CampaignID,
  cs.clicks AS Clicks,
  cs.cost AS Cost
FROM
  `DATASET.CampaignStats_ADVERTISER_ID` cs
WHERE cs._DATA_DATE = 'OLD_DATA_DATE')
GROUP BY
1, 2
ORDER BY
1, 2

次のように置き換えます。

DATASET: データセットの名前。
CUSTOMER_ID: 検索広告 360 のお客様 ID
ADVERTISER_ID: 検索広告 360 の広告主 ID
NEW_DATA_DATE: 検索広告 360 リニューアル版テーブルのデータ日付
OLD_DATA_DATE: 検索広告 360 従来版テーブルのデータ日付

発生しうる割り当ての問題

Search Ads 360 Reporting API では、Google プロジェクトで 1 日に送信できるリクエストの数に割り当てが設定されています。BigQuery Data Transfer Service と他のサービスに 1 つのプロジェクトを使用している場合は、すべてのサービスが同じ割り当てを共有し、どのサービスでも割り当て上限に達する可能性があります。

この発生しうる問題を回避して既存のワークフローに影響を与えないようにするには、次のオプションを検討してください。

BigQuery Data Transfer Service 用に別個のプロジェクトを設定します。プロジェクト間のテーブル結合は次のようになります。

  #standardSQL
  select count(a.item1)
  from (select item1, item2 from project-A.data_set_a.table_name_a) a
  inner join
  (select item3, item4 from project-B.data_set_b.table_name_b) b
  on a.item1 = b.item3

検索広告 360 のサポートにお問い合わせのうえ、追加の割り当てをリクエストします。

検索広告 360 の転送

サポートされるレポート

検索広告 360 の転送からのデータ取り込み

更新ウィンドウ

制限事項

始める前に

必要な権限

検索広告 360 のデータ転送を作成する

コンソール

bq

API

検索広告 360 の転送を手動でトリガーする

検索広告 360 のクライアント センター（MCC）アカウントのサポート

例

お客様 ID 1234567890 の転送構成

お客様 ID 1234 の転送構成

お客様 ID 567 の転送構成

お客様 ID 89 の転送構成

お客様 ID 0000 の転送構成

データに対するクエリを実行する

検索広告 360 のサンプルクエリ

キャンペーンの掲載結果

キーワード数

ID マッピング テーブル

クエリの例

発生しうる割り当ての問題

検索広告 360 のクライアントセンター（MCC）アカウントのサポート

ID マッピングテーブル