Adicionar wallet ao seu stack ou trocar de plataforma?

Se a sua plataforma de engajamento de clientes não tem wallet passes nativos, existem 2 caminhos. Conectar uma ferramenta de passes e manter 2 sistemas sincronizados, ou migrar para uma plataforma que emite passes do Apple e do Google Wallet no mesmo perfil do cliente. O primeiro é mais rápido para começar. O segundo é mais simples de operar quando o wallet passa a fazer parte das suas jornadas.

Escrevemos este texto para times em plataformas como Braze, OneSignal ou CleverTap que querem wallet passes sem desmontar tudo. Para uma visão por fornecedor, veja o comparativo de Wallet passes.

De onde você está partindo

O suporte a wallet varia muito entre plataformas de engajamento. A Braze adiciona wallet por meio de parceiros como a PassKit. O OneSignal não tem wallet passes nativos. Confira a documentação atual da sua plataforma antes de planejar, porque isso muda.

Sem suporte nativo, o passe fica em 1 sistema e o cliente em outro. Cada passe que você emite, atualiza ou segmenta precisa de dados dos 2.

No Brasil, onde o Android passa de 85% dos celulares, esse problema dobra de tamanho: a maior parte da sua base vai salvar o passe no Google Wallet, não no Apple Wallet. Antes de comparar os caminhos, confirme que a ferramenta escolhida emite os 2 tipos de passe de forma nativa, e não só o da Apple.

Caminho A: manter sua CEP e adicionar uma ferramenta de passes

Você mantém a plataforma atual para push, e-mail e segmentos e conecta uma ferramenta de passes independente para o Apple e o Google Wallet.

Na prática, costuma funcionar assim. A sua CEP ou o seu backend chama a API da ferramenta de passes para emitir os passes, muitas vezes via webhooks. Se a ferramenta de passes expõe eventos, eles voltam para a sua CEP, e você consegue segmentar os titulares.

A vantagem é real. Nada migra. O time mantém as ferramentas e as jornadas, e você pode começar com 1 caso de uso, como um cartão de fidelidade.

A desvantagem cresce com o tempo. 2 bancos de dados para sincronizar, 2 assinaturas, 2 avaliações de segurança e de GDPR. Cada cenário que combina uma atualização do passe com uma mensagem, como “seus pontos expiram em breve”, é montado em 2 ferramentas.

Caminho B: migrar para uma plataforma com wallet nativo

Você leva a mensageria para uma plataforma que emite wallet passes de forma nativa, no mesmo perfil do push, das mensagens in-app, do e-mail e do SMS.

Os passes são emitidos por User ID dentro da plataforma. Segmentos, jornadas e canais enxergam o titular do passe como 1 cliente só. 1 etapa da jornada emite o passe, e a seguinte envia o link.

Você fica com 1 perfil, 1 jornada e 1 contrato. Atualizações do passe e mensagens saem do mesmo gatilho, e não existe camada de sincronização para vigiar.

O custo é a própria migração: mudanças no SDK, importação de dados, reconstrução de jornadas e templates. Ela compensa quando o wallet é um canal de longo prazo, não uma campanha pontual.

Como decidir

Responda a 4 perguntas.

Se 2 ou mais respostas forem “longo prazo”, “muitos”, “sem desenvolvedores” ou “menos operadores”, olhe com atenção para o Caminho B. Se nenhuma for, o Caminho A é uma escolha perfeitamente boa, e você pode rever a decisão daqui a 1 ano.

A pergunta sobre o time pesa mais para startups e scaleups brasileiras com times enxutos. Quando os mesmos 2 ou 3 desenvolvedores cuidam do app, do backend e das integrações, uma camada de sincronização a mais concorre direto com o roadmap do produto.

Quanto custam 2 ferramentas

O Caminho A parece mais barato no primeiro dia, porque nada muda de lugar. Ao longo de 1 ano, some as partes que nunca aparecem na fatura do fornecedor de passes: construir a integração, manter a sincronização, o trabalho duplicado nas jornadas e uma segunda avaliação de fornecedor.

O Caminho B concentra o custo no começo: o trabalho de migração e depois 1 mensalidade de plataforma. Compare os 2 num horizonte de 12 a 24 meses, não de 1.

Pense também no calendário. Black Friday, em novembro, é o maior evento de e-commerce do Brasil, e o Natal vem logo depois. Se o seu primeiro caso de uso de wallet é um cupom para essas datas, o Caminho A coloca o passe no ar a tempo. Se você escolher o Caminho B, programe a migração para terminar antes do pico, não no meio dele.

Checklist de migração

Se escolher o Caminho B, planeje a mudança em torno do cliente, não da ferramenta.

• Audite o que você envia. Liste as campanhas de push, e-mail, SMS e in-app, as jornadas e os segmentos que precisam migrar.
• Mapeie os dados. User IDs, tags, eventos e registros de consentimento. O User ID é o que liga um passe a um cliente.
• Configure o wallet uma vez. Um certificado Pass Type ID da Apple (conta Apple Developer, US$ 99 por ano) e um Issuer ID do Google com a service account do Pushwoosh convidada para o seu emissor.
• Integre o SDK. Substitua o SDK antigo no app e teste o push antes de mover o tráfego.
• Reconstrua primeiro as jornadas principais. Boas-vindas, carrinho abandonado, reconquista e depois os novos cenários de wallet.
• Planeje o lançamento dos passes. Emita os passes a partir de uma etapa da jornada e envie o link por e-mail, SMS ou push.
• Rode em paralelo por pouco tempo. Mantenha a plataforma antiga durante uma sobreposição curta e depois desligue.

Durante a migração, use a API para emitir passes a partir do seu próprio backend.

Simplifique seu stack com o Pushwoosh

O Pushwoosh emite passes nativos do Apple e do Google Wallet no mesmo User ID, nos mesmos segmentos e nas mesmas jornadas do push, das mensagens in-app, do e-mail, do SMS e do WhatsApp. É 1 plataforma, hospedada em infraestrutura própria na Alemanha e nos EUA, com conformidade com o GDPR e SOC 2 Type 2. Veja onde o Pushwoosh se encaixa entre as opções de wallet.

Adicionar wallet não deveria significar pendurar mais 1 ferramenta. Deveria significar 1 perfil de cliente que todos os canais conseguem usar.

FAQ