Sistemas que construí

Detalhe técnico: a tabela-fato consolida ~106 mil pedidos com sync incremental a cada 15 minutos, integrando 7 fontes de dados — Shopify Admin API (REST + GraphQL), Meta Marketing API, GA4 Data API, Tiny ERP de 3 empresas diferentes, UpPromote (afiliados), Stamped.io (reviews) e Google Sheets (metas). A atribuição multi-touch é motor próprio, reconstruído a partir da jornada do cliente (last-click não-direto) — não a API pronta de nenhuma plataforma. PII fica cifrada em repouso com AES-256-GCM, e um HMAC-SHA256 permite contar clientes únicos sem nunca expor o dado em claro. O motor de margem/custo por canal é configurável, então o lucro real considera custo de produto e taxa por canal, não só receita bruta.

Detalhe técnico: a atribuição casa venda↔campanha por utm_term=campaign.id — identificador imutável que sobrevive a renomear a campanha — com 4 camadas de fallback caso o parâmetro falhe. Além das travas de sROAS, o autopilot respeita um teto agregado de conta, não mexe em campanha que ainda está na trava de aprendizado do Meta, aplica cooldown de aumento (no máximo 1x a cada N dias por campanha) e limita a variação máxima por rodada para evitar oscilação. O estado persiste cifrado em AES-256-GCM, a chamada à Graph API tem retry com backoff e respeito ao header Retry-After, e um dead-man's switch (heartbeat + healthcheck + alerta no Telegram) avisa se o robô parar de rodar. Roda via supercronic, está na versão 3, com testes unitários e deploy programático.

Detalhe técnico: os três sinais — co-compra, semântico e popularidade — entram normalizados por rank antes de somar, para que uma escala diferente entre eles não domine o resultado sozinha. A intenção complemento/substituto decide se a sugestão empurra "leva junto" ou "alternativa"; a diversidade por família de produto evita mostrar 5 variações do mesmo item; a penalidade de preço evita empurrar sempre o mais caro do catálogo. A flag de rollback existe porque motor de recomendação é o tipo de sistema que erra silencioso — dá para reverter pro sinal anterior sem redeploy.

Detalhe técnico: o guard não se contenta com e-mail — cruza contato, e-mail, telefone e ID da loja (Shopify) antes de disparar qualquer lembrete ou cupom. O último campo importa porque a mesma automação atende mais de uma loja: sem o ID da loja no cruzamento, um cliente que já comprou na loja A poderia receber cupom disparado pela loja B só por coincidência de e-mail ou telefone. Foi exatamente essa lacuna — checagem por um campo só — que causou o bug original.

Detalhe técnico: a Conversions API deduplica eventos por event_id — evita contar a mesma venda duas vezes quando o pixel do navegador e o servidor mandam o mesmo evento — e faz hashing de PII antes de enviar, o que sobe o EMQ (Event Match Quality), a nota que o Meta dá pra qualidade do sinal recebido. O conector que injeta gasto do Meta Graph e do GA4 de volta na Shopify é idempotente (pode rodar de novo sem duplicar linha) e roda em cron diário, mantendo o cálculo de ROAS real sempre com o gasto do dia certo.

Detalhe técnico: cada tenant nasce de uma imagem base comum e recebe patches versionados por cima — rebrand por tag fixa, não fork de código, então uma correção sobe para todas as lojas de uma vez. A automação (que mensagem, quando, pra quem) é resolvida por override gravado em banco por tenant, não por deploy separado — mudar um fluxo de uma loja não exige subir código novo. O cupom é emitido via integração OAuth própria com a Shopify de cada loja, e webhooks de pedido/cliente acionam os fluxos em tempo real.