Conector personalizado Data Studio: quando criar, como funciona e quanto custa

O que é um conector personalizado do Data Studio?

É um código que ensina o Data Studio a fazer login em uma fonte, quais campos ela oferece e como buscar linhas sob demanda. A documentação para desenvolvedores do Google chama esses conectores de conectores da comunidade (o nome se manteve durante os anos de Looker Studio), e eles são escritos em Google Apps Script sobre a Connector API do Google.

Todo conector precisa definir quatro funções. getAuthType informa ao Data Studio como o usuário faz login. getConfig pede ao usuário as configurações, como o ID de uma conta ou a exigência de um intervalo de datas. getSchema retorna a lista de dimensões e métricas com seus tipos. getData retorna as linhas dos campos que um gráfico realmente pediu. Depois de implantado, o conector aparece como uma fonte de dados, igual aos conectores nativos do GA4 ou do Google Ads, e os seus relatórios, campos calculados, filtros e envios agendados funcionam sobre ele normalmente.

A documentação do Google lista sete tipos de autenticação aceitos: OAuth 2.0, USER_PASS, USER_TOKEN, KEY, PATH_USER_PASS, PATH_KEY e NONE. As credenciais devem ficar nas propriedades do próprio usuário (PropertiesService.getUserProperties), e não digitadas em campos de configuração, para que uma chave de API nunca fique visível para outros editores do relatório.

Você precisa de um conector personalizado, de um conector parceiro ou de um pipeline de dados?

A maioria das equipes que me pede um conector personalizado acaba precisando de outra coisa. Antes de escrever qualquer código, submeto a fonte a três perguntas: já existe um conector para ela, quantos dados cada relatório precisa e qual deve ser a atualização desses dados?

O Data Studio se conecta de forma nativa ao GA4, Google Ads, Search Console, Sheets, BigQuery, YouTube, Campaign Manager 360, Display and Video 360, Ad Manager, Cloud SQL, MySQL, PostgreSQL, SQL Server e Redshift. Conectores parceiros de fornecedores como Supermetrics, Windsor.ai, Porter Metrics, Funnel, Power My Analytics e Catchr cobrem centenas de plataformas comuns por uma mensalidade. Criar um conector só faz sentido quando nenhum deles cobre a sua fonte, ou quando o fornecedor não consegue organizar os dados do jeito que os seus relatórios precisam.

A que um conector da comunidade pode se conectar?

A quase tudo que esteja acessível pela internet. A documentação do Google cita quatro caminhos: APIs web, bancos de dados JDBC, arquivos simples em CSV, JSON ou XML e outros serviços do Apps Script. Na prática, os pedidos que recebo se dividem em três grupos.

O primeiro é um sistema interno com API, como uma plataforma de pedidos, um motor de reservas ou um sistema de gestão de apólices. O segundo é um produto SaaS de nicho que os grandes fornecedores de conectores não atendem. O terceiro é uma empresa de software que quer que os próprios clientes façam relatórios sobre os seus dados no Data Studio, e é nesse caso que publicar o conector abertamente faz sentido.

• APIs REST internas com autenticação por chave ou token.
• Ferramentas SaaS setoriais com API, mas sem conector parceiro.
• Bancos de dados acessíveis via JDBC que os conectores nativos não cobrem.
• Arquivos CSV, JSON ou XML hospedados que são atualizados de forma agendada.

Como um conector personalizado do Data Studio é criado, passo a passo?

A programação em si é a parte menor. A maior parte do esforço está em acertar os campos, lidar com as particularidades da fonte e testar contra números em que a empresa já confia. Esta é a sequência que sigo.

• Escopo: listar os relatórios que o conector alimenta, cada campo de que eles precisam, o tipo de cada um e os totais para conciliar.
• Revisão da API: método de autenticação, paginação, limites de requisições, filtro por data e até onde vai o histórico.
• Autenticação: escolher o tipo de autenticação correspondente e guardar as credenciais nas propriedades do usuário, com erros claros quando uma chave expira.
• Configuração e esquema: definir as configurações que os usuários escolhem e um esquema tipado, com dimensões e métricas nomeadas do jeito que a sua equipe fala.
• getData: buscar apenas os campos e o intervalo de datas solicitados, paginar os resultados e mapeá-los para o esquema.
• Cache: guardar as respostas recentes para que carregamentos repetidos de gráficos não chamem a API de novo.
• Erros: retornar mensagens legíveis em vez de um gráfico em branco, porque o Data Studio não avisa quando um conector quebra.
• Implantação e testes: criar uma implantação com versão, conectá-la a um relatório de teste, conciliar os totais e depois compartilhá-la com a sua equipe.
• Entrega: código na sua própria conta Google, um documento curto com os campos e os limites e uma apresentação guiada.

Quais limites você deve considerar antes de criar um conector?

As cotas do Apps Script definem o teto, então compare-as primeiro com o seu volume de dados. Os números abaixo vêm da página de cotas do Apps Script e da referência do serviço de cache do Google, ambas consultadas em outubro de 2026. O número do URL Fetch é por dia para a conta que executa o script, o que pesa quando muitos leitores abrem um relatório ao mesmo tempo.

Os limites do próprio Data Studio continuam valendo. As combinações aceitam até 5 fontes de dados, apenas com junções de igualdade, e consultas muito grandes retornam erros de linhas demais. Um conector não elimina nenhum desses limites.

Por que os conectores personalizados são lentos e como mantê-los rápidos?

Cada solicitação de dados executa o Apps Script antes mesmo de consultar a sua fonte, e páginas com muitos gráficos e muitos leitores geram muitas solicitações. Em um tópico de julho de 2025 no fórum de desenvolvedores do Google (discuss.google.dev, intitulado Custom Connectors Very Slow), um desenvolvedor relatou que os gráficos levavam mais de 10 segundos para renderizar mesmo quando o conector retornava um resultado minúsculo e fixo no código, e o tópico ficou sem solução publicada. Isso confirma o que vejo: um custo fixo por chamada, multiplicado pelo número de gráficos por página.

As soluções são, em grande parte, decisões de design, e não código engenhoso. Menos gráficos por página, filtros que restringem a solicitação e respostas agregadas antes de chegarem ao Data Studio ajudam. Quando os dados são grandes ou a API é lenta, a melhor resposta é carregá-los no BigQuery de forma agendada e apontar o Data Studio para uma tabela particionada, o que tira o Apps Script do caminho de visualização por completo.

• Retorne apenas os campos e o intervalo de datas que o gráfico pediu.
• Agregue na API ou em uma camada de cache, e não linha por linha no Data Studio.
• Use cache por usuário e por consulta, para que visitas repetidas não chamem a API.
• Mantenha nas páginas apenas os gráficos que as pessoas realmente leem.
• Migre para uma carga agendada no BigQuery quando o volume ou o número de leitores crescer.

O conector deve ficar privado ou ser publicado na galeria?

Mantenha-o privado se ele ler os dados da sua própria empresa. A documentação do Google confirma que um conector pode ser compartilhado diretamente com qualquer usuário, o que é tudo de que uma equipe interna de relatórios precisa, e isso evita um processo de revisão pensado para produtos públicos.

Publique-o se você for uma empresa de software e quiser que os clientes façam relatórios sobre os seus dados. Os requisitos do Google para conectores parceiros são específicos: uma implantação de produção, acesso de visualização compartilhado com os endereços de revisão do Google, uma página hospedada no seu próprio domínio com política de privacidade e termos de uso, uma página de suporte em vez de um link de e-mail, um logotipo hospedado sob o seu controle, escopos OAuth explícitos, a verificação do cliente OAuth concluída e um conector finalizado, e não em beta. Reserve tempo para essa revisão além do desenvolvimento.

Quanto custa um conector personalizado do Data Studio?

O desenvolvimento é o custo principal, e os custos de operação costumam ser pequenos. O Apps Script em si não tem taxa de licença dentro das cotas acima, e o Data Studio é gratuito para criadores e leitores. O Data Studio Pro, a US$ 9 por usuário por projeto por mês, só é necessário se a sua equipe quiser espaços de trabalho Pro e conteúdo de propriedade da organização, e não para usar um conector.

O que muda o preço do desenvolvimento é a fonte, não os gráficos. Uma API com autenticação por chave, JSON limpo e filtro por data é um trabalho modesto. OAuth, paginação profunda, nomes de campos inconsistentes, histórico ausente ou limites rígidos de requisições acrescentam trabalho, e um envio para a galeria acrescenta mais. Como referência, valores publicados por agências como a halo-lab.com colocam consultores freelancers de Data Studio entre US$ 100 e US$ 200 por hora, mas um preço fixo sobre um escopo escrito é mais fácil de comparar.

Faça a comparação com honestidade. Se um conector parceiro já cobre a sua plataforma, a assinatura costuma sair mais barata do que criar e manter o seu próprio código, e eu digo isso na revisão.

Erros comuns e quando não criar um conector personalizado

A maioria dos projetos de conector que fracassam tem as mesmas causas, e nenhuma delas é o código. São problemas de escopo e de responsabilidade que aparecem meses depois, geralmente quando alguém sai da empresa ou a API de origem muda.

Às vezes, a resposta certa é não ter conector nenhum. Para uma corretora de seguros australiana que recebia arquivos .xls bagunçados de várias seguradoras, um projeto que conduzi na Greenwolf Tech Labs automatizou a chegada dos arquivos ao Google Drive, mapeou-os em uma planilha central do Google Sheets com as regras de negócio aplicadas e alimentou o dashboard a partir dela. A preparação do relatório caiu de 4 a 5 horas para menos de 5 minutos, e a precisão dos relatórios subiu de cerca de 75% para 99%. Um conector não teria resolvido aqueles arquivos; um pipeline resolveu.

• Criar um conector para uma plataforma que um conector parceiro já atende.
• Buscar linhas brutas e agregar no Data Studio, o que esgota as cotas rapidamente.
• Deixar o script na conta pessoal de um prestador de serviço.
• Colocar chaves de API em campos de configuração em vez de nas propriedades do usuário.
• Pular a conciliação, de modo que ninguém confia no primeiro relatório.
• Não crie um conector quando a fonte for uma exportação de arquivo, os dados forem muito grandes ou ninguém for manter o código depois do lançamento.

Como trabalho em projetos de conectores

Você trabalha diretamente comigo, da primeira revisão até a entrega. Começo lendo a documentação da sua API ou uma exportação de exemplo e os relatórios que você quer, e depois recomendo o caminho mais barato que vai se sustentar: um conector parceiro, um conector personalizado ou um pipeline em Sheets ou BigQuery. Você recebe um orçamento fixo para esse caminho depois de uma revisão gratuita, com os custos de operação listados à parte.

O código, as implantações e as fontes de dados ficam na sua conta Google desde o primeiro dia, então nada depende de eu continuar envolvido. Se o conector alimentar um novo dashboard, eu também o construo, e se um relatório existente quebrou depois de uma mudança na fonte, posso consertá-lo.