Warum nicht AMP for Email?
AMP for Email ist Googles Technologie, um echte interaktive Komponenten — Karussells, Formulare, Live-Preise — nativ innerhalb einer Nachricht auszuführen, ganz ohne Tap-through. Es ist eine legitime Technologie und eine naheliegende Frage: Warum baut MailInApp nicht darauf auf, statt (oder zusätzlich zu) kinetischem HTML/CSS? Diese Seite legt die Abwägung explizit dar, denn es ist eine bewusste Wette, kein Versehen.
Was AMP for Email tatsächlich ist, und seine zwei Kosten
AMP-Nachrichten werden als zusätzlicher MIME-Teil neben dem regulären HTML ausgeliefert, gebaut mit einem eingeschränkten Satz von amp-*-Komponenten (Googles AMP-Framework, für E-Mail zweckentfremdet). Wo es rendert, ist es wirklich nativ — für dieses Postfach ist kein statischer Fallback nötig.
Es bringt zwei Kosten mit sich, die in keiner Feature-Vergleichstabelle auftauchen:
- Genehmigung pro Absender. Jede sendende Domain muss sich bei Google registrieren und eine Prüfung bestehen, bevor irgendein Empfänger jemals eine AMP-Nachricht von ihr zu sehen bekommt — ein Nadelöhr außerhalb Ihrer Kontrolle, mit eigenem Zeitplan und Ablehnungsrisiko, vor jeder einzelnen Kampagne.
- Eingeschränkte Rendering-Unterstützung. Nur Gmail, Yahoo Mail und Mail.ru rendern AMP überhaupt. Jeder andere Client — Apple Mail, Outlook (klassisch und neu), Fastmail, Proton, Samsung Mail — ignoriert den AMP-Teil vollständig und fällt auf den mitgelieferten reinen HTML-Teil zurück.
Die Reichweiten-Rechnung
Laut Litmus' Daten zum Marktanteil von E-Mail-Clients (~1 Mrd. erfasste Öffnungen, Mai 2026):
| | Anteil an Öffnungen | | --- | --- | | Apple Mail | 64,7 % | | Gmail | 24,1 % | | Outlook (alle Versionen) | 6,9 % | | Yahoo Mail | 2,6 % | | Alles andere | 1,7 % |
Gmail und Yahoo zusammen sind das einzige reale AMP-Publikum und machen zusammen rund 27 % der Öffnungen aus. Die übrigen ~73 %, angeführt von Apple Mail allein mit fast zwei Dritteln aller Öffnungen, würden eine AMP-Komponente niemals zu sehen bekommen, egal wie gut sie gebaut wäre. Selbst innerhalb von Gmail funktioniert AMP for Email nur, wenn der Empfänger ein Gmail-Konto über Gmails eigenen Client liest; die mobile App, die ein Nicht-Gmail-Postfach (IMAP) liest, zählt ebenfalls nicht.
Jede Liste echter Empfänger wird mehrheitlich aus Apple Mail bestehen. Die interaktive Erfahrung auf AMP zu setzen bedeutet, dass der Großteil dieser Liste sie nie zu sehen bekommt.
Warum kinetisches HTML die bessere Wette für eine typische Liste ist
Die kinetische Stufe von MailInApp — :checked-gesteuerte CSS-Zustandsautomaten für Karussells, Akkordeons, Abstimmungen, Glücksräder, plus echte In-E-Mail-<form>-Übermittlungen, wo unterstützt — erreicht Gmail (Web und mobil), Apple Mail, Yahoo Mail und Samsung Mail: die große Mehrheit der privaten Postfächer, Apple Mail eingeschlossen. Siehe E-Mail-Client-Unterstützung für die vollständige Matrix und Wie Fallbacks funktionieren dafür, wie die drei Stufen aus einem Design kompiliert werden.
Das ist der Kern der Abwägung: Dieselbe Investition in die Fallback-Engine zahlt sich über praktisch die gesamte Liste aus, nicht nur über die ~27 %, die AMP je erreichen könnte — und das ganz ohne ein Genehmigungs-Nadelöhr pro Absender vor jeder Kampagne. AMPs Obergrenze ist dort, wo es rendert, höher (wirklich native Komponenten, ganz ohne Tap-through) — aber es kann nicht die primäre interaktive Ebene für eine Zielgruppe sein, die überwiegend nicht aus Gmail besteht.
Schließt das AMP dauerhaft aus?
Architektonisch nicht. Kinetisches HTML/CSS und der einfache Link-Fallback von Stufe 2 sind bereits die sichere Basis, auf die jeder Client zurückfällt — dasselbe Drei-Stufen-Modell, das diese Seite beschreibt, könnte eines Tages einen vierten, AMP-spezifischen Teil für Gmail-/Yahoo-Empfänger obendrauf tragen, ohne dass sich an den anderen Stufen etwas ändert. Es ist nur nicht das, worauf sich der Aufwand der Fallback-Engine zuerst richtet: jedes Postfach mit einer verlässlichen Technik zu erreichen, schlägt ein Viertel der Postfächer nativ zu erreichen und den Rest gar nicht.