Cara menyiapkan Universal Links dan App Links setelah Firebase

Kalau masih ada link lama di QR code, campaign TikTok/Instagram, email onboarding, landing page, atau flow referral, masalah Anda sekarang bukan cuma mencari "pengganti Firebase". Masalah Anda adalah menjaga link publik tetap hidup tanpa merusak pembukaan app, fallback, dan tracking campaign.

Karena itu, lebih aman kalau Anda memisahkan peran yang dulu digabung oleh Firebase Dynamic Links:

1. branded public URL
2. membuka app yang sudah terpasang
3. fallback ke App Store, Google Play, atau web
4. menjaga UTM dan parameter campaign

Menurut Firebase Dynamic Links FAQ, layanan ini shut down pada 25 Agustus 2025. Jika link lama masih hidup di campaign, QR, atau onboarding, langkah yang lebih sehat adalah membangun ulang link layer yang lebih bersih.

Peran Universal Links dan App Links

Apple Universal Links

Apple Universal Links memungkinkan link HTTPS biasa membuka app iOS yang sudah terpasang jika:

• domain terhubung ke app dengan benar
• capability sudah dikonfigurasi
• apple-app-site-association valid tersedia
• app mampu menangani path yang diterima

Android App Links

Android App Links melakukan hal yang sama di Android. Anda membutuhkan:

• domain yang terverifikasi
• konfigurasi manifest yang benar
• assetlinks.json yang valid
• path handling di dalam app

Apa yang belum terpecahkan oleh keduanya

Universal Links dan App Links saja tidak menyelesaikan:

• fallback desktop
• tujuan untuk pengguna yang belum memasang app
• branded campaign URL
• routing perangkat
• pelestarian UTM
• override campaign sementara

Untuk itu, Anda tetap butuh redirect layer.

Arsitektur yang paling praktis setelah Firebase

Untuk banyak tim, model yang paling mudah dirawat seperti ini:

go.brandanda.com/promo
  -> deteksi perangkat di edge
  -> iPhone + app terpasang: Universal Link
  -> iPhone + belum terpasang: App Store
  -> Android + app terpasang: App Link
  -> Android + belum terpasang: Google Play
  -> Desktop: landing page, docs, atau halaman QR

Model ini bagus karena:

• domain tetap Anda kuasai
• fallback jadi eksplisit
• marketing punya satu link rapi untuk dibagikan
• mobile, growth, dan product bisa menguji flow nyata yang sama

Titik macet yang paling sering: file verifikasi

Masalah praktis sering muncul pada:

• apple-app-site-association
• assetlinks.json

Kalau website utama ada di Shopify, Wix, Webflow, atau CMS yang membatasi file di root atau .well-known, bagian ini sering terasa lebih ribet daripada seharusnya.

Di sinilah UrlEdge berguna. Dengan custom response, Anda bisa menyajikan file-file itu dari edge tanpa harus membuat jalur deployment baru hanya untuk dua file verifikasi.

Langkah implementasi

1. Inventaris semua public link

Periksa:

• paid campaign
• QR code
• tombol download
• lifecycle email
• halaman support
• social bio
• referral flow

2. Pisahkan app opening dan fallback

Untuk setiap link penting, putuskan:

1. jika app sudah terpasang, apakah harus dibuka?
2. jika belum terpasang, apakah pengguna dikirim ke store atau web?
3. apa yang dilihat desktop?
4. apakah UTM harus tetap ada?

3. Pilih domain publik yang kanonik

Contoh yang umum:

• go.brandanda.com
• app.brandanda.com
• links.brandanda.com

Dengan begitu Anda tidak terlalu tergantung pada hostname vendor pihak ketiga.

4. Validasi file asosiasi

Selalu gunakan dokumentasi resmi:

• Apple Universal Links
• Android App Links

Kalau tahap ini salah, pembukaan app native akan tetap tidak konsisten walaupun redirect umum terlihat berjalan.

5. Tulis fallback secara eksplisit

Contohnya:

• iOS + app terpasang -> app
• iOS + belum terpasang -> App Store
• Android + app terpasang -> app
• Android + belum terpasang -> Google Play
• desktop -> landing atau QR handoff

Jangan biarkan bagian ini sekadar asumsi.

6. Uji di konteks yang nyata

Cek minimal:

• iPhone Safari
• Android Chrome
• browser in-app dari social apps
• desktop
• QR scan di ponsel
• link dengan UTM

Di sinilah terlihat perbedaan antara "link memberi respons" dan "pengalaman pengguna benar-benar beres".

Kesalahan yang sering terjadi

Mengira device routing menggantikan Universal Links dan App Links

Routing memilih tujuan. Universal Links dan App Links menangani native app opening yang dipercaya oleh sistem operasi.

Melupakan desktop

Fallback desktop yang lemah akan cepat merusak halaman support, docs, sales material, dan alur QR.

Kehilangan UTM

Kalau link hidup di email, QR, paid social, atau partner campaign, parameter campaign harus dipertahankan secara sengaja.

Menumpuk terlalu banyak layer

Semakin banyak shortener, redirect perantara, dan halaman transisi, semakin lambat proses debugging.

Di mana UrlEdge membantu

UrlEdge cocok kalau Anda ingin menggabungkan:

• branded public URL
• routing perangkat
• fallback ke store atau web
• UTM preservation
• click analytics
• publikasi file verifikasi di edge

Ini bukan pengganti penuh untuk seluruh attribution stack mobile. Tapi ini memberi kontrol kembali pada lapisan yang paling terlihat: public link dan perilaku fallback.

Ringkasnya

Setelah Firebase Dynamic Links, jawaban terbaik jarang berupa "kotak hitam baru". Biasanya justru arsitektur yang lebih jelas:

• branded domain
• routing perangkat
• Universal Links dan App Links yang tervalidasi
• fallback yang eksplisit
• parameter campaign yang tetap utuh

Lebih sedikit sihir, lebih banyak kontrol.