🌑 🧘🏼 🧘🏽 Comment contourner les erreurs lors de la création de rapports dans Power BI et arriver à la construction d'un système de téléchargement pour les mégadonnées 🚚 👩🏻‍🤝‍👨🏽 🙎🏿

Derrière des tableaux de bord Power BI magnifiques et compréhensibles se trouvent souvent des semaines de préparation et d'exploration de données. Surtout quand il s'agit de créer des rapports BI utiles dans une grande organisation avec un volume de trafic de dizaines de millions de visiteurs chaque mois.

Dans cet article, je veux décrire un certain nombre d'aspects négatifs que j'ai rencontrés lors de la création de rapports BI basés sur les données de systèmes d'analyse Web dans un certain nombre d'entreprises (grands représentants du commerce électronique russe, compagnies d'assurance, etc.). L'article n'a pas pour but de faire de l'anti-publicité, ou vice versa, la publicité de certains outils ou décisions. Il est préparé afin d'aider à éviter d'éventuels moments négatifs pour les autres utilisateurs et indiquer les options de solutions.

Avertissement

Je parle de grandes quantités de données et montre des exemples de téléchargement et d'échantillonnage à partir de Google Analytics 360. Sur les projets avec une petite quantité de données, de telles difficultés peuvent ne pas exister. J'ai rencontré tous les problèmes identifiés dans la pratique et dans l'article, je ne décris que mon expérience en résolution - la vôtre peut être complètement différente.

Connecteur vers Yandex.Metrica

Yandex.Metrica a des conditions d'échantillonnage plus douces et une interface intuitive par rapport à Google Analytics. Par conséquent, de nombreux spécialistes du marketing préfèrent Yandex.Metrica et créent des rapports BI sur le téléchargement de données à partir de là. Pour ce faire, utilisez le connecteur de Maxim Uvarov. Cette méthode n'est pas sûre et ne permet pas de traiter des demandes complexes.

Les grandes entreprises ont besoin d'une garantie que les informations confidentielles ne tomberont pas entre les mains des détracteurs, et les indicateurs financiers ne seront utilisés que pour les parties prenantes et exclusivement au sein de l'entreprise.

Le premier gros inconvénient est que pour utiliser le connecteur, dans Power BI, vous devez activer le paramètre "Ignorer les niveaux de confidentialité", sinon cela ne fonctionnera tout simplement pas.

Ainsi, les données confidentielles peuvent tomber entre les mains de tout utilisateur non autorisé. Cela est confirmé par un extrait de l'aide de Power BI.

La connexion de données est anonyme. Cependant, il n'y a aucune autorisation ou vérification de l'autorisation d'utiliser ces données pour les utilisateurs qui sont vraiment autorisés à le faire.

Pour que ces connecteurs fonctionnent, vous devez obtenir un jeton d'accès OAUTH. La description du connecteur fournit un lien sur la façon de donner à l'application l'accès à votre compte.

En fait, une application tierce aura accès à votre compte. Personne ne garantit la sécurité de vos données.

Le deuxième inconvénient est que l'API Yandex.Metrica ne peut pas traiter de grandes quantités de données sur de grands projets et, par conséquent, le connecteur refuse également de travailler avec des requêtes complexes sur des données Yandex.Metrica brutes - il ne les décharge pas.

Par exemple, vous devez télécharger des données pendant un an, sans aucun filtre complexe. Le connecteur renvoie une erreur: «La demande est trop complexe. Veuillez réduire l'espacement des dates ou l'échantillonnage. "

Bien sûr, il s'agit d'une traduction de l'erreur de l'API Yandex.Metrica elle-même. Cependant, dans ce cas, nous n'avons pas le choix de télécharger des données avec une ventilation par mois ou par jour - par exemple, pour faire un cycle de données pour chaque mois et les combiner en un seul ensemble de données surmontant une erreur d'API.
Si vous réduisez considérablement la période, l'API vous permet de pomper des données, mais ce n'est qu'une petite partie de ce dont nous avons besoin.

Pour créer des rapports volumineux, le déchargement pour de courtes périodes est peu pratique et peu pratique. En pratique, vous avez souvent besoin de décharger via des entonnoirs complexes pour sites ouverts avec un grand nombre de visites par jour. Surtout lors de l'utilisation de segments de visites complexes, il est pratiquement impossible de télécharger les données nécessaires.

Même si vous avez pu charger les données, ce n'est pas un fait qu'il sera possible de télécharger vers le modèle de données pour créer le rapport lui-même, car diverses erreurs de chargement apparaissent de temps en temps. Pour une raison quelconque, même avec une table normalement chargée, des erreurs se produisent.

Pour que toutes les parties prenantes de l'entreprise puissent utiliser le rapport basé sur le connecteur API Yandex.Metrica, vous devez publier le rapport dans PowerBI Service. Dans ce cas, les niveaux de confidentialité devront également être ignorés.

Lorsque la visualisation est configurée et que le rapport est publié dans le cloud Microsoft, le connecteur affichera une erreur de requête combinée et ne sera pas mis à jour via le service Power BI - vous ne pourrez pas configurer la mise à jour planifiée de votre rapport. L'erreur se produit lorsque l'une des requêtes, qui forme la table de téléchargement finale, contient la logique du travail simultané avec la requête externe et interne.

Dans l'erreur, la

table «Fonction appelée» est juste indiquée: Cette table est obtenue grâce à la fonction PQYM, qui fonctionne avec une source de données externe - l'API Yandex.Metrica. Le mécanisme de mise à jour des rapports dans Power BI ne fonctionne pas et demande de refaire la combinaison de requêtes. Cela est dû aux liens internes d'une demande de connexion à une demande externe, ainsi qu'à la structure de la fonction elle-même.

Nous avons décidé de ne pas utiliser un tel connecteur lors de la création de rapports et sommes passés au déchargement des données de l'API Yandex.Metrica via des scripts Python, plus à ce sujet plus loin dans l'article.

Connecteur Google Analytics

Pour créer des rapports sur les données de Google Analytics (nous parlons de téléchargement direct à partir du système d'analyse), il existe également un connecteur Maxim Uvarov.

Ici, vous devrez également définir «Ignorer les niveaux de confidentialité». L'accès à l'API de votre système d'analyse, qui contient des données sur les ventes en ligne, se fait via une connexion anonyme.

Selon les instructions, vous devrez à nouveau ouvrir l'accès à une application tierce, uniquement pour un compte Google, qui contient une menace pour la confidentialité de vos données.

Vous pouvez réécrire certaines données dans le connecteur lui-même et commencer à les utiliser pour votre propre application. Pour ce faire, enregistrez «ID client OAuth 2.0» sur cloud.google.com, obtenez des jetons d'accès et entrez les clés d'accès nécessaires dans son mécanisme de travail. Mais même ces actions ne vous aideront pas dans la lutte contre l'échantillonnage et la mise à jour de vos rapports.

Chaque fois que vous touchez les données agrégées de l'API Google Analytics, nous rencontrons toujours un échantillonnage.

Le connecteur a la possibilité de décharger un jour, mais même il ne sauvegarde pas toujours. L'indicateur d'échantillonnage intégré au connecteur montre qu'il est là même en une journée.

Par exemple, les données de session ventilées par Shopping Stage ne peuvent pas être téléchargées sans échantillonnage sur de telles quantités de données. Cela entraînera de grandes erreurs dans les données et les mesures lors de la création de rapports, en particulier lorsqu'il est nécessaire de calculer avec précision la conversion de la transition d'une étape à l'autre, ou de télécharger des données sur des entonnoirs avec une structure complexe de segments.

Même si la perte de données n'est pas critique pour vous, vous ne pouvez toujours pas configurer la mise à jour planifiée de vos rapports via le service Power BI.

La même erreur du mécanisme de travail interfère, seules les fonctions PQGA.

Nous avons également refusé de travailler avec ce connecteur.

Connecteur natif Google Analytics

Parfois, Google et Microsoft se font des concessions: Power BI prêt à l'emploi dispose d'un connecteur Google Analytics standard. Malheureusement, il n'y a pas une telle option pour Yandex.Metrica.

Le mécanisme de travail avec l'API Google Analytics est plus facilement mis en œuvre ici que dans le connecteur de Maxim Uvarov, mais lors du téléchargement d'un grand nombre d'indicateurs, les données sont trop échantillonnées. Les nombres répétés dans la capture d'écran sont les données échantillonnées.

Vous pouvez éviter l'échantillonnage si vous déchargez des mini-tableaux ventilés uniquement par date et par n'importe quel indicateur. Par exemple, la date, le nombre de sessions et le type d'appareil. Et puis à partir de ces tableaux pour collecter les rapports nécessaires.

Si vous n'avez pas des millions de trafic, cela peut vous aider. Cependant, les rapports ne seront pas informatifs et avec des limites d'évolutivité: en raison des nombreuses mini-tables dans le modèle de données, il est difficile de créer des relations entre elles. Cela impose une restriction sur la création de filtres et de tranches.

Vous pouvez réécrire le connecteur standard et le forcer à télécharger des données pour chaque jour, tandis que les données seront proches des vrais chiffres dans l'interface GA, mais vous ne pourrez pas éviter l'échantillonnage.

Selon mes observations, lors de la répartition des sessions Shopping Stage, pas un seul connecteur n'a pu normalement télécharger des données sans échantillonner de grandes quantités de données.

Dans le connecteur standard, vous ne pouvez pas personnaliser les dates de téléchargement. Tout ce qui est simplement une sélection de paramètres et de métriques à partir des API Google Analytics disposées dans des dossiers.

Ce connecteur convient aux projets Internet de petite et moyenne taille avec peu de trafic. Ici, une situation similaire se présente avec l'obtention de données auprès de Yandex.Metrica. Toutes les informations nécessaires sans perte de précision ne peuvent être téléchargées directement via l'API qu'à l'aide de scripts ou de services de streaming de données spéciaux - plus d'informations à ce sujet plus loin dans l'article.

Sticks in Wheels par Google

Récemment, nous avons remarqué un verrou étrange - lors de la tentative de configuration de la mise à jour du connecteur "natif" de Google Analytics, une erreur d'autorisation est apparue via un compte Google dans l'interface du service Power BI.

Nous avons essayé de savoir ce que Google devait faire dans une telle situation et comment «blanchir» la réputation du compte, mais nos tentatives ont échoué. Nous avons essayé d'enregistrer de nouveaux comptes et de nous connecter via différents appareils - Google a bloqué toute tentative d'autorisation.

Environ un mois après le blocage, nous avons toujours réussi à nous connecter via le même compte, mais un tel incident peut considérablement interférer avec la publication des rapports de BI nécessaires à temps et mettre le client dans une position délicate. Immédiatement après l'écluse, nous avons commencé à chercher une issue possible à la situation. Pour éviter les verrous inattendus, nous avons décidé de créer notre propre environnement contrôlé avec les données nécessaires pour les rapports BI.

Options de solution

Obtenez les rapports BI nécessaires pour les moyennes et grandes organisations, et même sans échantillonnage est possible. Mais vous devez essayer un peu et choisir l'une des différentes façons.

Vous pouvez utiliser des services prêts à l'emploi pour diffuser des données. Leur objectif principal est de télécharger des données du système d'analyse, de divers systèmes de publicité, de CRM et d'autres services vers n'importe quel stockage. Pratique, rapide et pratique, mais pas gratuit. Sur de gros volumes de données ou des données avec plusieurs sources, les montants sont tangibles.

Les services les plus connus:

Chacun de ces systèmes vous permet de configurer la diffusion quotidienne de données non échantillonnées à partir de systèmes d'analyse Web (Yandex.Metrics et Google Analytics) vers des bases de données (par exemple, BigQuery, Azure SQL Database, Microsoft SQL Server ou ClickHouse) pour la connexion via Power BI et la création de rapports.

Si les outils répertoriés sont trop chers pour l'entreprise, vous pouvez essayer d'implémenter votre système de téléchargement de données et utiliser Power BI + Python + Any Cloud Server (ou Yandex.Cloud) + PostgreSQL. Il s'agit de la méthode que nous utilisons lors de la création de rapports BI.

Schéma d'interaction du système:

Un tel schéma de travail assure la conservation, l'autonomie et l'agrégation des données nécessaires. Après avoir établi un tel schéma une fois, vous n'aurez pas besoin de passer du temps à collecter des informations - tout est dans le référentiel, il vous suffit de vous connecter et de commencer à créer un rapport sur Power BI.

Les scripts Python «tirent» toutes les données selon l'API des sources nécessaires, écrivent dans la base de données ou déchargent les formulaires (par exemple, au format csv). Les scripts pour le téléchargement à partir de l'API et le chargement dans la base de données méritent un article séparé, et un jour je l'écrirai.

Bien sûr, il existe de nombreux modèles et solutions prêtes à l'emploi sur Internet, mais pour une mise à l'échelle supplémentaire, il est nécessaire de connaître les besoins individuels du système sous lequel les scripts de déchargement sont créés.

Les données sont écrites dans une base de données pré-créée et configurée - dans notre cas, PostgreSQL. Les scripts pompent des données pour chaque jour et les écrivent dans des tableaux selon un calendrier. Ils sont situés sur un serveur cloud sous notre contrôle ou sous le contrôle du service de sécurité informatique du client.

Il existe un grand nombre d'entreprises qui fournissent des services de stockage cloud. En fonction de vos préférences personnelles, Yandex . Cloud a été sélectionné .

Avantages de Yandex.Cloud:

Configuration pratique et location de serveurs avec PostgreSQL préinstallé.
Une documentation complète en russe, qui est clairement indiquée et vous permet d'apprendre rapidement à utiliser le service.
Gestion de serveur pratique.
Support rapide de spécialistes.
Flexibilité des différents réglages et tarifs des équipements: personne n'impose de packages de configuration prêts à l'emploi, vous choisissez vous-même la configuration de vos équipements, et vous pouvez immédiatement commander le preset de n'importe quelle base de données.

Les téléchargements résultants sont écrits dans la base de données PostgreSQL. Cette base de données a été choisie car il s'agit d'un SGBD relationnel objet (fonctionnant avec des tableaux multidimensionnels et le support JSON de la «boîte» - pour les structures de données complexes doivent avoir). Il est flexible, fiable, gratuit et dispose également d'une énorme communauté de support.

Power BI dispose d'un connecteur direct intégré dans PostgreSQL. Lors de la première connexion, vous devez installer Npgsql supplémentaire . Power BI vous en informe et fournit un lien.

Pour configurer les mises à jour de rapports lors de l'utilisation du stockage cloud, vous devez configurer la passerelle Power BI . Il est nécessaire de configurer la mise à jour des rapports BI et d'assurer la sécurité des données confidentielles lors de leur transfert à partir d'une base de données, qui doit être située dans le circuit informatique interne de votre organisation, ou sur un serveur cloud sécurisé.

La passerelle permet un transfert de données rapide et sécurisé entre les magasins de données situés sur le réseau interne de l'organisation et les services cloud Microsoft. Le transfert de données entre Power BI et la passerelle est sécurisé, et toutes les informations d'identification fournies par les administrateurs de la passerelle sont cryptées pour protéger les informations dans le cloud et sont décryptées uniquement sur l'ordinateur de la passerelle.

Après avoir téléchargé Power BI Gateway et l'avoir lancé, une boîte de dialogue apparaît.

Pour enregistrer et utiliser la passerelle, les informations d'identification du service cloud Power BI Service sont requises.

Après tous les paramètres, une fenêtre sur la passerelle de travail apparaîtra. Ensuite, vous devez définir des paramètres supplémentaires.

Une alternative plus simple à la personnalisation de PostgreSQL est Google BigQuery. Power BI dispose d'un connecteur intégré dans Google BigQuery. Dans ce cas, il est nécessaire de suivre le principe "sept fois pour calculer le coût, une fois pour répondre à la demande".

BigQuery peut être utilisé gratuitement pendant un an, simplement en attachant une carte bancaire sur accord pour utiliser le service. L'argent après la date limite à votre insu ne sera pas débité. Tarification supplémentaire - selon les tarifs du système lui-même, mais avec quelques "avantages" agréables.

Si les données téléchargées de vos systèmes n'atteignent pas 10 Go par mois (!), Le téléchargement ne sera pas facturé.

Si le traitement mensuel des données ne dépasse pas 1 To, aucun frais ne sera facturé non plus. Si plus, alors 5 $ pour chaque traitement 1 To.

Si vous devez stocker plus de 10 Go par mois, chaque gigaoctet suivant coûtera 0,010 $.

Les tarifs sont décrits plus en détail sur la page BigQuery.

Sommaire

Si vous avez besoin de données provenant de divers systèmes d'analyse, et en même temps, la sûreté, la sécurité, l'agrégation continue, la convivialité et le manque d'échantillonnage sont fondamentaux pour vous, vous avez deux façons.

Le premier est les services de streaming. Ils sont faciles à utiliser, ils ont un support technique continu et une intégration prête à l'emploi avec les entrepôts de données.

Désavantages:

Coûts tangibles sur de grandes quantités de données.
Type d'intégration limité fourni.
Processus non contrôlés du côté du fournisseur de services de streaming pour travailler avec vos informations.

Le second est son propre flux de téléchargement et d'agrégation de données. Évolutif, contrôlé, avec sécurité des données. Il peut sembler compliqué et long à mettre en œuvre. Si l'entreprise a besoin d'une organisation efficace du reporting BI, de son évolutivité et de la sécurité des données supplémentaires, cette option est la plus acceptable.

Tous ceux qui pensent simplement à un reporting BI à part entière doivent ajouter la devise «Accumuler, structurer et protéger ces données contre les jeunes» dans la culture d'entreprise. Il n'y a rien de mieux qu'une base de données à part entière à haute tolérance aux pannes avec une sauvegarde régulière et avec des droits différenciés pour l'utiliser pour différentes catégories de parties prenantes.

Il est nécessaire d'accumuler, de structurer et d'agréger vos données à partir de systèmes d'analyse, d'une application mobile et d'autres services clients. Tout cela à l'avenir vous aidera à analyser à la fois votre audience et vos produits dans toutes les sections. Les informations et les données dominent désormais le monde et coûtent parfois plus cher que l'argent.

Comment implémenter l'approche décrite dans l'article pour transférer des données d'analyse vers une base de données PostgreSQL à l'aide de scripts Python et des détails d'implémentation, je vais discuter dans les articles suivants.

Comment contourner les erreurs lors de la création de rapports dans Power BI et arriver à la construction d'un système de téléchargement pour les mégadonnées