Comment surveiller les nouvelles créations publicitaires Google Ads dans le temps

1. Mettez en place votre premier instantané de référence

Définissez exactement les annonceurs vérifiés et les valeurs de filtre que vous surveillez. Enregistrez un petit lot de référence avec l'heure de collecte, la limite de résultats, l'issue de l'exécution et toute note de périmètre. Enregistrez les lignes de création sans les écraser.

La tâche publique Google Ads Advertiser Monitor | Creative Snapshots est un préréglage d'entrée enregistré pour l'acteur. Son entrée de préréglage est `{"targets": ["apple.com", "samsung.com"], "region": "US", "platform": "ALL", "adFormat": "ALL", "includeDeliveryDetails": false, "maxItems": 10}`. Remplacez les cibles par les identifiants exacts ou les URL exactes des annonceurs vérifiés, car les domaines peuvent se résoudre en plusieurs comptes. `maxItems` est un plafond partagé entre les cibles. Consignez vos filtres réels, y compris la politique de dates.

Une ligne signifie un annonceur et une création observés. L'identité exacte utilise `advertiserId` plus `creativeId`. Les champs obligatoires comprennent `creativeUrl`, `observedAt`, `requestedRegion`, `requestedPlatform`, `requestedFormat`, `status` et `statusReason`. `firstShownAt` et `lastShownAt` sont des dates de la source publique, et non le moment de votre première observation. `variations` et `variationCount` sont des détails d'assets enfants, et non de nouveaux identifiants de création.

Conservez l'identifiant de votre lot de collecte et l'état de l'exécution dans un manifeste appartenant au lecteur. La ligne n'a pas de champ `runId`. N'inventez pas un total de source et n'affirmez pas l'exhaustivité à partir d'une exécution réussie limitée par un plafond. Examinez la sortie et son plafond réel ou son état d'arrêt. Si la couverture ne peut pas être établie, étiquetez l'instantané comme limité. L'acceptation actuelle de métadonnées à deux lignes n'est pas un test de surveillance à deux moments.

2. Planifiez et validez les exécutions ultérieures

Fixez un intervalle de répétition manuel raisonnable pour votre besoin. La tâche n'a pas d'alerte récurrente intégrée. Conservez le même compte cible, la même région, le même format, la même plateforme et la même politique de fenêtre de dates. Si une fenêtre mobile est nécessaire, consignez les deux fenêtres réelles et ne traitez pas leurs exclusions comme des retraits.

Validez chaque exécution ultérieure avant de la comparer. Vérifiez une collecte réussie, les comptes attendus, le même périmètre prévu, l'absence d'échec non traité et un état honnête de plafond ou de couverture. Un échantillon partiel réussi reste un échantillon. Maintenez les échecs, les collectes vides et un zéro explicite de la source bien distincts.

3. Comparez les ensembles d'identités d'un lot à l'autre

Dédoublonnez les lignes à l'intérieur d'un lot par `advertiserId` et `creativeId`. D'un lot à l'autre, conservez votre historique d'observation, mais comparez l'ensemble d'identités de chaque lot.

Étiquetez les éléments actuels moins les éléments précédents comme nouvellement observés dans cette comparaison. Étiquetez les éléments précédents moins les éléments actuels comme non observés maintenant. Ne qualifiez jamais ces derniers de supprimés ou d'inactifs uniquement du fait de leur absence. Comparez seulement les clés non vides formées de `advertiserId` plus `creativeId`. Une identité manquante reste non résolue en dehors des ensembles.

L'intersection signifie les identités présentes dans les deux ensembles. L'union signifie toutes les identités distinctes sur les deux ensembles.

4. Examinez les créations nouvellement observées

Ouvrez chaque source de création nouvellement observée et examinez son identité, les dates de la source, et si vous avez déjà traité cette clé exacte de compte et de création. Conservez un état non examiné lorsque l'aperçu est indisponible. Une découverte tardive peut montrer une ancienne date de premier affichage. Signalez cela au lieu d'annoncer un nouveau lancement.

Conservez une table de clés traitées pour les alertes. Chaque clé doit avoir la date à laquelle le processus de collecte a observé pour la première fois cette clé exacte de compte et de création, un statut de revue, une heure de dernière observation et un état d'alerte. Relancez une alerte en échec séparément d'une nouvelle collecte des données. Un aperçu modifié sous la même clé de création peut faire l'objet d'une revue de révision, mais ce n'est pas une alerte de nouvelle création. Conservez ces décisions de façon explicite.

Enregistrez votre file de revue et la suite donnée après chaque comparaison acceptée. Ne faites pas avancer la référence de confiance après une exécution en échec. Une exécution limitée peut produire de nouveaux candidats observés, mais ses identités manquantes doivent rester inconnues.

Exemple pratique fictif

Toutes les identités, dates, décomptes et événements de cet exemple sont inventés.

Imaginez que vous vérifiez l'annonceur A avec le même ensemble de filtres :

• Le lot 1 a été collecté le 1er octobre 2026 à 12:00:00 UTC. Il contient les clés de création A/C1, A/C2 et A/C3. Vous notez qu'il s'agit d'un échantillon limité. Vos alertes traitées contiennent déjà C1, C2 et C3.
• Le lot 2 a été collecté le 8 octobre 2026 à 12:00:00 UTC. Il contient A/C2, A/C3, A/C4 et A/C5. C'est aussi un échantillon limité.
• Actuel moins précédent égale `{C4, C5}` avec le décompte 2.
• Précédent moins actuel égale `{C1}` avec le décompte 1.
• L'intersection égale `{C2, C3}` avec le décompte 2.
• L'union égale `{C1, C2, C3, C4, C5}` avec le décompte 5.
• Ne transformez pas 2 éléments nouveaux et 4 éléments renvoyés en un taux de croissance, car les échantillons sont plafonnés.

Ensuite, vous inspectez les éléments du lot 2 :

• Pour la création C4, la source donne le 2 septembre 2026 comme valeur de `firstShownAt`. Elle est nouvellement observée, mais ce n'est clairement pas un premier affichage cette semaine.
• La création C5 a une date `firstShownAt` inconnue, donc son moment de lancement est inconnu.
• État de la file de revue :
• A/C4 est nouvellement observée, la source est vérifiée, elle a une ancienne date de source, et elle fait l'objet d'une alerte comme nouvelle dans la bibliothèque.
• A/C5 est nouvellement observée, l'aperçu est indisponible, la date est inconnue et la revue est en attente.
• C1 n'est pas observée maintenant, la comparaison est limitée, la disponibilité est inconnue et aucune alerte de retrait n'est envoyée.

Étapes suivantes de la chronologie fictive :

• Le lot 3 du 9 octobre échoue et ne renvoie aucune ligne acceptée. Vous conservez le lot 2 comme dernière référence de confiance. Vous ne faites pas avancer la référence après le lot 3 en échec, et vous ne produisez pas d'alertes de retrait pour C2 à C5.
• Le lot 4 du 15 octobre renvoie C3, C4, C5 et C6 avec le même périmètre. Vous comparez le lot 4 accepté au lot 2.
• Nouvellement observé égale `{C6}`.
• Non observé égale `{C2}`.
• Les éléments communs égalent `{C3, C4, C5}`.

• La création C4 traitée évite une alerte répétée. La création C5 n'est pas examinée. La création C6 requiert une nouvelle revue. L'absence de C1 ou de C2 est inconnue. Les lignes complètes du registre comprennent C4 alertée, C5 en attente, C6 nouvelle revue requise, et l'absence de C1 ou de C2 inconnue. Ceci est un contrôle de règle fictif, et non une preuve de la disponibilité complète actuelle de la source.