🏦 ▪️ 👸🏻 Como solucionar os erros ao criar relatórios no Power BI e começar a construção de um sistema de upload para big data 👃🏾 🧚 🈺

Por trás dos painéis bonitos e compreensíveis do Power BI, muitas vezes há semanas de preparação e mineração de dados. Especialmente quando se trata de criar relatórios úteis de BI em uma grande organização com um volume de tráfego de dezenas de milhões de visitantes todos os meses.

Neste artigo, quero descrever vários aspectos negativos que encontrei ao criar relatórios de BI com base em dados de sistemas de análise da Web em várias empresas (grandes representantes do comércio eletrônico russo, companhias de seguros etc.). O artigo não tem como objetivo fazer propaganda antipublicidade, ou vice-versa, de determinadas ferramentas ou decisões. É preparado para ajudar a evitar possíveis momentos negativos para outros usuários e indicar opções de soluções.

aviso Legal

Estou falando sobre grandes quantidades de dados e mostrando exemplos de upload e amostragem do Google Analytics 360. Em projetos com uma pequena quantidade de dados, essas dificuldades podem não existir. Eu conheci todos os problemas identificados na prática e, no artigo, descrevo apenas minha experiência em resolver - a sua pode ser completamente diferente.

Conector para Yandex.Metrica

O Yandex.Metrica possui condições de amostragem mais brandas e uma interface intuitiva em comparação com o Google Analytics. Portanto, muitos profissionais de marketing preferem o Yandex.Metrica e criam relatórios de BI sobre o upload de dados a partir daí. Para fazer isso, use o conector de Maxim Uvarov. Este método é inseguro e não permite o processamento de solicitações complexas.

As grandes empresas precisam garantir que as informações confidenciais não caiam nas mãos dos detratores, e os indicadores financeiros serão usados apenas pelas partes interessadas e exclusivamente dentro da empresa.

O primeiro grande ponto negativo é que, para usar o conector, no Power BI, é necessário ativar a configuração "Ignorar níveis de privacidade", caso contrário, não funcionará.

Assim, dados confidenciais podem cair nas mãos de qualquer usuário não autorizado. Isso é confirmado por um trecho da Ajuda do Power BI.

A conexão de dados é anônima. No entanto, não há autorização ou verificação de permissão para usar esses dados para os usuários que realmente têm permissão.

Para que esses conectores funcionem, você precisa obter um token de acesso oauth. A descrição do conector fornece um link sobre como conceder ao aplicativo acesso à sua conta.

De fato, um aplicativo de terceiros terá acesso à sua conta. Ninguém garante a segurança dos seus dados.

O segundo ponto negativo é que a API do Yandex.Metrica não pode processar grandes quantidades de dados em projetos grandes e, como resultado, o conector também se recusa a trabalhar com consultas complexas nos dados brutos do Yandex.Metrica - não os descarrega.

Por exemplo, você precisa fazer o upload de dados por um ano, sem filtros complexos. O conector gera um erro: “A solicitação é muito complexa. Por favor, reduza o espaçamento ou a amostragem da data ".

Obviamente, esta é uma tradução do erro da própria API Yandex.Metrica. No entanto, nesse caso, não temos opção de baixar dados com uma discriminação por mês ou dia - por exemplo, para alternar dados para cada mês e combiná-los em um único conjunto de dados, superando um erro de API.
Se você reduzir significativamente o período, a API permitirá que você bombeie dados, mas isso é apenas uma pequena parte do que precisamos.

Para criar relatórios grandes, o descarregamento por períodos curtos é impraticável e inconveniente. Na prática, você geralmente precisa descarregar através de funis complexos de site aberto com um grande número de visitas por dia. Especialmente ao usar segmentos complexos de visitas, é praticamente impossível fazer o upload dos dados necessários.

Mesmo que você tenha conseguido carregar os dados, não é possível carregar no modelo de dados para criar o próprio relatório, porque vários erros de carregamento aparecem de vez em quando. Por algum motivo, mesmo com uma tabela carregada normalmente, ocorrem erros.

Para que todas as partes interessadas na empresa possam usar o relatório criado no conector da API Yandex.Metrica, é necessário publicar o relatório no Serviço PowerBI. Nesse caso, os níveis de privacidade também terão que ser ignorados.

Quando a visualização estiver configurada e o relatório publicado na nuvem da Microsoft, o conector exibirá um erro de consulta combinado e não será atualizado pelo Serviço do Power BI - você não poderá configurar a atualização agendada do seu relatório. O erro ocorre quando uma das consultas, que forma a tabela de upload final, contém a lógica do trabalho simultâneo com a consulta externa e interna.

No erro, a

tabela "Função chamada" é apenas indicada: Esta tabela é obtida devido à função PQYM, que funciona com uma fonte de dados externa - a API Yandex.Metrica. O mecanismo de atualização de relatórios no Power BI não funciona e solicita refazer a combinação de consultas. Isso ocorre devido aos links internos de uma solicitação para conectar-se a uma solicitação externa, bem como à estrutura da própria função.

Decidimos não usar esse conector ao criar relatórios e passamos a descarregar dados da API Yandex.Metrica por meio de scripts Python, mais sobre isso mais adiante neste artigo.

Conector do Google Analytics

Para criar relatórios sobre os dados do Google Analytics (estamos falando de download direto do sistema de análise), também há um conector Maxim Uvarov.

Aqui você também terá que definir "Ignorando níveis de privacidade". O acesso à API do seu sistema de análise, que contém dados sobre vendas online, ocorre em uma conexão anônima.

De acordo com as instruções, novamente você terá que abrir o acesso a um aplicativo de terceiros, apenas para uma conta do Google, que contenha uma ameaça à privacidade dos seus dados.

Você pode reescrever alguns dados no próprio conector e começar a usá-los para seu próprio aplicativo. Para fazer isso, registre o "ID do cliente OAuth 2.0" em cloud.google.com, obtenha tokens de acesso e insira as chaves de acesso necessárias em seu mecanismo de trabalho. Mas mesmo essas ações não ajudarão na luta contra a amostragem e a atualização dos seus relatórios.

Sempre que você tocar nos dados agregados da API do Google Analytics, sempre encontraremos amostras.

O conector tem a opção de descarregar um dia, mas nem sempre ele salva. O indicador de amostragem embutido no conector mostra que ele existe mesmo em um dia.

Por exemplo, os dados da sessão divididos pelo Shopping Stage não podem ser carregados sem amostragem nessas quantidades de dados. Isso levará a grandes erros de dados e medidas na criação de relatórios, especialmente quando for necessário calcular com precisão a conversão da transição de uma etapa para outra ou fazer upload de dados em funis com uma estrutura complexa de segmentos.

Mesmo que a perda de dados não seja crítica para você, você ainda não poderá configurar a atualização agendada de seus relatórios por meio do Serviço do Power BI.

O mesmo erro do mecanismo de trabalho interfere, apenas as funções PQGA.

Também nos recusamos a trabalhar com este conector.

Conector nativo do Google Analytics

Às vezes, o Google e a Microsoft fazem concessões entre si: o Power BI pronto para uso possui um conector padrão do Google Analytics. Infelizmente, não existe essa opção para o Yandex.Metrica.

O mecanismo para trabalhar com a API do Google Analytics é mais convenientemente implementado aqui do que no conector de Maxim Uvarov, mas durante o download de um grande número de indicadores, os dados são muito amostrados. Os números repetidos na captura de tela são os dados amostrados.

Você pode evitar a amostragem se descarregar minitabelas discriminadas apenas por data e qualquer um dos indicadores. Por exemplo, data, número de sessões e tipo de dispositivo. E, a partir dessas tabelas, para coletar os relatórios necessários.

Se você não possui milhões de tráfego, isso pode ajudar. No entanto, os relatórios não serão informativos e com limitações de escalabilidade: devido às muitas minitabelas no modelo de dados, é difícil criar relacionamentos entre elas. Isso impõe uma restrição à criação de filtros e fatias.

Você pode reescrever o conector padrão e forçá-lo a fazer upload de dados para cada dia, enquanto os dados estarão próximos dos números reais na interface do GA, mas não será possível evitar a amostragem.

De acordo com minhas observações, no detalhamento das sessões do Shopping Stage, nem um único conector conseguiu fazer upload de dados normalmente sem amostrar grandes quantidades de dados.

No conector padrão, você não pode personalizar as datas do download. Tudo isso é simplesmente uma seleção de parâmetros e métricas das APIs do Google Analytics organizadas em pastas.

Esse conector é adequado para projetos de Internet de pequeno e médio porte com pouco tráfego. Aqui, uma situação semelhante surge com a obtenção de dados do Yandex.Metrica. Todas as informações necessárias sem perda de precisão só podem ser baixadas diretamente através da API usando scripts ou serviços especiais de streaming de dados - mais sobre isso mais adiante neste artigo.

Sticks in Wheels by Google

Recentemente, notamos um bloqueio estranho - ao tentar configurar a atualização para o conector "nativo" do Google Analytics, um erro de autorização apareceu por meio de uma conta do Google na interface do Serviço do Power BI.

Tentamos descobrir no Google o que fazer em tal situação e como "branquear" a reputação da conta, mas nossas tentativas falharam. Tentamos registrar novas contas e fazer login em diferentes dispositivos - o Google bloqueou qualquer tentativa de autorização.

Cerca de um mês após o bloqueio, ainda conseguimos acessar a mesma conta, mas esse incidente pode interferir seriamente na liberação dos relatórios de BI necessários em tempo hábil e colocar o cliente em uma situação embaraçosa. Imediatamente após o bloqueio, começamos a procurar uma possível saída da situação. Para evitar bloqueios inesperados, decidimos criar nosso próprio ambiente controlado com os dados necessários para os relatórios de BI.

Opções de solução

Obtenha os relatórios de BI necessários para organizações de médio e grande porte, e mesmo sem amostragem é possível. Mas você precisa tentar um pouco e escolher uma das várias maneiras.

Você pode usar serviços prontos para transmitir dados. Seu principal objetivo é fazer upload de dados do sistema de análise, vários sistemas de publicidade, CRM e outros serviços para qualquer armazenamento. Conveniente, rápido e prático, mas não gratuito. Em grandes volumes de dados ou dados com várias fontes, os valores são tangíveis.

Os serviços mais famosos:

Cada um desses sistemas permite configurar o fluxo diário de dados não amostrados dos sistemas de análise da web (Yandex.Metrics e Google Analytics) para bancos de dados (por exemplo, BigQuery, Banco de Dados SQL do Azure, Microsoft SQL Server ou ClickHouse) para conectar-se via Power BI e criar relatórios.

Se as ferramentas listadas forem muito caras para a empresa, você pode tentar implementar seu sistema de upload de dados e usar o Power BI + Python + Qualquer Cloud Server (ou Yandex.Cloud) + PostgreSQL. Este é o método que usamos ao criar relatórios de BI.

Esquema de interação do sistema:

Este esquema de trabalho fornece a necessária segurança, autonomia e agregação de dados. Depois de estabelecer esse esquema uma vez, você não precisará gastar tempo coletando informações - tudo está no repositório, basta conectar e começar a fazer um relatório no Power BI.

Os scripts Python “extraem” todos os dados de acordo com a API das fontes necessárias, gravam no banco de dados ou formam descarregamentos (por exemplo, no formato csv). Os scripts para upload da API e carregamento no banco de dados merecem um artigo separado, e algum dia eu o escreverei.

Obviamente, existem muitos modelos e soluções prontas na Internet, mas, para ampliar ainda mais a escala, é necessário conhecer as necessidades individuais do sistema sob o qual os scripts para descarregamento são criados.

Os dados são gravados em um banco de dados pré-criado e configurado - no nosso caso, o PostgreSQL. Os scripts distribuem dados para cada dia e os escrevem nas tabelas de acordo com uma programação. Eles estão localizados em um servidor em nuvem sob nosso controle ou sob o controle do serviço de segurança de TI do cliente.

Há um grande número de empresas que fornecem serviços de armazenamento em nuvem. Com base nas preferências pessoais, o Yandex Cloud foi selecionado .

Vantagens do Yandex.Cloud:

Configuração conveniente e aluguel de servidores com o PostgreSQL pré-instalado.
Documentação extensa em russo, que é claramente declarada e permite que você aprenda rapidamente como usar o serviço.
Gerenciamento conveniente de servidores.
Suporte rápido de especialistas.
Flexibilidade de várias configurações e tarifas de equipamentos: ninguém impõe nenhum pacote de configurações prontas, você mesmo escolhe a configuração do seu equipamento e pode solicitar imediatamente a predefinição de qualquer banco de dados.

Os uploads resultantes são gravados no banco de dados PostgreSQL. Esse banco de dados foi escolhido por ser um DBMS relacional a objetos (trabalhando com matrizes multidimensionais e suporte a JSON da “caixa” - pois estruturas de dados complexas devem ter). É flexível, confiável, gratuito e também possui uma enorme comunidade de suporte.

O Power BI possui um conector direto interno no PostgreSQL. Na primeira conexão, você precisa instalar o Npgsql adicional . O Power BI notifica você sobre isso e fornece um link.

Para configurar atualizações de relatório ao usar o armazenamento em nuvem, você deve configurar o Power BI Gateway . É necessário configurar a atualização dos relatórios de BI e garantir a segurança dos dados confidenciais ao transferi-los de um banco de dados, que deve estar localizado no circuito interno de TI da sua organização ou em um servidor em nuvem seguro.

O gateway fornece transferência de dados rápida e segura entre repositórios de dados localizados na rede interna da organização e nos serviços de nuvem da Microsoft. A transferência de dados entre o Power BI e o gateway é segura e todas as credenciais fornecidas pelos administradores do gateway são criptografadas para proteger as informações na nuvem e são descriptografadas apenas no computador do gateway.

Depois de baixar o Power BI Gateway e iniciá-lo, uma caixa de diálogo é exibida.

Para registrar e operar o gateway, são necessárias as credenciais do serviço de nuvem do Power BI Service.

Após todas as configurações, uma janela sobre o gateway de trabalho será exibida. Em seguida, você precisa fazer configurações adicionais.

Uma alternativa mais simples para personalizar o PostgreSQL é o Google BigQuery. O Power BI possui um conector interno no Google BigQuery. Nesse caso, é necessário seguir o princípio de "sete vezes para calcular o custo, uma vez para atender à solicitação".

O BigQuery pode ser usado gratuitamente por um ano, simplesmente amarrando um cartão bancário mediante acordo para o uso do serviço. Dinheiro após o prazo final sem o seu conhecimento não será debitado. Tarifas adicionais - de acordo com as tarifas do próprio sistema, mas com algumas "vantagens" agradáveis.

Se os dados baixados do seu sistema não atingirem 10 GB por mês (!), Não haverá cobrança pelo download.

Se o processamento mensal de dados não exceder 1 TB, nenhuma taxa será cobrada por isso também. Se houver mais, então US $ 5 para cada tratamento 1 TB.

Se você precisar armazenar mais de 10 GB por mês, cada gigabyte subsequente custará US $ 0,010.

As tarifas são descritas em mais detalhes na página do BigQuery.

Sumário

Se você precisar de dados de vários sistemas de análise e, ao mesmo tempo, segurança, segurança, agregação contínua, usabilidade e falta de amostragem são fundamentais para você, você tem duas maneiras.

O primeiro são os serviços de streaming. São fáceis de usar, contam com suporte técnico contínuo e integração pronta com data warehouses.

Desvantagens:

Custos tangíveis em grandes quantidades de dados.
Tipo limitado de integração fornecido.
Processos não controlados no lado do provedor de serviços de streaming para trabalhar com suas informações.

O segundo é o seu próprio fluxo de upload e agregação de dados. Escalável, controlado, com segurança de dados. Pode parecer complicado e demorado de implementar. Se a empresa precisar de uma organização eficaz de relatórios de BI, de mais escalabilidade e segurança de dados, essa opção será a mais aceitável.

Todos aqueles que pensam apenas em relatórios de BI completos precisam adicionar o lema "Acumular, estruturar e proteger esses dados da juventude" na cultura corporativa. Não há nada melhor do que um banco de dados completo e tolerante a falhas com um backup regular e com direitos diferenciados de usá-lo para diferentes categorias de partes interessadas.

É necessário acumular, estruturar e agregar seus dados de sistemas de análise, de um aplicativo móvel e de outros serviços de clientes. Tudo isso no futuro ajudará a analisar seu público e produtos em qualquer seção. Informações e dados agora dominam o mundo e às vezes custam mais que dinheiro.

Falarei sobre como implementar a abordagem descrita no artigo para transferir dados de análise para um banco de dados PostgreSQL usando scripts Python e detalhes de implementação nos artigos a seguir.

Como solucionar os erros ao criar relatórios no Power BI e começar a construção de um sistema de upload para big data