⚡ 30 Eylül’e Kadar Web Sitesi Paketlerinde %30 İndirim! ⚡ 30 Eylül’e Kadar %30 İndirim!

00Gün 00Saat 00Dakika 00Saniye
Webioo Blog

Deep Link Nedir? Mobil Uygulamalarda Kullanıcı Doğru Ekrana Nasıl Yönlendirilir?

Deep link, custom scheme ve deferred deep linking yapılarını; route tasarımı, oturum sonrası yönlendirme, fallback ve test adımlarıyla öğrenin.

11 dk okuma
2.282 kelime
Deep Link Nedir? Mobil Uygulamalarda Kullanıcı Doğru Ekrana Nasıl Yönlendirilir?

Deep link, kullanıcıyı mobil uygulamanın ana ekranına bırakmak yerine doğrudan belirli bir ürün, kampanya, sipariş, profil veya içerik ekranına götüren bağlantıdır. Kullanıcı reklamda gördüğü ürüne dokunduğunda uygulama açılıp aynı ürün detayını göstermeli; e-postadaki “siparişi görüntüle” bağlantısı kullanıcıyı sipariş listesine değil ilgili siparişe ulaştırmalıdır. Bu geçiş doğru kurulmadığında link kampanyası çalışır görünse bile kullanıcı bağlamını kaybeder.

Deep linking yalnız URL'yi uygulamada açmak değildir. Linkin hangi route'a karşılık geldiği, parametrelerin doğrulanması, kullanıcının oturum durumu, içeriğin hâlâ mevcut olup olmadığı, uygulama kurulu değilse ne gösterileceği ve kurulumdan sonra hedefin nasıl korunacağı aynı deneyimin parçalarıdır. Bu rehber, push bildirim stratejisine veya genel mobil UX kurallarına taşmadan web, reklam ve mesaj bağlantısından uygulama içindeki doğru ekrana geçişi ele alır.

Kısa tanım: Deep link, bir mobil uygulamanın içindeki belirli hedefi temsil eden URI veya web bağlantısıdır. Uygulama linki aldığında URL'yi bir navigation route'una çevirir, gerekli veriyi yükler ve kullanıcıyı uygun ekran durumuna taşır.

Deep link nasıl çalışır?

Android, deep link'i bir Intent üzerinden uygun uygulama ve activity'ye yönlendirebilir. Android Developers, deep link'in tarayıcı, sosyal medya, reklam veya başka bir kaynaktan kullanıcıyı doğrudan uygulama içeriğine taşıdığını açıklar Android Developers – Create Deep Links. iOS tarafında uygulamalar custom URL scheme kaydederek özel biçimli bağlantıları belirli bir bağlamda açabilir Apple – Defining a Custom URL Scheme.

İşletim sistemi bağlantıyı uygulamaya teslim ettikten sonra asıl sorumluluk uygulamanın navigation katmanına geçer. Uygulama URL'yi parçalar, path ve query parametrelerini doğrular, hedef route'u belirler ve ekran için gerekli veriyi yükler.

  1. Kullanıcı bir bağlantıya dokunur.
  2. İşletim sistemi URL şeması ve domain'e göre uygun uygulamayı veya web hedefini belirler.
  3. Uygulama gelen URI'yi navigation katmanına teslim eder.
  4. Route resolver path ve parametreleri izin verilen link sözleşmesiyle karşılaştırır.
  5. Kimlik doğrulaması gerekiyorsa hedef geçici olarak saklanır ve login akışı başlatılır.
  6. Hedef veri API veya local cache üzerinden yüklenir.
  7. İçerik bulunuyorsa doğru ekran açılır; bulunmuyorsa güvenli fallback gösterilir.
  8. Kampanya ve yönlendirme sonucu ölçüm sistemine uygun event ile kaydedilir.

Normal URL ile deep link arasındaki fark nedir?

Bağlantı türüÖrnekBeklenen davranış
Normal web URLhttps://example.com/products/482Varsayılan olarak web sayfasını açar; doğrulanmış uygulama bağlantısı varsa app'e yönlenebilir.
Custom scheme deep linkexampleapp://products/482Scheme'i destekleyen yüklü uygulamayı açmaya çalışır.
Uygulama içi routeproduct/{productId}Navigation sisteminin kendi iç hedef tanımıdır; dış URL ile birebir aynı olmak zorunda değildir.
Deferred deep linkKampanya linki + kurulum sonrası hedefUygulama kurulu değilse mağazaya yönlendirir, ilk açılışta asıl hedefi yeniden kurmaya çalışır.

Uygulama içi route ile dışarıdan kabul edilen link yapısını ayırmak güvenliği ve sürdürülebilirliği artırır. Dış URL doğrudan ekran sınıfı adı veya dahili navigation ayrıntısı taşımamalıdır. Örneğin /products/482 bağlantısı içeride farklı navigation graph'larına yönlendirilebilir; dış sözleşme sabit kalırken uygulama mimarisi değişebilir.

Custom scheme nedir?

Custom scheme, uygulamaya ait özel bir URI ön eki kullanır. exampleapp://product/482 bağlantısında scheme exampleapp, hedef ise ürün route'udur. Android dokümantasyonu custom URI scheme'lerin uygulama içindeki belirli içeriğe yönlendirme sağlayabildiğini, ancak başka bir uygulamanın aynı scheme'i kaydedebilmesi nedeniyle seçim veya çakışma riski taşıdığını belirtir Android Developers – About Deep Links.

Apple da custom URL scheme kullanımını destekler; fakat URL parametrelerinin doğrulanması ve riskli eylemlerin sınırlandırılması gerektiği konusunda uyarır. Apple, uygulamanın sahip olduğu web domain'leri için doğrulanmış universal link yaklaşımını önerir Apple – Defining a Custom URL Scheme.

Custom scheme ne zaman kullanılabilir?

  • Aynı cihazdaki iki uygulama arasında kontrollü geçiş gerekiyorsa
  • Ödeme veya kimlik sağlayıcısından uygulamaya callback alınacaksa
  • Web domain'i bulunmayan dahili veya sınırlı entegrasyon varsa
  • Bağlantı yalnız uygulamanın kurulu olduğu bilinen kapalı bir akıştan geliyorsa
  • Legacy entegrasyon mevcutsa ve hemen doğrulanmış web linkine taşınamıyorsa

Custom scheme'in sınırlamaları

  • Standart web bağlantısı değildir; uygulama kurulu değilse anlamlı web fallback'i sunmaz.
  • Scheme sahipliği domain gibi doğrulanmadığından başka uygulamalar aynı scheme'i kaydedebilir.
  • Tarayıcı ve mesajlaşma uygulamalarının açma davranışları farklılaşabilir.
  • Yanlış parametre doğrulaması güvenlik ve veri bütünlüğü riski oluşturabilir.
  • Kampanya paylaşımı ve SEO açısından HTTPS bağlantıları kadar doğal değildir.
Custom scheme bir navigation taşıyıcısıdır; uygulamanın kimliğini güvenilir biçimde kanıtlayan domain doğrulaması değildir.

Universal Links ve App Links bu yapının neresindedir?

iOS Universal Links ve Android App Links, normal HTTPS URL'lerini uygulamayla doğrulanmış biçimde ilişkilendirir. Uygulama yüklüyse link doğrudan ilgili içeriği açabilir; yüklü değilse aynı URL web üzerinde çalışmaya devam eder. Apple, universal link desteği için uygulama ile web sitesi arasında iki yönlü association kurulmasını ister Apple – Supporting Universal Links. Android de App Links'i domain sahipliğinin doğrulandığı önerilen web-to-app yaklaşımı olarak tanımlar Android Developers – About App Links.

Bu blogun odağı deep link deneyiminin temelidir. Domain association dosyaları, App Links intent filter'ları, iOS entitlement ve doğrulama ayrıntıları 285. blogun kapsamındadır.

Deferred deep linking nedir?

Deferred deep linking, uygulama kullanıcı cihazında kurulu değilken tıklanan hedefin kurulum sürecinden sonra korunmasıdır. Kullanıcı kampanya bağlantısına dokunur, uygulama mağazasına gider, uygulamayı yükler ve ilk açılışta doğrudan kampanyadaki ürün veya teklif ekranına yönlendirilir.

Normal deep link yalnız yüklü uygulamayı açabilir. Deferred yapı ise tıklama bağlamını mağaza geçişi boyunca saklayıp ilk uygulama açılışıyla eşleştiren ek attribution ve backend mekanizması gerektirir.

DurumNormal deep linkDeferred deep link
Uygulama kuruluHedef ekran doğrudan açılabilir.Hedef ekran doğrudan açılır.
Uygulama kurulu değilCustom scheme başarısız olabilir; web URL varsa web açılır.Kullanıcı mağazaya gider ve hedef bilgisi kurulum sonrasına taşınır.
İlk açılışGenellikle ana ekran açılır.Attribution sonucu bulunursa asıl hedef yeniden oluşturulur.
Gerekli altyapıRoute eşleştirme ve platform link kaydıLink resolver, mağaza/referrer bilgisi, attribution ve first-open işleme

Deferred deep link teknik olarak nasıl korunur?

Android'de Google Play Install Referrer API, Google Play üzerinden güvenli referral içeriği alınmasına izin verir. Uygulama ilk açılışta referrer bilgisini okuyarak kuruluma yol açan kampanya bağlamını backend ile eşleştirebilir Android Developers – Play Install Referrer.

iOS tarafında universal link, uygulama yüklü değilse web hedefini açabilir; ancak hedefin App Store kurulumu boyunca otomatik olarak korunması ayrı bir attribution veya hesap-temelli devam mekanizması gerektirir. Deferred deneyim genellikle link resolver, ölçüm sağlayıcısı, web oturumu veya uygulama ilk açılışında alınan güvenli bir token ile tasarlanır.

  1. Kampanya linki backend'deki link resolver'a gelir.
  2. Resolver hedef türü, hedef kimliği, kampanya ve geçerlilik süresini kaydeder.
  3. Uygulama kuruluysa platform linki üzerinden uygulama açılır.
  4. Kurulu değilse kullanıcı uygun mağaza veya web fallback'ine gönderilir.
  5. Kurulum ve ilk açılış sonrasında referrer ya da attribution bilgisi alınır.
  6. Uygulama tek kullanımlık veya süreli kampanya token'ını backend'e gönderir.
  7. Backend token'ı doğrular ve güvenli hedef route'u döndürür.
  8. Login gerekiyorsa hedef login sonrasına saklanır.
  9. İçerik geçerliyse hedef ekran; değilse kategori veya ana ekran fallback'i açılır.
Güvenlik notu: Deferred link token'ı ödeme, şifre değiştirme veya hesap bağlama gibi hassas işlemleri tek başına yetkilendirmemelidir. Link yalnız hedefi tarif eder; kullanıcının işlem yetkisi backend tarafından ayrıca doğrulanır.

Deep link route sözleşmesi nasıl tasarlanmalıdır?

Deep link yapısı, uygulamanın public navigation API'si gibi düşünülmelidir. Path'ler kararlı, anlaşılır ve sürümlenebilir olmalıdır.

HedefÖrnek public pathGerekli doğrulamaFallback
Ürün/products/{productId}ID biçimi, ürün erişimi ve yayın durumuKategori veya arama ekranı
Sipariş/orders/{orderId}Aktif kullanıcı siparişin sahibi mi?Sipariş listesi veya login
Kampanya/campaigns/{campaignCode}Kampanya aktif mi ve kullanıcı uygun mu?Kampanyalar ekranı
Destek talebi/support/tickets/{ticketId}Yetki ve tenant eşleşmesiDestek ana ekranı
İçerik/articles/{slug}Slug izinli formatta mı, içerik mevcut mu?İçerik listesi veya web sayfası

İyi route sözleşmesinin özellikleri

  • Ekran sınıfı veya navigation framework ayrıntısını dışarı açmaz.
  • Kullanıcı tarafından tahmin edilebilen ID'leri yetkilendirme yerine kullanmaz.
  • Query parametreleri için allowlist ve tür kontrolü uygular.
  • Eski kampanya linkleri için kontrollü redirect veya fallback sunar.
  • Android ve iOS'ta aynı anlamı taşır.
  • Analytics event'inde ham hassas veri göndermeden kaynak ve hedefi ölçer.

Oturum açmamış kullanıcı doğru ekrana nasıl taşınır?

Deep link korumalı bir ekrana gidiyorsa kullanıcıyı login sayfasına yönlendirmek gerekir. En sık yapılan hata, login tamamlandıktan sonra hedefi kaybedip kullanıcıyı ana ekrana bırakmaktır.

  1. Gelen link doğrulanır ve güvenli bir pending destination nesnesine çevrilir.
  2. Uygulama hedefin authentication gerektirip gerektirmediğini kontrol eder.
  3. Gerekiyorsa login ekranı açılır; ham dış URL yerine doğrulanmış hedef state saklanır.
  4. Login başarılı olduğunda kullanıcı ve tenant yetkisi yeniden kontrol edilir.
  5. Pending destination tek sefer kullanılır ve temizlenir.
  6. Hedef artık geçerli değilse güvenli fallback gösterilir.

Bu akış mobil uygulama geliştirme sürecinde navigation ile authentication mimarisinin birlikte tasarlanmasını gerektirir. Deep link, ekranı açma emri değil; uygulamanın güvenlik kurallarından geçen bir navigation talebidir.

Kampanya ve ürün linkleri nasıl ölçülmelidir?

Deep link ölçümü yalnız “link tıklandı” event'iyle sınırlı kalmamalıdır. Tıklamanın uygulama açılışına, hedef ekran yüklenmesine ve iş sonucuna dönüşüp dönüşmediği ayrı olaylarla izlenmelidir.

  • Link tıklandı
  • Uygulama açıldı veya foreground'a geldi
  • Deep link parse edildi
  • Hedef route bulundu
  • Login gerekti
  • Hedef ekran başarıyla yüklendi
  • Fallback çalıştı
  • Ürün sepete eklendi, form tamamlandı veya sipariş oluştu

Ham access token, sipariş numarası, e-posta veya kişisel veri analytics parametresi olarak gönderilmemelidir. Kampanya ID'si ve genel hedef türü çoğu raporlama için yeterlidir.

Deep link güvenlik riskleri nelerdir?

  • Parametre enjeksiyonu: URL'den gelen değer güvenilmeden SQL, webview veya native fonksiyona taşınabilir.
  • Yetkilendirme atlama: Tahmin edilen orderId ile başka kullanıcının ekranına erişilmeye çalışılabilir.
  • Open redirect: Uygulama doğrulanmamış dış URL'lere yönlendirilebilir.
  • Custom scheme hijacking: Başka uygulama aynı scheme'i kaydedip bağlantıyı yakalayabilir.
  • Tekrar kullanımı: Süresiz kampanya veya işlem token'ı yeniden kullanılabilir.
  • WebView riski: Deep link parametresiyle kontrolsüz URL webview içinde açılabilir.
  • Log sızıntısı: Hassas query parametreleri crash veya analytics loglarına yazılabilir.
Temel kural: Deep link verisini kullanıcı girdisi gibi kabul edin. Route allowlist'i, şema ve host kontrolü, parametre tür doğrulaması, authorization ve hassas eylem için yeniden onay uygulayın.

Hatalı veya eski deep link nasıl ele alınmalıdır?

Ürün silinmiş, kampanya bitmiş veya route yeni uygulama sürümünde değişmiş olabilir. Uygulamanın çökmesi veya boş ekran göstermesi yerine anlamlı fallback gerekir.

Hata durumuÖnerilen davranış
Bilinmeyen routeGüvenli ana ekran veya ilgili kategori; hata telemetrisi
Geçersiz parametreİsteği reddet, kullanıcıya genel açıklama göster
İçerik kaldırılmışBenzer içerik, kategori veya arama ekranı
Kampanya sona ermişKampanyanın bittiğini açıkla ve güncel fırsatları göster
Yetki yokKaynağın varlığını gereksiz açıklamadan erişim hatası göster
Eski uygulama sürümüDesteklenen fallback veya gerekli ise mağaza güncelleme ekranı

Android ve iOS için test matrisi

  • Uygulama kapalıyken linke dokunma
  • Uygulama arka plandayken linke dokunma
  • Uygulama açık ve başka ekrandayken link alma
  • Kullanıcı login olmuş ve olmamış durumlar
  • Uygulama kurulu ve kurulu olmayan durumlar
  • Geçerli, geçersiz ve süresi dolmuş hedefler
  • Farklı tarayıcı, e-posta ve mesajlaşma uygulamaları
  • Android back stack ve iOS geri navigation davranışı
  • Yeni kurulum sonrası deferred hedef
  • Eski uygulama sürümünde yeni route
  • Analytics ve attribution event'lerinin tekilleştirilmesi

Android, deep link Intent'lerinin komut satırı ve platform araçlarıyla test edilmesini destekler; uygulamanın linkten açıldıktan sonraki Back ve Up davranışının kullanıcı beklentilerine uyması gerekir Android Developers – Create Deep Links. iOS tarafında custom scheme, universal link ve uygulama yaşam döngüsü durumları ayrı ayrı test edilmelidir. Bu kontroller Android ve iOS uygulama geliştirme süreçlerinin ortak kabul kriterlerine eklenmelidir.

Deep link entegrasyonu kontrol listesi

  1. Public link route sözleşmesini ve izin verilen hedefleri yazılı hale getirin.
  2. Custom scheme ile HTTPS tabanlı linklerin kullanım sınırını belirleyin.
  3. Uygulama kurulu değilken web veya mağaza fallback'ini planlayın.
  4. Deferred deep linking gerekiyorsa attribution ve first-open mimarisini tasarlayın.
  5. Gelen URL'yi doğrudan navigation komutu olarak kullanmayın.
  6. Scheme, host, path ve query parametrelerini allowlist ile doğrulayın.
  7. Login sonrası hedefe devam mekanizması kurun.
  8. Her hedefte backend authorization kontrolünü tekrar uygulayın.
  9. Silinen içerik ve biten kampanya için fallback tanımlayın.
  10. Cold start, warm start ve background senaryolarını test edin.
  11. Link açılışı ile hedef ekran yüklenmesini ayrı event'lerle ölçün.
  12. Eski uygulama sürümleri ve route değişiklikleri için uyumluluk planlayın.
  13. Deep link parametrelerinde hassas veri taşımayın.
  14. Custom scheme hijacking riskine karşı doğrulanmış web linki geçişini değerlendirin.

Sonuç: Deep link kullanıcı bağlamını koruyan navigation sözleşmesidir

Deep link, kullanıcıyı uygulamaya açmakla kalmaz; geldiği kampanya, ürün veya işlem bağlamını doğru ekrana taşır. Sağlam yapı URL'yi güvenli route'a dönüştürür, oturum ve yetki durumunu kontrol eder, içerik bulunamadığında fallback sunar ve sonucu ölçer.

Custom scheme hızlı ve kontrollü entegrasyonlarda kullanılabilir; fakat standart web fallback'i ve domain doğrulaması açısından sınırlıdır. Deferred deep linking ise uygulama kurulu olmayan kullanıcı için mağaza geçişinden sonra hedefi yeniden kuran ek bir attribution mimarisidir. Başarılı deneyim, link üretimi ile Android/iOS navigation, backend yetkilendirme ve ölçüm katmanlarının birlikte tasarlanmasına dayanır.

Sıkça Sorulan Sorular

Deep link ile normal web linki arasındaki fark nedir?

Normal web linki varsayılan olarak tarayıcıdaki bir sayfayı temsil eder. Deep link ise mobil uygulamanın içindeki belirli hedefi açmak için kullanılır. HTTPS linkleri Universal Links veya App Links ile uygulamayla doğrulanabilir; uygulama kurulu değilse web sayfası açılabilir. Custom scheme bağlantıları ise uygulamaya özgü URI kullanır ve uygulama kurulu olmadığında doğal web fallback'i sunmaz.

Custom scheme deep link güvenli midir?

Kontrollü akışlarda kullanılabilir; ancak domain sahipliğiyle doğrulanmaz. Başka bir uygulama aynı scheme'i kaydedebilir ve bağlantıyı yakalamaya çalışabilir. Bu nedenle hassas token taşınmamalı, bütün parametreler doğrulanmalı ve işlem yetkisi backend tarafından kontrol edilmelidir. Uygulamanın sahip olduğu web domain'lerinden gelen genel kullanıcı bağlantıları için doğrulanmış Universal Links ve App Links genellikle daha güvenli yaklaşımdır.

Deferred deep link nedir?

Deferred deep link, kullanıcı bağlantıya dokunduğunda uygulama kurulu değilse hedef bilgisini kurulum sonrasına taşıyan akıştır. Kullanıcı mağazaya gider, uygulamayı yükler ve ilk açılışta kampanyadaki ürün veya ekran yeniden açılır. Bunun için yalnız custom scheme yeterli değildir; link resolver, install referrer veya attribution sistemi, first-open işleme ve backend'de güvenli hedef eşleştirme gerekir.

Deep link kullanıcı login değilse ne yapmalıdır?

Uygulama önce linki doğrulanmış bir pending destination nesnesine çevirmelidir. Hedef authentication gerektiriyorsa kullanıcı login ekranına gönderilir. Başarılı girişten sonra hedefin hâlâ geçerli olduğu ve kullanıcının kaynağa erişim yetkisi bulunduğu yeniden kontrol edilir. Ham dış URL doğrudan saklanmamalı; hedef tek kullanımdan sonra temizlenmelidir.

Deep link içinde ürün veya sipariş ID'si taşımak güvenli midir?

ID taşınabilir; ancak ID'nin bilinmesi erişim yetkisi sağlamamalıdır. Uygulama parametre biçimini doğrulamalı, backend ise aktif kullanıcının ilgili ürün, sipariş veya tenant kaynağına erişimini kontrol etmelidir. Hassas kişisel veri, access token veya parola benzeri bilgiler query parametresine konmamalıdır. Link loglarda, analytics sistemlerinde ve paylaşım kanallarında görünebilir.

Deep link çalışmıyorsa hangi noktalar kontrol edilmelidir?

Önce linkin scheme, host ve path değerlerinin uygulamadaki kayıtlarla eşleştiği kontrol edilmelidir. Ardından uygulamanın cold start, background ve aktif durumlarında URL'nin navigation katmanına ulaşıp ulaşmadığı incelenmelidir. Route mapping, login sonrası devam, içerik erişimi ve fallback ayrıca test edilmelidir. HTTPS tabanlı doğrulanmış linklerde domain association ve platform doğrulaması 285. blogun kapsamındaki App Links/Universal Links kontrolleriyle incelenir.

Yazar: Emre Öcel — Webioo
Yayın: 29 Eylül 2026
Okuma: 11 dakika
Güncel İçerik

Son Blog Yazılarımız

Sektörel içgörüler ve güncel dijital pazarlama ipuçları

Call Tracking Nedir? Telefon Aramalarını Reklam Performansına Bağlama Rehberi - Webioo Blog
28 Eylül 2026

Call Tracking Nedir? Telefon Aramalarını Reklam Performansına Bağlama Rehberi

Call tracking ile telefon tıklaması, gerçek arama, görüşme süresi, nitelikli çağrı ve satış sonucunu reklam ka...

Web Sitesi Yaptırmadan Önce Ajansa Sorulması Gereken 15 Soru - Webioo Blog
28 Eylül 2026

Web Sitesi Yaptırmadan Önce Ajansa Sorulması Gereken 15 Soru

Web sitesi yaptırmadan önce ajansa sorulması gereken 15 soruyu; kapsam, tasarım, yazılım, SEO, içerik, destek ...

Idempotency Nedir? API ve Ödeme Sistemlerinde Neden Önemli? - Webioo Blog
27 Eylül 2026

Idempotency Nedir? API ve Ödeme Sistemlerinde Neden Önemli?

Idempotency yaklaşımını; güvenli retry, idempotency key, eş zamanlı istekler, ödeme işlemleri ve yinelenen web...

Canary Release Nedir? Yeni Sürüm Küçük Grupta Nasıl Test Edilir? - Webioo Blog
27 Eylül 2026

Canary Release Nedir? Yeni Sürüm Küçük Grupta Nasıl Test Edilir?

Canary release ile yeni sürümü küçük bir kullanıcı grubuna açmayı, guardrail metrikleriyle izlemeyi ve güvenli...

E-Ticaret Sitesinde Ürün Fotoğraf Standartları Nasıl Belirlenmeli? - Webioo Blog
26 Eylül 2026

E-Ticaret Sitesinde Ürün Fotoğraf Standartları Nasıl Belirlenmeli?

E-ticaret ürün fotoğraf standartlarını ana görsel, detay çekimi, varyant, dosya adı, alt metin, hız ve pazarye...

Eski Yazılımı Yenilemek mi Baştan Yazmak mı? Karar Rehberi - Webioo Blog
26 Eylül 2026

Eski Yazılımı Yenilemek mi Baştan Yazmak mı? Karar Rehberi

Eski yazılımı yenilemek mi yoksa baştan yazmak mı daha doğru? Teknik borç, maliyet, risk, veri, entegrasyon ve...