Esse texto tem a estrutura de um case de gestão de produto, por isso na estrutura terá detalhes como contexto, estrutura de time, desafios, discovery, priorizações, resultados e aprendizados. Esse texto faz parte de uma série de artigos cases que apresentaremos por aqui.

Neste case, apresentaremos os desafios de construir um tech stack de Martech para resolver problemas de marketing e growth com objetivo de gerar maior rentabilidade para a companhia.

Contexto, Objetivo e Desafio

Contexto: A Empresa em questão já buscava por eficiência operacional e financeira desde o fim do ano de 2021. Por isso, ser eficiente com os custos de marketing era extremamente importante.

Objetivo: Atrair mais e melhores clientes, dependendo cada vez menos de mídia paga como Google e Facebook, etc.

Desafio: como aplicar inteligência de dados para segmentar audiências nas plataformas de mídia ao invés de deixar que eles escolham a audiência por nós. Gerando assim, maiores taxas de conversão e menor CAC (custo de aquisição).

Estrutura do Time

Na ocasião, liderando 2 tribos de Product Growth, juntamente com uma camada de liderança sênior, GPM (Group Product Manager), GDM (Group Design Manager), ED (Engineering Director), Ops (Marketing Growth) e Dados (Business Analytics e Data Science). E todos os fatos, desafios e estrutura técnica mencionados aqui, tem total mérito das pessoas que trabalharam nesse time.

Iniciativa, Criar um Time de Martech

Para tangibilizar isso a estrutura de dados para marketing e endereçar os objetivos, criamos uma squad de Martech (que o nome era Martech 😀 ), que era composto por uma pessoa de produto (PM), e 4 de engenharia, 1 EM (Engineering Manager) e 3 pessoas desenvolvedoras. 

E por que não terceirizar?

Cogitamos a possibilidade de seguir com agências digitais e consultoria. Porém, ao considerar o nosso modelo de negócio, ciclo de venda longo (em média 7 meses), ticket médio (venda de apartamento), baixa ou nenhuma recorrência, e parque tecnológico e acesso a dados sensíveis (isso aqui é muito sério), decidimos seguir com time próprio.

Mas antes de seguir, o que é Martech?

Não é o foco deste case explicar profundamente o que é Martech, mas eu particularmente gosto da definição do Gartner;

Marketing technology (martech) is a set of integrated technologies that enables marketing capabilities, such as efficiently and effectively targeting, acquiring and retaining customers.

Perceba que a definição menciona “tecnologias que habilitam capacidades de marketing”, não se restringe a uma única ferramenta. Isso é importante, pois aqui nós vamos falar da junção de ferramentas de mercado com soluções próprias, que nos leva a um ponto importante mencionar aqui.

Existem diferentes consensos sobre o tema, o que define Martech como ferramentas unicamente, e o que define Martech como um conceito amplo que une ferramentas, estratégias, pessoas, visão de produto, escalabilidade e rentabilidade.  Eu particularmente me identifico mais com a segunda.

O Discovery

Antes de tudo, vale fazer um disclaimer aqui, este não é um discovery convencional, com entrevistas com usuários finais, uso de dados transacionais ou comportamentais, testes de usabilidade etc. Pois não existia nada disso na empresa até o momento. Nossos usuários mais próximos eram as pessoas do time de marketing e de business analytics. 

O que fizemos foi:

• Conversas com principais stakeholders, que era o MKT, que já estavam com uma lista de dores/desafios vivenciados no dia-a-dia. Que estavam acumulados por anos de ausência total de qualquer suporte dos times de produto;
• Fazer benchmarking de mercado e conversar com profissionais de outras empresas;
• Umas das lideranças de MKT trouxe algumas referências de arquitetura da empresa que havia trabalhado anteriormente;
• Parte do time fez um curso de Martech em uma escola internacional de referência;
• Usamos material prévio preparado pelo time de Service Design (Service Blueprint, Mapas de Jornada;

Visão de Produto [Nada Convencional]

Aqui vale mais um disclaimer, essa não é uma visão de produto como as que estamos acostumados a ver, que são documentos com muitas informações sobre o cliente, dados quantitativos e qualitativos, as vezes até protótipos de interface ou vídeo aspiracional. No nosso caso estamos falando de um “produto” quase invisível, que funciona nos bastidores de tudo. O que dificulta muito o entendimento das pessoas envolvidas, tanto patrocinadores quanto consumidores. Por isso usamos uma tática diferente. 

Sem fazer juízo de prioridade, nível de complexidade ou se aquela seria a versão que iria se manter no futuro. Desenhamos uma estrutura visual que endereçava nossos desejos, para tangibilizar tanto para o próprio time quanto para stakeholders. E o resultado você pode conferir na imagem abaixo, um desenho no Miro que usamos em algumas conversas para explicar o que estávamos fazendo e onde queremos chegar.

A imagem está propositalmente pequena, sem muita resolução, mas para fins de contexto: da esquerda para a direita, temos;

• Audiências: grupos de usuários que queremos impactar com campanhas de mídia paga
• Jornada dentro do site dividida em topo, meio e fundo de funil
• Uma camada de dados onde os dados de marketing e navegação no site é enriquecido com dados da base de cliente, mantendo dados PII (informações pessoais) anônimas
• Um funil resultante desses dados, onde é possível ver o percentual de cada audiência que avançou ao longo do funil
• Um recurso que permite compor novas audiências (segmentações) com base nos perfis que mais avançaram no funil.
• O hub que devolve audiências enriquecidas e otimizadas para os canais de mkt (facebook, google, crite, crm, app push, etc)

Arquitetura de Dados da Estrutura de Martech

Na arquitetura do stack de martech é composta por uma série de ferramentas de mercado misturando com algumas soluções próprias. Algumas delas são;

• Segment: poderosa ferramenta de integração/orquestração de dados, ela possui outros módulos, mas o principal utilizado era focado em levar eventos de um coletor central para outras ferramentas como GA, Heap e AppsFlyer.
• Event Horizon: ferramenta própria da empresa que fazia coleta de eventos nos principais touchpoints da jornada, online e off-line.
• GA, Heap e AppsFlyer: ferramentas de product analytics para dados comportamentais e associar as origens de tráfego
• Google Ads, Facebook Ads e Criteo: players de distribuição de online paid mídia.
• Salesforce como CRM de gestão de cliente e também réguas de comunicação automáticas, junto com Twilio
• Entre outras ferramentas e banco de dados que de acordo com a necessidade e evolução no stack vão se conectando no ecossistema.

Como foi a Priorização desse time

Uma dúvida recorrente em times/pessoas de produto é, como foi a priorização e quais critérios foram utilizados.

Nesse caso, optamos logicamente pelo básico que gerava mais impacto, que era basicamente otimizar o que já funcionava no marketing. Campanhas de Facebook Ads e Google Ads. Melhoramos a coleta e devolução de dados, com eventos mais confiáveis. Ainda ao nível de início de jornada (topo do funil), acesso, identificação e visita. Mas o com o objetivo inicial de empoderar o time de MKT para otimizar campanhas com dados, focando em melhores taxas de conversão e menor CAC.

Depois disso, passamos a atacar coisas que não tão óbvias assim, mas que faria a diferença para a “visão de produto” desejada.

Primeiras Entregas Desafios do Time

A expectativa é contar que foi tudo muito rápido e fluido, com grandes entregas desde o início, mas não foi bem assim. O primeiro trimestre do time foi muito difícil, por uma série de fatores;

• Curva de aprendizado, ninguém havia feito Martech anteriormente.
• Visão imediatista da área de Ops gerou atritos.
• O trabalho inicial era muito de estruturação de alicerces do stack, com pouca entrega efetiva de valor
• Dificuldade para tangibilizar o que havia sido construído até aquele momento.
• Mudamos o roadmap, pois descobrimos quick-wins que geravam valor mais rápido, não mapeados antes.

Tudo isso contribui para um início bem turbulento, mas que gerou aprendizados que falaremos em seguida.

Entregas e Impactos 

Agora sim podemos falar de entregas e impactos gerados pelo time, e vale deixar claro que tudo isso aqui foi depois de 1 ano de trabalho, tropeços, correções de rota, e aprendizados.

• Próprio criador de feeds XML que alimentas ads (+conversão / – erros)
• Próprio criador de banners (+flexibilidade para o time de MKT / – custo)
• Próprio coletor de eventos, com enriquecimento de dados e anonimização de PII (+ confiabilidade de dados, melhores segmentações de ads)
• Banco de dados no Data Lake, possibilitando N análises cross-companhia
• Integração via Segment com 3rd parties como Criteo, Google, Facebook, além de devolver eventos offline para GA e Heap analytics (- devsenvolvimento / – eros / + velocidade)
• Um portal de dados self-service, cadastro eventos direto na platafoma (- dev)
• Modelos próprios de atribuição e alocação de budget de MKT junto com o time de DS (+ visibilidade do público / – CAC)

Resultados de Negócio

Coo essas entregas se convertiam em resultados de negócio;

• Reduzimos o CAC em -85% (em 1 ano)
• No final de Q3 2022 reportamos um saving do custo de mídia paga de 2.5M
• A base e eventos próprios é utilizado por 12+ squads e passou a ser a fonte oficial de dados do time de marketing
• Não era o propósito inicial, mas a base de eventos passa a prover dados para o time de atendimento
• Aprendemos a fazer nosso próprio motor de regras de segmentação que irá substituir uma solução de terceiros que custa 120k USD/ano

Aprendizados dessa jornada

1. Uma disciplina nova na companhia que não conhece a iniciativa, deve ser comunicado e alinhado as expectativas com o dobro de vigor, em todos os níveis, incluindo a expectativa de quando se espera capturar o primeiro impacto.
2. Produto técnico e de plataforma precisa de constante comunicação de updates e boa documentação de como usar de forma “self-service” pelos times internos, e também uma forma visual e criativa que ajude as pessoas não-técnicas a entender.
3. Tenha muito cuidado com expectativas e deslumbramentos que chegam disfarçadas de benchmarking. Isso pode ser, na verdade, o modelo mental de “pensar na solução ao invés de entender o problema” e não observar ele por diferentes perspectivas e hipóteses. Elas geram atrito e reduzem a autonomia dos times, tirando o foco do problema.

Espero que esse material ajude com algumas referências, aprendizado e reflexões.