Alan eşleme (field mapping): iki sistem arasında veriyi doğru hizalamak
Alan eşleme, iki sistem arasında veriyi doğru hizalamanın anahtarıdır. Kaynak-hedef alanlardan dedupe anahtarına, geliştirici gerektirmeyen pratik bir rehber.
İki sistem arasında entegrasyon kurduğunuzda ilk birkaç kayıt genelde sorunsuz akar; ekip rahatlar, "çalışıyor" denir ve konu kapanır. Sonra bir gün fark edersiniz ki bazı müşterilerin adı telefon alanına yazılmış, bazı siparişlerin tutarı boş kalmış, CRM'deki fırsat durumu hiçbir zaman "kazanıldı" olarak güncellenmemiş. Sorun genelde entegrasyonun kendisinde değil, gözden kaçan bir adımdadır: alan eşleme (field mapping) — kaynak sistemdeki her verinin hedef sistemde tam olarak nereye, hangi biçimde ve hangi kuralla düşeceğinin baştan tanımlanması.
Bu yazıda alan eşlemeyi uçtan uca, pratik şekilde ele alıyoruz: kaynak ve hedef alanları çıkarmaktan veri türü uyuşmazlıklarına, zorunlu alanlara, picklist hizalamaya, yinelenen kayıt yaratmayı önleyecek dedupe anahtarına ve haritayı canlıya almadan önce test etmeye kadar. Bunların hiçbiri kod yazmayı gerektirmez; gerektirdiği şey doğru soruları sırayla sormaktır.
Alan eşleme neden küçük bir ayrıntı değildir
Entegrasyon kurulumlarında bütçe ve dikkat genelde "bağlantıyı kurmaya" gider: API anahtarını girmek, yetkilendirmeyi tamamlamak, ilk testi görmek. Alan eşleme bu heyecanlı kısımdan sonra gelir ve sıkıcı görünür — oysa verinin gerçekten kullanılabilir olup olmayacağını belirleyen tam olarak bu adımdır.
Yanlış eşlenmiş bir alan genelde hemen fark edilmez. Sistem hata vermez, kayıt "başarıyla" aktarılır; sadece yanlış yere ya da yanlış biçimde gider. Haftalar sonra raporlar tutmadığında, satış ekibi yanlış telefon numarasını aradığında ya da bir fatura tutarı sıfır göründüğünde sorunun kaynağını bulmak, baştan doğru eşlemek kadar kolay olmaz.
Önce envanter: kaynak ve hedef alanları yan yana koyun
İyi bir eşlemenin ilk adımı basit ama sık atlanır: iki sistemdeki alanları tek bir listede yan yana yazmak. Bir tarafa kaynak sistemin (web formu, e-ticaret platformu, muhasebe yazılımı) alan adlarını, diğer tarafa CRM'deki karşılıklarını koyun. Bu genelde bir tablodan ibarettir ama entegrasyonun en çok zaman kazandıran belgesidir.
Örneğin iki kişilik bir emlak ofisi web formundan gelen talepleri CRM'e bağladığında, formdaki "Ad Soyad" alanı CRM'de "Ad" ve "Soyad" olarak iki ayrı alana mı gidecek, yoksa tek bir "İsim" alanına mı? Bu tür kararlar envanter aşamasında, veri akmaya başlamadan önce verilmeli.
- Kaynak alan adı ve örnek değer: her alanın gerçek bir örnek değerini yazın; "Tarih" yazmak yerine "12/07/2026" gibi gerçek formatı görmek çok şey ortaya çıkarır.
- Hedef alan ve türü: CRM'de karşılık gelen alanın metin mi, sayı mı, tarih mi, yoksa sabit bir liste mi (picklist) olduğunu not edin.
- Zorunlu mu, opsiyonel mi: hedef sistemde o alan boş bırakılabiliyor mu, yoksa kayıt reddedilir mi?
Veri türü ve biçim uyuşmazlıkları
İki sistem aynı bilgiyi çoğu zaman farklı biçimlerde tutar ve burası alan eşlemenin en çok sürpriz çıkardığı yerdir. Tarihler klasik örnektir: bir sistem "07/12/2026" yazdığında bunun 7 Aralık mı yoksa 12 Temmuz mu olduğunu biçim bilmeden anlayamazsınız. Telefon numaraları da benzer bir tuzaktır — kaynak sistem "0532 123 45 67" yazarken hedef alan uluslararası format ("+90532...") bekliyor olabilir.
Sayısal alanlarda da benzer uyuşmazlıklar çıkar: bir sistem ondalık ayracı olarak virgül kullanırken diğeri nokta kullanabilir, ya da tutar alanı para birimi bilgisini ayrı bir alanda tutarken diğer sistem bunu tek bir metin içinde bekleyebilir. Bu uyuşmazlıklar tek tek küçük görünür ama toplamda "veri temiz değil" hissinin asıl kaynağıdır.
Alan eşleme entegrasyonun en sıkıcı adımıdır — ve tam da bu yüzden en çok ihmal edilenidir.
Zorunlu alanlar: sistemin sessizce reddettiği kayıtlar
Her sistemin "olmazsa olmaz" dediği birkaç alanı vardır. CRM'de bu genelde bir isim ve bir iletişim bilgisidir (e-posta ya da telefon); e-ticaret entegrasyonunda sipariş numarası ya da tutar olabilir. Kaynak sistemde bu alan boş kalabiliyorsa ama hedefte zorunluysa, o kayıt ya reddedilir ya da hedef sistem kendi varsayılan değerini (boş dize, sıfır) yazar — ikisi de fark edilmeden birikir.
Bunu önlemenin yolu, eşlemeyi kurmadan önce her iki sistemin zorunlu alan listesini çıkarmak ve aralarındaki farkı görmektir. Kaynakta opsiyonel ama hedefte zorunlu olan her alan için bir yedek kural (fallback) tanımlamak gerekir — telefon yoksa e-posta kullan, ikisi de yoksa kaydı bir "eksik veri" listesine düşür ve elle tamamlansın.
Picklist ve durum değerlerini hizalamak
Açık uçlu metin alanları nadiren sorun çıkarır; asıl zorluk sabit seçenek listelerinde (picklist, dropdown, durum alanı) yaşanır. Kaynak sistemde bir siparişin durumu "shipped" olarak geçerken, CRM'deki karşılık gelen aşama "Kargoda" ya da "Gönderildi" olabilir. Sistemler bu iki değeri otomatik olarak eşleştirmez; siz her bir değeri tek tek karşılıklandırmazsanız, eşleşmeyen kayıtlar ya boş kalır ya da varsayılan bir aşamaya (genelde listenin ilk seçeneği) düşer — bu da raporları sessizce bozar.
Aynı sorun potansiyel müşteri kaynağı gibi alanlarda da çıkar: "Facebook Ads", "facebook-ads" ve "FB Ads" bir insana aynı şey gibi görünür, ama sistem için üç farklı değerdir. E-ticaret entegrasyonunu kuran biri, platformdaki sipariş durumlarının tam listesini çıkarıp CRM'deki aşamalarla bire bir eşleştirmeden yayına almamalı.
Yinelenen kayıtları önleyecek dedupe anahtarı
İki sistem aynı müşteriyi farklı zamanlarda, farklı kanallardan CRM'e gönderebilir — biri web formundan, biri e-posta entegrasyonundan. Bu kayıtların tek bir kişide birleşmesi için sisteme "bu ikisi aynı kişi" diyebileceği bir anahtar gerekir; buna dedupe anahtarı denir ve genelde e-posta adresidir.
Ama e-posta her zaman güvenilir değildir: bazı kayıtlarda boş kalır, bazılarında büyük/küçük harf ya da boşluk farkı yüzünden sistem iki farklı adres sanır. Bu yüzden pratikte ikinci bir anahtar (telefon numarası gibi) yedek olarak tanımlamak ve eşlemeden önce alanları küçük harfe çevirip baştaki/sondaki boşlukları temizlemek işe yarar.
- Birincil anahtar olarak e-posta: çoğu CRM için en güvenilir tekillik göstergesidir, ama yalnızca doğru normalize edilmişse (küçük harf, boşluksuz).
- Yedek anahtar olarak telefon: e-posta boş geldiğinde ikinci bir eşleşme şansı verir.
- Şirket + isim kombinasyonu: B2B akışlarında bazen e-postadan daha güvenilir bir eşleştirme sağlar.
Basit eşlemenin yetmediği yerler: dönüşümler
Bazı alanlar birebir taşınamaz; önce dönüştürülmesi gerekir. "Ad Soyad" tek alanını CRM'in ayrı "Ad" ve "Soyad" alanlarına bölmek bir dönüşümdür. Telefon numarasının başına ülke kodu eklemek, tarihi bir biçimden diğerine çevirmek, adres parçalarını (mahalle, ilçe, şehir) tek bir metinde birleştirmek de öyle.
Dönüşümleri fazla karmaşık kurmamaya dikkat edin: her ek kural, ileride bakımı gereken bir parça daha demektir. Zapier veya Make gibi bir otomasyon aracı kullanıyorsanız çoğu dönüşüm hazır fonksiyonlarla (metin bölme, biçim çevirme) yapılabilir; native bir entegrasyon kullanıyorsanız bu seçenekler daha sınırlı olabilir, bu yüzden hangi dönüşümlerin gerçekten gerekli olduğuna baştan karar vermek zaman kazandırır.
Alan eşlemeyi elle değil, doğru araçla yönetin
Rocketly'nin entegrasyon panelinde alanları sürükle-bırakla eşleştirir, dönüşümleri kod yazmadan tanımlarsınız
Entegrasyonları keşfedinHaritayı canlıya almadan önce test edin
Eşleme tablosu kağıt üzerinde ne kadar doğru görünürse görünsün, gerçek veriyle test edilmeden güvenilmemeli. En az on-on beş gerçek (ya da gerçeğe yakın) kayıtla küçük bir deneme aktarımı yapın ve sonucu satır satır kontrol edin.
- Uç durumları özellikle deneyin: boş alanlar, çok uzun metinler, Türkçe karakterler, iki kelimeden fazla olan isimler test setinde mutlaka bulunmalı.
- Reddedilen kayıt günlüğünü okuyun: çoğu sistem hangi kaydın neden aktarılamadığını bir log'da tutar; bu log'u okumadan "eşleme tamam" dememelisiniz.
- Picklist eşlemesini tek tek doğrulayın: her durum/kaynak değerinin beklenen karşılığa düştüğünü, sessizce boş ya da varsayılana düşmediğini gözle kontrol edin.
Küçük test temiz çıktıktan sonra biraz daha büyük bir grupla ikinci bir deneme yapın, ardından canlıya alın ve ilk birkaç günü yakından izleyin. Entegrasyonu izlemeye almak, bağlantı sessizce bozulduğunda bunu haftalar sonra değil aynı gün fark etmenizi sağlar.
Ne zaman dışarıdan yardım almalısınız
Çoğu alan eşleme işini teknik bilgi olmadan, dikkatli bir envanter ve test disipliniyle yürütebilirsiniz. Ama bazı durumlarda işin karmaşıklığı artar: onlarca alan, çok adımlı dönüşümler, ya da muhasebe yazılımı gibi hataya toleransı düşük bir sistemle çalışıyorsanız, kurulumu bir entegrasyon uzmanıyla birlikte yapmak zaman kaybettirmez, zamandan tasarruf ettirir.
Dürüst olmak gerekirse, çok basit tek yönlü akışlarda (örneğin sadece isim ve e-postayı taşıyan bir form) bu yazıdaki adımların hepsini resmi bir süreç haline getirmeye gerek yok — on dakikalık bir kontrol yeterli olabilir. Karmaşıklık arttıkça disiplin de artmalı.
Sıkça sorulan sorular
Alan eşleme ile veri dönüşümü aynı şey mi?
Hayır. Alan eşleme, hangi kaynak alanın hangi hedef alana gideceğini belirler; dönüşüm ise o veri hedefe düşmeden önce biçiminin nasıl değiştirileceğini (örneğin ad soyadın bölünmesi) tanımlar. Çoğu entegrasyon ikisini birlikte gerektirir.
Zorunlu alan eksikse kayıt tamamen kaybolur mu?
Sisteme göre değişir; bazı platformlar kaydı tamamen reddeder, bazıları eksik alanı boş bırakıp kaydı yine de oluşturur. İkisi de istenmeyen bir sonuçtur, bu yüzden zorunlu alanlar için baştan bir yedek kural tanımlamak gerekir.
Dedupe anahtarı olarak her zaman e-posta mı kullanılmalı?
Çoğu durumda en pratik seçim e-postadır, ama tek başına yeterli değildir. E-postanın boş ya da tutarsız geldiği durumlar için telefon numarası gibi ikinci bir yedek anahtar tanımlamak, yinelenen kayıtları büyük ölçüde azaltır.
Alan eşlemeyi kaç kayıtla test etmek yeterli?
Kesin bir sayı yok, ama on-on beş kayıtlık, uç durumları (boş alan, uzun metin, özel karakter) içeren bir test seti çoğu hatayı ortaya çıkarır. Temiz çıkarsa daha büyük bir grupla ikinci bir deneme yapılabilir.
Eşleme bir kere kurulduktan sonra tekrar kontrol etmek gerekir mi?
Evet. Kaynak sistem bir alan ekleyip kaldırdığında ya da picklist değerlerini değiştirdiğinde eşleme sessizce bozulabilir; bu yüzden entegrasyonu periyodik olarak, özellikle kaynak sistemde güncelleme yapıldıktan sonra gözden geçirmek gerekir.
Alan eşleme, entegrasyon projelerinin en görünmez ama en belirleyici parçasıdır: doğru yapıldığında kimse fark etmez, yanlış yapıldığında haftalar sonra bozuk raporlar ve kızgın müşterilerle karşılaşırsınız. Envanter çıkarmak, biçim uyuşmazlıklarını önceden görmek, zorunlu alanları ve picklist değerlerini tek tek karşılıklandırmak, bir dedupe anahtarı seçmek ve küçük bir test yapmak — bunların hepsi bir geliştirici gerektirmez, sadece sabır ve düzen ister. Rocketly'nin entegrasyon araçlarını kullanırken de kullanmazken de bu disiplin, verinizin size sadık kalmasını sağlayan şeydir.