Linkuri profunde. Deschide aplicația. Revino elegant la fallback.
Manifeste Universal Links și App Links, servite de pe domeniul tău personalizat. iOS îți deschide aplicația la atingere; Android face la fel. Fallback către browser pe desktop.
- Universal Links (iOS) și App Links (Android), servite de pe domeniul tău
- Deep link-uri amânate - contextul supraviețuiește instalării aplicației
- Detectare inteligentă a platformei, cu fallback-uri elegante
- Fără SDK necesar - funcționează cu mecanismele standard ale OS-ului
Universal Links & App Links
Fișiere de manifest, servite automat de pe domeniul tău
iOS Universal Links necesită un fișier apple-app-site-association . Android App Links necesită assetlinks.json. Elido generează și servește ambele automat de pe domeniul tău personalizat - fără găzduire separată, fără gestionare manuală a fișierelor.
- iOS Universal LinksBundle ID + Team ID → AASA servit automat la /.well-known/
- Android App LinksNume de pachet + amprentă SHA-256 → assetlinks.json, HTTPS impus
- Fallback prin linkuri inteligenteAplicație neinstalată → App Store / Play Store, prin direcționare bazată pe reguli
- Transmitere UTMParametrii UTM sunt păstrați către URL-ul magazinului - atribuirea nu se rupe
- Fără SDK în aplicația taDoar interceptare la nivel de OS; intent-filter și continueUserActivity
{ "applinks": { "apps": [], "details": [ { "appID": "TEAMID.com.yours.app", "paths": [ "/product/*", "/referral/*", "/invite/*" ] } ] } }
[{ "relation": [ "delegate_permission/ common.handle_all_urls" ], "target": { "namespace": "android_app", "package_name": "com.yourcompany.app", "sha256_cert_fingerprints": [ "AB:12:CD:34:EF:56:..." ] } }]
Servite automat de pe domeniul tău personalizat. Configurezi ID-ul bundle-ului + Team ID (iOS) sau numele de pachet + amprenta SHA-256 (Android) în setările de domeniu - Elido generează și găzduiește ambele fișiere.
Deep link-uri amânate
Context care supraviețuiește instalării
Când aplicația nu este instalată, utilizatorul ajunge la magazin, o instalează și o deschide. Deep-linking-ul amânat transmite contextul original de deep link de-a lungul acestui traseu, astfel încât aplicația să poată aduce utilizatorul exact pe ecranul corect după prima lansare.
- 01
Dă click pe link
Utilizatorul atinge un link scurt Elido - din email, social, cod QR.
go.compania-ta.com/p/12345 - 02
Fără aplicație → Magazin
Aplicația nu este instalată. OS-ul detectează asta din verificarea AASA / assetlinks. Revine la App Store sau Play Store.
iOS → App Store · Android → Play Store - 03
Instalează aplicația
Utilizatorul instalează din magazin. Recomandarea de instalare poartă contextul click-ului ca parametru de query.
click_id + UTM păstrate în URL-ul de recomandare - 04
Deschide aplicația
Aplicația se deschide pentru prima dată. MMP-ul citește recomandarea de instalare; mapează click_id la evenimentul de instalare.
Appsflyer / Adjust / Branch o preiau - 05
Ajunge exact pe pagina corectă
Aplicația direcționează către ecranul legat inițial - product/12345 - ca și cum utilizatorul ar fi avut deja aplicația.
product/12345 - context păstrat prin instalare
Parametrul click_id și parametrii UTM din linkul scurt original sunt transmiși ca parametri de query către URL-ul magazinului. Platformele de măsurare mobilă (MMP) care captează recomandarea de instalare - Appsflyer, Adjust, Branch - pot potrivi instalarea cu click-ul de origine. Deep-linking-ul amânat complet (transmiterea contextului din aplicație prin instalare) necesită SDK-ul MMP în aplicația ta; Elido acoperă stratul de link.
Detectare inteligentă a platformei
Un link. Trei trasee de redirecționare.
Edge-ul citește User-Agent și semnalele de platformă la nivelul de redirecționare - înainte ca vreun JS să ruleze. iPhone primește Universal Links, Android primește App Links, desktop-ul primește fallback-ul tău web. Fără întârziere de redirecționare prin JavaScript; fără detectare de platformă pe client.
- Parsare UA la edge, sub-milisecundă
- iOS → interceptare Universal Link de către OS
- Android → interceptare App Link prin intent-filter
- Desktop → URL web, fără ocol prin magazin
- Browserele in-app sunt detectate și redirecționate către browserul de sistem
- Se combină cu regulile pentru linkuri inteligente - geo + dispozitiv + deep link
Ce poți face
- Apple App Site Association
- Android Asset Links
- Reguli de linkuri inteligente pentru fallback către magazin
- Testat cu adb și xcrun
Cum funcționează, de fapt, linkurile profunde - și unde se rup
Universal Links și App Links sunt mecanisme la nivel de OS. Configurarea este simplă; cazurile limită nu sunt. Aici acoperim imaginea completă.
apple-app-site-association servit automat de pe domeniul tău personalizat
Universal Links necesită un fișier apple-app-site-association (AASA) la /.well-known/apple-app-site-association pe domeniul tău personalizat. iOS descarcă acest fișier când aplicația ta este instalată; el mapează domeniul tău la ID-ul bundle-ului aplicației tale și la ID-ul de echipă. Dacă maparea este corectă, atingerea unui link HTTPS de pe domeniul tău în orice aplicație iOS (Safari, Mail, Twitter, Instagram) deschide direct aplicația ta, în loc să meargă către un browser. Elido generează și servește automat fișierul AASA de la calea well-known a domeniului tău personalizat, pe baza ID-ului bundle-ului și ID-ului de echipă pe care le configurezi în setările de domeniu. Nu găzduiești fișierul separat. iOS pune în cache fișierul AASA și îl redescarcă periodic; dacă schimbi configurarea ID-ului bundle-ului în setările de domeniu Elido, noul AASA este activ în câteva secunde, dar dispozitivele iOS îl vor prelua la următoarea reîmprospătare a cache-ului (de regulă, 24-48 de ore, sau la reinstalarea aplicației). Testat față de validatorul AASA de la Apple la fiecare lansare Elido.
assetlinks.json servit automat - amprentă SHA-256 din cheia ta de semnare
Android App Links necesită un fișier Digital Asset Links la /.well-known/assetlinks.json pe domeniul tău. Fișierul mapează domeniul tău la numele pachetului aplicației tale și la amprenta SHA-256 a certificatului tău de semnare. Android verifică acest fișier la instalarea aplicației și apoi periodic. Elido îl servește automat de pe domeniul tău personalizat, pe baza numelui de pachet și a amprentei SHA-256 pe care le configurezi. Verificarea Android necesită HTTPS (impus de TLS-ul Elido pe domeniul personalizat), iar fișierul trebuie să răspundă în câteva secunde (de asemenea, gestionat automat). Un mod comun de eșec: cheile de semnare diferite pentru build-urile de debug vs. release au amprente SHA-256 diferite. Configurează ambele amprente în setările de domeniu Elido dacă testezi cu un build de debug; build-urile de producție au nevoie doar de amprenta de release. Testat cu adb shell pm get-app-links la fiecare lansare.
Aplicație instalată → deep link. Aplicație neinstalată → magazin. Desktop → web. UTM păstrat pe tot parcursul.
Lanțul de fallback se setează per link sau per domeniu, în setările Elido. Pentru un link scurt cu configurare de deep link: dacă OS-ul interceptează atingerea (aplicație instalată, domeniu verificat), se deschide aplicația. Dacă nu (aplicația nu este instalată), linkul se deschide în browser; destinația din browser ar trebui să fie linkul tău către App Store / Play Store sau un fallback web. Regulile pentru linkuri inteligente gestionează acest lucru curat: configurezi o regulă pentru iOS → URL App Store, o regulă pentru Android → URL Play Store și fallback către destinația web. Parametrii UTM din linkul scurt original sunt păstrați în URL-urile de fallback, astfel încât atribuirea nu se rupe când utilizatorul ajunge la magazin. Deep-linking-ul amânat (transmiterea unei căi specifice de deep link printr-o instalare, astfel încât aplicația să se deschidă pe ecranul corect după instalare) necesită un SDK în aplicație - Elido nu oferă acest lucru. Pentru deep-linking amânat, tot ai nevoie de Appsflyer, Adjust sau Firebase App Distribution.
Retargetare post-instalare: ID-ul de click este transmis către destinație, pentru atribuire
La o redirecționare de deep link, Elido transmite click_id ca parametru de query către URL-ul de fallback. Dacă utilizatorul ajunge în App Store și instalează aplicația, click_id se află în URL-ul de recomandare, dar nu este propagat automat în aplicație după instalare - asta necesită SKAdNetwork pe iOS sau un SDK de deep link amânat pe Android. Ce face Elido: transmite click_id și parametrii UTM către URL-ul magazinului, astfel încât o platformă de atribuire mobilă (MMP) care captează recomandarea de instalare să îi poată prelua. Acest lucru funcționează cu Appsflyer și Adjust dacă transmiți click_id în parametrul de campanie al URL-ului magazinului. Dacă nu folosești un MMP, click_id din URL-ul magazinului se pierde efectiv după instalare.
Migrarea de la Firebase Dynamic Links (retras în 2025)
Firebase Dynamic Links a fost retras de Google în 2025. Elido poate gestiona tiparul de bază: un singur link scurt HTTPS care deschide ecranul corect într-o aplicație instalată, revine la magazin dacă nu este instalată și revine la web pe desktop. Configurezi AASA și assetlinks.json în setările de domeniu Elido (înlocuiește găzduirea acestor fișiere de către Firebase), îți actualizezi linkurile de distribuire ca să indice către linkuri scurte Elido, în loc de URL-uri page.link, și configurezi lanțul de fallback prin reguli de linkuri inteligente. Ce nu replică Elido: deep-linking-ul amânat al Firebase (context de deep link post-instalare, prin SDK-ul Firebase) și deep link-urile Firebase App Distribution. Dacă aplicația ta se bazează intens pe deep-linking amânat, vei avea nevoie de Appsflyer, Adjust sau Branch alături de Elido, pentru stratul de atribuire. Pentru aplicațiile care au nevoie doar de „deschide ecranul corect dacă e instalată, altfel mergi la magazin”, Elido înlocuiește Firebase Dynamic Links complet.
Echipe mobile care folosesc linkurile profunde Elido
Numele sunt momentan generice - numele reale ale clienților vor apărea aici pe măsură ce publicăm studii de caz.
“Am migrat de la Firebase Dynamic Links în săptămâna în care s-a anunțat retragerea. Configurarea AASA și assetlinks.json în Elido a durat jumătate de zi. Lanțul de fallback al linkurilor inteligente a înlocuit logica SDK-ului Firebase pe care o aveam în aplicație pentru direcționarea către magazin.”
“Analiticele de click per link pentru linkurile profunde ne-au arătat că 35% din linkurile noastre de distribuire erau accesate de pe desktop - nu aveam un fallback web configurat. Adăugarea fallback-ului a durat 10 minute; rata de conversie a linkurilor de distribuire a crescut, pentru că utilizatorii care dădeau click de pe desktop puteau acum finaliza acțiunea.”
“Folosim linkuri scurte Elido cu configurare de deep link pentru programele de recomandare. Transmiterea UTM către URL-ul App Store înseamnă că MMP-ul nostru preia corect recomandarea de instalare - atribuirea funcționează fără muncă suplimentară de SDK personalizat din partea noastră.”
Linkuri profunde Elido vs. Branch.io vs. Adjust vs. Firebase Dynamic Links (retras)
Branch și Adjust sunt platforme complete de atribuire mobilă - mai puternice pentru deep-linking amânat și atribuire MMP. Elido este instrumentul potrivit atunci când deep link-urile fac parte dintr-o configurație mai amplă de shortener, nu produsul principal.
| Feature | Elido | Branch.io | Adjust |
|---|---|---|---|
| Universal Links (iOS) | AASA servit automat de pe domeniul tău | Complet gestionat, la scară | Nu - doar MMP, nu găzduiește deep link-uri |
| App Links (Android) | assetlinks.json servit automat de pe domeniul tău | Complet gestionat | Nu |
| SDK necesar în aplicație | Nu - interceptare la nivel de OS | Da - SDK Branch | Da - SDK Adjust |
| Deep-linking amânat | Nu - necesită SDK în aplicație | Da - funcție de bază | Da - cu SDK Adjust |
| Atribuire mobilă (MMP) | Transmitere ID de click; conectarea la MMP este manuală | MMP nativ - integrări Appsflyer, Kochava | Platformă MMP completă |
| Transmitere UTM către magazin | Da - prin parametru de query pe URL-ul de fallback | Da, cu context de atribuire | Da |
| Analitice pentru click-urile pe link | Magazin de analitice - geo, dispozitiv, per link | Analitice profunde de atribuire mobilă | Date de atribuire pentru instalări + evenimente |
| Înlocuitor pentru Firebase Dynamic Links | Da, pentru tiparul de bază; fără deep-link amânat | Înlocuitor complet, inclusiv amânat | Parțial - doar partea de MMP |
Întrebări despre linkurile profunde
Am nevoie de un SDK Branch sau de orice alt SDK în aplicația mea, ca să folosesc linkurile profunde Elido?
Nu. Linkurile profunde Elido folosesc iOS Universal Links și Android App Links - mecanisme la nivel de OS. Aplicația ta trebuie doar să gestioneze URL-ul primit în modul standard iOS (scene:openURLContexts sau application:continueUserActivity) sau Android (intent-filter în manifest). Nu se instalează niciun SDK terță parte; OS-ul gestionează interceptarea pe baza fișierelor AASA și assetlinks.json pe care Elido le servește de pe domeniul tău.
Care este fluxul de configurare AASA?
În setările de domeniu Elido → Deep links: introduci ID-ul bundle-ului aplicației tale iOS (de exemplu, com.compania-ta.app) și Apple Team ID (un șir de 10 caractere din contul tău de Apple Developer). Elido generează JSON-ul AASA și îl servește la /.well-known/apple-app-site-association pe domeniul tău personalizat. Verifică accesibilitatea cu curl înainte să trimiți aplicația la TestFlight sau App Store. iOS descarcă fișierul AASA în timpul instalării aplicației, pe dispozitivele cu iOS 9+.
Pot avea mai multe aplicații pe un singur domeniu?
Da - fișierul AASA acceptă mai multe intrări de aplicație. Configurezi ID-ul bundle-ului și Team ID pentru fiecare aplicație în setările de domeniu; Elido generează un AASA combinat, cu toate aplicațiile listate. assetlinks.json pentru Android acceptă, de asemenea, mai multe combinații de nume de pachet + amprentă. Caz de utilizare comun: aplicația principală și un App Clip, sau aplicația principală și o extensie widget.
Retragerea Firebase Dynamic Links - care este calea de migrare?
Înlocuiește URL-urile scurte page.link cu linkuri scurte Elido (domeniul tău personalizat sau domeniul comun Elido). Configurezi AASA și assetlinks.json în setările de domeniu Elido. Configurezi lanțul de fallback prin reguli de linkuri inteligente (regulă iOS → App Store, regulă Android → Play Store, fallback → web). Actualizezi generarea linkurilor de distribuire în aplicația ta, ca să apeleze API-ul create_link al Elido, în loc de Firebase. Ce nu migrează: dacă aplicația ta se bazează pe deep-linking-ul amânat al Firebase (transmiterea intenției post-instalare), vei avea nevoie de Branch sau Adjust pentru acea parte.
Cum testez Universal Links înainte de a publica în App Store?
Folosește xcrun simctl openurl booted 'https://go.compania-ta.com/test-slug', cu aplicația ta instalată pe un simulator. Pe un dispozitiv fizic cu un build de debug, ține apăsat un link în Safari și vezi dacă apare „Open in Your App”. Apple oferă și App Association File Validator la developer.apple.com - lipești URL-ul AASA și acesta verifică accesibilitatea, Content-Type-ul și validitatea JSON. AASA-ul Elido trece toate cele trei verificări.
Ce este deep-linking-ul amânat și de ce nu îl face Elido?
Deep-linking-ul amânat transmite context (de exemplu, „utilizatorul vizualiza produsul cu ID-ul 123”) de la click-ul pe link, printr-o instalare de aplicație, până la prima lansare a aplicației. Necesită un SDK de fingerprinting sau atribuire în aplicație (Branch, Appsflyer, Adjust), care potrivește instalarea cu click-ul în timpul procesului de instalare. Elido nu instalează cod de SDK în aplicația ta; servim doar AASA și assetlinks.json. Fără SDK, nu există niciun mecanism pentru a transmite context printr-o instalare. Pentru cazul de bază „deschide ecranul corect dacă e instalată”, Elido este suficient. Pentru transmiterea intenției printr-o instalare, ai nevoie de un MMP.
Pot folosi deep link-uri pe domeniul comun al Elido (s.elido.me)?
Nu. Universal Links și App Links necesită propriul tău domeniu - nu poți revendica *.elido.me ca domeniu Universal Link pentru aplicația ta. Deep link-urile necesită un domeniu personalizat, pe Pro sau Business. Domeniul personalizat este cel pe care îl configurezi în AASA și assetlinks.json, iar Elido servește acele fișiere de pe el.
Cum gestionez cazul în care browserul utilizatorului blochează interceptarea aplicației?
Unele browsere (în special Chrome pe Android sub 6.0, și unele browsere in-app precum cel al Instagram) blochează interceptarea App Links sau Universal Link. URL-ul de fallback este ce văd ei. Pentru browserele in-app: redirecționează mai întâi către browserul de sistem, folosind un URL de tip intent (Android) sau un prompt pentru utilizator. Pentru browserele in-app Instagram / TikTok: abordarea standard este să afișezi un prompt „atinge pentru a deschide în browser”. Elido nu injectează automat acest prompt - URL-ul de fallback este destinația ta, iar tu controlezi ce se întâmplă acolo.
Continuă lectura
Configurarea domeniului personalizat - necesară pentru deep link-uri; AASA și assetlinks.json servite de pe hostname-ul tău.
iOS → App Store, Android → Play Store, desktop → web - lanțul de fallback folosind reguli de linkuri inteligente.
Cum folosesc echipele de produs deep link-urile alături de variante A/B și reguli de linkuri inteligente.
Integrări MMP - Appsflyer, Adjust și Branch pentru deep-linking amânat, alături de Elido.
Ești pregătit să încerci?
Începe cu planul gratuit, fă upgrade când ai nevoie de un domeniu personalizat.