Perché MailInApp non usa AMP for Email?

AMP for Email si renderizza solo in Gmail, Yahoo Mail e Mail.ru — circa il 27% delle aperture reali — e richiede che ogni dominio di invio si registri presso Google e superi prima una revisione. L'approccio HTML/CSS cinetico di MailInApp raggiunge la grande maggioranza delle caselle di posta dei consumatori, Apple Mail incluso, senza alcuna barriera di approvazione per mittente.

Quale percentuale delle aperture email può raggiungere realmente AMP for Email?

Circa il 27% — Gmail e Yahoo Mail combinati, secondo i dati di quota di mercato dei client email di Litmus. Apple Mail da sola rappresenta quasi due terzi delle aperture e non renderizza mai AMP, quindi qualsiasi lista di destinatari reale è per la maggior parte irraggiungibile da AMP, non importa quanto bene sia costruito il componente.

MailInApp esclude AMP for Email in modo permanente?

Non a livello architetturale. Lo stesso modello di fallback a tre livelli potrebbe un giorno portare una quarta parte, specifica per AMP, per i destinatari Gmail/Yahoo, oltre agli attuali livelli cinetico, statico e Outlook — semplicemente non è lì che va per prima lo sforzo del motore di fallback, dato che una tecnica affidabile su tutta la lista batte un'esperienza nativa per solo un quarto di essa.

Perché non AMP for Email?

AMP for Email è la tecnologia di Google per eseguire componenti interattivi reali — caroselli, moduli, prezzi in tempo reale — nativamente all'interno di un messaggio, senza bisogno di passare da un tap-through. È una tecnologia legittima, e una domanda naturale: perché MailInApp non si basa su di essa invece di (o insieme a) HTML/CSS cinetico? Questa pagina espone il compromesso in modo esplicito, perché si tratta di una scommessa deliberata, non di una svista.

Cos'è davvero AMP for Email, e i suoi due costi

I messaggi AMP vengono spediti come una parte MIME aggiuntiva accanto all'HTML normale, costruita con un insieme vincolato di componenti amp-* (il framework AMP di Google, riadattato per l'email). Dove viene renderizzato, è genuinamente nativo — nessun fallback statico necessario per quella casella di posta.

Comporta due costi che non compaiono in una tabella di confronto delle funzionalità:

Approvazione per mittente. Ogni dominio di invio deve registrarsi presso Google e superare una revisione prima che qualsiasi destinatario possa mai vedere un messaggio AMP proveniente da esso — un varco fuori dal tuo controllo, con tempistiche proprie e rischio di rifiuto, che si frappone davanti a ogni campagna.
Supporto di rendering ristretto. Solo Gmail, Yahoo Mail e Mail.ru renderizzano AMP. Ogni altro client — Apple Mail, Outlook (classico e nuovo), Fastmail, Proton, Samsung Mail — ignora completamente la parte AMP e torna a qualsiasi parte HTML semplice spedita insieme ad essa.

La matematica della copertura

Usando i dati di quota di mercato dei client email di Litmus (~1 miliardo di aperture monitorate, maggio 2026):

| | Quota di aperture | | --- | --- | | Apple Mail | 64,7% | | Gmail | 24,1% | | Outlook (tutte le versioni) | 6,9% | | Yahoo Mail | 2,6% | | Tutto il resto | 1,7% |

Gmail e Yahoo insieme sono l'unico pubblico AMP reale, e rappresentano circa il 27% delle aperture. L'altro ~73%, guidato da Apple Mail da solo con quasi due terzi di tutte le aperture, non vedrebbe mai un componente AMP per quanto ben costruito. Anche all'interno di Gmail, AMP for Email funziona solo se il destinatario sta leggendo un account Gmail attraverso il client Gmail stesso; l'app mobile che legge una casella di posta non Gmail (IMAP) non è idonea nemmeno lei.

Qualsiasi elenco di destinatari reali sarà in maggioranza Apple Mail. Scommettere l'esperienza interattiva su AMP significa che la maggior parte di quell'elenco non la vedrà mai.

Perché l'HTML cinetico è la scommessa migliore per un elenco tipico

Il livello cinetico di MailInApp — macchine a stati CSS guidate da :checked per caroselli, fisarmoniche, sondaggi, spin-to-win, più veri invii di <form> all'interno dell'email dove supportati — raggiunge Gmail (web e mobile), Apple Mail, Yahoo Mail e Samsung Mail: la grande maggioranza delle caselle di posta dei consumatori, Apple Mail incluso. Vedi Supporto dei client email per la matrice completa e Come funzionano i fallback per come i tre livelli vengono compilati a partire da un unico design.

Questo è il nucleo del compromesso: lo stesso investimento nel motore di fallback ripaga su praticamente l'intero elenco, non solo sul ~27% che AMP potrebbe mai raggiungere — e viene distribuito senza un varco di approvazione per mittente che si frappone davanti a ogni campagna. Il tetto di AMP è più alto nell'unico luogo in cui renderizza (componenti veramente nativi, senza alcun tap-through), ma non può essere il livello interattivo primario per un pubblico che non è affatto per lo più su Gmail.

Questo esclude AMP in modo permanente?

Non a livello architetturale. L'HTML/CSS cinetico e il fallback a link semplice del Livello 2 sono già la base sicura su cui ogni client ricade — lo stesso modello a tre livelli descritto in questa pagina potrebbe un giorno trasportare sopra di sé una quarta parte specifica per AMP per i destinatari Gmail/Yahoo, senza toccare il funzionamento degli altri livelli. Semplicemente non è lì che va per prima lo sforzo del motore di fallback: raggiungere ogni casella di posta con una tecnica affidabile batte il raggiungere nativamente un quarto delle caselle di posta e nient'altro per il resto.