Dados entregues aos clientes do SaaS

Escreva a transformação uma vez com o id do tenant como coluna e leia a lista de tenants de uma tabela de configuração (id, nome de exibição, camada de destino, data de início, fontes ativas, parâmetros como janela e tarifa). Cliente novo é uma linha nessa tabela. Cópias só se justificam quando o cliente tem fonte própria que não existe para os outros, e mesmo assim chamando o mesmo cálculo.

Na Nekt, permissão se dá por camada. Entregue cada cliente numa camada própria (ou num destino próprio) e nunca numa tabela compartilhada filtrada só na leitura. A tabela consolidada com todos os tenants fica numa camada interna, visível só para o time do SaaS.

Tabelas que têm o id do tenant são filtradas direto. Tabelas filhas sem essa coluna (itens, mensagens, insights) entram pela chave estrangeira da tabela dona; tabelas de referência entram só com as linhas que os registros do tenant usam. Confira que toda tabela copiada tem caminho até o tenant.

Mantenha uma lista fechada de colunas que nunca saem: client_secret, access_token, refresh_token, senhas, chaves de API e credenciais de integração. Exclua-as em toda tabela entregue, inclusive nas que vêm de conector padrão, como o client_secret do payment intent do Stripe.

Receita atribuída a uma mensagem, campanha ou automação conta só pedidos do mesmo cliente final feitos depois do envio e dentro da janela combinada (um caso real usa 3 dias). Cada pedido é atribuído a um único disparo, o mais recente antes dele. Valores em centavos são divididos por 100 uma vez.

Algumas integrações de pedido mandam só a data, com hora 00:00:00. Para cada tenant, olhe os últimos três pedidos: se todos têm hora, minuto e segundo zerados, trate o campo como data e compare a janela em dias; senão, como timestamp. Guarde a decisão na configuração do tenant.

Se falta um insumo (tarifa não cadastrada, medidor offline, integração parada), o resultado é nulo com uma coluna de motivo, nunca zero. Distinga erro de dado de decisão deliberada: um cliente que contratou só a medição em kWh tem economia em reais nula e sem alerta, não um alerta de tarifa incompleta.

Dias sem leitura podem ser preenchidos pela média do mesmo dia da semana no período real mais próximo, mas a linha leva uma marca (medido ou projetado). Nunca use um valor fixo de preenchimento. A linha de base de economia é a média por dia da semana na janela de monitoramento antes da automação; se a operação muda (por exemplo, o número de equipamentos), abra um novo regime de linha de base com data de corte.

Para provar impacto de uma funcionalidade, divida os itens do cliente em com e sem ela a partir da lista que o próprio cliente mantém, e compare visualizações, carrinho, compra e receita no mesmo período. O cruzamento é pelo id do item; sem id, pelo nome que começa com o nome cadastrado, ficando com um único casamento, o mais específico (nome mais longo).

Quando o produto grava tabelas derivadas próprias (prefixos como dw_ ou dwt_) ao lado das tabelas de aplicação, use as de aplicação, que são a fonte da verdade. Registre no context document as tabelas cujo nome engana (por exemplo, uma tabela chamada crédito que guarda cobranças), filtre soft delete (deletedAt nulo) e tire do relatório métricas cujo status nunca é preenchido na origem.