LinkedIn Adsからデータを取り込む

備考

ベータ版

この機能はベータ版です。ワークスペース管理者は、 プレビュー ページからこの機能へのアクセスを制御できます。Databricksのプレビューを管理するを参照してください。

LinkedIn Ads から Databricks にデータを取り込むための管理された取り込みパイプラインを作成する方法を学びます。

要件

• 取り込み パイプラインを作成するには、次の要件を満たす必要があります。

  • ワークスペースでUnity Catalogが有効になっている必要があります。

  • ワークスペースで Serverless コンピュートを有効にする必要があります。See Serverless コンピュートの要件.

  • 新しい接続を作成するには、メタストアに対する CREATE CONNECTION 権限が必要です。Unity Catalog での権限の管理を参照してください。

    コネクタが UI ベースのパイプライン オーサリングをサポートしている場合、管理者はこのページのステップを完了することで、接続とパイプラインを同時に作成できます。 ただし、パイプラインを作成するユーザーが API ベースのパイプライン オーサリングを使用している場合、または管理者以外のユーザーである場合、管理者はまずカタログ エクスプローラーで接続を作成する必要があります。 「管理対象取り込みソースへの接続」を参照してください。

  • 既存の接続を使用するには、接続オブジェクトに対する USE CONNECTION 権限または ALL PRIVILEGES 権限が必要です。

  • ターゲットカタログに対するUSE CATALOG権限が必要です。

  • 既存のスキーマに対する USE SCHEMA 権限と CREATE TABLE 権限、またはターゲットカタログに対する CREATE SCHEMA 権限が必要です。

• LinkedIn広告から取り込むには、「 LinkedIn広告の接続」のステップを完了する必要があります。

• 取り込みたい広告アカウントごとにスポンサー広告アカウントIDが必要です。12のソーステーブルのうち11は、そのIDにちなんだアカウント名付き名前空間に存在します。ソース ネームスペースを参照してください。

取り込みパイプラインを作成

LinkedIn AdvertisingはAPIベースのパイプライン作成のみをサポートしています。宣言型自動化バンドルやパイプラインREST APIを使いましょう。

Declarative Automation Bundles

このtabでは、Declarative Automation Bundles を使用して取り込みパイプラインをデプロイする方法について説明します。バンドルにはジョブとタスクの YAML 定義を含めることができ、Databricks CLI を使用して管理され、異なるターゲット ワークスペース（開発、ステージング、本番運用など）で共有および実行できます。詳細については、「宣言型オートメーションバンドルとは？」をご覧ください。

1. Databricks CLI を使用してバンドルを作成するには、次の手順を実行します。

   Bash

   databricks bundle init

2. バンドルに2つの新しいリソースファイルを追加します：

   • パイプライン定義ファイル（例：resources/linkedin_ads_pipeline.yml）。
   • データ取り込みの頻度を制御するジョブ定義ファイル（例：resources/linkedin_ads_job.yml）。

   「pipeline.ingestion_definition」を参照してください。および「Examples」を参照してください。

3. Databricks CLI を使用してパイプラインをデプロイします：

   Bash

   databricks bundle deploy

Pipelines REST API

Pipelines API を使用してパイプラインを作成します。ingestion_definition フィールドには、YAML仕様を指定します。例を参照してください。

例

次の例は、宣言型オートメーションバンドルまたは REST API を使用してパイプラインを作成するための YAML 仕様を示しています。

1つの広告アカウントから5つのエンティティテーブルすべてを取り込む

account_history テーブルは default 名前空間から取得されます。他の4つのエンティティテーブルは広告アカウント独自の名前空間から取得されるため、source_schema にスポンサー広告アカウントIDを設定してください。

YAML

resources:
  pipelines:
    pipeline_linkedin_ads:
      name: <pipeline-name>
      catalog: <destination-catalog>
      target: <destination-schema>
      ingestion_definition:
        connection_name: <connection-name>
        objects:
          - table:
              source_schema: default
              source_table: account_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
          - table:
              source_schema: <ad-account-id>
              source_table: campaign_group_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
          - table:
              source_schema: <ad-account-id>
              source_table: campaign_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
          - table:
              source_schema: <ad-account-id>
              source_table: creative_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
          - table:
              source_schema: <ad-account-id>
              source_table: account_user_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>

カスタム同期オプションを使用して構築済みのレポートを取り込む

各レポートはconnector_options.linkedin_ads_optionsから独自の設定を取得します。これにはsync_start_date（ISO日付文字列）とlookback_window_days（0から365までの整数）を指定できます。いずれかのキーを省略すると、default値（開始日は2年前、ルックバック期間は7日間）が使用されます。各レポートが独自のカーソルを追跡するため、レポートごとにオプションを設定してください。

7つのレポートはすべてアカウントごとのものであるため、source_schemaは常にスポンサー広告アカウントIDとなります。

YAML

resources:
  pipelines:
    pipeline_linkedin_ads_reports:
      name: <pipeline-name>
      catalog: <destination-catalog>
      target: <destination-schema>
      ingestion_definition:
        connection_name: <connection-name>
        objects:
          # Daily campaign report: backfill from an explicit date and widen the
          # lookback to 30 days so late-attributed conversions are re-read.
          - table:
              source_schema: <ad-account-id>
              source_table: ad_analytics_by_campaign_report
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
              connector_options:
                linkedin_ads_options:
                  sync_start_date: '2026-01-01'
                  lookback_window_days: 30
          # Daily creative report: same start date, default seven-day lookback.
          - table:
              source_schema: <ad-account-id>
              source_table: ad_analytics_by_creative_report
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
              connector_options:
                linkedin_ads_options:
                  sync_start_date: '2026-01-01'
          # Monthly demographic report: the start date is aligned to the first of
          # its month, so 2026-05-15 fetches all of May 2026.
          - table:
              source_schema: <ad-account-id>
              source_table: monthly_ad_analytics_by_member_industry_report
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
              connector_options:
                linkedin_ads_options:
                  sync_start_date: '2026-05-15'
                  lookback_window_days: 45
          # Monthly demographic report with no options: defaults to a two-year
          # start date, capped by the two-year demographic retention horizon.
          - table:
              source_schema: <ad-account-id>
              source_table: monthly_ad_analytics_by_member_seniority_report
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>

複数の広告アカウントから取り込む

アカウントごとのテーブルは広告アカウントIDの名前が付けられた名前空間に存在するため、異なる source_schemaでテーブル定義を繰り返して2つ目のアカウントを取り込むことができます。各宛先テーブルに別々の名前を付けて、2つのアカウントが衝突しないようにしてください。なぜならDatabricksは同じ名前の2つのテーブルを1つのパイプラインで取り込むことができないからです。

YAML

resources:
  pipelines:
    pipeline_linkedin_ads_multi_account:
      name: <pipeline-name>
      catalog: <destination-catalog>
      target: <destination-schema>
      ingestion_definition:
        connection_name: <connection-name>
        objects:
          - table:
              source_schema: <first-ad-account-id>
              source_table: campaign_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
              destination_table: campaign_history_account_1
          - table:
              source_schema: <second-ad-account-id>
              source_table: campaign_history
              destination_catalog: <destination-catalog>
              destination_schema: <destination-schema>
              destination_table: campaign_history_account_2

パイプラインの起動、スケジュール、アラートの設定

1. パイプラインが作成されたら、Databricks ワークスペースに戻り、左側のペインで ジョブとパイプライン をクリックします。

   新しいパイプラインがリストに含まれています。パイプライン名をクリックすると詳細が表示されます。

2. パイプラインの詳細ページで、 起動 をクリックしてパイプラインをすぐに実行します。スケジュールに従って実行するには、 スケジュール をクリックします。詳細については、 「パイプラインの更新を実行する」を参照してください。

3. パイプラインにアラートを設定するには、それをスケジュールするジョブを使ってください。パイプライン詳細ページから 「スケジュール 」をクリックし、スケジュールの中から選択してジョブの詳細を表示します。

4. ジョブ詳細ペインの ジョブ通知 で、通知を設定します。ジョブに通知を追加するを参照してください。

5. パイプラインの詳細ページでパイプラインの更新を監視してください。アップデートが成功裏に完了したら、宛先テーブルにクエリーしてデータが届いたか確認してください。

その他のリソース

• LinkedIn広告コネクタのリファレンス
• LinkedIn広告コネクタの概念
• LinkedIn広告コネクタのトラブルシューティング