Por que não usar AMP for Email?
AMP for Email é a tecnologia do Google para executar componentes interativos reais — carrosséis, formulários, preços em tempo real — nativamente dentro de uma mensagem, sem exigir clique algum. É uma tecnologia legítima, e uma pergunta natural: por que o MailInApp não é construído sobre ela em vez de (ou além de) HTML/CSS cinético? Esta página expõe essa escolha explicitamente, porque é uma aposta deliberada, não um descuido.
O que o AMP for Email realmente é, e seus dois custos
As mensagens AMP são enviadas como uma parte MIME extra, junto com o HTML normal, construída com um conjunto restrito de componentes amp-* (o framework AMP do Google, reaproveitado para e-mail). Onde ele renderiza, é genuinamente nativo — não é preciso nenhum fallback estático para aquela caixa de entrada.
Isso vem com dois custos que não aparecem em uma tabela de comparação de recursos:
- Aprovação por remetente. Todo domínio de envio precisa se registrar no Google e passar por uma revisão antes que qualquer destinatário veja uma mensagem AMP vinda dele — uma barreira fora do seu controle, com prazo e risco de rejeição próprios, na frente de toda campanha.
- Suporte de renderização restrito. Apenas Gmail, Yahoo Mail e Mail.ru renderizam AMP. Todo outro cliente — Apple Mail, Outlook (clássico e novo), Fastmail, Proton, Samsung Mail — ignora completamente a parte AMP e recorre à parte em HTML simples enviada junto com ela.
A matemática do alcance
Usando os dados de participação de mercado de clientes de e-mail da Litmus (~1 bilhão de aberturas rastreadas, maio de 2026):
| | Participação nas aberturas | | --- | --- | | Apple Mail | 64.7% | | Gmail | 24.1% | | Outlook (todas as versões) | 6.9% | | Yahoo Mail | 2.6% | | Tudo o mais | 1.7% |
Gmail e Yahoo juntos são o único público real de AMP, representando aproximadamente 27% das aberturas. Os outros ~73%, liderados apenas pelo Apple Mail com quase dois terços de todas as aberturas, nunca veriam um componente AMP, não importa quão bem construído fosse. Mesmo dentro do Gmail, o AMP for Email só funciona se o destinatário estiver lendo uma conta do Gmail pelo próprio cliente do Gmail; o aplicativo móvel lendo uma caixa de entrada não Gmail (IMAP) também não se qualifica.
Qualquer lista de destinatários reais vai ser majoritariamente Apple Mail. Apostar a experiência interativa no AMP significa que a maior parte dessa lista nunca a verá.
Por que o HTML cinético é a melhor aposta para uma lista típica
O nível cinético do MailInApp — máquinas de estado em CSS controladas por :checked para carrosséis, acordeões, enquetes, roleta premiada, além de envios reais de <form> dentro do e-mail onde há suporte — alcança Gmail (web e mobile), Apple Mail, Yahoo Mail e Samsung Mail: a grande maioria das caixas de entrada de consumidores, Apple Mail incluído. Veja Suporte a clientes de e-mail para a matriz completa e Como os fallbacks funcionam para saber como os três níveis são compilados a partir de um único design.
Esse é o núcleo da escolha: o mesmo investimento no motor de fallback compensa em praticamente toda a lista, não apenas nos ~27% que o AMP conseguiria alcançar — e isso é lançado sem uma barreira de aprovação por remetente na frente de cada campanha. O teto do AMP é mais alto no único lugar em que ele renderiza (componentes verdadeiramente nativos, sem clique algum), mas ele não pode ser a camada interativa principal para um público que é, em sua imensa maioria, não Gmail.
Isso descarta o AMP permanentemente?
Não arquiteturalmente. O HTML/CSS cinético e o fallback de link simples do Nível 2 já são a base segura à qual todo cliente recorre — o mesmo modelo de três níveis que esta página descreve poderia, algum dia, carregar uma quarta parte, específica para AMP, para destinatários de Gmail/Yahoo, sem tocar em como os outros níveis funcionam. Simplesmente não é para onde o esforço do motor de fallback vai primeiro: alcançar toda caixa de entrada com uma técnica confiável vale mais do que alcançar nativamente um quarto das caixas de entrada e nada no resto.