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.

      Si le connecteur prend en charge la création de pipeline basée sur l'interface utilisateur, un administrateur peut créer la connexion et le pipeline en même temps en suivant les étapes sur cette page. Cependant, si les utilisateurs qui créent des pipelines utilisent la création de pipeline basée sur API ou ne sont pas des utilisateurs administrateurs, un administrateur doit d'abord créer la connexion dans Catalog Explorer. Voir Se connecter à des sources d'ingestion gérées.

    • 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).

    Voir pipeline.ingestion_definition et Exemples.

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

    Bash
    databricks bundle deploy

Exemples​

Les exemples suivants montrent des spécifications YAML que les Declarative Automation Bundles ou l'API REST peuvent utiliser pour créer des 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​

Chaque rapport prend ses propres réglages de connector_options.linkedin_ads_options, qui accepte sync_start_date (une chaîne de dates ISO) et lookback_window_days (un entier de 0 à 365). Omettez l’une des deux clés pour prendre sa valeur par default : une date de start de deux ans et une rétrospection de sept jours. Définissez les options par rapport, car chaque rapport suit son propre curseur.

Les sept rapports sont par compte, donc source_schema est toujours l’identifiant du compte publicitaire sponsorisé.

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>

Ingérer depuis plusieurs comptes publicitaires​

Comme les tables par compte résident dans un espace de noms nommé d’après l’ID de compte publicitaire, ingérez un second compte en répétant les définitions de table avec un source_schema différent. Donnez à chaque table de destination un nom distinct afin que les deux comptes ne soient pas en conflit, car Databricks ne peut pas ingérer deux tables portant le même nom dans un seul 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