Bonnes pratiques

Les bonnes pratiques suivantes vous fourniront des techniques pour développer des requêtes performantes et axées sur la confidentialité.

Confidentialité et précision des données

Développer des requêtes sur des données de bac à sable

Bonne pratique : Interrogez les données de production uniquement lorsque vous êtes en production.

Dans la mesure du possible, utilisez des données de bac à sable pendant le développement de vos requêtes. Les tâches utilisant des données de bac à sable n'introduisent pas d'opportunités supplémentaires de vérification des différences permettant de filtrer les résultats de votre requête. De plus, en l'absence de contrôles de confidentialité, les requêtes de bac à sable s'exécutent plus rapidement, ce qui permet une itération plus rapide lors du développement des requêtes.

Si vous devez développer des requêtes pour vos données réelles (par exemple, lorsque vous utilisez des tables de correspondances), choisissez des périodes et d'autres paramètres peu susceptibles de se chevaucher à chaque itération de votre requête. Vous réduirez ainsi les risques de chevauchement des lignes. Enfin, exécutez votre requête sur la plage de données souhaitée.

Étudier attentivement les historiques de résultats

Bonne pratique : Réduisez la probabilité que les ensembles de résultats se chevauchent entre des requêtes récentes.

N'oubliez pas que le taux de variation entre les résultats des requêtes aura un impact sur la probabilité qu'ils soient omis plus tard en raison des contrôles de confidentialité. Un second ensemble de résultats ressemblant fortement à un autre ensemble de résultats récemment renvoyé risque d'être abandonné.

Modifiez plutôt les paramètres clés de votre requête, tels que les plages de dates ou les ID de campagne, afin de réduire la probabilité d'un chevauchement important.

Ne pas interroger les données du jour

Bonne pratique : N'exécutez pas plusieurs requêtes dont la date de fin est aujourd'hui.

Si vous exécutez plusieurs requêtes dont la date de fin est identique à la date du jour, des lignes risquent d'être filtrées. Ces conseils s'appliquent également aux requêtes exécutées peu après minuit sur des données de la veille.

Ne pas interroger les mêmes données plus que nécessaire

Bonnes pratiques :

  • Sélectionnez des dates de début et de fin étroitement liées.
  • Plutôt que d'interroger des fenêtres qui se chevauchent, exécutez vos requêtes sur des ensembles de données distincts, puis agrégez les résultats dans BigQuery.
  • Utilisez des résultats enregistrés au lieu de réexécuter votre requête.
  • Créez des tables temporaires pour chaque plage de dates sur laquelle vous effectuez des requêtes.

Ads Data Hub limite le nombre de fois où vous pouvez interroger les mêmes données. Essayez donc de limiter le nombre d'accès à un élément de données.

Ne pas utiliser plus d'agrégations que nécessaire dans la même requête

Bonnes pratiques :

  • Minimiser le nombre d'agrégations dans une requête
  • Réécrire les requêtes pour combiner les agrégations lorsque cela est possible

Ads Data Hub limite à 100 le nombre d'agrégations multi-utilisateurs autorisées dans une sous-requête. Par conséquent, nous vous recommandons globalement d'écrire des requêtes générant davantage de lignes avec des clés de regroupement ciblées et des agrégations simples, plutôt qu'un plus grand nombre de colonnes avec des clés de regroupement larges et des agrégations complexes. Le format suivant doit être évité :

SELECT
  COUNTIF(field_1 = a_1 AND field_2 = b_1) AS cnt_1,
  COUNTIF(field_1 = a_2 AND field_2 = b_2) AS cnt_2
FROM
  table

Les requêtes qui comptabilisent les événements en fonction du même ensemble de champs doivent être réécrites avec l'instruction GROUP BY.

SELECT
  field_1,
  field_2,
  COUNT(1) AS cnt
FROM
  table
GROUP BY
  1, 2

Le résultat peut être agrégé de la même manière dans BigQuery.

Les requêtes qui créent des colonnes à partir d'un tableau, puis les agrègent doivent être réécrites pour fusionner ces étapes. 

SELECT
  COUNTIF(a_1) AS cnt_1,
  COUNTIF(a_2) AS cnt_2
FROM
  (SELECT
     1 IN UNNEST(field) AS a_1,
     2 IN UNNEST(field) AS a_2,
   FROM
     table)

La requête précédente peut être réécrite comme suit :

SELECT f, COUNT(1) FROM table, UNNEST(field) AS f GROUP BY 1

Les requêtes qui utilisent différentes combinaisons de champs dans différentes agrégations peuvent être réécrites en plusieurs requêtes plus ciblées.

SELECT
  COUNTIF(field_1 = a_1) AS cnt_a_1,
  COUNTIF(field_1 = b_1) AS cnt_b_1,
  COUNTIF(field_2 = a_2) AS cnt_a_2,
  COUNTIF(field_2 = b_2) AS cnt_b_2,
FROM table

La requête précédente peut être divisée en :

SELECT
  field_1, COUNT(*) AS cnt
FROM table
GROUP BY 1

et

SELECT
  field_2, COUNT(*) AS cnt
FROM table
GROUP BY 1

Vous pouvez scinder ces résultats en requêtes distinctes, créer et joindre les tables dans une même requête, ou les combiner avec UNION si les schémas sont compatibles.

Optimiser et comprendre les jointures

Bonne pratique : Utilisez une LEFT JOIN au lieu d'une INNER JOIN pour joindre les clics ou les conversions aux impressions.

Toutes les impressions ne sont pas associées à des clics ou à des conversions. Par conséquent, si vous effectuez une INNER JOIN entre des clics/conversions et des impressions, les impressions qui ne sont pas liées à des clics ou des conversions seront exclues de vos résultats.

Image montrant plusieurs types de jointure via des diagrammes de Venn

Joindre certains résultats finaux dans BigQuery

Bonne pratique : Évitez les requêtes Ads Data Hub qui joignent des résultats agrégés. Écrivez plutôt deux requêtes distinctes et joignez les résultats dans BigQuery.

Les lignes qui ne répondent pas aux exigences d'agrégation sont exclues de vos résultats. Par conséquent, si votre requête joint une ligne insuffisamment agrégée à une autre ligne qui l'est suffisamment, la ligne obtenue sera filtrée. De plus, les requêtes comportant plusieurs agrégations sont moins performantes dans Ads Data Hub.

Vous pouvez joindre des résultats (dans BigQuery) à partir de plusieurs requêtes d'agrégation (depuis Ads Data Hub). Les résultats calculés à l'aide de requêtes courantes partageront des schémas finaux.

La requête suivante prend des résultats Ads Data Hub individuels (campaign_data_123 et campaign_data_456) et les joint dans BigQuery :

SELECT t1.campaign_id, t1.city, t1.X, t2.Y
FROM `campaign_data_123` AS t1
FULL JOIN `campaign_data_456` AS t2
USING (campaign_id, city)

Utiliser les récapitulatifs des lignes filtrées

Bonne pratique : Ajoutez des récapitulatifs des lignes filtrées à vos requêtes.

Les récapitulatifs des lignes filtrées regroupent les données filtrées suite à des contrôles de confidentialité. Les données des lignes filtrées sont additionnées et ajoutées à une ligne collectrice. Bien que les données filtrées ne puissent pas être analysées plus en détail, elles fournissent un récapitulatif du volume de données exclu des résultats.

Comptabiliser les ID utilisateur remis à zéro

Bonne pratique : Comptabilisez les ID utilisateur remis à zéro dans vos résultats.

L'ID d'un utilisateur final peut être défini sur 0 pour diverses raisons, y compris pour désactiver la personnalisation des annonces, pour des raisons réglementaires, etc. Les données issues de différents utilisateurs sont alors associées à un user_id de 0.

Si vous souhaitez comprendre les totaux des données, tels que le nombre total d'impressions ou de clics, vous devez inclure ces événements. Toutefois, ces données ne sont d'aucune utilité pour obtenir des informations sur les clients ; elles doivent par conséquent être filtrées si vous effectuez une analyse de ce type.

Vous pouvez exclure ces données de vos résultats en ajoutant WHERE user_id != "0" à vos requêtes.

Performances

Éviter la réagrégation

Bonne pratique : Évitez d'ajouter plusieurs couches d'agrégation au niveau des utilisateurs.

Le traitement des requêtes qui combinent des résultats déjà agrégés, comme une requête avec plusieurs GROUP BY ou une agrégation imbriquée, nécessite davantage de ressources.

Souvent, les requêtes comportant plusieurs couches d'agrégation peuvent être divisées, ce qui améliore les performances. Vous devez essayer de conserver les lignes au niveau de l'événement ou de l'utilisateur pendant le traitement, puis de les combiner avec une seule agrégation.

Les formats suivants doivent être évités :

SELECT SUM(count)
FROM
  (SELECT campaign_id, COUNT(0) AS count FROM ... GROUP BY 1)

Les requêtes utilisant plusieurs couches d'agrégation doivent être réécrites afin qu'elles n'en utilisent qu'une seule.

(SELECT ... GROUP BY ... )
JOIN USING (...)
(SELECT ... GROUP BY ... )

Les requêtes pouvant être facilement divisées doivent l'être. Vous pouvez joindre les résultats dans BigQuery.

Optimiser les performances de BigQuery

En règle générale, les requêtes moins complexes affichent de meilleures performances. Lorsque vous évaluez les performances d'une requête, la quantité de travail nécessaire dépend des facteurs suivants :

Si l'exécution d'une requête ne respecte pas vos contrats de niveau de service, ou si vous rencontrez des erreurs en raison de l'épuisement des ressources ou du délai d'inactivité, appliquez les recommandations suivantes :

  • Utiliser les résultats des requêtes précédentes au lieu de faire de nouveaux calculs. Par exemple, le total hebdomadaire peut correspondre à la somme (calculée dans BigQuery) de sept requêtes quotidiennes agrégées.
  • Décomposer des requêtes en sous-requêtes logiques (par exemple, diviser des jointures en plusieurs requêtes) ou restreindre l'ensemble de données en cours de traitement. Vous pouvez combiner les résultats de tâches individuelles dans un seul ensemble de données dans BigQuery. Bien que cela puisse atténuer l'épuisement des ressources, votre requête risque également d'être ralentie.
  • Si vous rencontrez des erreurs de dépassement de ressources dans BigQuery, essayez de diviser vos requêtes en plusieurs requêtes BigQuery à l'aide de tables temporaires.
  • Référencer moins de tables dans une même requête, car cela consomme beaucoup de mémoire et peut faire échouer votre requête.
  • Réécrire vos requêtes de manière à ce qu'elles joignent moins de tables utilisateur.
  • Réécrire vos requêtes pour éviter de joindre une table à elle-même.

Query Advisor

Si votre requête SQL est valide, mais qu'elle peut déclencher un filtrage excessif, Query Advisor affiche des conseils concrets lors du processus de développement de la requête pour vous aider à éviter les résultats indésirables.

Les motifs suivants peuvent être des déclencheurs :

Pour utiliser Query Advisor :

  • Interface utilisateur : des recommandations s'affichent au-dessus du texte de la requête dans l'éditeur.
  • API : utilisez la méthode customers.analysisQueries.validate.