Tabelas finais de mídia, funil, GA4 e atendimento
Uma tabela por tela, filtrada por cliente e pseudonimizada
Carga por upsert no schema de entrada do app
Portal do cliente e agente de IA por cliente
O que resolve
- Cada tela do portal lê uma tabela pronta, com nome, colunas e chave combinados.
- Nenhum cliente vê dado de outro, nem quando a fonte é compartilhada.
- Telefone, e-mail e documento chegam ao app pseudonimizados, nunca crus.
Perguntas de negócio que responde
Faça estas perguntas ao seu agente quando o caso estiver pronto.
O que você precisa
- As tabelas finais de mídia e funil já modeladas na Nekt
- Um destino configurado (Postgres do app, Supabase ou endpoint HTTP) com schema de entrada próprio
- O registro que liga cada cliente às suas contas e à sua camada
O que você recebe
- Uma tabela de entrega por tela, com grão e chave de upsert declarados
- Carga disparada pelo fim da fonte, com data da última atualização em cada linha
- Isolamento por cliente e pseudonimização feitos antes de o dado sair da Nekt
- Uma tabela por cliente quando cada cliente tem o próprio agente de IA
Onde ativar
Cada tela lê a sua tabela no banco do app, atualizada ao fim da fonte.
Uma tabela por cliente na pasta dele, para o agente de cada cliente enxergar só o próprio dado.
Aviso quando uma tabela de entrega passa do atraso aceitável da sua fonte.
A modelagem já existe nos outros casos. O trabalho está em fechar o contrato de cada tela com quem constrói o app e em manter os filtros de isolamento. O detalhado traz as regras de negócio, as armadilhas e o teste de aceitação. Ou mande tudo direto para o seu agente com o MCP da Nekt.
O app do cliente não consulta a Nekt em tempo real: a Nekt empurra o dado pronto para o banco do app. Sem um contrato por tela, qualquer ajuste de coluna deixa a tela vazia, o upsert com chave incompleta sobrescreve linhas e um filtro esquecido numa fonte compartilhada entrega ao cliente dado de outro negócio. Nada disso gera erro: o destino continua rodando verde.
Como costuma ser feito, e a regra
Cada linha é um erro que já aconteceu na prática.
Cada tela lê uma tabela de consumo com nome fixo (por exemplo, prefixo mart_) e colunas explícitas e tipadas. O nome e as colunas são o contrato com o app. Coluna nova se adiciona; coluna existente nunca se renomeia nem muda de tipo; mudança de grão vira tabela nova. Normalização de fonte fica em tabelas stg_, sem regra de negócio.
Declare a chave de upsert com todas as colunas do grão. Na tela de anúncios, a chave é data, cliente, plataforma, conjunto e anúncio: o conjunto entra porque no Google o mesmo anúncio pode estar em mais de um grupo. Rode a checagem de unicidade da chave antes de cada carga.
O destino escreve num schema de entrada (staging ou landing). Os triggers e as regras de acesso do app (RLS) fazem deduplicação, derivação e exposição a partir dali. Escrever direto no schema público atropela essa lógica e deixa dado cru visível para o front.
Fonte compartilhada (conta do Google Meu Negócio com vários locais, Business Manager com várias contas) precisa de filtro pelo identificador oficial do cliente (location_id, account_id do registro) dentro da própria transformação de entrega. Um filtro esquecido não dá erro: entrega ao cliente os dados de dezenas de negócios. Quando cada cliente tem o próprio agente de IA, grave uma tabela por cliente na pasta dele, para que o agente só enxergue o seu dataset.
A pseudonimização acontece na Nekt, não no app. Telefone vira hash do número normalizado (só dígitos) mais os últimos 4 dígitos; e-mail e documento viram hash; endereço e campos que o painel não usa não saem. Se uma tela precisa do dado cru, a discussão é sobre permissão no app, não sobre a consulta.
Ligue cliente e camada por uma coluna de identidade no cadastro (por exemplo, client_slug ou a camada da Nekt registrada no portal), com no máximo um cliente por camada. Nomes de camada não podem ser renomeados e divergem do nome comercial do cliente.
A transformação de entrega dispara no fim da execução da fonte que ela lê, para nunca rodar antes de a extração terminar. Horário fixo só onde o destino tem janela própria. Gatilho manual não é pipeline vivo e precisa estar marcado como tal.
Toda tabela de entrega carrega a data e hora da carga e a data máxima do dado. A cópia do cadastro do portal na Nekt pode ter até 24 horas de atraso: antes de acusar divergência entre portal e Nekt, confira a última execução da fonte.
As colunas de métrica têm os mesmos nomes da tabela de mídia da carteira (spend, clicks, leads, conversions), para o app reaproveitar o mapeamento. Cada plataforma preenche as suas colunas e deixa as da outra nulas, nunca zero. Valores já em reais, convertidos antes da entrega.
A imagem do anúncio vem de adimages.permalink_url no Meta, descrito como link permanente. Os demais links de miniatura expiram. Marque na linha se a miniatura é permanente, para o app saber quando buscar de novo.
Do warehouse à tela
Camadas que separam a regra de negócio do que o app lê.
Definições
Armadilhas que já aconteceram
Uma coluna foi renomeada na tabela de entrega. O destino continuou entregando e o app passou a ler campo nulo, sem nenhum erro.
Trate a tabela como contrato: adicione colunas, nunca renomeie.
A conta do Google Meu Negócio da agência cobria dezenas de locais. Sem o filtro por location_id, o painel de um cliente mostraria avaliações de todos.
Filtre pelo id oficial do cliente dentro da transformação de entrega.
No Google, o mesmo anúncio aparecia em dois grupos. Com a chave sem o grupo, a segunda linha apagava a primeira.
Inclua o conjunto ou grupo na chave de upsert.
Edições feitas no portal depois da extração diária só apareciam na Nekt no dia seguinte, e a contagem de clientes e o MRR divergiram por um dia.
Confira a última execução da fonte antes de acusar divergência.
O painel de um cliente dependia de um conector registrado na camada da própria agência. Quando ele falhou, a investigação olhou só a camada do cliente.
Documente a camada de origem de cada tabela de entrega.
Dois destinos ativos entregavam o mesmo dado ao mesmo app, um mais novo que o outro. Mudar o errado não teve efeito.
Um destino por tabela de entrega, com o antigo desligado.
Teste de aceitação
O caso está pronto quando todos os itens passam.
- Para um cliente e um mês fechado, o investimento somado na tabela de entrega é igual ao da tabela de mídia da carteira (diferença zero).
- A chave de upsert não se repete em nenhuma linha da tabela de entrega.
- Cada destino recebe exatamente um cliente distinto, ou só os clientes autorizados para aquele app.
- Nenhum telefone entregue tem mais de 4 dígitos legíveis.
- A data da última carga de cada tabela está dentro do atraso aceitável da sua fonte.
Pacote para o agente
Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.
Portal do cliente - O portal não lê a Nekt em tempo real. A Nekt entrega tabelas de consumo (mart_<tela>) no schema de entrada do banco do app, por upsert. - Cada tabela de entrega é um contrato: nome, colunas, grão e chave fixos. Não renomeie colunas; mudança de grão é tabela nova. - Chave de upsert da tela de anúncios: date, client, platform, adset_id, ad_id. - O destino nunca escreve no schema public do app. - Toda tabela de entrega é filtrada pelo id oficial do cliente (account_id, location_id) dentro da transformação. Fonte compartilhada sem filtro é vazamento. - Telefone sai como hash do número normalizado mais os últimos 4 dígitos. E-mail e documento saem em hash. Endereço não sai. - O cliente é ligado à camada pela coluna de identidade do cadastro, nunca pelo nome. - Para perguntar se o portal está atualizado, leia a data da última carga e a data máxima do dado da tabela de entrega. - Métricas com nome único entre plataformas; nulo onde a plataforma não mede. Exceções por cliente: - <cliente>: destino <destino>, schema <schema>, telas <lista de tabelas mart_>. - <cliente>: avaliações filtradas por location_id <id> a partir da conta compartilhada da agência.
Construa no meu workspace Nekt o caso "Portal do cliente" seguindo as regras em https://academy.nekt.com/industrias/agencias/portal-do-cliente.md. 1) Encontre as tabelas de origem e confirme as colunas usadas pelas regras. 2) Crie uma transformação no grão indicado aplicando todas as regras. 3) Rode o teste de aceitação e me mostre o resultado de cada item. 4) Crie o context document do caso no workspace, com as exceções dos meus clientes em aberto para eu preencher.
Variações
App sem banco acessível: envie a tabela em lotes (ex.: 1.000 linhas por chamada), com o token guardado no cofre de segredos da Nekt, nunca no código.
Para reaproveitar um painel pronto no Looker, entregue a tabela com os mesmos nomes de campo do conector que alimentava o template.
O mesmo padrão serve para telas além do marketing, como avaliações, atendimento ou renovação, sempre com uma tabela por tela.