Google Ads Scripts pour l'export BigQuery

Google Ads Scripts sont des programmes JavaScript qui s’exécutent à l’intérieur de la plateforme Google Ads. Ils ont accès aux données de votre compte et peuvent exporter directement vers BigQuery. Ils ne nécessitent pas de developer token. Ils ne nécessitent pas d’infrastructure serveur. Ils s’authentifient via le compte Google Ads connecté et s’exécutent dans l’infrastructure propre de Google.

Cela les positionne entre DTS et un pipeline dlt complet : plus de contrôle que le Data Transfer Service, moins d’infrastructure que dlt, et sans file d’attente d’approbation API.

Comment ils fonctionnent

Les Scripts se trouvent dans Google Ads → Outils → Actions en masse → Scripts. Vous écrivez du JavaScript dans l’éditeur intégré, connectez BigQuery en tant que service avancé, et planifiez l’exécution.

Le modèle d’authentification est la différence clé par rapport aux autres approches. Les Scripts s’authentifient en tant qu’utilisateur Google Ads qui les a créés. Ils s’exécutent dans l’infrastructure de Google, contre l’API de reporting propre de Google. Du point de vue de Google, c’est interne — c’est la même chose que vous interrogez des données via l’interface, juste automatisé. C’est pourquoi aucun developer token externe n’est nécessaire.

L’intégration BigQuery nécessite l’activation de l’API Avancée BigQuery dans les paramètres du script. Une fois activée, vous pouvez interroger directement le service BigQuery depuis votre code JavaScript.

Un pattern d’export de base

Un script minimal qui interroge les performances de campagne et écrit dans BigQuery :

function main() {
  var startDate = getStartDate();
  var endDate = getEndDate();

  var report = AdsApp.report(
    "SELECT campaign.name, campaign.id, " +
    "metrics.clicks, metrics.impressions, metrics.cost_micros, " +
    "metrics.conversions, segments.date " +
    "FROM campaign " +
    "WHERE segments.date BETWEEN '" + startDate + "' AND '" + endDate + "' " +
    "AND campaign.status = 'ENABLED'"
  );

  var rows = report.rows();
  var tableData = [];

  while (rows.hasNext()) {
    var row = rows.next();
    tableData.push({
      campaign_name: row['campaign.name'],
      campaign_id: row['campaign.id'],
      clicks: parseInt(row['metrics.clicks']),
      impressions: parseInt(row['metrics.impressions']),
      // Le coût est en micros — diviser par 1 000 000 pour obtenir la devise réelle
      cost: parseFloat(row['metrics.cost_micros']) / 1000000,
      conversions: parseFloat(row['metrics.conversions']),
      date: row['segments.date']
    });
  }

  writeToBigQuery(tableData);
}

function writeToBigQuery(data) {
  var projectId = 'your-project-id';
  var datasetId = 'google_ads';
  var tableId = 'campaign_performance';

  var schema = {
    fields: [
      {name: 'campaign_name', type: 'STRING'},
      {name: 'campaign_id', type: 'STRING'},
      {name: 'clicks', type: 'INTEGER'},
      {name: 'impressions', type: 'INTEGER'},
      {name: 'cost', type: 'FLOAT'},
      {name: 'conversions', type: 'FLOAT'},
      {name: 'date', type: 'DATE'}
    ]
  };

  BigQuery.Jobs.insert({
    configuration: {
      load: {
        destinationTable: {
          projectId: projectId,
          datasetId: datasetId,
          tableId: tableId
        },
        schema: schema,
        writeDisposition: 'WRITE_TRUNCATE',
        sourceFormat: 'NEWLINE_DELIMITED_JSON'
      }
    }
  }, projectId, Utilities.newBlob(
    data.map(JSON.stringify).join('\n'),
    'application/octet-stream'
  ));
}

function getStartDate() {
  var date = new Date();
  date.setDate(date.getDate() - 7);
  return Utilities.formatDate(date, AdsApp.currentAccount().getTimeZone(), 'yyyyMMdd');
}

function getEndDate() {
  var date = new Date();
  date.setDate(date.getDate() - 1);
  return Utilities.formatDate(date, AdsApp.currentAccount().getTimeZone(), 'yyyyMMdd');
}

La définition du schéma vit dans le script. Vous contrôlez les champs à extraire, la façon de nommer les colonnes, et les types de données à affecter. C’est fondamentalement différent du schéma fixe du Data Transfer Service.

Notez la conversion du coût. Google Ads rapporte le coût en micros — divisez par 1 000 000 pour obtenir les valeurs monétaires réelles. C’est l’un des pièges classiques de Google Ads, et c’est à vous de le gérer dans le script. Il n’y a pas de conversion automatique.

Limites d’exécution

Les Scripts ont une limite d’exécution stricte de 30 minutes par exécution. C’est la contrainte déterminante de l’approche.

Pour les petits comptes (quelques centaines de campagnes, volume de données modeste), 30 minutes est amplement suffisant. Pour les grands comptes avec des milliers de campagnes, plusieurs groupes d’annonces par campagne, et des données au niveau annonce ou mot-clé, vous pouvez atteindre la limite. Quand cela se produit, le script expire à mi-exécution et votre table BigQuery peut contenir des données partielles.

Il existe deux façons de travailler dans cette limite :

Réduire la portée par exécution. Au lieu de récupérer tous les groupes d’annonces en une seule exécution, récupérez par campagne et planifiez plusieurs exécutions de scripts ou échelonnez la couverture sur la semaine. Cela ajoute une complexité de coordination.

Utiliser des requêtes agrégées. Récupérez des données au niveau campagne plutôt qu’au niveau annonce ou mot-clé. L’agrégation réduit considérablement les comptages de lignes. La plupart des cas d’usage de reporting peuvent fonctionner au niveau campagne ; vous n’avez besoin des données granulaires que pour des analyses d’optimisation spécifiques.

Les options de planification sont horaire, quotidienne ou hebdomadaire — pas au niveau de la minute. Vous ne pouvez pas planifier un script à 3h17 du matin ; vous choisissez 3h ou 4h. Pour les rafraîchissements quotidiens, planifiez à 3h ou plus tard pour garantir que les données de la veille sont complètes (les statistiques Google Ads peuvent avoir jusqu’à 3 heures de retard).

Comparaison avec les alternatives

Les Scripts occupent une niche spécifique. Ils sont plus flexibles que DTS (vous définissez les champs, la logique et le schéma — pas de piège d’inflation ClickType ni de surprises de schéma fixe) et plus simples que dlt (pas de developer token, pas de Python, pas d’infrastructure). Mais ils sont bornés par JavaScript et le mur des 30 minutes.

Quand les Scripts sont le bon choix

Les Scripts conviennent bien quand :

• Une logique d’extraction personnalisée ou un filtrage de champs est nécessaire mais aucune infrastructure serveur n’est disponible
• L’approbation du developer token est en attente ou refusée — les Scripts utilisent un chemin d’authentification différent
• Le volume du compte est suffisamment modeste pour se terminer dans la limite de 30 minutes
• Une planification horaire, quotidienne ou hebdomadaire est suffisante (pas de besoins sub-horaires)
• L’équipe travaille en JavaScript ; les équipes Python peuvent préférer dlt une fois qu’un developer token est disponible

Pour les comptes à l’échelle entreprise, les volumes de données élevés, les besoins sub-horaires, ou les équipes qui veulent Python et le contrôle de version, le processus d’approbation du developer token devient rentable. Voir dlt Google Ads Pipeline pour ce qui devient disponible avec l’accès API.