Adres Doğrulama Sistemi Nedir? İşletmeler İçin Rehber

Müşterinin sipariş formuna yazdığı adres tek bir yerde kalmaz. Depoya, kargo sürecine, fatura sistemine ve müşteri kayıtlarına gider. Başlangıçtaki küçük bir yazım farkı, sonunda geri dönen bir gönderiye, düzeltilmesi gereken bir faturaya ya da aynı müşteriye ait iki ayrı kayda dönüşebilir. Adres doğrulama sistemi bu zincirin başında çalışan bir kontrol katmanıdır. Girilen adresin il, ilçe, mahalle, cadde/sokak ve dış kapı düzeyinde bir adres kataloğuyla tutarlı olup olmadığını denetler ve sonucu tek tip bir biçimde saklamanızı sağlar.

Bu rehberi EKKASOFT Ekibi olarak karar vericiler ve operasyon ekipleri için hazırladık. Rehberde şu sorulara yanıt veriyoruz:

• Sistem ne yapar, ne yapmaz?
• Hangi süreçte, hangi noktada devreye girmelidir?
• Nasıl aşamalı olarak devreye alınır?
• Hangi riskler önceden yönetilmelidir?
• Başarı hangi göstergelerle izlenir?

Teknik ayrıntıyı ekiplerin ortak bir dil kurmasına yetecek düzeyde tutuyoruz. Uygulama ayrıntıları için API dokümantasyonu ayrı bir kaynak olarak hazır.

Adres doğrulama sistemi nedir, ne yapmaz?

Türkiye'de bir adres katmanlı bir yapıdır: il → ilçe → mahalle → cadde/sokak → dış kapı. Bu tür bir sistem, kullanıcının her katmana girdiği değeri bir referans katalogla karşılaştırır. Sonuç üç durumdan biri olur:

1. Tam ve tekil eşleşme: Girilen bileşenler katalogda tek bir adrese karşılık gelir ve birbirini tutarlı biçimde izler.
2. Bir katmanda eşleşme yok: Örneğin il ve ilçe tutar ama mahalle o ilçede bulunmaz. Sistem sorunun hangi katmanda başladığını bildirir.
3. Belirsizlik: Girilen değer birden fazla adaya uyar. Sistem bunlardan birini kendiliğinden seçmez, adayları önünüze koyar.

Sistemin sınırlarını bilmek de en az bu kadar önemlidir. Doğrulamadan olumlu sonuçla geçen bir adres için şunlar söylenemez:

• O adreste kimin oturduğu bilinmez.
• Gönderinin teslim edilebileceği kanıtlanmış olmaz.
• Daire, kat, blok gibi dış kapının içindeki ayrıntılar kontrol edilmez.
• Kullanıcı yanlışlıkla var olan başka bir adresi seçtiyse bu fark edilmez.

Bu sınırları baştan ekiplerinizle paylaşırsanız sistemden gerçekçi beklentiler kurarsınız.

Vatandaşların aldığı adres belgesiyle aynı şey değil

"Adres doğrulama" ifadesi günlük dilde çoğu zaman kişinin kayıtlı ikamet adresini gösteren belgelerle karıştırılır. Yerleşim yeri belgesi bunun bir örneğidir. Bu yazının konusu o belgeler değildir.

Vatandaşın bir kurumdan aldığı belge, belirli bir kişinin adresini gösterir. İşletmelerin kullandığı adres doğrulama ise kişiyle ilgilenmez. Yalnız yazılan adresin bileşenlerinin katalogda tutarlı biçimde bulunup bulunmadığına bakar. Bir müşterinin belirli bir adreste yaşadığını belgelemeniz gerekiyorsa bu ayrı bir süreçtir; adres doğrulama onun yerine geçmez.

Doğrulama ile standartlaştırma arasındaki fark

İki kavram çoğu zaman birlikte anılır ama farklı sorulara yanıt verir.

Aynı adres üç farklı kanaldan şöyle gelebilir:

• Web sitesi: "Caferağa Mah. Moda Cad. No 12"
• Çağrı merkezi: "moda caddesi 12 caferaga kadıköy"
• Satış ekibinin listesi: "CAFERAĞA MH, MODA CD. NO:12, KADIKÖY"

Üçü de aynı yeri anlatır, ama bir veri tabanı için üç ayrı metindir. Adres standartlaştırma sonrasında üçü de tek biçime iner: CAFERAĞA MAHALLESİ, MODA CADDESİ No:12, KADIKÖY/İSTANBUL. Örnekteki adres yalnız biçimi göstermek içindir.

Asıl kazanç, metnin düzgün görünmesinden çok her bileşenin kalıcı bir kimlikle eşleşmesidir. API Türkiye'de her kayıt, sürümden bağımsız bir stableId taşır.

Kayıtları adlarla karşılaştırmak yanıltıcıdır, çünkü aynı mahalle adı farklı yerleşimlerde bulunabilir. Kimlikle karşılaştırdığınızda şu işler çok daha tutarlı yürür:

• mükerrer müşteri kartlarını bulmak,
• ilçe bazında satış raporu almak,
• bölge planlaması yapmak.

API Türkiye'de doğrulama ve standartlaştırma tek adımda yapılır. Adres tam ve tekil olarak eşleştiğinde yanıt üç bilgiyi birlikte döndürür:

• standart adres metni,
• her bileşenin kimliği,
• doğrulamanın yapıldığı veri seti sürümü.

Bu özellik Pro ve üzeri paketlerde bulunur.

Neden önemli? Karar vericiler için bir çerçeve

Hatalı adresin maliyet kalemlerini Hatalı Adres E-Ticarete Neye Mal Oluyor? yazısında ayrıntılı ele aldık. Burada aynı listeyi tekrarlamıyoruz. Bunun yerine, kurumunuzda bir adres doğrulama sistemine ne kadar öncelik vermeniz gerektiğini belirlemek için beş soru öneriyoruz:

1. Adres nerede doğuyor? Web ve mobil formlar, çağrı merkezi, saha satış ekibi, bayi portalı, toplu içe aktarılan listeler. Giriş noktası arttıkça tutarsızlık riski de artar.
2. Adres nereye akıyor? Depo, kargo, fatura, CRM, servis ve kurulum ekipleri. Adresi kullanan her sistem, hatanın etkisini çoğaltır.
3. Hatanın bedelini kim ödüyor? Formu yöneten ekip ile hatanın sonucunu yaşayan ekip çoğu zaman farklıdır. Sorunun uzun süre görünmez kalmasının başlıca nedeni bu ayrılıktır.
4. Mevcut kayıtların durumu ne? Yeni girişleri düzeltmek yetiyor mu, yoksa birikmiş kayıtların da temizlenmesi mi gerekiyor?
5. Ritim ne? Giriş anında doğrulama mı, toplu kontrol mü, yoksa ikisi birden mi?

Etkiyi varsayımsal bir senaryoyla görelim. Bir çağrı merkezi operatörü, müşterinin söylediği mahalle adını yazıyor. Aynı ad hem müşterinin ilçesinde hem komşu ilçede var. Ardından şunlar yaşanıyor:

1. Sipariş yanlış ilçeye yönlendiriliyor.
2. Gönderi geri dönüyor.
3. Müşteri hizmetleri müşteriyi arıyor.
4. Gönderi yeniden çıkıyor.
5. Finans, fatura adresini düzeltiyor.

Tek bir giriş anındaki belirsizlik dört ekibin iş listesine giriyor. Doğrulama bu belirsizliği giriş anında görünür kılar: operatör iki adayı ekranda görür ve müşteriye sorar.

Yanıtlarınızda birden fazla giriş noktası, adresi kullanan çok sayıda sistem ve bedeli farklı ekiplerin ödediği bir yapı görüyorsanız, doğrulamayı yalnız teknik bir iyileştirme olarak görmeyin. Onu süreç tasarımının parçası olarak ele alın.

Sipariş, kayıt ve faturalama anında doğrulama

Temel ilke şudur: adresi doğru bilen kişi, onu giren kişidir. Doğrulamayı o kişi hâlâ ekrandayken yapın. Sonradan yapılan her düzeltme, müşteriye yeniden ulaşmayı gerektirir.

Sipariş anında

• Adresi bileşen bileşen toplayın. Doğrulama, tek satırlık bir adres metni beklemez. İl, ilçe, mahalle, cadde/sokak ve kapı numarasını ayrı alanlar olarak ister. Seçimli formun nasıl kurulacağını İl, İlçe ve Mahalle Seçimli Adres Formu Nasıl Kurulur? yazısında anlattık. Hazır adres seçici bileşen örneklerine de göz atabilirsiniz.
• Cadde/sokak için akıllı arama kullanın. Arama, küçük yazım hatalarına ve Türkçe karakter farklarına toleranslıdır. Seçilen il veya ilçeyle daraltılabilir. Kapı numarası ise seçilen sokağın içinde aranır.
• Siparişi onaylamadan hemen önce doğrulayın. Sonuç olumsuzsa kullanıcıya önerileri gösterin. Bunu bir sonraki bölümde ayrıntılı anlatıyoruz.
• Daire, kat ve tarif bilgisini ayrı alanda tutun. Doğrulama dış kapı düzeyinde çalışır. İç ayrıntıları kaybetmemek için ayrı bir "adres tarifi" alanı kullanın.

Kayıt anında: üyelik, CRM, bayi ve tedarikçi kartları

• Satış ekibinin yeni müşteri kartı açtığı ekran, web formundaki kuralların aynısını uygulamalıdır. Farklı kurallar farklı veri üretir.
• Doğrulanan adresin bileşen kimliklerini müşteri kaydıyla birlikte saklayın. Mükerrer kayıt aramaları ve bölge raporları bu kimliklere dayanır.
• Toplu içe aktarılan listeleri sisteme almadan önce kontrol edin. Doğrulanamayan kayıtları ayrı bir listeye ayırın.

Faturalama anında

• Fatura adresi ile teslimat adresi farklı olabilir. İkisini ayrı ayrı doğrulayın ve ayrı alanlarda saklayın.
• Standart adres biçiminin faturada nasıl kullanılacağına finans ekibiyle birlikte karar verin.
• Faturada hangi adres bilgilerinin yer alması gerektiği hukuki bir konudur. Mali müşavirinizin veya hukuk danışmanınızın görüşünü alın.

Belirsiz adreslerde kullanıcıya seçim sunmak

Doğrulama projelerinin başarısı çoğu zaman olumlu sonuçlarda değil, olumsuz ve belirsiz sonuçlarda belirlenir. API Türkiye'nin doğrulama yanıtı bu durumlar için üç bilgi verir:

• failedAt: eşleşmenin koptuğu katman (il, ilçe, mahalle, cadde/sokak veya kapı numarası).
• matched: o katmana kadar eşleşen bileşenler.
• suggestions: aynı üst kapsam içindeki en fazla beş aday. Bu liste boş da olabilir.

Teknik ekibinizin gönderdiği istek, adresin bileşenlerini ayrı alanlar olarak taşır:

curl "https://api.apiturkiye.com/v1/addresses/validate" \
  -H "X-API-Key: apt_live_..." \
  -H "Content-Type: application/json" \
  --data '{"province":"İstanbul","district":"Kadıköy","neighborhood":"Caferağa Mahallesi","street":"Moda Caddesi","doorNumber":"12"}'

Eşleşme bulunamadığında veya birden fazla kesin aday olduğunda yanıt şu biçimdedir. Değerler yalnız biçimi göstermek içindir:

{
  "data": {
    "valid": false,
    "failedAt": "district",
    "matched": { "province": { "stableId": "apt_v1_prv_...", "code": "34", "name": "İSTANBUL" } },
    "suggestions": [{ "stableId": "apt_v1_dst_...", "code": "1421", "name": "KADIKÖY" }]
  }
}

Bu yanıtı iyi bir kullanıcı deneyimine çevirmek için önerilerimiz:

1. Yalnız sorunlu katmanı sorun. matched bilgisi, kullanıcının doğru girdiği kısmı gösterir. Formu baştan açtırmayın; yalnız sorunlu alanı vurgulayın.
2. Önerileri tıklanabilir seçenekler olarak gösterin. "Bunu mu demek istediniz?" sorusunun altında adaylar listelensin, kullanıcı birini seçsin.
3. Adayı sessizce seçmeyin. İlk öneriyi otomatik kabul etmek belirsizliği gizler ve yanlış ilçe senaryosunu geri getirir. Sistem aynı adlı mahalleler arasında kendiliğinden seçim yapmaz; sizin uygulamanız da yapmamalıdır.
4. Ayırt edici bağlam ekleyin. Aynı adı taşıyan mahalleleri ayırmak için mahalle listesindeki bağlı yerleşim adını etikete ekleyebilirsiniz. Örnek: "DEMİROLUK (ÇAVUŞOĞLU)".
5. Öneri yoksa bir çıkış yolu bırakın. Liste boşsa "Adresimi girdiğim gibi kaydet" seçeneği sunun ve kaydı inceleme kuyruğuna işaretleyin. Katalog sürümler hâlinde yayımlanır. Sahadaki bir değişiklik kataloğa yansıyana kadar gerçek bir adres bulunamayabilir.
6. Kapı numarasını listeden seçtirin. Aynı kapı numarasına ait birden fazla kayıt olabilir. Kullanıcı kapıyı sokak listesinden seçerse, teknik ekip bu kaydın kimliğini doğrulama isteğine ekleyerek kayıtları ayırt edebilir.

Çağrı merkezi için de kısa bir konuşma metni hazırlayın. Operatör adayları müşteriye okur ve müşterinin onayıyla seçer.

Operasyon ekibinin bilmesi gereken bir ayrım daha var:

• Bozuk veya eksik gönderilmiş bir istek hata yanıtı alır. Bu bir entegrasyon sorunudur.
• Eşleşmeyen bir adres ise normal bir yanıt içinde valid: false olarak döner. Bu bir veri kalitesi sinyalidir.

İkisini raporlarda ayrı izleyin.

Devreye alma: aşamalı uygulama planı

Bazı aşamalar için ek notlar:

Aşama 1: Başlangıç ölçümünü atlamayın. Önceki durumu bilmeden yapılan bir iyileştirmenin etkisi sonradan gösterilemez.

Aşama 2: Saklanacak bilgileri netleştirin. Olumlu doğrulamada en az şunları saklamanızı öneririz:

• standart adres metni,
• her bileşenin stableId değeri,
• doğrulamanın yapıldığı veri seti sürümü.

Sürüm bilgisi, bir adresin hangi katalog sürümüne göre doğrulandığını sonradan görmenizi sağlar. Gerektiğinde yeniden doğrulamayı da buna göre planlarsınız.

Aşama 3: Teknik ön koşulları sağlayın.

• API anahtarını müşteri portalından alın.
• Anahtar her istekte X-API-Key başlığıyla gönderilir.
• Anahtar tarayıcı koduna konmaz; istekler sizin sunucunuzdan yapılır.
• Servis yanıt vermediğinde ya da paket kotası dolduğunda sipariş akışı durmamalıdır. Bunun için bir yedek davranış tanımlayın: adres kaydedilir, doğrulama sonraya bırakılır.
• Servisin anlık durumunu servis durumu sayfasından izleyebilirsiniz.

Aşama 5'i Aşama 4'ten sonra yapın. Önce yeni tutarsız girişleri durdurun, sonra birikmiş kayıtları temizleyin. Aksi hâlde temizlediğiniz tabana her gün yeni sorunlu kayıtlar eklenir.

Paket seçimi: ihtiyaçtan pakete

Karar verirken şu ölçütlere bakın:

• Doğrulama şimdi mi gerekiyor? Formunuz hâlâ tek bir serbest metin kutusuysa, ilk adım Core ile seçimli forma geçmek olabilir. Bu adım tek başına giriş kalitesini iyileştirebilir. Doğrulamaya Pro ile geçersiniz.
• Hacim tahmini yapın. Kaç giriş noktası var? Her adres girişinde kaç arama ve kaç doğrulama isteği oluşuyor? Kampanya dönemlerinde tepe kullanım ne olur?
• Kotayı hesap düzeyinde düşünün. Kota müşteri hesabı bazındadır; aynı hesaptaki anahtarlar ortak kotayı kullanır. Web sitesi, çağrı merkezi ve CRM aynı hesaptaysa toplam kullanımı birlikte hesaplayın.
• Toplu temizlik ihtiyacını değerlendirin. Büyük bir birikmiş kayıt tabanınız varsa toplu dosya erişiminin sağlayacağı esnekliği göz önünde bulundurun.
• Operasyon modelini konuşun. Özel hız, kota veya operasyon düzeni gerekiyorsa Enterprise görüşmesini erken başlatın.

Paket içeriklerini paket karşılaştırması bölümünde inceleyebilirsiniz.

Sık yapılan hatalar, riskler ve önlemler

Kişisel verilere ilişkin kısa bir not: Adres, bir kişiyle ilişkilendirildiğinde kişisel veri niteliği taşıyabilir. Doğrulama isteği yalnız adres bileşenlerini içerir. Ad, telefon veya e-posta gibi bilgileri bu sürece katmanıza gerek yoktur. Aydınlatma metinleri, saklama süreleri ve veri aktarımı konularında KVKK alanında uzman bir danışmandan görüş almanızı öneririz.

Başarıyı nasıl ölçersiniz?

Bir adres doğrulama sisteminin işe yarayıp yaramadığını tek bir gösterge söylemez. Aşağıdaki göstergeleri devreye almadan önce ölçmeye başlayın. Ardından sonuçları kanal bazında karşılaştırın.

Giriş kalitesi

• İlk denemede doğrulanan adreslerin payı. Formun ve akıllı aramanın ne kadar iyi çalıştığını gösterir.
• Öneriden seçimle düzeltilen adresler. Belirsizlik yönetiminin işlediğini gösterir.
• "Doğrulanmadı" etiketiyle kaydedilen adresler ve inceleme kuyruğunun yaşı. Kuyruk büyüyorsa kural ya da kapasite sorunu vardır.

Operasyon etkisi

• Adres kaynaklı teslim edilemeyen ve iade edilen gönderiler.
• Adres düzeltmek için açılan müşteri hizmetleri talepleri.
• Fatura adresi düzeltme talepleri.
• Mükerrer müşteri kayıtları.

Denge

• Adres adımında formdan ayrılan kullanıcılar. Doğrulama oranı yükselirken bu gösterge kötüleşiyorsa form fazla katı olabilir.
• Doğrulama isteklerindeki teknik hata yanıtları ve kota uyarıları. Entegrasyon sorunlarını veri kalitesi sorunlarından ayırmanızı sağlar.

Göstergeleri iki ritimde değerlendirin:

• Haftalık operasyon toplantısı: inceleme kuyruğu ve teknik hatalar.
• Aylık yönetim değerlendirmesi: teslimat, müşteri hizmetleri ve finans üzerindeki etki.

Kampanya dönemlerini ayrıca işaretleyin. Hacimdeki ani değişim göstergeleri yanıltabilir.

Uygulanabilir kontrol listesi

Hazırlık

• Adres giriş noktalarının tamamı listelendi.
• Adresi kullanan sistemler ve ekipler belirlendi.
• Başlangıç ölçümleri alındı.

Tasarım

• Tek bir alan sözlüğü ve kural seti yazıldı.
• Olumsuz ve belirsiz sonuçlarda ne yapılacağı her kanal için tanımlandı.
• Daire, kat ve tarif bilgisi için ayrı alan eklendi.
• Saklanacak bilgiler belirlendi: standart adres, bileşen kimlikleri, veri seti sürümü.
• Kişisel veri konuları bir uzmanla değerlendirildi.

Teknik

• API anahtarı sunucu tarafında güvenli biçimde saklanıyor.
• Servis veya kota sorununda yedek davranış çalışıyor.
• Teknik hatalar ile "eşleşme yok" sonuçları ayrı raporlanıyor.

Yaygınlaştırma ve izleme

• Pilot tamamlandı, geri bildirimler işlendi.
• Çağrı merkezi ve satış ekibi için konuşma metni ve eğitim hazırlandı.
• Birikmiş kayıtların temizliği planlandı ve bir sorumlu atandı.
• Gösterge panosu kuruldu; haftalık ve aylık değerlendirmeler takvime işlendi.

Sonraki adım

1. Kendi adres giriş noktalarınızı listeleyerek kapsamı belirleyin.
2. Teknik ekibinizle birlikte API dokümantasyonu üzerinden doğrulama akışını inceleyin.
3. Akıllı arama ve seçimli formla başlamak isterseniz ücretsiz kayıt ile Core paketini deneyin.
4. Doğrulamaya geçmeye hazır olduğunuzda paket karşılaştırmasından ihtiyacınıza uygun seçeneği belirleyin.

Sorularınız için [email protected] adresinden bize ulaşabilirsiniz.