Amazon SES kombiniert Klicktracking und App-Deep-Links

Der E-Mail-Klick landet jetzt in der App, nicht mehr im Browser

Sie kennen das Problem vermutlich aus eigener Erfahrung: Eine Kundin öffnet Ihre Warenkorb-Erinnerung auf dem Smartphone, tippt auf den Button „Jetzt weiterkaufen“ – und landet trotz installierter App im mobilen Browser, mit Cookie-Banner, Login-Aufforderung und einem Checkout, der spürbar länger dauert als in der App. Der Grund liegt selten am Kundenwillen, sondern an der Technik dahinter: Amazon SES leitet Klicks aus E-Mails über eine eigene Tracking-Domain um, damit Öffnungs- und Klickraten messbar bleiben. Genau diese Umleitung hat bislang verhindert, dass mobile Betriebssysteme den Link als Deep Link erkennen und die passende App öffnen.

Seit dem 14. August 2026 schließt Amazon Web Services diese Lücke mit einem neuen Attribut für Amazon SES: ses:custom-path. Damit trägt der Versanddienst den ursprünglichen Pfad Ihres Links unverändert durch die Tracking-URL, sodass iOS und Android ihn weiterhin ihren eigenen Deep-Link-Regeln zuordnen können. Amazon Simple Email Service unterstützt mobiles Deep Linking damit erstmals, ohne dass Sie auf die Messwerte verzichten müssen, die Ihr Marketing-Team für Kampagnenreports braucht.

Für den Onlinehandel ist das mehr als eine technische Fußnote. Rückstandsmails, Versandbenachrichtigungen, Retourenlabels und Cross-Selling-Kampagnen laufen fast ausnahmslos über getrackte Links. Jeder Klick, der bislang im Browser statt in der App endete, war ein kleiner Umweg – und Umwege kosten in der mobilen Konvertierung regelmäßig zweistellige Prozentpunkte an Abschlussrate, weil Login-Zustand, gespeicherte Zahlungsmittel und Warenkorb in der App liegen, im Browser aber neu aufgebaut werden müssen.

Wer bereits App-Push und E-Mail parallel bespielt, kennt den Frust doppelt: Die Push-Nachricht öffnet zielsicher die App, die E-Mail zum gleichen Angebot schickt dieselbe Kundin über den Browser auf eine gefühlt andere Baustelle. Bislang war das ein hausgemachter Bruch in der eigenen Customer Journey, kein Schicksal – nur eben einer, der sich mit Bordmitteln von SES nicht beheben ließ.

Ein eigener Pfad hält Tracking und App-Ziel zusammen

Technisch bleibt der Trick simpel: Sie hängen das Attribut ses:custom-path an den -Tag in Ihrer HTML-E-Mail. Fügen Sie dieses Attribut einem Link hinzu, führt SES das Pfadsegment durch die Tracking-URL, sodass mobile Betriebssysteme es mit der Universal-Links-Konfiguration unter iOS beziehungsweise der App-Links-Konfiguration unter Android abgleichen können. Der Klick landet weiterhin zuerst bei SES zur Messung, wird von dort aber mit dem Original-Pfad an das Gerät zurückgegeben – und erst dann entscheidet das Betriebssystem, ob die App oder der Browser öffnet.

Bislang mussten Sie sich bei App-Kampagnen effektiv zwischen zwei Übeln entscheiden: entweder das Klicktracking von SES abschalten und Deep Links direkt verlinken, oder Tracking behalten und die App-Erkennung der mobilen Betriebssysteme faktisch aushebeln. Beides tat weh – im ersten Fall fehlten Ihnen belastbare Kennzahlen für A/B-Tests, im zweiten Fall verschenkten Sie Conversion an unnötige Browser-Umwege. Das neue Attribut erlaubt laut Ankündigung mobiles Deep Linking, ohne das Engagement-Tracking zu deaktivieren – zum ersten Mal müssen Sie also nicht mehr zwischen Meldung und Ziel wählen.

Wer bislang auf spezialisierte Deep-Link-Dienste wie Branch oder AppsFlyer ausgewichen ist, kennt die Rechnung: Solche Plattformen verlangen je nach Klickvolumen schnell dreistellige bis niedrige vierstellige Dollarbeträge im Monat, nur um genau diese eine Lücke zwischen Tracking-Link und App-Ziel zu schließen. Das SES-Attribut kostet Sie dagegen keinen zusätzlichen Cent gegenüber Ihrem bestehenden Sendevolumen – der Preis ist allerdings Konfigurationsaufwand statt Abonnementgebühr, und dieser Aufwand ist nicht trivial.

Für Teams, die SES ohnehin schon als Versanddienst nutzen, ist der Umstieg trotzdem naheliegend: Statt einen zusätzlichen Vertrag samt eigenem SDK, eigenem Consent-Text und eigener Datenverarbeitungsvereinbarung zu verhandeln, bleibt die gesamte Klickstrecke in einem einzigen AWS-Konto. Wer dagegen bereits einen Drittanbieter im Einsatz hat und mit dessen Attributions-Reports zufrieden ist, muss den Wechsel nicht erzwingen – die Kosten-Nutzen-Rechnung hängt stark vom bestehenden Vertragsstand ab.

Domain-Verifizierung als Pflichtübung vor dem ersten Deep Link

Der Haken folgt im zweiten Absatz der Ankündigung: Um die Funktion zu nutzen, benötigen Sie eine eigene Redirect-Domain für das Klicktracking, auf der eine Apple-App-Site-Association-Datei (AASA) oder eine Digital-Asset-Links-Verifizierungsdatei liegt. Ohne diese eigene Domain bleibt SES bei seiner Standard-Tracking-Domain – und die kann naturgemäß nicht auf Ihre App verweisen, weil sie niemandem außer Amazon gehört.

In der Praxis heißt das: CNAME-Eintrag auf die SES-Tracking-Domain, ein gültiges TLS-Zertifikat für diese Subdomain und eine statisch erreichbare Verifizierungsdatei unter dem vorgeschriebenen Pfad, ohne Weiterleitung und ohne Login-Zwang davor. Klingt nach einer Fünf-Minuten-Checkbox, wird in den meisten Unternehmen aber zum eigenen Ticket: DNS-Änderungen laufen über die IT-Abteilung, Zertifikate über das Security-Team, und die Verifizierungsdatei muss exakt das Format treffen, das Apple beziehungsweise Google erwarten.

Wer schon einmal eine AASA-Datei gepflegt hat, weiß, dass „einfacher“ in der AWS-Ankündigung relativ zu verstehen ist. Realistisch sollten Sie für die Erstkonfiguration einen halben bis ganzen Arbeitstag Entwicklerzeit einplanen, plus Wartezeit für DNS-Propagierung und Zertifikatsausstellung – bei einer trägen internen Change-Freigabe schnell auch mehrere Tage.

Wie stark sich Nutzerverhalten inzwischen ohnehin verschiebt, zeigt sich auch daran, wie ChatGPT die Produktsuche in Onlineshops schon jetzt verändert: Wenn Kaufentscheidungen zunehmend außerhalb der klassischen Suchmaschine anlaufen, wird jede verlorene Sekunde zwischen Klick und App-Erlebnis noch teurer.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptA commerce hand aligns a small verification key with a branching click path so one route enters a glazed mobile doorway while the alternate route remains open on paper. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

Zuordnungsdateien entscheiden über den Sprung

Die eigentliche Weichenstellung passiert in der Verifizierungsdatei selbst. Unter iOS erwartet Apple eine apple-app-site-association-Datei mit den korrekten App-IDs und den Pfaden, die zur App weiterleiten dürfen. Unter Android übernimmt eine assetlinks.json mit Package-Name und den SHA-256-Zertifikats-Fingerprints Ihrer App diese Rolle. Beide Dateien müssen mit dem Content-Type application/json ausgeliefert werden – schon ein falsch konfigurierter Webserver, der stattdessen text/plain sendet, reicht aus, damit das Betriebssystem die Datei ignoriert und der Klick stumm im Browser landet.

Besonders unangenehm wird es, wenn ein Content Delivery Network die Verifizierungsdatei zwischenspeichert und nach einem App-Update oder einer Zertifikatsrotation eine veraltete Version ausliefert. Es gibt dann keine Fehlermeldung, keinen Log-Eintrag beim Kunden, nur eine leise ausbleibende App-Öffnung – ein Fehlerbild, das sich in der Support-Warteschlange meist erst nach Tagen als systematisches Muster zeigt, nicht als Einzelfall.

Kommerzielle Deep-Link-Anbieter nehmen Ihnen genau diese Pflege inklusive Monitoring-Dashboard ab und schlagen dafür Aufpreis auf ihre Grundgebühr. Bei Amazon SES bleibt die Verifizierungsdatei vollständig in Ihrer eigenen Verantwortung – ein guter Deal für Teams mit eigenem DevOps, ein zusätzlicher Wartungsposten für alle anderen.

Ein pragmatischer Kompromiss ist ein wöchentlicher automatisierter Abruf der eigenen Verifizierungsdatei per Cronjob, der Statuscode und Content-Type prüft und bei Abweichung Alarm schlägt. Der Aufwand dafür liegt bei wenigen Zeilen Skript – deutlich günstiger als jedes kommerzielle Monitoring-Add-on, aber eben auch etwas, das jemand im Team tatsächlich einrichten und pflegen muss.

Der Web-Rückfall bleibt Teil der Conversion-Strecke

Amazon verweist zur Vertiefung auf die Dokumentation zur Konfiguration eigener Domains für das Öffnen- und Klicktracking sowie auf die FAQ zu den Versandmetriken im SES-Entwicklerhandbuch. Zwischen den Zeilen steht dort ein Hinweis, der für den Handel wichtiger ist als jede App-Statistik: Der Deep Link ist immer nur der Idealfall, nicht die Garantie.

Ist die App nicht installiert, das Zertifikat gerade rotiert oder das Gerät älter als erwartet, muss der Klick trotzdem in einer brauchbaren mobilen Webseite enden – nicht in einer Fehlerseite und nicht in einer Schleife aus drei Weiterleitungen, bevor endlich das Produkt erscheint. Genau solche Bruchstellen sind es, die Kundinnen und Kunden am Ende einer sonst tadellosen Kampagne noch abspringen lassen.

Planen Sie den Web-Rückfall deshalb von Anfang an als gleichwertigen zweiten Pfad, nicht als nachträgliche Notlösung. Ein sauberer Rückfall braucht dieselbe Produktseite, denselben Warenkorbstand und im Idealfall denselben Rabattcode wie der App-Deep-Link – alles andere fühlt sich für die Kundschaft wie ein Bruch in der Erzählung an, selbst wenn die Technik im Hintergrund tadellos funktioniert.

Ein einfacher Praxistest zeigt schnell, wo Ihr Rückfall noch hakt: Deaktivieren Sie kurz die App auf einem Testgerät, klicken Sie den echten Kampagnenlink und stoppen Sie die Zeit bis zur fertig geladenen, korrekten Produktseite. Alles über drei bis vier Sekunden ist für ein mobiles Klickziel bereits grenzwertig – und jede Sekunde darüber sollte einen konkreten technischen Grund haben, keinen achselzuckenden.

Regionen und Konfiguration begrenzen den Nutzen

Die Funktion steht laut Ankündigung in allen AWS-Regionen zur Verfügung, in denen Amazon SES überhaupt betrieben wird. Regionale Verfügbarkeit ist aber nicht mit automatischer Aktivierung zu verwechseln: Sie müssen das Attribut pro Template selbst einbauen, die Redirect-Domain je Absenderdomain konfigurieren und die Verifizierungsdateien für jede betroffene App separat pflegen.

Preislich ändert sich an Ihrer SES-Rechnung nichts – Sie zahlen weiterhin nach Sendevolumen, grob im Bereich von zehn US-Cent pro 1.000 versendete E-Mails, und das neue Attribut kommt ohne Aufpreis dazu. Kostenlos ist allerdings relativ, wenn Sie vorher eine Woche Entwicklerzeit in Domain- und Zertifikatsarbeit investieren müssen, während ein Wettbewerbsprodukt mit eigenem Onboarding-Team diese Arbeit gegen eine monatliche Lizenzgebühr abnimmt.

Für die Entscheidung zwischen Eigenbau und Drittanbieter lohnt sich deshalb eine ehrliche Aufwandsrechnung: Wer ohnehin schon eigene Zertifikate und DNS-Automatisierung betreibt, spart mit dem SES-Attribut auf Dauer eher Geld. Wer solche Prozesse erst aufbauen müsste, sollte die Umstellungskosten realistisch gegen die laufenden Gebühren eines Fertigprodukts stellen, statt vorschnell „kostenlos“ mit „günstig“ zu verwechseln.

Wer solche Kontrollpflichten grundsätzlich unterschätzt, sollte sich auch ansehen, welche Prüfpunkte Website-Betreiber bei Google-Overviews aktuell einplanen sollten – ein weiteres Beispiel dafür, wie sehr technische Detailarbeit inzwischen über Sichtbarkeit und Umsatz entscheidet.

Ein nüchterner Deep-Link-Test für Commerce-Teams

Bevor Sie das Attribut in Ihre Massen-Templates übernehmen, lohnt sich ein enger Testlauf: echte iOS- und Android-Geräte statt Simulatoren, ein bewusst provozierter Zertifikatswechsel, um den Fallback zu prüfen, und ein Vergleich der Klick-zu-App-Öffnungsrate vor und nach der Umstellung. Erst wenn diese Zahl sauber steigt, lohnt sich der nächste Rollout-Schritt.

Ein realistischer Einstieg ist ein einzelner Mail-Typ mit hohem Volumen und klarem Ziel, etwa die Warenkorb-Erinnerung oder die Versandbestätigung. Dort lässt sich der Effekt schnell messen, ohne gleich das gesamte E-Mail-Programm umzustellen – und Fehler in der Verifizierungsdatei fallen auf, bevor sie sich über Dutzende Kampagnen verteilen.

Setzen Sie sich für diesen ersten Mail-Typ eine konkrete Zielmarke, etwa eine um fünf Prozentpunkte höhere App-Öffnungsrate innerhalb von zwei Wochen. Bleibt die Zahl trotz korrekt eingerichteter Verifizierungsdatei flach, liegt das Problem meist nicht an SES, sondern an der App-Konfiguration selbst – ein häufig übersehener Punkt, wenn Marketing und App-Entwicklung getrennte Teams sind und die Universal-Links-Einstellungen seit dem letzten Release nicht mehr aktuell gepflegt wurden.

Amazon SES löst mit ses:custom-path ein enges, klar umrissenes technisches Problem, keine Revolution im E-Mail-Marketing. Genau deshalb lohnt sich der Blick auf die Details: Wer die Domain-Verifizierung ernst nimmt und den Web-Rückfall nicht dem Zufall überlässt, bekommt eine spürbar bessere mobile Klickstrecke, ohne für jeden Deep Link einen zusätzlichen Dienstleister zu bezahlen.