CRMAds: transformar inventário de mídia em espaço vendável.
Plataforma de retail media da CRMBonus, desenhada com o SBT como publisher piloto. Traduzi a documentação e as regras de um produto de mídia denso em jornadas para publisher, anunciante e agência.
As telas apresentadas são conceito. Dados, marcas e valores são ilustrativos.
Recebia a complexidade em estado bruto e a transformava em jornada.
Meu ponto de partida era a documentação do produto: regras de negócio, restrições técnicas, o que o PM havia definido. Meu trabalho era transformar isso em jornadas que fizessem sentido para usuários com necessidades distintas (o publisher, o anunciante, o ad ops), garantindo que cada fluxo respeitasse ao mesmo tempo a regra de negócio e o que a engenharia conseguia construir.
As decisões de feature e o recorte vinham do PM. Eu devolvia os fluxos e as alternativas de interface que davam forma a cada escolha, em conversa próxima com produto e engenharia.
A CRMBonus estava sentada em cima de dois ativos que a mídia tradicional não consegue replicar.
Retail media cresce por um motivo simples: quem tem relacionamento direto com o consumidor tem dado de primeira mão e inventário próprio. A CRMBonus já operava o elo entre varejo e consumidor em escala, com canais próprios: QR code, WhatsApp, cashback. O que faltava era transformar isso em um produto de mídia.
A parceria com o SBT deu forma concreta à aposta: um publisher com audiência massiva, inventário próprio e necessidade de monetizar melhor.
Um publisher tem inventário, mas não tem como vendê-lo de forma estruturada e mensurável.
O anunciante quer alcançar audiência qualificada, mas não quer negociar caso a caso. Entre os dois, faltava produto.
Primeiro desafio: dar forma a um conceito que não existia. O que exatamente é um "espaço publicitário" quando o inventário não é uma página web, e sim um programa de TV, um cupom ou uma mensagem de WhatsApp?
Segundo desafio: tornar operável algo denso. Inventário, campanhas, pedidos, anunciantes, agências, pacing e performance. Tudo precisava caber numa interface que um time de ad ops usasse todo dia.
A CRMBonus tinha dois ativos para vender: espaço de mídia e audiência.
O publisher (o SBT) trazia o inventário de mídia: os espaços onde o anúncio aparece. A CRMBonus trazia o outro lado, o inventário de dados: a audiência da própria base, que dava ao anunciante para quem falar.
A regra de negócio já vinha definida. Meu trabalho de design foi dar a esses dois ativos uma mesma gramática na interface, para que o produto não parecesse dois sistemas colados. O publisher modela o inventário de mídia como programa, com períodos de exibição (dias e faixas de horário); a audiência entra como um catálogo de segmentos, com volume e preço.
Modelei o inventário de mídia como programa + período de exibição. O dropdown "tipo de inventário" foi desenhado para que novos formatos entrem sem redesenhar o produto.
A peça que amarra tudo: cada espaço publicitário disponível para venda.
A definição precisava ser abstrata o suficiente para caber banner em aplicativo, QR code em cupom, espaço em WhatsApp, mídia em e-mail, tela de cashback e push notification patrocinada, sem que nenhum novo formato exigisse repensar o produto.
A tela de detalhe da campanha é onde o conceito inteiro se materializa: veiculação por programa, dia e faixa horária de um lado; do outro, a oferta que chega ao consumidor via QR code no WhatsApp, com giftback atrelado à compra no varejo.
Coloquei performance, veiculação e a prévia do anúncio na mesma tela porque quem opera precisa ver, de uma vez, o que foi comprado, onde vai ao ar e o que o consumidor recebe.
Uma hierarquia clara: publisher, pedido, campanha.
A plataforma não servia um publisher, servia uma rede deles. Isso pedia um topo de hierarquia que a maioria dos ad servers esconde: a gestão dos próprios publishers, cada um com seu ciclo de vida (convite, ativo, suspenso, em teste).
O topo da hierarquia. Cada publisher tem um estado próprio, porque onboarding, operação e suspensão são momentos distintos da relação, e a tela precisa deixar claro em qual deles cada um está.
Dentro de um publisher, a performance por programa: é assim que ele vende, e é assim que o anunciante compra. Fill rate, CPM e receita são as métricas que um publisher realmente olha.
Pedido e campanha são coisas diferentes: o pedido é o acordo comercial (anunciante, agência, budget), a campanha é a execução.
Um pedido, cinco pessoas
Olhe uma linha dessa tela: anunciante, agência, vendedor, trafficker e o publisher dono do inventário. São cinco atores com ritmos e responsabilidades distintas, atravessando o mesmo registro.
O comercial fecha o acordo e some. O ad ops opera todos os dias. Se os dois dividissem a mesma tela, um estaria sempre no caminho do outro.
O sistema existia para ser testado. Este produto foi o teste.
O CRMAds foi um dos primeiros produtos a rodar sobre o design system da casa. Meu papel não era só consumir a biblioteca: era descobrir onde ela quebrava diante de um domínio real.
Retail media cobrou coisas que um catálogo abstrato não previa. O ciclo de vida de uma campanha exigiu estados que não existiam (rascunho, reservada, entregando, pausada, cancelada, finalizada), cada um com peso visual diferente porque não têm a mesma urgência. O pacing exigiu uma barra de progresso que carrega dois números ao mesmo tempo: quanto foi entregue e quanto foi contratado.
Cada peça que propus voltou para o sistema, disponível para o próximo produto. É o mesmo raciocínio de plataforma que orientou o produto, aplicado à ferramenta que o constrói.
Governança de acesso: com muitos atores no mesmo sistema, controlar quem entra e com qual permissão deixa de ser detalhe e vira parte do produto.
No MVP, a audiência era informativa. Plugar a base do cliente ficou para depois.
A audiência vinha da base da CRMBonus. Mas abrir isso por completo, deixando cada cliente conectar e ativar a própria base, era um problema grande de integração e de governança de dado. Grande demais para o primeiro teste.
O recorte que entrou foi uma página informativa: mostrava ao publisher os segmentos disponíveis, com volume e preço, como uma vitrine. A ativação real da base do cliente ficou como evolução, para depois de validar que o publisher vendia o inventário básico.
Audiência apresentada como catálogo: cada segmento com volume, atualização e preço. No recorte do MVP, esta camada era informativa.
Desenhei o produto inteiro sem validar uma tela com usuário real.
A estratégia da liderança foi construir primeiro e testar depois, apostando que o negócio se fecharia quando o cliente visse o produto funcionando. É uma aposta legítima em contexto de inovação, e foi a restrição dentro da qual trabalhei.
Mas ela deixou um risco em aberto que eu reconheço: proto-persona e alinhamento com o PM são proxy, não evidência. Desenhei decisões de fluxo sobre um usuário presumido, sem confrontá-las com um usuário observado.
Não é uma crítica à decisão de negócio. É o que eu, como designer, faria para reduzir a distância entre o que projetamos e o que o usuário confirmaria.
O MVP estava pronto para teste quando encerrei meu ciclo na empresa.
O conceito foi validado com liderança, engenharia e time de inovação. Estas eram as métricas definidas para a validação:
| MÉTRICA | O QUE RESPONDERIA |
|---|---|
| Tempo até publicação | O produto é operável? |
| Fill rate | O inventário está sendo vendido? |
| Recorrência | O anunciante volta? |
| CTR e ROI | A mídia entrega resultado? |
| NPS | O publisher confia na plataforma? |