Compare ETL e ELT na consolidação de dados de vídeo, eventos e sistemas corporativos para análises confiáveis de Business Intelligence.
Confira!
ETL e ELT são duas arquiteturas de preparação de dados que podem sustentar uma solução de Business Intelligence. No ETL, os dados são extraídos, transformados e depois carregados no destino analítico. No ELT, os dados são carregados primeiro em um ambiente capaz de processá-los, e a transformação ocorre nesse ambiente. Essa diferença orienta decisões sobre capacidade, rastreabilidade e custos, mas não determina sozinha a qualidade de um indicador.
Em operações com vídeo, eventos de segurança, vendas, estoque e equipes, cada sistema produz informações em formatos, frequências e condições diferentes. Uma câmera registra passagens; um sistema comercial registra transações; um VMS apresenta eventos e alarmes. O projeto de Business Intelligence precisa estabelecer como essas fontes se relacionam, quais números podem ser comparados e quais são apenas estimativas. Escolher entre ETL e ELT antes de definir essas regras coloca o meio tecnológico à frente da decisão que deveria orientar o projeto.
Nenhum dos métodos é sinônimo de dashboard pronto. A solução precisa de fontes confiáveis, governança, modelos de análise, filtros e critérios de aceitação definidos conforme a necessidade do cliente.
O que muda entre ETL e ELT
No ETL, a transformação ocorre antes da carga no repositório analítico de consumo. Uma camada intermediária pode corrigir formatos, padronizar identificadores, validar registros, retirar duplicações e rejeitar valores inválidos. Esse arranjo permite controlar a entrada em um destino com recursos limitados de processamento e torna explícitas algumas etapas de homologação. A eliminação de registros, contudo, precisa gerar evidência: descartar silenciosamente eventos incompletos pode melhorar artificialmente um indicador.
No ELT, o destino recebe registros antes da aplicação de boa parte das regras analíticas. Um data warehouse ou lakehouse capaz de executar transformações permite reprocessar históricos e testar novas hipóteses sem pedir novamente todos os dados aos sistemas de origem. Essa vantagem depende de capacidade de processamento, controles de acesso e política de retenção. Não é justificativa para conservar indefinidamente dados que não têm finalidade documentada.
O Azure Architecture Center, da Microsoft, diferencia essas abordagens pelo local da transformação e recomenda selecionar conforme requisitos. ETL pode ser apropriado quando há necessidade de processamento externo ou validação anterior ao destino. ELT tende a ser útil em destinos escaláveis que podem explorar registros retidos e múltiplas visões. Uma solução pode combinar pré-tratamento e transformações posteriores: a arquitetura híbrida não constitui uma terceira tecnologia, mas uma divisão deliberada de responsabilidades.
| Critério | ETL | ELT |
| Transformação predominante | Antes da carga analítica | Dentro do ambiente de destino |
| Flexibilidade de reprocessamento | Depende da retenção de dados de origem | Favorecida quando a origem é preservada |
| Exigência técnica | Processamento na camada intermediária | Capacidade de processamento no destino |
| Controle crítico | Rejeições e alterações antes da carga | Segurança e retenção de registros originais |
A pergunta de negócio define as fontes
Uma rede de varejo pode querer decidir em que horários aumentar equipes, quando investigar perdas de produtividade ou quais lojas exigem revisão de layout. A resposta pode demandar contagem de entradas, valor e quantidade de transações, disponibilidade de vendedores, calendário de promoções e informações de atendimento. Não se justifica coletar tudo o que cada plataforma é capaz de exportar: mais atributos criam custos, riscos e possibilidades de interpretação incorreta.
Cada decisão deve ser vinculada a um indicador, uma fonte autorizada e uma ação possível. O número de passagens por câmera não equivale necessariamente a visitantes únicos. Uma transação não representa, obrigatoriamente, um cliente distinto. Alarmes gerados não demonstram, por si, incidentes confirmados. O modelo de Business Intelligence precisa preservar essas distinções ao construir indicadores, em vez de usar rótulos gerenciais para valores que só representam medições técnicas.
Uma solução que relaciona vídeo, eventos e dados corporativos precisa de interfaces com identificação, temporalidade e qualidade conhecidas. A engenharia da integração determina como o valor de cada registro será preservado até a construção dos indicadores.
A periodicidade é outro requisito de negócio. Comparações semanais de desempenho podem depender de fechamento estável de vendas; alertas críticos exigem ação operacional no sistema competente. Um dashboard gerencial não precisa nem deve substituir sistemas responsáveis por comandos de segurança ou proteção de pessoas. O projeto define quais resultados exigem atualização quase imediata e quais dependem de conciliação posterior.
Vídeo, VMS e dados da rotina operacional
Os analíticos de vídeo podem produzir contagens, eventos de linha, permanência estimada, classificação de objetos e alertas. A qualidade depende de posição de câmera, iluminação, oclusões, licenças, versão do algoritmo e regras aplicadas. O ONVIF Profile M descreve interfaces para metadados e eventos em produtos conformes, mas a existência de um protocolo não comprova que todo recurso analítico esteja disponível ou funcionando corretamente em um projeto específico.
Um VMS pode concentrar câmeras, gravações, alarmes e estados de eventos, fornecendo relatórios e dashboards operacionais conforme suas funcionalidades. Essa plataforma pode constituir uma origem relevante de Business Intelligence, mas a análise empresarial também utiliza vendas, gestão de pessoas, ERP, manutenção, estoque, atendimento e calendário comercial. O conteúdo sobre Business Intelligence e dados de vídeo trata dessa contribuição das fontes para uma solução personalizada.
O inventário de fontes deve informar quem é o responsável pela origem, qual identificador pode ser exportado, quais períodos estão disponíveis, qual é a taxa de atualização e quais dados exigem controle especial. Fontes que registram pessoas identificáveis precisam de avaliação de finalidade e proteção; nem toda informação existente no sistema operacional deve circular pela base analítica.
| Fonte | Dado disponível | Limite de interpretação |
| Video Analytics | Contagem ou evento | Detecção não equivale a visita única |
| VMS | Alarme e estado | Alarme não equivale a ocorrência confirmada |
| PDV | Transações | Venda não equivale a cliente único |
| Controle de acesso | Credencial e porta | Acesso autorizado não comprova permanência |
| Gestão de equipe | Escala e jornada | Escala prevista não equivale a presença real |
Granularidade e modelagem dos indicadores
Granularidade é o fenômeno representado por cada registro. Uma passagem individual, uma transação comercial e um consolidado por hora têm granularidades diferentes. Se a tabela de vendas for relacionada diretamente a cada evento de câmera no mesmo dia, uma junção mal projetada pode repetir o valor da transação diversas vezes. Um painel pode exibir resultados com aparência consistente e números inflados. O tratamento correto define a unidade de observação antes de realizar cruzamentos.
Um modelo dimensional organiza fatos e dimensões. Fatos incluem transações, contagens e ocorrências; dimensões descrevem loja, período, área, tipo de evento ou unidade de negócio. A orientação da Microsoft sobre modelos em estrela destaca relações coerentes e granularidade uniforme por tabela. Uma mudança de código da loja ou reorganização regional também precisa ser tratada para que comparações históricas não sejam alteradas silenciosamente.
Indicadores devem possuir ficha técnica com nome, finalidade, fórmula, periodicidade, fonte, unidade, responsável, tolerância e limitações. Uma taxa de conversão calculada dividindo transações por fluxo estimado de entradas é um indicador operacional construído sob hipóteses específicas; não é prova de quantas pessoas distintas compraram. A formulação e as ressalvas devem estar disponíveis a quem decide. Consistência de nomenclatura entre dashboards evita interpretações diferentes do mesmo número.
Transformações de eventos: horários, duplicidade e identidade
Equipamentos e aplicações podem registrar horário da ocorrência, horário do recebimento e horário do processamento. Esses instantes devem ser diferenciados. Um evento atrasado que chega após a virada de turno pertence à janela da ocorrência, mas pode exigir atualização do consolidado anterior. Fuso horário, sincronização de relógios e calendário comercial são parte do contrato de dados. Sem essas definições, o desempenho de turnos ou filiais pode parecer distinto somente por atraso de transmissão.
Conectores e filas podem retransmitir registros após perda de comunicação. Uma chave estável de evento permite processamento idempotente: o mesmo registro recebido repetidamente não deve aumentar o contador final. Se o equipamento não fornece identificador confiável, a deduplicação precisa adotar critérios explícitos e ensaiados, pois dois eventos legítimos próximos no tempo não podem ser descartados por parecerem semelhantes.
Códigos usados por origens diferentes também exigem mapeamento. “Loja 14”, “LJ014” e um identificador interno no VMS podem apontar ao mesmo estabelecimento. A tabela de correspondência deve ter autoridade, responsável por alterações e histórico quando necessário. A engenharia de dados não se encerra quando uma API responde corretamente: o significado do evento precisa sobreviver a cada transformação até o dashboard.
Arquitetura de dados do ingresso ao dashboard
Uma solução pode separar fontes, camada de ingestão, armazenamento, harmonização, modelo semântico e visualização. Essa separação é lógica: pode ser implementada em ferramentas diferentes ou dentro de uma mesma plataforma, desde que as responsabilidades permaneçam distinguíveis. O registro deve conservar sua proveniência e permitir identificar a origem, o conector, a versão de regra aplicada, a janela de atualização e os processos que modificaram seus valores.
O ETL posiciona transformações principais antes da carga analítica; o ELT usa o ambiente de destino para executá-las. Em ambos, versões de esquema e regras precisam ser controladas. Uma atualização de firmware que altera a classificação de um evento, por exemplo, não pode passar despercebida. O sistema de supervisão deve detectar falhas de ingestão e anomalias, distinguir atraso de falta de movimento e permitir reprocessar períodos afetados sem perder auditoria.
A Integração de Sistemas ajuda a estabelecer interfaces e fluxos adequados às fontes. O objetivo de Business Intelligence vai além da conexão: comprovar que os números resultantes são reprodutíveis e que cada transformação tem critério definido.
Atualização incremental e disponibilidade
Volumes crescentes podem tornar custoso recalcular todo o histórico a cada ciclo. Uma política incremental processa registros novos ou modificados e preserva dados anteriores quando apropriado. A documentação da Microsoft sobre atualização incremental indica o uso de filtros temporais e particionamento em cenários suportados. Isso depende das condições concretas da fonte e da plataforma; uma API não assegura atualização em tempo real nem desempenho ilimitado.
A política precisa incluir correções tardias. Estornos comerciais, eventos retransmitidos depois de falhas e mudanças retroativas de escala podem chegar após o fechamento inicial. É necessário definir janelas de retificação, identificação de dados alterados e transparência para quem consultou indicadores que serão recalculados. Um processamento rápido que ignora correções pode ser menos útil do que uma atualização mais lenta, porém confiável.
A disponibilidade também tem camadas: a câmera pode funcionar enquanto o conector falha; o repositório pode estar atualizado enquanto o painel consulta um cache antigo. O projeto precisa especificar medições de integridade, tempo de atualização e comportamento diante de indisponibilidade parcial. Para decisões táticas, a indicação da hora da última atualização é parte do significado do indicador.
Testes de qualidade e critérios de aceite
Um pipeline não está comprovado porque conseguiu carregar linhas no repositório. O aceite deve comparar amostras representativas da origem com valores resultantes, verificar duplicações, perdas, períodos vazios, dados fora de ordem, conversão de unidade e mudança de esquema. Testes de falha precisam avaliar retomada de comunicação, reprocessamento e rastreabilidade das correções. Evidência deve estar vinculada à versão do processo ensaiado.
O tratamento de dados de vídeo demanda atenção adicional. Uma contagem pode variar por alteração de posição de câmera, iluminação, sombra ou atualização de algoritmo. Esse desvio não corresponde necessariamente a mudança do comportamento da operação. Séries históricas precisam registrar quebras metodológicas para não sugerir tendência comercial inexistente. Amostras independentes e testes de cobertura ajudam a conhecer limites e estabelecer tolerâncias.
Indicadores de qualidade podem mostrar completude da janela, disponibilidade da origem e proporção de registros rejeitados. Isso permite distinguir uma loja sem movimento de uma loja sem dados. A apresentação gerencial precisa sinalizar quando resultados não são comparáveis, mesmo que o sistema possua números para ambos os casos.
Privacidade, retenção e acesso
Dados captados por vídeo, controle de acesso e outras plataformas podem estar ligados a pessoas identificadas ou identificáveis. A LGPD exige considerar finalidade, adequação, necessidade, segurança e demais princípios aplicáveis. A ANPD esclarece que o tempo de tratamento depende das circunstâncias e da finalidade: não há uma regra única que autorize armazenar todos os registros por período indeterminado.
Em ELT, conservar dados originais pode favorecer reprocessamento, mas exige política explícita de retenção, acesso e eliminação. Em ETL, a transformação anterior ao destino não elimina a necessidade de proteger a área intermediária. Agregação, minimização e segregação de papéis devem seguir a necessidade do uso. O desenho precisa considerar ambientes de desenvolvimento, logs, cópias de segurança e exportações, que também podem conter informações sensíveis.
A escolha do método de tratamento envolve decisões sobre retenção, segurança, escala e definição dos indicadores. Diagnosticar fontes, riscos e responsabilidades antes da contratação evita transferir inconsistências para um painel que aparenta precisão.
A possibilidade técnica de exportar uma credencial ou atributo não constitui autorização para transformar dados em acompanhamento individual de produtividade. O dashboard deve apresentar o nível mínimo necessário para seu público e finalidade legítima. Governança de dados é requisito de arquitetura, e não uma correção a ser feita depois que o painel já estiver operando.
Custos e contratação de Business Intelligence
Comparar ETL e ELT exige considerar o custo total: processamento, armazenamento, transferência, conectores, licenças, manutenção, monitoramento e reprocessamento. ELT pode utilizar processamento elástico do destino, mas consultas e transformações mal projetadas aumentam custos. ETL pode demandar infraestrutura intermediária, porém aliviar um repositório restrito. O dimensionamento deve observar volume por unidade, crescimento do histórico e quantidade de fontes.
O termo de referência deve estabelecer quais decisões serão apoiadas, quais indicadores são esperados, quais sistemas são autorizados a fornecer dados, quais exceções precisam ser tratadas e como a entrega será aceita. “Dashboard funcionando” é requisito insuficiente: é necessário provar origem, significado, qualidade e segurança dos resultados. Responsabilidades pela correção de dados e pela mudança de regras também devem constar no escopo.
As informações geradas por câmeras e analíticos só contribuem com Business Intelligence quando a captura atende aos critérios técnicos do uso pretendido. Cobertura, qualidade de imagem e testes em condições reais precisam estar alinhados às métricas que serão calculadas.
A Consultoria Técnica de Engenharia pode apoiar o diagnóstico de fontes, a comparação de alternativas e o desenho de critérios verificáveis antes da contratação da ferramenta. A escolha tecnológica deve decorrer das necessidades de análise, e não determinar quais perguntas a organização poderá fazer.
Exemplo aplicado: fluxo de lojas, vendas e regras de consolidação
Considere uma rede que recebe contagens por hora de cada entrada e transações consolidadas do ponto de venda. A primeira etapa consiste em mapear quais acessos foram instrumentados, a direção de cada contador, o horário de funcionamento e o momento de fechamento das vendas. Se o contador de uma porta não envia dados durante duas horas, não é aceitável completar a janela com zeros: zero representa ausência observada de passagens; ausência de registro significa que o resultado é desconhecido. Essa distinção precisa ser preservada na camada de fatos.
Um ETL pode validar e harmonizar o código da loja, rejeitar mensagens sem identificador e carregar totais horários elegíveis para análise. Um ELT pode carregar eventos detalhados em uma área controlada e materializar depois agregações por loja, dia e faixa horária. O segundo desenho facilita recalcular a série quando a regra de exclusão de funcionários muda, mas exige políticas explícitas de acesso e retenção. Nenhuma das alternativas dispensa testar o contador contra amostras independentes para conhecer seu erro.
Suponha, como exercício hipotético, que um ponto comercial registre 600 passagens estimadas e 90 transações em um período. O quociente de 15 transações por 100 passagens não representa automaticamente 15% de pessoas compradoras. Há possibilidades de múltiplas passagens, transações repetidas por cliente e observação incompleta de entradas. O painel deve explicitar o denominador e permitir investigar variações de estoque, campanhas e escala antes de concluir que houve melhora ou piora de desempenho.
Na expansão para outras lojas, é necessário definir a mesma granularidade e o mesmo calendário. Uma unidade com contador bidirecional e outra com medição apenas de entrada precisam ter indicadores distintos até que sua comparabilidade seja comprovada. O valor de Business Intelligence está na capacidade de contextualizar essas diferenças, não em ocultá-las para oferecer um ranking uniforme.
Matriz de decisão para selecionar a arquitetura
A escolha entre ETL e ELT precisa ser convertida em critérios verificáveis. Para cada conjunto de dados, o projeto pode registrar volume diário, tamanho médio do evento, frequência de atualização, qualidade do esquema de origem, necessidade de histórico bruto, capacidade do ambiente de destino e restrições de dados pessoais. A avaliação deve considerar cenários de expansão, porque uma prova de conceito de poucas câmeras pode não representar a quantidade de eventos produzida por uma rede inteira.
Se uma fonte fornece apenas totais horários estáveis e o objetivo é analisar tendências mensais, uma cadeia simples de validação e carga pode ser suficiente. Se diferentes gestores pretendem reconstruir métricas de eventos detalhados, a retenção controlada de registros de origem pode justificar processamento analítico posterior. Se os registros possuem atributos pessoais desnecessários, a minimização pode precisar acontecer antes da chegada ao repositório compartilhado, independentemente da terminologia escolhida para o pipeline.
Também devem ser testados custos de reprocessamento, portabilidade e dependência do fornecedor. Uma transformação que só funciona em determinada ferramenta pode dificultar troca de plataforma, enquanto uma arquitetura altamente genérica pode acrescentar complexidade incompatível com o porte da operação. A avaliação técnica deve documentar hipóteses, resultados de ensaios e limites de validade; escolher o produto apenas pelo número de conectores disponíveis não comprova adequação.
Dicionário de dados, versionamento e responsabilidade
Quando o campo `count` muda de significado após atualização do analytics, o problema ultrapassa a engenharia do conector. A definição do indicador, os filtros e os relatórios históricos podem perder consistência. Um dicionário de dados deve registrar significado do campo, unidade, fonte, formato, tratamento de valores ausentes e responsável por aprovar mudanças. O catálogo de eventos e as regras de transformação devem ter versões identificáveis e datas de vigência.
Um processo de mudança precisa avaliar impacto na origem, na integração, na tabela de fatos e no dashboard. Se a operação altera a zona de contagem, a série histórica anterior pode precisar ser segmentada ou reprocessada. Se o ponto de venda muda a classificação de cancelamentos, os indicadores comerciais precisam ser reconciliados antes de publicar comparações. A governança evita que duas áreas adotem fórmulas distintas para um indicador com o mesmo nome.
Atribuir responsabilidades também reduz o tempo de investigação. O responsável pela origem confirma se o evento foi gerado; a equipe de integração verifica entrega e idempotência; o proprietário do modelo analítico comprova cálculos; o gestor de negócio aceita a interpretação. Essa divisão não precisa criar burocracia, mas deve existir em registros suficientes para resolver divergências e sustentar uma evolução auditável da solução de Business Intelligence.
Os documentos finais devem permitir que alguém que não participou da implantação compreenda por que um indicador mudou. Contratos de interface, tabelas de correspondência, tolerâncias de qualidade, resultados de ensaios e histórico de versões precisam permanecer vinculados à configuração implantada. O acompanhamento após a entrega faz parte do ciclo de vida, porque novos sistemas e novas perguntas alteram continuamente o contexto analítico.
Implantação gradual e governança do ciclo de vida
Uma implantação controlada começa por um caso de uso mensurável e fontes representativas, como fluxo por intervalo, vendas e escala em um subconjunto de lojas. Documenta-se o dicionário, valida-se a contagem, identifica-se a origem de cada transação e comprova-se a interpretação dos indicadores com a equipe operacional. O piloto deve revelar dificuldades de qualidade e integração antes de expandir o sistema.
ETL e ELT podem ser comparados em pequena escala por latência, capacidade de recuperar falhas, custo de processamento, manutenção e facilidade de alterar regras. Pode ser legítima uma abordagem híbrida, com filtragem de dados pessoais antes de ingestão e transformação dimensional posterior. O projeto precisa manter evidências das escolhas e indicar quando uma condição exige reavaliação.
A expansão deve ser autorizada com base em métricas e testes de qualidade, não somente em interfaces já conectadas. Mudanças de firmware, API ou regras de contagem exigem manutenção e revisão de indicadores. Contratos de interface e fichas de métricas devem sobreviver a alterações de fornecedores e de equipes responsáveis pela operação.
Gestão das exceções e encerramento de períodos
O projeto deve estabelecer como uma janela de análise é encerrada e quando pode ser corrigida. Vendas estornadas depois do fechamento, eventos recuperados após falha de rede e revisões de escala podem modificar dados de períodos anteriores. A política precisa dizer quais registros são provisórios, em que momento ganham condição de consolidados e como uma retificação será apresentada aos responsáveis pelas decisões. Caso contrário, duas pessoas que consultam o mesmo indicador em momentos diferentes podem receber resultados distintos sem compreender a razão.
Um mecanismo de exceções deve registrar motivo de rejeição, origem, tratamento, responsável e data da decisão. Eventos sem identificação de loja, horários impossíveis e registros de fonte não autorizada não podem ser descartados sem rastreabilidade. A fila de exceções também é um instrumento de melhoria: sua recorrência pode revelar defeito de câmera, mudança de API, problema de sincronismo ou lacuna no cadastro de unidades. O tratamento precisa produzir evidência, não apenas reduzir o número de erros exibidos pelo dashboard.
Antes de encerrar o aceite, é útil demonstrar uma correção controlada do histórico: alterar uma regra, reprocessar um período de amostra, conferir a nova métrica e manter a trilha da versão anterior. Esse ensaio comprova que ETL ou ELT foi escolhido com atenção à evolução real do negócio. Reprocessamento sem controle pode resolver uma divergência local e produzir inconsistências em outras áreas; com governança, passa a ser uma capacidade administrável da solução.
Considerações finais
ETL e ELT são escolhas de engenharia para tornar dados de múltiplas origens utilizáveis em Business Intelligence. A melhor alternativa depende da qualidade das fontes, da capacidade de processamento, da privacidade, do custo e da possibilidade de auditar e reconstruir cálculos. O método não dispensa definir o que cada indicador significa e qual decisão ele pretende apoiar.
Com vídeo, eventos, vendas e outros dados operacionais, a utilidade da solução depende da capacidade de relacionar informações sem distorcer sua granularidade ou sua cronologia. Quando as regras, limitações e fontes estão documentadas, os painéis tornam-se verificáveis e podem ajudar a comparar condições e avaliar resultados.
O percurso mais consistente é começar pela decisão do cliente, testar a qualidade dos dados, estabelecer um modelo semântico e ampliar a arquitetura somente após aceitar evidências de funcionamento. Dessa forma, as ferramentas de transformação servem à análise e não substituem a engenharia da solução.
Referências técnicas
[1] MICROSOFT. ETL (extração, transformação, carregamento). Azure Architecture Center. Disponível em: https://learn.microsoft.com/pt-br/azure/architecture/data-guide/relational-data/etl.
[2] GOOGLE CLOUD. O que é ETL? Google Cloud. Disponível em: https://cloud.google.com/learn/what-is-etl?hl=pt-BR.
[3] MICROSOFT. Understand star schema and the importance for Power BI. Microsoft Learn. Disponível em: https://learn.microsoft.com/power-bi/guidance/star-schema.
[4] ONVIF. Profile M: Metadata and Events for Analytics Applications. Disponível em: https://www.onvif.org/profiles/profile-m/.
[5] MICROSOFT. Configure incremental refresh and real-time data for Power BI semantic models. Disponível em: https://learn.microsoft.com/en-us/power-bi/connect-data/incremental-refresh-overview.
[6] AUTORIDADE NACIONAL DE PROTEÇÃO DE DADOS. Perguntas frequentes. Disponível em: https://www.gov.br/anpd/pt-br/acesso-a-informacao/perguntas-frequentes.
Perguntas frequentes
ETL transforma dados antes da carga analítica; ELT carrega primeiro e transforma no ambiente de destino. A escolha depende de requisitos, custos e governança.
Não. ELT precisa de destino capaz de processar os dados; ETL pode ser mais adequado a requisitos de tratamento anterior à carga. Arquiteturas híbridas são possíveis.
Sim, desde que os eventos estejam estruturados, suas regras sejam conhecidas e a qualidade da medição seja verificada.
O VMS gerencia vídeo e eventos e pode oferecer relatórios operacionais; a análise conjunta com vendas e operação pode exigir arquitetura analítica complementar.
Somente depois de considerar cobertura, duplicações, direção, oclusão e qualidade. Somar registros brutos pode inflar resultados.
É a unidade representada por cada registro, como passagem, venda ou total por hora. Misturar granularidades sem critério distorce indicadores.
Não necessariamente. A frequência de atualização depende da decisão; resposta operacional crítica deve permanecer nas plataformas responsáveis.
Por amostragem, reconciliação, testes de falha, deduplicação, monitoramento de atraso, rastreabilidade e validação das fórmulas dos indicadores.
Aplique finalidade, minimização, retenção justificada, segregação de acesso e proteção em todas as etapas, considerando a LGPD.
A arquitetura deve ser dimensionada conforme fontes, volume, crescimento, qualidade, custo, necessidade de reprocessamento e recursos disponíveis.
Comprovar que cada indicador é reprodutível a partir de fontes verificadas, com regras de cálculo, limites e comportamento em falhas definidos.
