Aller au contenu principal
Dernière mise à jour le

Ingérer les données des annonces LinkedIn

info

Bêta

Cette fonctionnalité est en version bêta. Les administrateurs de Workspace peuvent contrôler l’accès à cette fonctionnalité depuis la page Aperçus . Consultez Gérer les aperçus Databricks.

Apprenez à créer un pipeline d'ingestion géré pour ingérer des données de LinkedIn Ads dans Databricks.

Exigences​

  • Pour créer un pipeline d'ingestion, vous devez remplir les conditions suivantes :

    • Votre workspace doit être activé pour Unity Catalog.

    • Le compute serverless doit être activé pour votre workspace. Voir les exigences du compute serverless.

    • Pour créer une nouvelle connexion, vous devez disposer des privilèges CREATE CONNECTION sur le métastore. Voir Gérer les privilèges dans Unity Catalog.

      If the connector supports UI-based pipeline authoring, an admin can create the connection and the pipeline at the same time by completing the steps on this page. However, if the users who create pipelines use API-based pipeline authoring or are non-admin users, an admin must first create the connection in Catalog Explorer. See Connect to managed ingestion sources.

    • Pour utiliser une connexion existante, vous devez disposer des privilèges USE CONNECTION ou ALL PRIVILEGES sur l'objet de connexion.

    • Vous devez disposer des privilèges USE CATALOG sur le catalogue cible.

    • Vous devez disposer des privilèges USE SCHEMA et CREATE TABLE sur un schéma existant ou des privilèges CREATE SCHEMA sur le catalogue cible.

  • Pour ingérer des données depuis LinkedIn Ads, vous devez suivre les étapes décrites dans Créer une connexion LinkedIn Ads.

  • Vous avez besoin de l'ID de compte publicitaire sponsorisé pour chaque compte publicitaire que vous souhaitez ingérer. Onze des douze tables sources résident dans un espace de noms par compte nommé d'après cet ID. Voir Espaces de noms sources.

Créer un pipeline d'ingestion​

LinkedIn Ads prend uniquement en charge la création de pipelines basée sur l’API. Utilisez les Declarative Automation Bundles ou l’API REST Pipelines.

Cet tab décrit comment déployer un pipeline d’ingestion à l’aide de Declarative Automation Bundles. Les bundles peuvent contenir des définitions YAML de Jobs et de tâches, sont gérés à l'aide de la CLI Databricks et peuvent être partagés et exécutés dans différents Workspace cibles (tels que le développement, la pré-production et la production). Pour plus d'informations, consultez Que sont les Declarative Automation Bundles ?.

  1. Créez un bundle à l'aide de la CLI Databricks :

    Bash
    databricks bundle init

  2. Ajoutez deux nouveaux fichiers de ressources au bundle :

    • Un fichier de définition de pipeline (par exemple, resources/linkedin_ads_pipeline.yml).
    • Un fichier de définition de job qui contrôle la fréquence d’ingestion des données (par exemple, resources/linkedin_ads_job.yml).

    See pipeline.ingestion_definition and Examples.

  3. Déployez le pipeline à l’aide de la CLI Databricks :

    Bash
    databricks bundle deploy

Exemples​

The following examples show YAML specifications that Declarative Automation Bundles or the REST API can use to create pipelines.

Ingérez les cinq tables d’entités depuis un seul compte publicitaire​

La table account_history provient de l'espace de noms default. Les quatre autres tables d'entités proviennent de l'espace de noms propre au compte publicitaire ; définissez donc source_schema sur l'ID du compte publicitaire sponsorisé.

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>

Ingérer des rapports prédéfinis avec des options de synchronisation personnalisées​

Each report takes its own settings from connector_options.linkedin_ads_options, which accepts sync_start_date (an ISO date string) and lookback_window_days (an integer from 0 to 365). Omit either key to take its default: a two-year start date and a seven-day lookback. Set the options per report, because each report tracks its own cursor.

All seven reports are per-account, so source_schema is always the sponsored ad-account 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>

Ingest from more than one ad account​

Because the per-account tables live in a namespace named after the ad-account ID, ingest a second account by repeating the table definitions with a different source_schema. Give each destination table a distinct name so the two accounts don't collide, because Databricks cannot ingest two tables with the same name in one pipeline.

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

start, planifier et configurer des alertes sur votre pipeline​

  1. Une fois le pipeline créé, revenez dans le Workspace Databricks, puis cliquez sur Jobs & Pipelines dans le volet de gauche.

    Le nouveau pipeline apparaît dans la liste. Cliquez sur le nom du pipeline pour afficher ses détails.

  2. Sur la page des détails du pipeline, cliquez sur Start pour exécuter le pipeline immédiatement. Pour l’exécuter selon un calendrier, cliquez sur Planifier . Pour plus de détails, consultez Exécuter une mise à jour de pipeline.

  3. Pour définir des alertes sur le pipeline, utilisez le job qui le planifie. Depuis la page des détails du pipeline, cliquez sur Planning , puis sélectionnez l'un de vos plannings pour afficher les détails du job.

  4. Dans le volet des détails du Job, sous Notifications de job , configurez des notifications. Voir Ajouter des notifications sur un Job.

  5. Surveillez la mise à jour du pipeline sur la page des détails du pipeline. Une fois la mise à jour terminée avec succès, interrogez vos tables de destination pour confirmer que les données sont bien arrivées.

Ressources supplémentaires​

Sur cette page