Impactos das interfaces de relatórios do Analytics em programas do Analytics

No mundo da análise, os analistas passam muito tempo em produtos de análise executando relatórios. Cada produto de análise tem uma abordagem ligeiramente diferente para relatórios. Alguns produtos de análise começam com uma tela em branco e exigem que o analista arraste os elementos de dados para realizar a análise. Outros permitem que os analistas importem dados para planilhas. Alguns requerem o uso de SQL. Alguns fornecem modelos de relatório que permitem que os analistas preencham o espaço em branco com eventos e propriedades. Embora nenhuma interface de relatórios analíticos seja necessariamente melhor que outra, é importante que as organizações escolham aquela que melhor se adapta à sua organização e seus consumidores de dados. A interface de relatórios pode ter impactos consequentes no programa de análise como um todo. Neste post, descreverei algumas das interfaces de relatórios de análise que vi e como elas podem afetar os modelos e programas de entrega de análises.

Relatório de forma livre

Uma das interfaces de relatórios de análise mais populares é o que chamo de relatórios de forma livre. Nesta interface de relatórios, os analistas são apresentados a uma tela em branco e podem arrastar ou selecionar métricas e dimensões. À medida que os elementos de dados são adicionados à tela, os dados assumem a forma de uma tabela com colunas e linhas. Essa abordagem foi popularizada por ferramentas de BI como o Tableau e produtos de análise digital como Adobe e Google Analytics.

O benefício das interfaces de relatórios de forma livre é que você tem controle total sobre a estrutura dos dados que deseja analisar. Você pode criar vários níveis de detalhamento e muitas vezes pode adicionar filtros para restringir os dados por valores de dimensão. Os analistas de energia gostam desse modelo porque ele oferece muita liberdade e a capacidade de fazer algumas consultas avançadas sem precisar saber SQL.

Relatório Prescritivo

Outra interface de relatório de análise é o relatório prescritivo. Esse modelo fornece uma estrutura para o tipo de análise que está sendo feita e permite que os analistas insiram os itens necessários para a execução do relatório. Eu gosto de pensar nesse modelo como uma abordagem de “preencher as lacunas” da reportagem. Cada tipo de relatório sabe que tipo de métricas, eventos ou dimensões/propriedades são necessários e permite que os analistas escolham entre as opções qualificadas para criar o relatório.

Essa abordagem pode ser limitante em alguns aspectos, mas também evita que os analistas cometam muitos erros devido à sua estrutura.

Importações de planilhas

Não importa o quão avançado seja o campo de análise, sempre haverá aqueles que simplesmente querem fazer suas análises em planilhas. Muitos produtos de análise fornecem maneiras de baixar ou exportar dados para planilhas para que os analistas possam manipular os dados conforme necessário. As planilhas, especialmente o Microsoft Excel, tendem a ser o menor denominador comum para os analistas. No entanto, uma das desvantagens de usar planilhas é que elas são mais difíceis de compartilhar, colaborar e podem ter problemas de controle de versão.

SQL/R/Python

Aqueles que se consideram “cientistas de dados” geralmente preferem analisar dados via SQL ou por meio de linguagens de relatórios como R ou Python. Essas interfaces de programação e linguagens oferecem muita flexibilidade e podem ser usadas para fazer análises personalizadas e avançadas. Embora mais consumidores de dados estejam aprendendo esses idiomas atualmente, eles ainda são difíceis de dimensionar, especialmente em grandes empresas.

Impactos das interfaces de relatórios

Assim, com todas as opções disponíveis para fazer análises, como as organizações devem escolher a certa para elas? Como de costume, não há uma resposta certa, mas o seguinte fornecerá algumas coisas para você considerar ao fazer uma escolha. Além disso, é importante ter em mente que muitas organizações precisarão usar mais de um para diferentes públicos internos.

Tipos de consumidor de dados

A maioria das organizações tem diferentes tipos de consumidores de dados. Muitas vezes, há uma equipe de análise central que faz análises diariamente e há outras que são usuários de dados mais casuais. Os usuários de dados casuais podem incluir executivos ou pessoas da empresa que ocasionalmente precisam ver dados para informar suas decisões. Um exemplo disso pode ser um proprietário de produto que deseja ver visualizações semanais ou mensais do site dos produtos que gerencia.

As necessidades de relatórios da equipe principal de análise serão muito mais avançadas do que as dos usuários casuais. A equipe de análise principal provavelmente desejará fazer vários detalhamentos de dados e filtrar dados por várias dimensões/propriedades. Para eles, ter uma interface de relatório de forma livre ou usar uma linguagem de programação pode ser a melhor opção. Mas essas interfaces avançadas de relatórios geralmente podem ser intimidantes ou esmagadoras para pessoas que realizam análises apenas ocasionalmente. Os executivos podem querer apenas ver painéis de alto nível de uma ferramenta de BI.

É importante entender o nível de habilidade de cada consumidor de dados internos e garantir que cada um receba uma interface de relatório que seja adequada às suas necessidades e aptidão. Já vi muitas organizações falharem ao tentar usar uma abordagem de “tamanho único” e forçar todos os consumidores de dados a usar a mesma interface de relatórios de análise. Nessas situações, é comum para a equipe de análise central, que se inclina mais avançada, supor que todos os consumidores de dados podem dominar interfaces de relatórios que são muito complexas ou muito confusas para consumidores de dados casuais. Mesmo quando interfaces de relatórios mais avançadas são selecionadas para consumidores de dados mais novatos, estes últimos acham difícil detalhar os dados e encontrar as respostas de que precisam sem precisar de assistência. Eu mesmo tentei treinar consumidores de dados casuais em interfaces de relatórios avançados apenas para vê-los lutar para aprendê-los. Nesses casos, achei mais útil fornecer várias interfaces de relatórios de análise personalizadas para o público consumidor de dados.

Modelos de entrega do Analytics

No mundo analítico, existem vários modelos disponíveis para a realização de análises. Algumas organizações usam um modelo centralizado em que os consumidores de dados enviam solicitações para análise e a análise é feita por uma equipe centralizada. Outras organizações tentam usar uma abordagem descentralizada na qual se espera que todos conduzam sua própria análise (geralmente chamada de democratização de dados). Existem também abordagens híbridas que aproveitam o modelo centralizado para alguns tipos de análise e uma abordagem descentralizada para outros (você pode ouvir uma palestra sobre esse tópico aqui). Existem prós e contras de cada abordagem e esta é outra situação em que diferentes abordagens serão melhores ou piores para diferentes organizações.

Mas uma coisa que tenho visto é que erros cometidos no modelo de relatórios podem impactar negativamente o modelo de entrega de análises. Por exemplo, vamos imaginar que a Acme Corp, como organização, opte por usar um modelo descentralizado para análise. Mas, ao mesmo tempo, eles decidem padronizar a interface de relatórios de análise de forma livre. Com o tempo, eles descobrem que muitos consumidores de dados casuais lutam para entender os dados em sua implementação e como relatar sobre eles. Lentamente, a equipe principal de análise começa a receber e-mails e solicitações de ajuda. No início, eles podem acompanhar e tentar fazer treinamento adicional, mas logo percebem que os consumidores de dados não são capazes de autoatendimento e o número de solicitações se torna esmagador. Nessa situação, que já vi muitas vezes, havia claramente uma incompatibilidade entre a interface de relatórios e os consumidores de dados e essa incompatibilidade quebrou o modelo geral de entrega de análises. É por isso que acredito que existe uma relação direta e importante entre a interface de relatórios de análise e o modelo de entrega de análise.

Encontrando o ponto doce

Em meus vinte anos ajudando organizações com análises, raramente descobri que uma interface funcionaria para todos os tipos de consumidores de dados e todos os modelos de entrega de análises. Tenho visto um sucesso limitado com o treinamento de produtos analíticos para consumidores de dados casuais, pois se você não usa uma ferramenta com frequência, é difícil aprender. Acho que as melhores organizações dedicam tempo para entender sua cultura corporativa, as habilidades dos diferentes tipos de consumidores de dados e usam ambos para escolher sua interface de relatório de análise e modelo de entrega de análise. Fiz muitos workshops e treinamentos com organizações para ajudá-las a descobrir quais interfaces e modelos funcionarão melhor para elas. Também encorajo as organizações a experimentar periodicamente novas interfaces de relatórios para diferentes tipos de consumidores de dados para ver se um deles “clica” mais do que o que está usando atualmente. Na Amplitude, tentamos criar uma interface de relatórios que seja fácil para consumidores de dados casuais e estamos orgulhosos do fato de que em algumas organizações centenas de pessoas atendem diariamente. É por isso que criamos maneiras fáceis para as equipes de análise aproveitarem o trabalho feito em outros fornecedores de análise (Google e Adobe) para enviar dados ao Amplitude para que eles vejam se nossa interface de relatórios pode complementar o que a equipe principal de análise usa.

No final das contas, todas as organizações querem usar os dados com eficiência e diminuir o tempo que levam para transformar dados em insights. Escolher a interface de relatórios de análise certa para seus diferentes consumidores de dados é um grande passo para melhorar o valor geral do programa de análise.