Cette fonctionnalité n'est disponible que dans Analytics 360, qui fait partie de Google Marketing Platform. En savoir plus sur Google Marketing Platform |
Cet article contient des exemples montrant comment créer des requêtes concernant les données Analytics que vous exportez vers BigQuery. Grâce à notre exemple d'ensemble de données, vous pouvez vous entraîner à utiliser les requêtes présentées dans cet article.
Au sommaire de cet article :- Optimisation des requêtes
- Conseils et bonnes pratiques
- Exemples de requêtes de base
- Nombre total de [metric] par [dimension]
- Taux de rebond moyen par [dimension]
- Nombre moyen de pages produit vues par type d'acheteur
- Nombre moyen de transactions par acheteur
- Montant moyen dépensé par session
- Séquence d'appels (analyse du chemin)
- Dimensions personnalisées multiples au niveau de l'appel ou de la session
- Exemples de requêtes avancées
- Produits achetés par les clients qui acquièrent le produit A (e-commerce classique)
- Produits achetés par les clients qui acquièrent le produit A (e-commerce amélioré)
- Nombre moyen d'interactions de l'utilisateur avant l'achat
- Pourcentage de stock vendu par produit
- Rentabilité de chaque produit
- Rentabilité réelle de chaque produit
Optimisation des requêtes
Chaque requête que vous exécutez contribue à votre allocation mensuelle de traitement de données. Si vous sélectionnez des champs superflus, vous augmentez la quantité de données qui doit être traitée, vous utilisez donc votre allocation mensuelle plus que nécessaire. Les requêtes optimisées utilisent votre allocation mensuelle de traitement de données d'une manière plus efficace.
En savoir plus sur la tarification
Sélectionnez uniquement ce dont vous avez besoin
Lorsque vous formulez une requête, sélectionnez les champs pertinents au sein de l'instruction SELECT. En évitant d'appeler des champs superflus, vous réduisez la quantité de données ainsi que le temps nécessaire au traitement de la requête.
Exemple : Évitez d'utiliser l'opérateur générique
Mauvaise formulation : en utilisant l'opérateur générique |
---|
SELECT * |
Meilleure formulation : en utilisant les noms des champs pour éviter tout traitement inutile |
---|
SELECT field1, field2 |
Autoriser la mise en cache
Lorsque cela est possible, évitez d'utiliser des fonctions à la place des champs. Les fonctions (telles que NOW()
ou TODAY()
) renvoient des résultats variables qui empêchent la mise en cache des requêtes et retardent donc la réception de leurs résultats. Utilisez plutôt des dates et des heures précises.
Utiliser des tableaux intermédiaires pour les sous-requêtes couramment utilisées
Si vous constatez que vous utilisez régulièrement une même requête en tant que sous-requête, vous pouvez l'enregistrer sous la forme d'un tableau intermédiaire en cliquant sur Save as Table (Enregistrer en tant que tableau) au-dessus des résultats de la requête. Vous pouvez ensuite référencer ce tableau dans la section FROM
de votre requête, ce qui réduira à la fois la quantité de données à traiter et le temps de traitement nécessaire.
En utilisant un tableau intermédiaire |
---|
SELECT field1, field2 |
Débogage des requêtes
BigQuery permet de déboguer votre code au fur et à mesure que vous le construisez. Dans la fenêtre dédiée, le débogage est indiqué juste en dessous de la requête. Le débogage est également disponible via l'API grâce au marqueur dryRun.
Les requêtes correctes ont un indicateur vert sur lequel vous pouvez cliquer pour afficher la quantité de données traitées par la requête. Cette fonction vous donne la possibilité d'optimiser vos données avant d'exécuter la requête de sorte à éviter le traitement de données inutiles.
Les requêtes incorrectes ont un indicateur rouge sur lequel vous pouvez cliquer pour afficher des informations sur l'erreur, et trouver la ligne et la colonne où l'erreur se produit. Dans l'exemple ci-dessous, l'instruction GROUP BY est vide et l'erreur est mise en évidence.
Conseils et bonnes pratiques
Utiliser l'exemple d'ensemble de données
Les exemples suivants utilisent l'exemple d'ensemble de données Google Analytics.
Pour utiliser les requêtes pour vos propres données, il vous suffit de remplacer les noms du projet et de l'ensemble de données dans les exemples par vos propres noms de projet et d'ensemble de données.
Utiliser SQL standard ou l'ancien SQL
BigQuery est compatible avec les deux dialectes SQL suivants :
Pour en savoir plus sur les différences entre les deux dialectes, consultez Migrer vers le langage SQL standard.
SQL standard est actuellement le dialecte SQL privilégié pour interroger des données stockées dans BigQuery.
Pour en savoir plus sur l'activation du dialecte SQL standard dans l'interface utilisateur, la CLI ou l'API BigQuery (ou toute autre interface que vous utilisez), consultez Activer le langage SQL standard.
La manière la plus simple de commencer consiste à inclure le commentaire "standardSQL" en haut de vos requêtes SQL standard, comme indiqué dans les exemples suivants.
En cas d'utilisation de l'ancien SQL, les données Google Analytics 360 sont transmises chaque jour à un nouveau tableau. Pour créer des requêtes portant sur plusieurs tableaux à la fois, vous pouvez séparer le nom des tableaux par une virgule, utiliser la fonction de caractères génériques du tableau TABLE_DATE_RANGE
ou plusieurs fonctions TABLE_DATE_RANGE
séparées par une virgule, comme dans les exemples suivants.
Créer des requêtes sur plusieurs tableaux
Vous trouverez ci-dessous des exemples de requêtes dans les deux dialectes (SQL standard et ancien SQL) pour les mêmes données.
3 jours
SQL standard
3 jours avec "UNION ALL" |
---|
#standardSQL |
Ancien SQL
3 jours avec des noms de tableaux séparés par une virgule |
---|
SELECT |
1 095 derniers jours
SQL standard
1 095 derniers jours avec "_TABLE_SUFFIX" |
---|
#standardSQL |
Ancien SQL
1 095 derniers jours avec "TABLE_DATE_RANGE" |
---|
SELECT |
36 derniers mois
SQL standard
36 derniers mois avec "_TABLE_SUFFIX" |
---|
#standardSQL |
Ancien SQL
36 derniers mois avec "TABLE_DATE_RANGE" |
---|
SELECT |
3 dernières années
SQL standard
3 dernières années avec "_TABLE_SUFFIX" |
---|
#standardSQL |
Ancien SQL
3 dernières années avec "TABLE_DATE_RANGE" |
---|
SELECT |
Période spécifique
SQL standard
Période spécifique avec "_TABLE_SUFFIX" |
---|
#standardSQL |
Ancien SQL
Période spécifique avec "TABLE_DATE_RANGE" |
---|
SELECT |
3 dernières années, avec les données d'aujourd'hui (intrajournalières)
SQL standard
3 dernières années, avec les données d'aujourd'hui (intrajournalières), avec "UNION ALL" et "_TABLE_SUFFIX" |
---|
Remarque : Cet exemple de requête n'est pas compatible actuellement avec l'ensemble de données public Google Analytics, car celui-ci ne contient pas de tableau intrajournalier. |
#standardSQL |
Ancien SQL
3 dernières années, avec les données d'aujourd'hui (intrajournalières), avec plusieurs "TABLE_DATE_RANGE" |
---|
Remarque : Cet exemple de requête n'est pas compatible actuellement avec l'ensemble de données public Google Analytics, car celui-ci ne contient pas de tableau intrajournalier. |
SELECT |
Exemples de requêtes de base
Cette section explique comment construire des requêtes de base à l'aide de statistiques et de dimensions à partir des données d'exemple Analytics.
Nombre total de [metric] par [dimension] ?
Voici des exemples de scripts pour la question Quel est le nombre total de transactions générées par navigateur d'appareil en juillet 2017 ?
SQL standard
Nombre total de transactions par navigateur d'appareil en juillet 2017 |
---|
#standardSQL |
Ancien SQL
Nombre total de transactions par navigateur d'appareil en juillet 2017 |
---|
SELECT |
Taux de rebond moyen par [dimension] ?
Le taux de rebond réel est défini comme étant le pourcentage de visites avec une seule page vue. Voici des exemples de scripts pour la question Quel a été le taux de rebond réel par source de trafic ?
SQL standard
Taux de rebond par source de trafic en juillet 2017 |
---|
#standardSQL |
Ancien SQL
Taux de rebond par source de trafic en juillet 2017 |
---|
SELECT |
Nombre moyen de pages produit vues par type d'acheteur (acheteurs ou non-acheteurs)
Voici des exemples de scripts pour la question Quel était le nombre moyen de pages produit vues par les utilisateurs ayant effectué un achat en juillet 2017 ?
SQL standard
Nombre moyen de pages produit vues par les utilisateurs ayant effectué un achat en juillet 2017 |
---|
#standardSQL |
Ancien SQL
Nombre moyen de pages produit vues par les utilisateurs ayant effectué un achat en juillet 2017 |
---|
SELECT |
Voici des exemples de scripts pour la question Quel était le nombre moyen de pages produit vues par les utilisateurs n'ayant pas effectué d'achat en juillet 2017 ?
SQL standard
Nombre moyen de pages produit vues par les utilisateurs n'ayant pas effectué d'achat en juillet 2017 |
---|
#standardSQL |
Ancien SQL
Nombre moyen de pages produit vues par les utilisateurs n'ayant pas effectué d'achat en juillet 2017 |
---|
SELECT |
Nombre moyen de transactions par acheteur
Vous trouverez ci-dessous des exemples de scripts pour la question Quel a été le total moyen de transactions enregistrées par utilisateur ayant effectué un achat en juillet 2017 ?
SQL standard
Nombre moyen de transactions par utilisateur ayant effectué un achat en juillet 2017 |
---|
#standardSQL |
Ancien SQL
Nombre moyen de transactions par utilisateur ayant effectué un achat en juillet 2017 |
---|
SELECT |
Montant moyen dépensé par session
Voici des exemples de scripts pour la question Quel a été le montant moyen dépensé par session en juillet 2017 ?
SQL standard
Montant moyen dépensé par session en juillet 2017 |
---|
#standardSQL |
Ancien SQL
Montant moyen dépensé par session en juillet 2017 |
---|
SELECT |
Séquence d'appels
Voici des exemples de scripts pour la question Dans quel ordre les pages ont-elles été vues ?
SQL standard
Ordre dans lequel les pages ont été vues par les utilisateurs en juillet 2017 |
---|
#standardSQL |
Ancien SQL
Ordre dans lequel les pages ont été vues par les utilisateurs en juillet 2017 |
---|
SELECT |
Dans cette requête, vous devez limiter les types d'appels aux PAGES
pour ne pas voir apparaître les interactions liées aux événements et aux transactions. Chacune des lignes de la sortie représente une page vue. Elles sont listées par défaut en fonction des champs de l'instruction SELECT
.
Dimensions personnalisées multiples au niveau de l'appel ou de la session
Dimension personnalisée au niveau de l'appel |
---|
SELECT fullVisitorId, visitId, hits.hitNumber, hits.time, |
Dimension personnalisée au niveau de la session |
---|
SELECT fullVisitorId, visitId, |
Dans chaque requête :
L'instruction SELECT
permet d'obtenir les champs de dimension et de métrique correspondants.
La fonction MAX
:
- Renvoie la dimension personnalisée en tant que nouvelle colonne. Vous pouvez répéter la fonction afin de renvoyer plusieurs dimensions personnalisées en tant que nouvelles colonnes.
- Les appels
WITHIN
et lesWITHIN RECORD
évaluent la condition à l'intérieur des champs répétés dans BigQuery. - La condition que comporte le
MAX
est évaluée en fonction de chaque dimension personnalisée. Pour toutes celles qui ne sont pas desindex=1 (hits)
ou desindex=2 (sessions)
, la fonction renvoie la valeurNULL
. - Renvoie la valeur maximale, qui correspond à la valeur de la dimension personnalisée 1 pour les appels ou à celle de la dimension personnalisée 2 pour les sessions, étant donné que toutes les autres valeurs sont
NULL
.
Exemples de requêtes avancées
Maintenant que vous connaissez les requêtes simples, vous pouvez créer des requêtes à l'aide des fonctions avancées et des fonctionnalités disponibles dans BigQuery.
Produits achetés par les clients qui acquièrent le produit A (e-commerce classique)
Voici le squelette de script pour la question : Quels sont les autres produits que peuvent acheter les clients qui acquièrent le produit A ?
Produits achetés par un client qui acquiert le produit A (e-commerce classique) |
---|
SELECT hits.item.productName AS other_purchased_products, COUNT(hits.item.productName) AS quantity |
- Dans la première ligne, vous sélectionnez tous les autres articles achetés par un utilisateur, la fonction d'agrégation
COUNT()
se charge de compter les autres articles achetés. Le résultat s'affiche ensuite dans un champ intituléquantity
et l'article correspondant dans le champ du produit intituléother_purchased_products
. - Dans la sous-requête grise, vous devez sélectionner uniquement les utilisateurs uniques (
fullVisitorId
) qui ont effectué des transactions (totals.transactions>=1
) et qui ont acheté le produit A (WHERE hits.item.productName CONTAINS 'Product Item Name A'
) au cours d'une transaction.
Les règles (instructions WHERE
et AND
) dans la requête de premier niveau (verte) ignorent les valeurs hits.item.productName
qui sont NULL et qui contiennent le produit A.
Voici un exemple de la requête Si un client achète un lot de quatre stylos en métal Brighton, quel(s) autre(s) produit(s) a-t-il acheté(s) ?
Produits achetés par un client qui acquiert "un lot de quatre stylos en métal Brighton" le 24 juin 2013 |
---|
SELECT hits.item.productName AS other_purchased_products, COUNT(hits.item.productName) AS quantity |
Dans Dremel/BigQuery, l'utilisation de WHERE expr IN
déclenche un JOIN et des restrictions de taille s'appliquent ; plus précisément, la taille du côté droit du JOIN (dans ce cas, le nombre de visiteurs) doit être inférieure à 8 Mo. Dans Dremel, cette opération porte le nom de broadcast JOIN. Lorsque la taille est supérieure à 8 Mo, vous devez déclencher un shuffled JOIN à l'aide de la syntaxe JOIN EACH. Malheureusement, cette requête ne peut pas être réalisée avec IN, mais il est toutefois possible de la réécrire avec la commande JOIN.
Produits achetés par les clients qui acquièrent le produit A (commerce électronique amélioré)
Il s'agit du même squelette de requête que le précédent, mais celui-ci s'applique au commerce électronique amélioré. Il utilise également les requêtes de données PLAGE_DE_DATES_DU_TABLEAU
sur plusieurs jours.
Produits achetés par un client qui acquiert le produit A (e-commerce amélioré) |
---|
SELECT hits.product.productSKU AS other_purchased_products, COUNT(hits.product.productSKU) AS quantity |
Nombre moyen d'interactions de l'utilisateur avant l'achat
Voici un exemple de requête d'une commande JOIN() [...] ON
, qui repose uniquement sur des données Analytics.
Voici le squelette de script pour la question Quel est le nombre moyen d'interactions de l'utilisateur avant un achat ?
Nombre d'interactions de l'utilisateur avant un achat |
---|
SELECT one.hits.item.productSku AS ProductSku, ( sum_of_hit_number / total_hits ) AS avg_hit_number |
- La première ligne réalise l'opération mathématique principale pour déterminer le nombre moyen d'interactions de l'utilisateur par produit, et cette requête crée une jointure entre deux sous-requêtes appelées ‘Alias_Name_1’ et ‘Alias_Name_2’.
- ‘Alias_Name_1’ sert à générer un champ qui utilise la fonction d'agrégation
SUM()
pour regrouper tous les numéros d'appel enregistrés pour un produit. - ‘Alias_Name_2’ sert à déterminer le nombre d'appels effectués par les utilisateurs pour chaque produit, en utilisant la fonction
COUNT()
. - La dernière ligne affiche le champ (
hits.item.productSku
) commun aux deux ensembles de données lors de la jointure.
Voici un exemple de la requête Quel est le nombre moyen d'interactions de l'utilisateur avant un achat au 10 septembre 2013 ?
Nombre d'interactions de l'utilisateur avant un achat, au 10 septembre 2013 |
---|
SELECT one.hits.item.productSku AS ProductSku, ( sum_of_hit_number / total_hits ) AS avg_hit_number |
Pourcentage de stock vendu par produit
Voici l'exemple d'une requête qui ne dépend pas seulement des données Analytics, mais aussi des données n'appartenant pas à Analytics. En combinant les deux ensembles de données, vous pouvez commencer à comprendre le comportement de l'utilisateur à un niveau plus segmenté. Vous pouvez importer des données n'appartenant pas à Analytics dans BigQuery, mais gardez à l'esprit que cela va être pris en compte dans vos frais mensuels de stockage de données.
Voici un squelette de script pour la question : Quel est le pourcentage de stock vendu par produit ?
Pourcentage de stock vendu par produit |
---|
SELECT AnalyticsImport.product_data_20130728.productId, ((( one.quantity_sold ) / ( AnalyticsImport.product_data_20130728.productstock + one.quantity_sold )) * 100 ) AS percentage_of_stock_sold |
- La première ligne génère deux champs : le premier contient tous les identifiants produit et le second correspond à une opération mathématique qui affiche le pourcentage de stock vendu pour cet identifiant produit.
- Étant donné que cette requête dépend de deux ensembles de données, vous devez utiliser la fonction
JOIN() ... ON
. Cette commande permet de joindre les lignes des deux ensembles de données en se basant sur le champ qu'ils ont en commun. Dans ce cas, les deux ensembles de données sont[ ‘Imported_DataSet’ ]
et‘Alias_Name’
. [ ‘Imported_DataSet’ ]
représente la donnée n'appartenant pas à Analytics. C'est l'ensemble de données qui contient le champ de la métrique relative au stock restant (Imported DataSet.'stock_left_field'
) et le champ de la dimension indiquant l'identifiant produit (Imported_DataSet.'productId_field'
).‘Alias_Name’
est le nom attribué aux données renvoyées par la sous-requête grise. Cette sous-requête utilise des données Google Analytics pour déterminer la quantité totale d'articles vendus par produit.- La dernière ligne utilise l'instruction
ON
pour afficher le champ commun et la jointure entre les deux ensembles de données.
Dans cette requête, de nombreuses variables ont pour préfixe le nom de l'ensemble de données auquel elles sont associées (par exemple, Imported_DataSet.’productId_field’, Alias_Name.quantity_sold
). Ceci permet de vous indiquer clairement le champ que vous sélectionnez et de mettre en évidence l'ensemble de données auquel il appartient.
Voici un exemple de la requête Quel a été le pourcentage de stock vendu par produit le 28 juillet 2013 ?
Pourcentage de stock vendu par produit le 28 juillet 2013 |
---|
SELECT AnalyticsImport.product_data_20130728.productId, ( ( ( one.quantity_sold ) / ( AnalyticsImport.product_data_20130728.productstock + one.quantity_sold ) ) * 100 ) AS percentage_of_stock_sold |
Rentabilité de chaque produit
Voici un squelette de script pour la question : Quelle est la rentabilité de chaque produit ?
Bénéfice par produit |
---|
SELECT Alias_Name.hits.item.productSku, ( Imported_DataSet.’product profit field’ * Alias_Name.quantity ) AS profit |
- La première ligne contient l'opération mathématique permettant de calculer le bénéfice total réalisé sur chaque produit.
- La sous-requête grise utilise les données n'appartenant pas à Analytics. Elle recueille les données relatives au bénéfice réalisé suite à la vente d'un produit.
- La sous-requête rouge correspond à la sous-requête de données Analytics, qui sera jointe avec les données n'appartenant pas à Analytics. Cette sous-requête calcule la quantité d'articles vendus par produit.
- La dernière ligne utilise l'instruction
ON
pour préciser le champ commun aux deux ensembles de données. Dans ce cas, il s'agit du numéro d'identifiant produit.
Voici un exemple de la requête : Quelle était la rentabilité de chaque produit le 28 juillet 2013 ?
Bénéfice par produit le 28 juillet 2013 |
---|
SELECT two.hits.item.productSku, ((AnalyticsImport.product_data_20130728.productprice-AnalyticsImport.product_data_20130728.productcost)*two.quantity) AS profit |
Le bénéfice est calculé en déterminant la différence entre le prix de vente du produit et son coût de fabrication. Ces informations sont stockées dans l'ensemble de données n'appartenant pas à Google Analytics.
Rentabilité réelle de chaque produit (en prenant en compte les remboursements)
Voici un squelette de script pour la question : Quelle est la véritable rentabilité de chaque produit ?
Bénéfice réel par produit |
---|
SELECT Alias_Name.hits.item.productSku, (gross_profit-total_refund_revenue) AS real_profit |
- Ceci est une requête très semblable à la requête Quelle est la rentabilité de chaque produit ? Les seules différences résident dans l'ensemble de données n'appartenant pas à Analytics contenu dans la sous-requête grise et dans l'opération mathématique, située à la première ligne, qui permet de calculer le bénéfice réel.
- Dans l'ensemble de données n'appartenant pas à Analytics, vous calculez également le montant total de l'argent dépensé pour les remboursements (dans l'instruction
SELECT
de la sous-requête rouge). - Ensuite, vous effectuez une opération mathématique sur la ligne 1 pour trouver le bénéfice réel en soustrayant les revenus dépensés pour les remboursements de votre bénéfice brut.
Pour plus d'informations sur la requête, veuillez consulter la section sur la rentabilité de chaque produit.
Voici un exemple de la requête : Quelle était la véritable rentabilité de chaque produit le 28 juillet 2013 ?
Bénéfice réel par produit le 28 juillet 2013 |
---|
SELECT two.hits.item.productSku, (gross_profit-total_refund_revenue) AS real_profit |
Le bénéfice réel tient compte de la rentabilité d'un produit après avoir pris les produits remboursés en considération. Pour calculer le total des revenus associés aux remboursements d'un produit :
Total des revenus associés aux remboursements pour un produit = (le prix du produit + le prix de la livraison du remboursement pour le produit) * la quantité de produits remboursés