Mobile Apps und Deeplinks

Ein Kurzlink, der zu einer mobilen App führt, hat drei Publika zugleich: Leute, die die App schon haben, Leute, die sie nicht haben, und Leute, deren Browser in einer anderen App steckt. Diese Seite deckt alle drei ab, dazu die beiden Einrichtungsteile, die den Unterschied machen — die Verknüpfungsdateien auf Ihrer Domain und den verzögerten Klick-Kontext, den Ihre App beim ersten Start lesen kann.

Was der Mobil-Bereich macht

Öffnen Sie einen Link, gehen Sie auf den Reiter Mobil und schalten Sie mobile Ziele ein. Für jede Plattform können Sie drei Adressen setzen:

• App-Link — die Adresse innerhalb Ihrer App: Ihr eigenes Schema mit einem Pfad (myapp://product/42), ein Android-Intent oder ein universeller https-Link.
• Store-Adresse — die Seite im App Store oder bei Google Play, genutzt, wenn sich die App nicht öffnet.
• Web-Ausweichziel — eine Seite für Besucher, die Sie lieber gar nicht in den Store schicken.

Alles ist optional. Ein Link mit nur einer Store-Adresse ist eine schlichte Store-Weiterleitung. Ein Link mit App-Link und Store-Adresse bekommt das volle Verhalten: Die Seite versucht zuerst die App und geht weiter in den Store, wenn nichts passiert.

Zwei weitere Einstellungen entscheiden, was außerhalb eines gewöhnlichen Handy-Browsers geschieht:

• Tablets — wie Smartphones behandeln (die Voreinstellung) oder wie Desktop.
• In-App-Browser — was zu tun ist, wenn der Link in Instagram, TikTok, Facebook oder einer ähnlichen App geöffnet wird.

Desktop-Besucher folgen dem Desktop-Ziel, wenn Sie eines setzen, und sonst dem Hauptziel des Links. Nichts am Mobil-Bereich ändert, was Desktop-Besucher sehen, solange Sie es nicht verlangen.

Warum In-App-Browser eine eigene Regel brauchen

Die meisten Linkklicks in einem sozialen Feed erreichen nie Safari oder Chrome. Sie öffnen sich in einer Web-Ansicht innerhalb der App selbst, und mehrere dieser Web-Ansichten behalten jede Navigation für sich: Ein universeller Link bleibt in der Web-Ansicht, und ein eigenes Schema tut still gar nichts. Das ist kein Fehler, den Sie vom Link aus beheben können — es ist eine Entscheidung der App, der die Web-Ansicht gehört.

Deshalb gibt Ihnen die Einstellung drei ehrliche Optionen:

| Wahl | Was der Besucher bekommt | | --- | --- | | Versuchen, die App zu öffnen | Die Zwischenseite probiert den App-Link; ist bekannt, dass die Web-Ansicht ihn blockiert, überspringt die Seite das Warten und zeigt, wie sich der Link im Handy-Browser erneut öffnen lässt. | | Direkt in den Store | Gar kein App-Versuch — nützlich für Installationskampagnen, bei denen die Store-Seite das Ziel ist. | | Zum Web-Ausweichziel | Der Besucher bleibt im Web, was für Content-Links oft die beste Antwort ist. |

Verknüpfungsdateien: die Einrichtung, mit der Links die App lautlos öffnen

Damit ein Link Ihre App ohne Zwischenstopp im Browser öffnet, muss das Betriebssystem wissen, dass Ihre Domain und Ihre App zusammengehören. Beide Plattformen prüfen das mit einer Datei, die von der Domain selbst ausgeliefert wird:

https://go.brand.com/.well-known/apple-app-site-association
https://go.brand.com/.well-known/assetlinks.json

Diese Dateien schreiben Sie nicht selbst. Öffnen Sie unter Domains die Domain und tragen Sie Ihre Apps unter Mobile Apps ein:

• für iOS: die App-ID in der Form TEAMID.com.company.app und die Pfade, die die App behandeln soll (* deckt jeden Kurzlink ab);
• für Android: den Paketnamen und die SHA-256-Signatur-Fingerprints aus der Play Console.

Die Plattform baut beide Dateien und liefert sie von Ihrer Domain aus, mit genau der Antwort, die beide Plattformen verlangen: Status 200, keine Weiterleitungen, application/json, keine Transportkomprimierung. Der letzte Punkt wiegt schwerer, als er klingt — ein Proxy, der die Datei unterwegs komprimiert, ist einer der häufigsten Gründe, warum App-Links stillschweigend aufhören zu funktionieren.

Die Einrichtung prüfen

Der Button Dateien prüfen holt beide Dateien von Ihrer Live-Domain und meldet, was eine Plattform sähe. Die Befunde führen zu konkreten Korrekturen:

| Befund | Was zu tun ist | | --- | --- | | Die Domain hat nicht geantwortet | Die Domain liefert noch keinen Traffic aus, oder das DNS propagiert noch. | | Die Datei fehlt | Für diese Domain sind keine Apps eingerichtet, oder die Anfrage erreicht die Plattform nie. | | Die Domain leitet diese Adresse weiter | Etwas vor der Domain schreibt /.well-known/ um. Die Plattformen folgen hier keinen Weiterleitungen. | | Mit dem falschen Typ ausgeliefert | Die Antwort ist HTML, meist eine 404-Seite eines anderen Dienstes. | | Die Antwort kommt komprimiert an | Ein Proxy komprimiert die Datei. Daran können die Prüfungen beider Plattformen scheitern. | | Keine App angegeben | Die Datei ist gültig, für diese Plattform aber leer — tragen Sie die App im Dashboard ein. |

Sind die Dateien einmal an Ort und Stelle, cachen beide Plattformen sie in ihrem eigenen CDN, sodass eine frische App-Installation eine Weile brauchen kann, um eine Änderung aufzunehmen. Die App neu zu installieren ist beim Testen der verlässliche Weg, ein erneutes Lesen zu erzwingen.

Verzögerter Klick-Kontext nach der Installation

Ein Besucher ohne Ihre App klickt einen Link, landet im Store, installiert die App und öffnet sie. In diesem Moment weiß die App nichts darüber, woher die Person kam — die Browsersitzung und die App sind zwei unverbundene Welten.

Schalten Sie Klick-Kontext nach der Installation liefern ein, und die Plattform behält für ein paar Stunden einen kurzen Gerätefingerabdruck: Plattform, Haupt-OS-Version, Sprache, Land, Bildschirmgröße, Zeitzone und Netzbetreiber. Darin steckt keine IP-Adresse, keine Werbekennung und nichts, was sich auf eine Person zurückführen ließe.

Beim ersten Start fragt Ihre App die Plattform, ob ein Klick stattgefunden hat:

curl -X POST https://go.brand.com/__dl/claim \
  -H 'content-type: application/json' \
  -d '{
    "platform": "ios",
    "os_version": "17.4",
    "language": "de",
    "timezone_offset": 120,
    "screen_width": 1170,
    "screen_height": 2532,
    "pixel_ratio": 3
  }'

Ein Treffer antwortet mit dem ursprünglichen Link und seinen Kampagnen-Tags:

{
  "matched": true,
  "confidence": "high",
  "score": 100,
  "matched_on": ["screen", "timezone_offset", "language", "os_version"],
  "url": "myapp://product/42",
  "domain": "go.brand.com",
  "slug": "promo",
  "link_id": "lnk_...",
  "utm": { "utm_source": "newsletter" },
  "click_id": "...",
  "clicked_at": "2026-08-14T10:00:00.000Z"
}

Kein Treffer antwortet mit {"matched": false} — und ebenso eine zweite Anfrage zu demselben Klick, denn der Eintrag wird genau einmal übergeben.

Die Grenzen, klar gesagt

• Die Zuordnung ist probabilistisch. Zwei Geräte desselben Modells, im selben Netz, in derselben Zeitzone und Sprache sehen für diese Methode identisch aus. Deshalb trägt jede Antwort ein confidence und die Liste der Attribute, anhand derer entschieden wurde: high heißt, Bildschirmgröße und Zeitzone passten bei einem frischen Klick; low heißt, behandeln Sie es als Hinweis und nicht als Tatsache.
• Das Fenster sind Stunden, keine Tage. Der Fingerabdruck verfällt zwei Stunden nach dem Klick, und die Konfidenz sinkt schon nach den ersten fünfzehn Minuten.
• Senden Sie die Anfrage einmal, beim ersten Start. Der Eintrag wird vom ersten erfolgreichen Treffer verbraucht; ein zweiter Aufruf liefert nichts.
• Eine Store-Weiterleitung ohne Zwischenseite sammelt weniger. Bildschirmgröße und Zeitzone kennt nur die Seite, die im Browser läuft — ein Link, der direkt in den Store geht, trifft allein über Sprache und OS-Version und sagt das auch, mit geringerer Konfidenz.

Test-Checkliste

1. Öffnen Sie den Link auf einem Handy mit installierter App: Er sollte in der App landen.
2. Öffnen Sie ihn ohne die App: Die Seite erscheint kurz, dann öffnet der Store.
3. Öffnen Sie ihn aus einem sozialen Feed: Prüfen Sie, dass Ihre Wahl für In-App-Browser dem entspricht, was Sie erwarten.
4. Öffnen Sie ihn in einem Desktop-Browser: das Desktop-Ziel oder das Hauptziel.
5. Führen Sie Dateien prüfen auf der Domain aus und bestätigen Sie, dass beide Dateien sauber zurückkommen.