Deep linking: universal links, app links și atribuție corectă

Un deep link este un URL care duce utilizatorul direct la un ecran specific dintr-o aplicație mobilă, nu la pagina principală. Spre deosebire de un link obișnuit care deschide aplicația la nivel de home screen, un deep link transportă context: ecranul produsului, articolul, sesiunea sau fluxul pe care utilizatorul ar fi trebuit să le vadă.

Termenul acoperă trei mecanisme cu arhitecturi diferite: schemele URL personalizate (vechi, fragile), universal links pe iOS și app links pe Android (domeniu-based, validat de platformă) și deferred deep linking (care funcționează chiar dacă aplicația nu este instalată). Confuzia între ele produce erori de fallback și atribuție greșită. Deep linking completează alte canale de re-engagement mobil, precum push notifications, dar funcționează prin URL, fără a necesita permisiunea utilizatorului.

Ce este un deep link mai exact?

La bază, un deep link este un URL care sistemul de operare îl pasează aplicației în loc să-l deschidă în browser. Există două generații:

• Scheme-based (URI schemes). Format de tipul myapp://produs/123. Aplicația declară schema în manifest; OS-ul o recunoaște și deschide aplicația. Problema: dacă aplicația nu este instalată, OS-ul nu știe ce să facă și linkul eșuează fără fallback. Mai grav, orice altă aplicație poate declara aceeași schemă, ceea ce deschide un vector de hijacking.
• Domain-based (Universal Links pe iOS, App Links pe Android). Format de tipul https://example.com/produs/123, același URL valabil și în browser. OS-ul verifică că domeniul aparține aplicației prin fișiere de configurare găzduite pe server. Dacă verificarea reușește, URL-ul deschide aplicația; dacă aplicația lipsește, se deschide în browser. Fallback-ul natural este cel mai mare avantaj față de schemele vechi.

Ambele abordări sunt compatibile simultan. În practică, scheme-based a rămas relevant pentru comunicarea între aplicații pe același dispozitiv; pentru linkuri distribuite (e-mail, reclame), domain-based este standardul actual.

Cum funcționează Universal Links pe iOS față de App Links pe Android?

Principiul este identic: serverul tău găzduiește un fișier JSON care declară că o anumită aplicație are dreptul să intercepteze URL-uri de pe acel domeniu. OS-ul verifică fișierul la instalare și îl poate reverifica periodic.

Pe iOS, fișierul se numește apple-app-site-association (AASA) și trebuie servit la https://example.com/.well-known/apple-app-site-association fără redirect, cu Content-Type: application/json, fără autentificare. Apple CDN-ul îl descarcă la instalare prin serverele proprii. Asocierea se declară în Xcode în Signing and Capabilities, adăugând entitlement-ul Associated Domains cu valori de tipul applinks:example.com.

Pe Android, echivalentul se numește Digital Asset Links și trăiește la https://example.com/.well-known/assetlinks.json. Conține hash-ul SHA-256 al certificatului de semnare și package name-ul. În AndroidManifest.xml, intent filter-ul pentru URL-uri HTTPS trebuie să aibă atributul android:autoVerify="true"; fără el, sistemul tratează linkul ca un URI obișnuit.

O diferență practică: pe iOS, dacă utilizatorul apasă Cancel la promisiunea de a deschide aplicația, iOS dezactivează universal link-ul pe acel dispozitiv până la reinstalarea aplicației. Pe Android, verificarea este silențioasă. Spre deosebire de actualizările OTA, care modifică codul aplicației deja instalate, deep linking nu depinde de o versiune minimă a aplicației; depinde doar de faptul că aplicația este instalată și că fișierele de configurare de pe server sunt accesibile.

Ce este deferred deep linking și de ce contează pentru install attribution?

Deferred deep linking rezolvă cazul în care utilizatorul dă click pe un link de marketing înainte să aibă aplicația instalată. Fără el, după instalare aplicația se deschide la home screen și contextul original se pierde. Cu deferred deep linking, aplicația deschide direct ecranul țintă din linkul original.

Metodele clasice foloseau fingerprinting: serverul captura IP, user agent și rezoluție; după instalare, aplicația trimitea aceiași parametri și serverul potrivea sesiunile. Apple a restricționat fingerprinting-ul odată cu revocarea IDFA (App Tracking Transparency, iOS 14.5+). Alternativa dominantă acum este clipboard-based: URL-ul este copiat în clipboard înainte de redirect la store; aplicația îl citește la primul start. Utilizatorul vede o notificare de permisiune pe iOS 16+, ceea ce reduce rata de succes, dar rămâne metoda acceptată de Apple.

Din perspectiva atribuției, deferred deep linking face diferența dintre a ști că un utilizator a instalat aplicația dintr-o campanie și a ști ce conținut l-a convins să o facă, ceea ce influențează direct cum interpretezi rata de engagement per canal. Servicii comerciale ca Branch.io, Adjust sau AppsFlyer gestionează complexitatea plus normalizarea parametrilor UTM, deduplicarea și raportarea. Firebase Dynamic Links, care era alternativa gratuită principală, a fost scos din uz în august 2025.

Cum testezi un deep link în development și producție?

Testarea deep link-urilor cere să simulezi atât deschiderea linkului, cât și absența aplicației pentru a verifica fallback-ul.

Pe iOS, deschide URL-ul direct în simulatorul Xcode:

xcrun simctl openurl booted "https://example.com/produs/123"

Dacă asocierea AASA este configurată corect, aplicația se deschide la ecranul corespunzător. Pentru a testa fallback-ul, dezinstalează aplicația din simulator și repetă comanda: trebuie să se deschidă Safari.

Pe Android, comanda echivalentă folosește adb:

adb shell am start -a android.intent.action.VIEW \
  -d "https://example.com/produs/123" \
  com.example.app

Fără package name specificat, comanda testează cum rezolvă OS-ul URL-ul în general. Google pune la dispoziție Digital Asset Links Tool pentru validarea assetlinks.json; erorile de format AASA sunt jurnalizate în Console.app de pe Mac conectat la dispozitivul fizic.

În producție, cele mai frecvente cauze de eșec sunt fișierul AASA inaccesibil după un redeploy și certificatul Android rotit fără actualizarea assetlinks.json. Un test automat care face HTTP GET pe cele două URL-uri și compară răspunsul cu valoarea așteptată detectează regresii înainte să le observe utilizatorii. Despre cum integrezi astfel de verificări periodice în practica ta de site reliability engineering, vezi principiile de monitorizare continuă.

Care sunt capcanele tipice?

• Fallback absent sau greșit. Dacă aplicația nu este instalată, universal link-ul cade în Safari pe URL-ul respectiv. Dacă pagina web nu există sau redirecționează la homepage, utilizatorul se pierde. Fiecare deep link ar trebui să aibă o pagină web care fie afișează conținutul, fie redirecționează spre store.
• Schimbarea schemei URL fără redirect. Dacă restructurezi URL-urile (de la /produs/:id la /p/:slug), toate deep link-urile distribuite anterior se sparg. Implementează redirecturi pe server exact cum faci pentru SEO. Paginile SSR servesc ca fallback natural și sunt locul ideal unde plasezi aceste redirecturi.
• Parametri de tracking care nu se propagă. UTM-urile trebuie incluși explicit în URL-ul de deep link, nu adăugați ulterior. Dacă serviciul de atribuție trimite un URL fără parametri, pierzi datele de campanie. Verifică în panoul de atribuție că parametrii ajung corect la evenimentele de install și open.
• Hash-ul certificatului Android rotit fără actualizare. assetlinks.json conține hash-ul SHA-256 al certificatului de semnare. Dacă cheia se rotește (incident de securitate, migrare între conturi), hash-ul vechi trebuie înlocuit imediat. App Links se sparg tăcut: aplicația se instalează normal, dar URL-urile se deschid în browser.
• Conflicte cu browser routing în SPA-uri. Dacă aplicația ta web este un SPA cu routing pe client, URL-uri de tipul /produs/123 trebuie să funcționeze și ca rute SSR, nu doar client-side. Un universal link care ajunge pe server la o rută nerecunoscută și primește 404 strică experiența de fallback. Asigură-te că toate rutele expuse ca deep links au și o reprezentare SSR valabilă. Legătura cu cum sunt structurate rutele pentru server-side rendering e directă.
• AASA cacheat de Apple CDN. Apple nu descarcă AASA direct de pe serverul tău, ci printr-un CDN propriu. Propagarea după o actualizare poate dura ore. Testează pe device fizic cu conexiune mobilă și verifică noile căi de URL înainte de a publica o versiune nouă în App Store.