A maioria dos times quer saber quais campanhas realmente geram dinheiro. O que trava isso é a atribuição: os dados de venda ficam espalhados em sistemas diferentes, cada um com seu formato, e conectar isso à mensagem que gerou a compra vira um projeto à parte. Por isso os times acabam voltando para aberturas e cliques: esses números já estão no dashboard.
A solução é trazer a receita para a plataforma de mensageria num formato que ela realmente consiga usar. Veja como fazer isso no Pushwoosh.
Por que os dados de receita nunca chegam na sua plataforma de mensageria 💰
O motivo é o formato: a receita nunca chega em 1 formato só.
Por exemplo, o seu SDK dispara um evento de compra in-app quando alguém compra moedas do jogo. O seu backend envia um OrderPlaced personalizado. Stripe, Mercado Pago e Shopify enviam seus próprios eventos de webhook para assinaturas e pedidos da loja. Cada um com nomes de campo diferentes, estrutura diferente, uma ideia diferente do que “valor” significa.
Para reportar receita cruzando tudo isso, alguém precisaria escrever uma lógica personalizada para cada fonte e manter isso sincronizado. A maioria dos times não faz isso porque raramente é prioridade — até chegar a revisão de fim de trimestre. E aí os dados simplesmente não estão lá. Então o rastreamento de receita fica pra depois, e o time continua reportando aberturas porque essas métricas padrão já estão conectadas.
E dá pra resolver rápido: tudo se resume a trazer a receita para 1 formato consistente.
1 evento para toda a sua receita
O Pushwoosh resolve o problema do formato com 1 evento nativo: PW_Conversion. Não importa qual seja a fonte original, a receita chega em 1 registro normalizado com um conjunto fixo de campos:
- value — o valor da transação
- currency — ex.: BRL, USD ou EUR
- transaction_id e product_id — identificadores opcionais
Só isso. A renovação de uma assinatura, uma compra in-app, um pedido pós-PIX — tudo vira o mesmo tipo de evento. Assim que a receita chega como PW_Conversion, tudo o que vem depois lê os mesmos dados: segmentação RFM, Customer Journeys, dashboards e o ManyMoney AI.
2 formas de começar a rastrear
Você configura eventos de conversão por aplicativo, e existem 2 caminhos. Escolha o que combina com como os seus dados de venda já fluem.
- Mapear um evento existente — sem precisar de código. Se os dados de venda já chegam ao Pushwoosh por outro evento, é só apontar o Pushwoosh para ele. Escolha o evento de origem e mapeie os campos: qual atributo carrega o preço, qual carrega a moeda. O Pushwoosh então gera um registro PW_Conversion toda vez que aquele evento dispara, sem mudar uma linha sequer do seu app. Você pode mapear várias fontes ao mesmo tempo — um evento personalizado purchase_completed junto com um webhook do Stripe, Mercado Pago ou Shopify.
- Enviar PW_Conversion direto pelo código. Se preferir enviar a receita de forma explícita, adicione uma chamada postEvent onde uma compra é concluída no seu app ou backend. Esse caminho precisa de uma mãozinha do seu time de dev, mas é uma integração pequena e feita uma única vez.
Quais eventos você pode transformar em receita (e quais não pode)
O caminho de mapeamento funciona com qualquer evento que carregue um valor monetário:
- Eventos personalizados — o seu próprio purchase_completed, subscription_renewed, order_placed.
- Eventos padrão — quando representam uma ação paga.
- Eventos de webhook recebidos — Stripe, Mercado Pago, Shopify e outras fontes de pagamento conectadas.
O que você não pode mapear é um evento sem valor pra ler. App_open, screen_view ou push_opened só registram o que o usuário fez. Sem um valor, não tem o que converter.
O que você consegue medir com a receita já entrando
Essa é a recompensa. Com a receita normalizada, 3 coisas que antes exigiam trabalho manual viram funcionalidade nativa:
- Segmentar por quanto o cliente gasta. A segmentação RFM lê o PW_Conversion diretamente, então seus clientes que mais gastam caem automaticamente no segmento Champions, prontos para receber uma oferta de fidelidade.
- Provar quais jornadas realmente geram compra. Defina o PW_Conversion como uma Meta de Conversão em qualquer Customer Journey. Depois de rodar, as estatísticas da meta mostram quantos usuários compraram de verdade, não só quantos abriram a mensagem. Aquela pergunta “esse fluxo valeu a pena?” finalmente tem resposta direto no canvas.
- Mostrar a receita nos dashboards ao lado das outras métricas de desempenho que importam pro seu app, sem construir lógica personalizada para cada evento de compra.
Encontre o seu tipo de app aqui
A mesma configuração se adapta a como o seu app realmente gera receita. Encontre a linha que mais se parece com o seu caso:
| Tipo de app | Eventos que você mapeia ou envia | O que você finalmente enxerga |
|---|---|---|
| E-commerce | Mapear order_placed + webhook do Mercado Pago, Stripe ou Shopify | Quais fluxos de recuperação de carrinho geram pedidos reais; RFM por valor gasto pra achar clientes recorrentes antes da Black Friday |
| Games | Enviar iap_completed, battle_pass_bought pelo código | Se uma oferta pós-fase converte, e não só é aberta; segmentos por gasto para jogadores de alto valor |
| Assinatura (mídia, streaming) | Mapear subscription_renewed, plan_upgraded (Stripe, App Store) | Se jornadas de reconquista geram reassinaturas de verdade; RFM por recência de renovação |
| FinTech | Mapear premium_subscribed, first_trade ou um webhook de pagamento via PIX | Quais estímulos de onboarding levam a contas com saldo; segmentos por volume de transação |
| Delivery de comida | Mapear order_placed do seu backend | Quais notificações de reengajamento geram novos pedidos; RFM por recência do último pedido |
| Viagem / reservas | Mapear booking_confirmed + extras como seat_upgraded | Quais fluxos de queda de preço convertem em reserva; segmentos por valor da viagem |
order_placed + webhook do Mercado Pago, Stripe ou Shopifyiap_completed, battle_pass_bought pelo códigosubscription_renewed, plan_upgraded (Stripe, App Store)premium_subscribed, first_trade ou um webhook de pagamento via PIXorder_placed do seu backendbooking_confirmed + extras como seat_upgradedColoque a receita onde os profissionais de marketing já trabalham
Os eventos de conversão são 1 peça de uma direção maior do Pushwoosh: deixar a receita visível onde os profissionais de marketing já trabalham, em vez de num relatório que eles precisam ir buscar.
Você já decide o que enviar, para quem e com que frequência. Hoje essas decisões são baseadas em aberturas e cliques, porque é só isso que a gente devolve pra você. Envie o PW_Conversion, e as mesmas decisões passam a ser tomadas em cima de dinheiro: quais campanhas manter, quais matar, quais segmentos merecem mais envios — e quais estão só custando cancelamentos de inscrição sem retorno nenhum.
Existe um ganho que se acumula assim que a receita começa a fluir:
Coloque o rastreamento de receita pra funcionar no Pushwoosh
Comece pelo caminho que dá menos trabalho: mapeie um evento que você já envia, ou passe o exemplo de postEvent pro seu time de dev. Defina o PW_Conversion como Meta de Conversão na sua próxima jornada, e veja a receita aparecer ao lado das aberturas e cliques.
