Os eventos da Dream Factory já produzem uma base rica: inscrições, compras e respostas de formulário acumuladas edição após edição.
O que falta é ligar cada registro à pessoa certa, com um vocabulário comum entre as fontes — sem perder a origem de nenhum dado.
139tabelasFontes e relações que precisam de um vocabulário comum.
552.294registros de participantesA mesma pessoa pode aparecer em vários eventos.
3,84 mirespostas de formuláriosPerguntas diferentes guardam informações valiosas.
Fonte: profiling offline do dump GoDream de 08/10/2026. Registros não equivalem a pessoas únicas.
02 · pessoas
uma identidade. diferentes papéis.
O documento real normalizado resolve a pessoa. Cada papel preserva seu contexto.
participante
Inscrição por edição. Presença exige evidência própria.
pessoa
ID interno estável Documento único
cliente
Compra confirmada. Pode comprar para terceiros.
lead
Contato elegível para ativação, com origem e finalidade.
participante é um papel da pessoa
cliente é um papel da pessoa
lead é um papel da pessoa
03 · evidências de mercado
receita: resultados publicados de bases integradas.
Cada gráfico tem base 100 calculada a partir do crescimento relatado. Os recortes são distintos.
ibm cloud
+70%
Receita no recorte do case em três meses
100base
170após
shiseido
+20%
Receita em loja por membro do programa de fidelidade
100base
120após
Casos de fornecedores. Não demonstram causalidade isolada e não são previsão de retorno para a Dream Data.
salesforce · data cloud
salesforce conecta eventos, navegação e crm.
+60%
Aumento relatado em receita de leads de marketing e valor contratual por lead.
Aplicação à Dream: reconhecer o mesmo público entre eventos e orientar a próxima oferta.
eventos
navegação
crm
perfil unificado
eventos alimentam o perfil unificado
navegação alimenta o perfil unificado
CRM alimenta o perfil unificado
Fonte: Salesforce, case de uso interno do Data Cloud. Receita de leads e valor contratual por lead, não receita corporativa total.
04 · arquitetura
arquitetura modular do sistema.
MySQL como proposta inicial. Módulos independentes, com origem e versão em cada transformação.
01
fontes
GoDream: a cada hora
Credenciamento: sazonal
Todo Mundo no Rio: sazonal
02
ingestão
Contratos por fonte
Histórico de cargas
Reprocessamento seguro
03
base central
Pessoa e documento
Eventos e inscrições
Comércio e respostas
04
uso dos dados
API interna e dashboard
IA e conceitos revisados
RD Station por seleção
Qualidade, finalidade de uso e rastreabilidade acompanham todas as etapas.
05 · banco de dados
modelo relacional central.
PK chave primária
FK chave estrangeira
UK unicidade
relações principais do esboço lógico
pessoa
PK pessoa_id nome / nascimento
edição
PK edição_id evento / ano / contexto
pedido
PK pedido_id FK comprador_pessoa_id FK edição_id / valores
documento
PK documento_id FK pessoa_id UK tipo + país + valor
inscrição
PK inscrição_id FK pessoa_id / edição_id FK item_id (opcional)
item de pedido
PK item_id FK pedido_id quantidade / preço
pessoa 1:N pedido (comprador)
pessoa 1:N documento
pessoa 1:N inscrição
edição 1:N inscrição
edição 1:N pedido
pedido 1:N item de pedido
inscrição N:1 item de pedido
Cortesias e inscrições sem pedido continuam no modelo. Valores comerciais permanecem no grão do pedido.
06 · protótipo
primeiro esboço do produto.
Uma visão integrada de pessoas, compras e inscrições ao longo do tempo.
dream factory / dream data
conheça as pessoas por trás dos eventos.
Uma visão integrada de pessoas, compras e inscrições ao longo do tempo.
primeiro esboço · discovery
dados ilustrativos — todos os números, pessoas, eventos e bancos abaixo são exemplos de apresentação.
pessoas únicas no recorte8identidade por documento
clientes com compra confirmada5comprador pode ser outro participante
inscrições vigentes17inclui cortesias válidas
recorrência entre edições63%pessoas em duas ou mais edições
histórico de inscrições por edição
inscrições vigentes · valores do conjunto fictício selecionado
42025 · corrida
22025 · festival
42026 · corrida
32026 · festival
42026 · credenc.
perfil agregado para bancos
pagamentos elegíveis de cartão · exemplos de emissores
Banco A50%
Banco B25%
Banco C25%
Desconhecido0%
Exemplo: um pagamento de cartão por cliente elegível no recorte (4 registros). Emissor observado não indica banco principal. Sem evidência de cartão fica fora deste denominador.
Dados inteiramente ilustrativos. Filtros por ano, evento, fonte, papel, documento e nascimento.
07 · qualidade
como refinar a base sem perder a evidência.
Cada atributo preserva o valor original, a origem, a atualidade e os conflitos.
recebido
Fonte, ID original e lote da carga
normalizado
Documentos, datas e opções válidas
identificado
Documento único e conflitos visíveis
contextualizado
Edição, inscrição e papel correto
elegível
Finalidade, seleção e revisão da ativação
Cortesia zero permanece válida. Nome repetido gera investigação, nunca exclusão automática.
Reconciliação por pedido: trocas, upgrades, cancelamentos e reembolsos evitam dupla contagem.
08 · inteligência semântica
ia para interpretar formulários diferentes.
Sugestões estruturadas passam por validação e revisão antes de entrar no catálogo.
