Alguns recursos do mobile push da Dito — imagem, botões de ação, deeplink e campos customizados — só funcionam se o aplicativo da sua marca estiver preparado para recebê-los. Este artigo explica, sem linguagem técnica, o que precisa ser feito, por quem, e como você confirma que está tudo pronto antes de disparar uma campanha.

• Nível de Acesso: Administrador, Administrador de Dados.
  Persona: Analista de Marketing, Gerente de CRM, Desenvolvedor Mobile.

Antes de tudo: quem faz o quê?

Pense na notificação como uma encomenda.

• A Dito é a transportadora. Ela monta o pacote (título, texto, imagem, links, dados extras) e entrega no aparelho do cliente.

• O app da sua marca é a casa. É ele quem abre o pacote e decide o que fazer com o conteúdo.

Se a casa não tiver uma caixa de correio do tamanho certo, a encomenda chega — mas o conteúdo não é aproveitado. É exatamente isso que acontece com o rich push: a Dito envia a imagem, mas se o app não souber exibir imagem, o cliente vê apenas título e texto.

Ponto mais importante deste artigo: esses recursos não são ativados na plataforma da Dito. Eles dependem de uma alteração no código do aplicativo, feita pelo time (ou fornecedor) que desenvolve o app da marca.

O que é a SDK da Dito

SDK é um pacote de código que a Dito disponibiliza para ser instalado dentro do app da marca. É a peça que conecta o aplicativo à plataforma.

Link para SDK de Mobile Push da Dito

Os cinco recursos

Texto

O que é: o título e o corpo da mensagem — a parte que o cliente lê antes de decidir se toca na notificação.

O que o app precisa fazer: Na maioria dos casos, nada além de ter a SDK instalada. O próprio sistema operacional exibe título e texto automaticamente.

Como saber se está pronto: Dispare um teste para um iPhone e um Android e compare com o que você escreveu na plataforma. Título e corpo devem chegar idênticos, com acentuação e emojis corretos.

Sobre o tamanho da mensagem: cada aparelho mostra uma quantidade diferente de caracteres antes de cortar o texto com "...". Coloque a informação essencial no início do título e não dependa do final da frase para a mensagem fazer sentido — o texto completo só aparece quando o cliente expande a notificação, e a maioria não expande. Isso não depende do app: é uma regra de escrita.

Imagem

O que é: a notificação exibe uma foto ou banner além do texto — produto, campanha, coleção.

O que o app precisa fazer: baixar a imagem que veio na notificação e exibi-la. No iOS, isso exige um componente extra no aplicativo, criado especificamente para processar notificações antes de mostrá-las na tela. É o item mais frequentemente esquecido nas integrações: o Android costuma funcionar e o iOS, não.

Como saber se está pronto: dispare um teste com imagem para um iPhone e um Android. Em ambos, ao arrastar ou pressionar a notificação, a imagem deve aparecer expandida.

Se não estiver pronto: a notificação chega normalmente, mas sem a imagem. O cliente vê apenas título e texto.

Botões de ação

O que é: a notificação exibe até dois botões com ações próprias, por exemplo "Ver oferta" e "Não tenho interesse".

O que o app precisa fazer: reconhecer cada botão que a Dito envia e definir o que acontece quando o cliente toca nele — abrir uma tela, aplicar um cupom, registrar uma recusa. Os botões não têm comportamento automático: cada um precisa ter uma ação programada no app.

Como saber se está pronto: em um envio de teste, os botões devem aparecer na notificação e executar a ação esperada ao serem tocados. Botão que aparece mas não faz nada significa que a implementação está incompleta.

Se não estiver pronto: dependendo da versão do sistema operacional, os botões podem não aparecer ou aparecer sem efeito — o que gera uma experiência ruim para o cliente. Não use botões antes de validar.

Observação: No sistema operacional iOS os botões só aparecem quando o usuário clica e segura a notificação push por alguns segundos para expandi-la.

Deeplink

O que é: o toque na notificação abre uma tela específica dentro do app — a página de um produto, o carrinho, a área de cashback — em vez da tela inicial.

O que o app precisa fazer: ter "endereços internos" mapeados para as telas que você quer usar em campanha. Cada tela precisa de um endereço próprio, e o app precisa saber interpretar esse endereço quando ele chega pela notificação.

O que você precisa pedir ao time de app: uma lista dos deeplinks disponíveis, com o endereço exato de cada tela. Guarde essa lista: é ela que você vai consultar na hora de montar campanhas. Sem esse mapeamento, não há como direcionar o cliente com precisão.

Como saber se está pronto: teste cada deeplink da lista. O app deve abrir na tela correta, inclusive quando estava fechado.

Se não estiver pronto: o app abre na tela inicial e o cliente precisa procurar o produto por conta própria. A conversão cai muito.

Campos customizados

O que é: informações estruturadas que viajam junto com a notificação, invisíveis para o cliente, mas usadas pelo app. Exemplo prático: em uma campanha de carrinho abandonado, a Dito envia o identificador do carrinho e o cupom junto com a mensagem. O app lê esses dados e, ao toque, abre o carrinho do cliente já com o cupom aplicado.

O que o app precisa fazer: ler os dados extras com os nomes exatos definidos pela Dito. Este é o ponto mais sensível dos cinco recursos.

Por que o nome exato importa tanto: a Dito publica um contrato de campos — uma lista de nomes padronizados que a plataforma sempre usa. Se o app procurar por um nome diferente do que a Dito envia, ele simplesmente não encontra nada. E o mais delicado: não há mensagem de erro. A notificação chega, o cliente toca, e nada acontece como esperado. Por isso a validação por teste é obrigatória.

O que você precisa fazer: entregar ao time de app a documentação do contrato de campos da Dito e confirmar que a implementação usa exatamente aqueles nomes.

Como saber se está pronto: monte um teste com campos customizados preenchidos e valide se o app executou a ação contextual esperada — abrir o carrinho certo, aplicar o cupom certo.

Se não estiver pronto: a notificação é entregue e o toque não produz o comportamento esperado. Como não existe erro visível, esse tipo de falha pode passar semanas sem ser percebido — e o resultado da campanha fica muito abaixo do potencial.

Checklist para enviar ao time de desenvolvimento

Copie e cole na conversa com o time de app ou com o fornecedor. É suficiente para eles dimensionarem o esforço.

Integração de mobile push com a Dito — recursos necessários

Base
[ ] SDK da Dito instalada (Android e iOS)
[ ] Identificação do contato configurada
[ ] Credenciais de push (Google e Apple) geradas e cadastradas na Dito
[ ] Registro do aparelho confirmado no painel da Dito

Recursos avançados
[ ] Exibição de imagem na notificação (Android)
[ ] Exibição de imagem na notificação (iOS — componente de processamento de notificação)
[ ] Tratamento dos botões de ação enviados pela plataforma
[ ] Rotas de deeplink implementadas + lista de endereços entregue ao time de marketing
[ ] Leitura dos campos customizados conforme o contrato de campos da Dito

Validação
[ ] Teste de cada recurso em aparelho iOS
[ ] Teste de cada recurso em aparelho Android
[ ] Teste com o app fechado, em segundo plano e aberto
[ ] Versão publicada na App Store e no Google Play

Como testar antes de disparar para a base

1. Instale a versão nova do app em pelo menos um iPhone e um Android.

2. Crie uma campanha de teste com todos os recursos ativados de uma vez.

3. Envie apenas para os aparelhos internos.

4. Valide, em cada um: a imagem aparece? Os botões aparecem e funcionam? O deeplink abre a tela certa? A ação contextual dos campos customizados acontece?

5. Repita com o app fechado — é o cenário mais comum na vida real e o que mais revela falhas de implementação.

Só depois de os cinco recursos passarem nos dois sistemas operacionais vale usá-los em campanha para a base.

Precisa de ajuda?

Fale com o seu time de Customer Success na Dito. Podemos participar da conversa com o time de desenvolvimento do app, revisar o que já foi implementado e acompanhar os testes até a primeira campanha com rich push no ar.

FAQ – Perguntas Frequentes

1. Pergunta: Preciso publicar uma nova versão do app?
Resposta: Sim. Todos esses recursos vivem no código do aplicativo. Sem uma nova versão nas lojas, nada muda para o cliente final.

2. Pergunta: Se eu ativar um recurso na campanha e o app não estiver preparado, o envio falha?
Resposta: Não. A notificação é entregue normalmente com título e texto. O que se perde é o recurso avançado — e, no caso dos botões e dos campos customizados, isso pode gerar uma experiência confusa para o cliente. É por isso que a plataforma mostra o aviso antes da confirmação do envio.

3. Pergunta: Meu app já usa outra ferramenta de push. Dá conflito?
Resposta: Pode dar, se duas ferramentas disputarem o recebimento da notificação. Sinalize isso ao time de app no início da conversa — é um cenário conhecido e tem solução, mas precisa ser tratado durante a integração.

4. Pergunta: Um recurso funciona no Android e não no iOS. É normal?
Resposta: É comum, e quase sempre indica implementação incompleta no iOS — em especial no caso da imagem, que exige um componente adicional no aplicativo. Os dois sistemas precisam ser tratados separadamente.

5. Pergunta: Existe limite de tamanho para os campos customizados?
Resposta: Sim. Apple e Google limitam o tamanho total da notificação a cerca de 4 KB. Campanhas que excedem esse limite são bloqueadas na validação, para evitar que o conteúdo seja cortado silenciosamente. Na prática, isso significa enviar identificadores e códigos curtos — não textos longos nem listas grandes.

6. Pergunta: Quem devo procurar se algo não funcionar no teste?
Resposta: Se a notificação não chega, fale com o suporte da Dito. Se ela chega mas o recurso não se comporta como esperado (imagem ausente, botão sem ação, deeplink abrindo a home), a investigação começa no time de app.

Ficou com alguma dúvida ou identificou algum problema? Acione nosso time pelo chat disponível no app dito. (Horário de Atendimento de Segunda a Sexta das 9hrs as 18hrs)