Análise Estratégica da Arquitetura Organizacional, Engenharia de Dados e Composable Commerce: O Ecossistema DivBrands (BÆRSkin, Findly.ai)

Resumo Executivo

Este relatório apresenta uma investigação exaustiva sobre a DivBrands (operando legalmente como Digital Innovation Ventures e associada a um portfólio de marcas globais como BÆRSkin Tactical Supply Co. e Hyper Arch Motion), dissecando sua transformação de uma holding de e-commerce Direct-to-Consumer (DTC) em uma incubadora de tecnologia de dados que culminou no spin-off da Findly.ai.

O documento foi elaborado para servir como referência estratégica para líderes de tecnologia e operações, detalhando como uma organização bootstrapped (autofinanciada) escalou para dezenas de milhões de dólares em receita anual através de uma arquitetura de dados moderna (Modern Data Stack) e uma filosofia organizacional ágil.

A análise aprofunda-se na "Física do Marketing" aplicada pela empresa, onde a ingestão de dados precede o desenvolvimento do produto, e mapeia a evolução crítica de seu time de dados — de um CTO generalista para esquadrões especializados em Analytics Engineering e Data Science. Examinamos a infraestrutura tecnológica baseada nos princípios MACH (Microservices, API-first, Cloud-native, Headless), o uso estratégico de ferramentas como Fivetran, Snowflake e dbt para orquestrar mais de 70 milhões de registros mensais, e como essa arquitetura permitiu uma redução massiva no overhead operacional enquanto aumentava o Retorno Sobre Investimento em Publicidade (ROAS) em 15%.

1. Fundamentos Corporativos e Escala Operacional

Para compreender a arquitetura de dados da DivBrands, é imperativo primeiro dissecar o terreno econômico e operacional sobre o qual essa infraestrutura foi construída. Diferentemente de varejistas tradicionais que digitalizaram operações legadas, a DivBrands nasceu como uma entidade nativa digital, operando sob restrições de capital que forçaram uma eficiência algorítmica desde o primeiro dia.

1.1 A Gênese Bootstrapped e a Disciplina de Capital

A DivBrands foi co-fundada por um núcleo de empreendedores com competências complementares em marketing de performance e engenharia de software de elite: Lourenço Maciel (CPO), Pedro Nascimento (CTO) e Jonathan Aeschlimann (CEO). A operação atingiu a marca de $40 milhões em receita anual sem a injeção inicial de capital de risco (Venture Capital).

Este detalhe financeiro não é trivial; ele moldou a arquitetura de dados da empresa. Em uma startup financiada por VC, há margem para "inchar" equipes de dados e contratar ferramentas caras antes da necessidade real. Na DivBrands, cada dólar investido na stack de tecnologia precisava retornar imediatamente em eficiência operacional ou incremento de receita.

A trajetória dos fundadores estabeleceu o DNA da empresa. Lourenço Maciel, por exemplo, não apenas liderou estratégias de marketing gastando mais de $50 milhões em anúncios ao longo da carreira, mas também aprendeu a programar para construir sistemas proprietários de atribuição quando as mudanças de privacidade do iOS 14 ameaçaram o modelo de negócios de publicidade digital. Esse sistema interno foi fundamental para segurar $35 milhões em receita durante um período de turbulência no mercado de anúncios digitais. Essa mentalidade de "construir para sobreviver" evoluiu para a criação da Findly.ai, demonstrando que na DivBrands, a tecnologia de dados é o core business, e os produtos físicos são a manifestação monetizável dessa inteligência.

1.2 Complexidade Operacional: O Desafio da Escala Global

A DivBrands não opera como uma loja única, mas como uma house of brands (casa de marcas) que gerencia múltiplas identidades comerciais simultaneamente em diversos mercados. A complexidade de dados aqui é exponencial, não linear.

1.2.1 Geografia e Fragmentação de Mercado

A empresa expandiu suas operações para vender em mais de 30 países e suportar 9 idiomas, com uma força de trabalho remota de mais de 100 colaboradores distribuídos globalmente. Operar em 19 mercados principais introduz uma complexidade de dados massiva:

• Conformidade Regulatória: A arquitetura de dados precisa segregar e gerenciar informações de acordo com o GDPR na Europa, CCPA na Califórnia e LGPD no Brasil, exigindo governança de dados robusta no nível do Data Warehouse.
• Logística Distribuída: A gestão de estoque não é centralizada. Um SKU (Stock Keeping Unit) do casaco BÆRSkin pode estar disponível no armazém dos EUA mas esgotado na Alemanha. O sistema de dados precisa ter visibilidade em tempo real desses inventários dispersos para pausar anúncios em regiões sem estoque, evitando o desperdício de ad spend.

1.2.2 Portfólio de Marcas e Análise de SKUs

A gestão de SKUs na DivBrands reflete uma estratégia de "nicho profundo" em vez de "varejo amplo".

BÆRSkin Tactical Supply Co. A marca de vestuário tático exemplifica a complexidade de variantes. O produto principal, o Tactical Hoodie, e suas extensões de linha (jaquetas fleece, calças cargo), possuem múltiplas dimensões de dados:

• Matriz de Variantes: Tamanhos variando de S a 3XL e múltiplas cores (ex: Verde Oliva, Preto, Tan).
• Ciclo de Vida do SKU: Diferente de eletrônicos, o vestuário tem alta taxa de devolução e troca. A arquitetura de dados deve rastrear não apenas a venda (Gross Revenue), mas a retenção final (Net Revenue após devoluções), o que exige integração profunda entre o sistema de logística reversa e o painel financeiro.

Hyper Arch Motion Esta marca de calçados ortopédicos representa um desafio diferente. Com vendas baseadas em feedback de mais de 100.000 clientes, os dados associados a cada SKU incluem atributos qualitativos de saúde e conforto. A escala aqui é validada pelo volume de feedback e pela menção de ser um "enorme sucesso" de vendas, sugerindo dezenas de milhares de pares vendidos anualmente.

1.3 Volume de Dados e Métricas de Fluxo

A escala da operação digital da DivBrands gera um "escape de dados" (data exhaust) significativo. A empresa movimenta cerca de 70 milhões de registros ativos por mês através de seus pipelines de dados. Este volume coloca a DivBrands fora do escopo de planilhas ou ferramentas de BI básicas. Estamos falando de Big Data real, onde a latência na consulta pode significar a perda de oportunidades de arbitragem de anúncios. O volume é impulsionado não apenas por transações, mas por eventos de clickstream (comportamento do usuário no site), impressões de anúncios em múltiplas plataformas (Facebook, TikTok, Google) e interações de suporte ao cliente.

2. Metodologia de Desenvolvimento Reverso: Dados como Motor de R&D

A DivBrands inverteu a lógica tradicional do varejo. Em vez de desenvolver um produto e depois procurar um mercado (Product-Market Fit tradicional), a empresa pratica o "Reverse Product Development" (Desenvolvimento de Produto Reverso), onde a demanda agregada e os dados de engajamento ditam as especificações do produto antes mesmo de sua fabricação em massa.

2.1 O Ciclo Cibernético de Feedback

A arquitetura de dados da DivBrands foi desenhada para facilitar este ciclo contínuo de feedback, transformando sinais de mercado em especificações de engenharia de produto. O caso da Hyper Arch Motion é o exemplo arquetípico deste processo:

1. Sinalização de Mercado (Ingestão de Dados): Através de testes de anúncios (Smoke Tests) e análise de tendências de busca, a empresa identificou um segmento demográfico (mulheres com dores nos pés/fascite plantar) que estava insatisfeito com as opções atuais.
2. Qualificação via Dados (Processamento): A coleta de feedback estruturado e não estruturado de 100.000 mulheres revelou a "falha de mercado": a dicotomia entre conforto ortopédico e estética visual. As clientes recusavam-se a usar sapatos ortopédicos feios.
3. Especificação do Produto (Ação): Os dados ditaram os requisitos funcionais (absorção de impacto 30% maior) e estéticos (design de sneaker moderno).
4. Validação Pós-Venda (Re-ingestão): Após o lançamento, o feedback de cada retorno ou troca é capturado pelos agentes de suporte (via LTVplus) e categorizado. Se um lote de tênis apresenta reclamações sobre "aperto no peito do pé", essa informação viaja do sistema de suporte (Zendesk/Gorgias) para o Data Warehouse, e de lá para o time de desenvolvimento de produto em tempo quase real, permitindo ajustes rápidos na produção.
5. Insight de Segunda Ordem: Esse modelo reduz drasticamente o risco de inventário, que é historicamente a maior causa de mortalidade no varejo de moda. Ao produzir apenas o que os dados já validaram como desejável, a DivBrands opera com um ciclo de conversão de caixa (Cash Conversion Cycle) superior e menor necessidade de capital de giro para estoque obsoleto. A "equipe de dados", portanto, atua indiretamente como gestora de risco financeiro.

2.2 Marketing de Impulso e Velocidade da Informação

A DivBrands opera fortemente em canais de Impulse Marketing (redes sociais, display), onde a decisão de compra é instantânea e emocional. Isso difere do "Search Marketing" (Google), onde o usuário já tem intenção.

• Mecânica de Dados: No marketing de impulso, a "vida útil" de um criativo (anúncio em vídeo/imagem) é curtíssima (dias ou semanas). A "fadiga de anúncio" (ad fatigue) se instala rapidamente.
• Necessidade Arquitetural: A stack de dados precisa informar a equipe criativa diariamente sobre quais ângulos visuais, cores ou hooks (ganchos narrativos) estão performando. Se o relatório de performance demorar uma semana para ser gerado (o padrão em empresas legadas), o dinheiro já foi desperdiçado em anúncios saturados. A DivBrands construiu sua stack para fornecer essa inteligência em tempo real ou D+1.

3. Composable Commerce e Infraestrutura MACH

Sob a liderança técnica do CTO Gus Fune, um embaixador da MACH Alliance, a DivBrands rejeitou as plataformas de e-commerce monolíticas (soluções "tudo em um" rígidas) em favor de uma arquitetura Composable Commerce. Esta escolha estratégica permite que a empresa selecione as melhores ferramentas para cada função específica (Best-of-Breed), integrando-as via APIs.

3.1 O CMS Headless: Payload

A gestão de conteúdo e catálogo de produtos migrou para o Payload CMS, uma solução headless (sem interface de usuário frontal acoplada ao backend) e code-first.

• O Problema Anterior: Plataformas tradicionais ou CMSs acoplados criavam gargalos onde qualquer mudança no design do site exigia intervenção complexa no backend, ou onde a gestão de dados de produto era misturada com a gestão de conteúdo de blog, criando "sujeira" nos dados.
• A Solução Payload: Centralizou documentos e bancos de dados voltados para o usuário em um único local. A natureza baseada em código do Payload permitiu que os engenheiros da DivBrands tratassem o conteúdo como dados estruturados, versionáveis e testáveis.
• Impacto Quantificável: Aumento de 30% na velocidade de desenvolvimento e redução do tempo de onboarding de editores para 30 minutos. Para uma empresa que lança marcas e produtos rapidamente, essa agilidade na camada de conteúdo é uma vantagem competitiva direta.

3.2 Frontend Progressivo (PWA) e Vue Storefront

Para a camada de apresentação (o que o cliente vê), a empresa adotou abordagens como Vue Storefront.

• Performance Mobile: Como a maior parte do tráfego de "impulse marketing" vem de dispositivos móveis (Instagram/TikTok), a velocidade de carregamento é crítica. PWAs (Progressive Web Apps) oferecem uma experiência quase nativa de aplicativo, carregando instantaneamente mesmo em redes móveis instáveis.
• Desacoplamento: O frontend pode ser iterado e testado A/B agressivamente sem risco de quebrar o backend de processamento de pedidos.

3.3 Orquestração de Pagamentos: Primer.io

A expansão para 19 mercados trouxe o desafio da fragmentação de pagamentos. Clientes na Holanda preferem iDEAL; no Brasil, PIX; nos EUA, Cartão de Crédito; na Ásia, carteiras digitais.

• Infraestrutura de Pagamento: A DivBrands utiliza a Primer.io como uma camada de orquestração.
• Funcionalidade: A Primer atua como um "adaptador universal". A DivBrands conecta a Primer ao seu checkout, e a Primer conecta-se a dezenas de processadores locais (Adyen, Stripe, Klarna, Atome).
• Vantagem de Dados: Isso normaliza os dados de transação. Em vez de ter que limpar dados de formatos diferentes vindos de 10 processadores distintos, a DivBrands recebe um fluxo de dados de pagamento padronizado da Primer, facilitando a reconciliação financeira automática no Data Warehouse.
• Performance: Taxas de autorização de 90% e capacidade de implementar Buy Now, Pay Later (BNPL) globalmente com poucos cliques.

4. A Arquitetura da Stack de Dados Moderna (MDS)

O coração pulsante da inteligência da DivBrands é sua Modern Data Stack. A arquitetura foi desenhada para resolver o problema clássico de silos de dados, consolidando informações de Marketing, Logística, Financeiro e Atendimento ao Cliente em uma "Single Source of Truth" (Fonte Única da Verdade).

4.1 Ingestão de Dados (ELT): A Revolução Fivetran

A decisão de arquitetura mais impactante foi a adoção do Fivetran para a ingestão de dados.

• O Desafio de Engenharia: Manter conectores de API para Facebook Ads, Google Ads, TikTok Ads, Shopify, Klaviyo e Zendesk é uma tarefa hercúlea. As plataformas mudam suas APIs constantemente, quebrando pipelines caseiros.
• A Solução Automatizada: O Fivetran automatiza o processo de Extração e Carregamento (EL). Ele detecta mudanças de esquema (schema drift) e se adapta automaticamente.
• Impacto no Capital Humano: Gus Fune estima que o Fivetran economizou o equivalente a três engenheiros de dados em tempo integral. Isso permitiu que a DivBrands operasse durante sua fase de hipercrescimento com uma equipe de dados extremamente enxuta (inicialmente apenas uma pessoa), focada em análise e não em "encanamento" de dados.

4.2 Armazenamento Escalável: Snowflake

Os dados brutos ingeridos são depositados no Snowflake, o Data Warehouse em nuvem.

• Separação de Compute e Storage: A arquitetura do Snowflake permite que a DivBrands armazene terabytes de dados históricos de forma barata (Storage) e pague pelo processamento (Compute) apenas quando as consultas estão rodando. Isso é vital para a sazonalidade do e-commerce (picos na Black Friday vs. dias normais).
• Centralização: Todos os dados — desde o clique no anúncio até a entrega do pacote e o ticket de suporte — residem no mesmo ambiente SQL, permitindo joins complexos que seriam impossíveis em sistemas separados.

4.3 Transformação e Engenharia Analítica: dbt (data build tool)

Com os dados brutos no Snowflake, a DivBrands utiliza o dbt para transformar esses dados em modelos de negócios utilizáveis.

• Engenharia de Software aplicada a Dados: O dbt permite que a equipe use controle de versão (Git), testes automatizados (Data Quality Tests) e documentação para seus modelos SQL.
• Modelagem de Negócios: Em vez de analistas escreverem queries complexas repetidamente, o dbt cria tabelas "oficiais" (ex: fct_orders, dim_customers) que contêm as definições de negócios aprovadas (ex: como calcular "Margem Bruta" considerando taxas de pagamento, impostos e custos de envio).
• Linhagem de Dados (Data Lineage): O dbt fornece um mapa visual de como os dados fluem e são transformados, essencial para depuração e governança quando se tem 70 milhões de registros.

4.4 Análise e Inteligência Artificial

Para a ponta final (consumo de dados), a empresa utilizou uma combinação de BI tradicional e desenvolvimento próprio.

• Databricks e Data Lake: Para cargas de trabalho de ciência de dados mais pesadas e machine learning, há menção ao uso de Databricks para construir o Data Lake.
• Ferramentas de BI: Uso de Looker Studio (Google), Power BI e Metabase para visualização operacional.
• Findly (Interno): O desenvolvimento de interfaces de chat baseadas em LLMs para democratizar o acesso aos dados, que eventualmente se tornou o produto Findly.ai.

5. Arquitetura de Pessoas e Evolução do Time de Dados

A estrutura organizacional da DivBrands desafia a norma corporativa. Em vez de grandes departamentos hierárquicos, a empresa adotou uma estrutura de Squads ágeis e remotos, suportada por uma gestão de RH global via Deel.

5.1 Fase 1: O Generalista (The One-Man Army)

Nos estágios iniciais (até ~$10-20M de receita), a função de dados era centralizada na liderança técnica (CTO Gus Fune e fundadores).

• Perfil: Habilidades híbridas de infraestrutura, desenvolvimento web e análise de negócios.
• Foco: Garantir que os dados fluíssem minimamente para tomar decisões de compra de mídia. A "equipe" era a ferramenta.

5.2 Fase 2: Especialização e Liderança (The Data Team)

Conforme a complexidade aumentou (17 marcas, múltiplos fusos horários), a empresa iniciou a contratação estratégica para formar um núcleo de dados dedicado.

5.2.1 Head de Data Science (Daniel Shinoda)

Contratado no final de 2021, este papel foi crucial para elevar a maturidade analítica.

• Perfil: Ex-B2W Digital, trazendo experiência de e-commerce de grande escala.
• Responsabilidades Estratégicas: Sair do descritivo ("O que aconteceu?") para o prescritivo ("O que devemos fazer?"). Implementar modelos de atribuição avançados para combater a perda de sinal do iOS 14 e integrar dados exógenos (como clima) aos modelos de vendas.

5.2.2 O Primeiro Engenheiro de Dados

A contratação do primeiro Data Engineer dedicado marcou a separação entre "usar dados" e "manter a plataforma de dados".

• Job Description (Reconstruído) - Missão: Libertar os cientistas de dados e o CTO da manutenção de pipelines. Garantir SLA (Service Level Agreement) dos dados.
• Atividades: Gerenciar a instância do Fivetran, otimizar custos do Snowflake, monitorar falhas de ingestão, integrar novas fontes de dados não-padrão (APIs obscuras de logística local).

5.2.3 Analytics Engineer

A presença de Analytics Engineers indica uma maturidade moderna. Este papel fica na interseção entre o Engenheiro de Dados e o Analista de Negócios.

• Job Description (Reconstruído) - Foco: A camada de transformação (dbt).
• Atividades: Traduzir lógica de negócios confusa em código SQL limpo e performático. Criar a documentação dos dados. Garantir que o Marketing e o Financeiro concordem com os números finais.

5.3 Cultura Remota e Assíncrona

Com colaboradores em 19 países, a sincronia é impossível. A arquitetura de pessoas depende de:

• Documentação Extensiva: Se não está escrito, não existe.
• Autonomia na Ponta: Os dados devem estar disponíveis self-service (via Findly ou Dashboards) para que um gestor de marca na Ásia não precise esperar o time de dados na Europa acordar para tomar uma decisão.
• Gestão Global de Talentos: O uso da plataforma Deel permitiu contratar os melhores talentos onde quer que estivessem, lidando com a complexidade legal e de pagamentos (Payroll) em conformidade com leis locais, sem a necessidade de abrir subsidiárias em cada país.

6. Conexão Causal: Dados Transformados em Receita

A infraestrutura técnica da DivBrands não é um exercício acadêmico; é uma máquina de fazer dinheiro. A conexão entre bytes e dólares é direta e mensurável.

6.1 Otimização de ROAS e Atribuição

A implementação da stack Fivetran + Snowflake + dbt foi creditada diretamente com um aumento de 15% no Return on Ad Spend (ROAS).

• Mecanismo: Antes, a unificação dos dados de gastos (Facebook) e receita (Shopify) podia levar dias ou ser feita em planilhas propensas a erro. Com a MDS, essa unificação é quase em tempo real.
• Ação Tática: O time de User Acquisition pode identificar intraday (no mesmo dia) que uma campanha está performando mal e cortar o orçamento, realocando-o para uma campanha vencedora. Em uma escala de milhões em ad spend, essa velocidade economiza fortunas.

6.2 Contextual Advertising: O Caso do Clima

Uma das aplicações mais sofisticadas citadas é o uso de dados climáticos.

• Hipótese: Pessoas compram mais casacos táticos (BÆRSkin) quando está chovendo ou frio.
• Execução de Dados: Daniel Shinoda integrou APIs de clima ao Data Warehouse. O sistema cruza a localização geográfica dos cliques/vendas com o clima histórico e previsto.
• Resultado: A DivBrands pode ajustar os lances de anúncios (bidding) geograficamente. Se uma frente fria está chegando a Berlim, os lances para a Alemanha aumentam automaticamente. Isso aumenta a relevância e a taxa de conversão, diminuindo o Custo por Aquisição (CPA).

6.3 Recuperação de Receita e Chat em Tempo Real

A integração de dados de suporte (Live Chat) via LTVplus gerou mais de $600.000 em receita incremental.

• Integração: Os agentes de chat não operam no escuro. Eles têm acesso a dados sobre o que o cliente tem no carrinho e seu histórico.
• Feedback Loop: As objeções levantadas no chat ("O frete é muito caro", "Tenho dúvida no tamanho") são transformadas em dados estruturados que alimentam a otimização da página de produto (CRO) e a estratégia de preços.

7. Findly.ai: A Evolução da Ferramenta para o Produto

A transição da DivBrands de usuária de tecnologia para fornecedora de tecnologia (via Findly.ai) é o clímax de sua estratégia de dados.

7.1 Do "Painel" para o "Chat"

Os fundadores perceberam que, mesmo com dashboards bonitos no Looker/Power BI, os tomadores de decisão não-técnicos ainda tinham dificuldades para extrair insights profundos ("Por que as vendas caíram ontem?"). Eles dependiam de analistas para interpretar os gráficos.

7.2 A Incubação

A equipe técnica começou a desenvolver uma camada interna que usava Processamento de Linguagem Natural (NLP) para permitir que gestores fizessem perguntas em inglês simples ao banco de dados.

• Exemplo: "Mostre-me as vendas do Hyper Arch Motion nos EUA vs. UK na última semana."
• Tecnologia: A ferramenta traduzia a pergunta em SQL, executava no Snowflake e retornava a resposta visualizada.

7.3 O Spin-off para o Mercado (SaaS)

Percebendo que esse problema era universal no e-commerce, a tecnologia foi empacotada como Findly.ai.

• Proposta de Valor: "Co-piloto para Business Intelligence".
• Integração: Focada no ecossistema que a DivBrands dominava (Google Analytics 4, Bancos SQL).
• Legado: A Findly é construída sobre a dor real sentida pela DivBrands. Ela é um produto forjado na trincheira operacional de uma empresa de $40M, não apenas uma ideia teórica de startup. A equipe fundadora da Findly é composta pelos ex-líderes da DivBrands (Jonathan, Pedro, Lourenço) e engenheiros ex-Google/Twitter, fechando o ciclo de evolução do talento.

8. Horizonte Futuro e Recomendações Estratégicas

A análise da trajetória da DivBrands aponta para tendências claras que definirão o futuro do e-commerce competitivo.

1. Automação Agêntica (AI Agents): O próximo passo lógico, já insinuado pelo desenvolvimento da Findly, é a transição de "análise" para "ação". Agentes de IA que não apenas relatam que o ROAS caiu, mas que têm permissão para ajustar o orçamento autonomamente dentro de parâmetros definidos.
2. A Consolidação do Modelo "Lean": A DivBrands provou que não são necessários exércitos de pessoas para escalar. O futuro pertence a organizações com alta densidade de talento e alta alavancagem tecnológica. A recomendação para players do setor é auditar suas equipes: onde há humanos fazendo o trabalho de robôs (ex: copiando dados de CSV para Excel), há ineficiência e perda de oportunidade.
3. Dados como Ativo de M&A: Caso a DivBrands busque uma saída (exit) ou aquisição de suas marcas, o valor não estará apenas na marca BÆRSkin, mas na riqueza e organização dos seus dados de clientes. Uma marca com dados estruturados, limpos e acionáveis vale múltiplos mais altos do que uma marca "caixa preta".

Apêndice: Tabela Comparativa de Job Descriptions (Reconstrução Tática)

Fim do Relatório Este documento consolida todas as informações factuais e insights estratégicos disponíveis sobre a operação da DivBrands até Janeiro de 2026.