Formda mükerrer kayıt filtresi: aynı kişi ikinci kez doldurunca

Salı sabahı 09:40. Pazarlama ekibi bir tanıtım webinarı duyurmuş, kayıt formundan gece boyunca 214 gönderim düşmüş. Satış temsilcisi listeyi açıyor, ilk yarım saatte otuz kişiyi arıyor ve üçüncü aramada aynı sesi ikinci kez duyuyor: "Ben sabah da konuşmuştum sizinle." Kişi formu iki kez doldurmuş — ilkinde şahsi e-postasıyla, ikincisinde şirket adresiyle, çünkü onay maili gelmedi sanmış. Listede iki satır var, iki farklı sahibi var, iki ayrı arama geçmişi birikiyor. Kimse hata yapmadı; form olduğu gibi çalıştı, sadece aynı insanı iki insan sandı.

Aşağıda bu durumu sırayla ele alacağız: ikinci gönderimin neden geldiğini, bir kaydın hangi kurala göre mükerrer sayıldığını, eşleştirme anahtarının nasıl seçildiğini, tekrar gönderim geldiğinde birleştirme–güncelleme–yok sayma arasındaki farkı, hangi alanın üzerine yazılıp hangisinin korunacağını, mükerrer filtresinin spam korumasıyla neden karıştırılmaması gerektiğini, sahiplik ve raporlama tarafındaki sonuçlarını, kişisel veri açısından değişenleri ve formu yayına almadan önceki kurulum sırasını.

Aynı kişi neden aynı formu ikinci kez doldurur?

Mükerrer gönderimlerin büyük kısmı kötü niyetli değil, belirsizlikten doğar. Kişi gönder düğmesine bastı, sayfa bir saniye bekledi, teşekkür ekranı görünmedi ya da göründü de fark edilmedi; kişi geri gelip tekrar doldurdu. Ya da kampanyayı iki kanaldan gördü: bir kez arama sonucundan, bir kez de e-posta bülteninden. Aynı formu iki farklı bağlamda karşısında bulunca ikisini de doldurmakta bir sakınca görmedi.

İkinci büyük kaynak, kişinin kendisini farklı kimliklerle tanıtması. Bir gönderimde ad soyad, ikincisinde sadece ad. Bir gönderimde cep telefonu, ikincisinde santral numarası. Bir gönderimde kişisel e-posta, ikincisinde kurumsal. Aynı insan, üç farklı anahtar. Randevu ve etkinlik akışlarında bu daha da belirginleşir; bir ziyaretçi hem formu doldurup hem de takvimden doğrudan randevu alan bir bağlantıyı kullandığında CRM'e aynı kişi iki farklı kapıdan girer.

Üçüncü kaynak zamandır. Aynı kişi altı ay önce fiyat listesi indirdi, bugün demo talebi bıraktı. İkisi de gerçek ve ikisi de değerli; ama bunlar "iki kişi" değil, bir kişinin iki teması. Mükerrer filtresi tasarlarken cevaplanması gereken ilk soru budur: neyi tekilleştiriyoruz — kişiyi mi, talebi mi?

• Teknik tekrar: sayfa yavaşladı, kullanıcı iki kez gönderdi. Saniyeler içinde aynı içerik.
• Kanal tekrarı: aynı kampanya farklı reklamdan görüldü, iki ayrı gönderim oldu.
• Kimlik tekrarı: aynı kişi farklı e-posta ya da telefonla geldi.
• Zaman tekrarı: aylar arayla iki ayrı ilgi, tek kişi.

Bir gönderim tam olarak ne zaman mükerrer sayılır?

Mükerrerlik teknik bir eşitlik değil, bir karar kuralıdır. "Aynı satır iki kez yazıldı" ile "aynı insan iki kez yazdı" farklı şeylerdir ve ikisi farklı çözümler ister. Birincisi genelde saniyeler içinde gelen, alanları harfi harfine aynı olan gönderimlerdir; bunları zaman penceresiyle elemek yeterlidir. İkincisi ise veri modeliyle ilgilidir: kişiyi tanımlayan alan hangisi?

Pratikte üç eşik birlikte kurulur. Birincisi anahtar eşleşmesi: hangi alan(lar) eşitse aynı kişi kabul edilir. İkincisi zaman penceresi: eşleşme kaç saat ya da gün içinde geçerli sayılır. Üçüncüsü eylem: eşleşince ne olur. Bu üçünü yazmadan kurulan filtre ya çok agresif olur ve gerçek talepleri yutar, ya çok gevşek olur ve hiçbir şey engellemez.

Rocketly'nin Form Builder tarafındaki Mükerrer Kayıt Filtresi tam bu kararı somutlaştırır: aynı e-posta ya da telefonla gelen tekrar gönderimleri tek kişide birleştirir, CRM'de ikinci bir kayıt açılmaz. Yani gönderim kaybolmaz, kişi çoğalmaz. Zaten CRM'e geçmiş kayıtlarda oluşmuş kalabalığı temizlemek ayrı bir iştir; yinelenen lead'leri bulup birleştirme yöntemlerini ayrı bir yazıda adım adım ele aldık. Form tarafındaki filtre ise o temizliğin bir daha gerekmemesi içindir.

Eşleştirme anahtarı olarak e-posta mı, telefon mu seçilmeli?

E-posta daha kararlı yazılır ama daha kolay çoğaltılır: bir kişinin üç adresi olabilir. Telefon daha tekil kimliktir ama yazım biçimi dağınıktır — başında sıfır olan, ülke kodu yazılan, arada boşluk bırakılan. Telefonu anahtar yapacaksanız önce normalleştirme kuralınızı yazmanız gerekir: ülke kodu her zaman eklenir, boşluk ve tire silinir, baştaki sıfır düşürülür. Bu kural yoksa telefon anahtarı her formatta yeni bir kişi üretir.

İkinci soru şudur: kişiyi mi, kurumu mu tekilleştiriyorsunuz? B2B'de aynı şirketten üç farklı kişi form doldurabilir ve bunların hepsi ayrı kişidir, ama tek bir fırsata bağlanmalıdır. Bunu ayırt edebilmek için kayıtların kişi, firma ve fırsat olarak nasıl ayrıştığını bilmek gerekir; CRM veri modelinde kişi, firma ve fırsat ilişkisini netleştirmeden kurulan mükerrer kuralı, meşru ikinci kişiyi yanlışlıkla ilk kişinin üstüne yazar.

Uygulamada en sağlam kurgu, tek anahtar yerine öncelik sırasıdır: önce e-posta eşleşmesine bak, yoksa normalleştirilmiş telefona bak, ikisi de yoksa yeni kişi aç. CRM Alan Eşleştirme burada belirleyicidir; form alanı hangi CRM alanına bağlandıysa eşleştirme o alan üzerinden yürür. E-posta alanını "not" alanına eşleştirdiyseniz filtre hiçbir şey eşleştiremez, çünkü baktığı yerde veri yoktur.

İkinci gönderim geldiğinde üç davranıştan hangisi doğru?

Eşleşme bulunduğunda üç seçenek vardır ve üçü de meşrudur; yanlış olan, hangisini seçtiğinizi bilmemektir.

Birleştir. Yeni gönderim mevcut kişinin altına bir temas olarak yazılır, ikinci kişi kaydı açılmaz. Kişinin geçmişi tek yerde toplanır. Aynı kişi hem fiyat listesi indirmiş hem demo istemişse, satış temsilcisi bu ikisini yan yana görür. Çoğu senaryonun varsayılanı budur.

Güncelle. Yeni gönderimdeki alanlar mevcut kaydın üzerine yazılır. Telefon numarası değişmiş olabilir, unvan değişmiş olabilir. Bu seçenek veriyi tazeler ama dikkatsiz kullanılırsa dolu bir alanı boş bir alanla ezer.

Yok say. Gönderim kaydedilir ama CRM'de hiçbir şey değişmez. Yalnızca teknik tekrarlarda — saniyeler içinde gelen birebir aynı gönderimde — mantıklıdır. Uzun vadeli tekrarlarda kullanılırsa gerçek talebi görmezden gelmiş olursunuz.

Filtreyi geç kurduysanız ve elinizde zaten karışmış bir liste varsa, tek tek düzeltmeye çalışmayın; toplu kayıt düzenleme ve toplu işlemlerle aynı kuralı geçmişe bir kez uygulayıp sonra formu doğru ayarla açık bırakmak çok daha az zaman alır.

Hangi alan yeni yanıtla güncellenir, hangisi korunur?

Birleştirmenin asıl tartışması burada yaşanır. "Yeni veri her zaman daha doğrudur" varsayımı yanlıştır: ikinci gönderimde kişi aceleyle sadece adını ve e-postasını yazmış, bütçe alanını boş bırakmış olabilir. O boşluğun ilk gönderimdeki bütçe bilgisini silmesi, veri kalitesini ilerletmez, geriletir. Aşağıdaki eşik tablosu, alan tipine göre pratik bir varsayılan verir.

Alan tipi	Örnek	Varsayılan davranış	Gerekçe
Kimlik anahtarı	E-posta, telefon	Koru, yenisini ek adres olarak sakla	Anahtarın değişmesi geçmiş eşleşmeleri bozar
Değişebilir profil	Unvan, şirket, şehir	Doluysa güncelle, boşsa dokunma	Yeni bilgi genelde daha günceldir
Ticari niyet	Bütçe, ihtiyaç, adet	Üzerine yazma, yeni temas olarak ekle	İki farklı talebin ayrı okunması gerekir
Atıf verisi	UTM kaynağı, kampanya	İlkini koru, yenisini ayrıca kaydet	İlk temas ile son temas farklı sorulara cevap verir
Serbest metin	Mesaj, not	Hiç ezme, alt alta ekle	Cümlelerin üzerine yazmak bilgi kaybıdır

Bu tabloyu bir kez yazmak, sonraki tartışmaların çoğunu bitirir. Aynı mantık sistemler arası akışta da geçerlidir: form CRM'i besliyor, CRM başka bir sistemi besliyorsa hangi tarafın hangi alanda söz sahibi olduğu baştan belirlenmelidir. ERP ve CRM'i aynı ekranda çalıştırırken aynı soruyu bir kez daha, bu kez kayıt bazında değil sistem bazında cevaplarsınız.

Mükerrer filtresi spam korumasının yerini tutar mı?

Hayır, ikisi farklı sorunlara bakar ve birbirinin yerine geçmez. Spam koruması "bu gönderim gerçek bir insandan mı geldi?" sorusunu sorar. Mükerrer filtresi "bu gerçek insan zaten kayıtlı mı?" sorusunu sorar. Bot trafiğini mükerrer filtresiyle durdurmaya çalışırsanız, botlar her seferinde farklı adres ürettiği için filtre hiçbir şey yakalamaz.

Form Builder tarafında bu iki katman ayrı ayrı çalışır. Bot Tuzağı ve Hız Sınırı görünmez bir tuzak alan ve IP başına gönderim limitiyle otomatik trafiği daha ilk adımda keser. Spam Koruması ise reCAPTCHA v3 skoru eşiğin altında kalan gönderimi spam kovasına düşürür ve o kayıttan lead açılmaz. Mükerrer filtresi bu ikisinden geçmiş, gerçek olduğu kabul edilmiş gönderimler üzerinde devreye girer. Sıra önemlidir: önce gerçeklik, sonra teklik.

Tekrarı azaltmanın filtre dışı bir yolu daha var: formu kısaltmak ve kişiye göre daraltmak. Aynı ekranda yirmi soru gören ziyaretçi yarıda bırakıp baştan başlama eğilimindedir. Koşullu mantıkla soruyu cevaba göre değiştirmek, gereksiz alanları hiç göstermeyerek yarıda bırakma kaynaklı tekrarların bir kısmını baştan siler.

Birleştirme kararı sahiplik ve takibi nasıl değiştirir?

İki kayıt tek kayda indiğinde çözülen tek şey liste uzunluğu değil; sahiplik netleşir. İki ayrı kayıt varken iki temsilci aynı kişiyi arar, ikisi de "ben ilgileniyorum" der ve müşteri iki farklı teklif alır. Tek kayıt varken sahibi bellidir, ikinci gönderim aynı kartın altına düşer ve o karta bakan kişi ikinci talebi görür.

Burada dikkat edilecek nokta yönlendirmedir. Yönlendirme Kuralları her gönderimi hizmete, bölgeye ya da bütçeye göre doğru temsilciye atar. Kişi ikinci gönderiminde farklı bir hizmet seçtiyse, kural yeni bir temsilciyi işaret edecektir. Kayıt birleşse bile bu bilgi kaybolmamalı: yeni talep, kaydın sahibini değiştirmeden ilgili ekibe bildirim olarak gitmelidir. Sahiplik devri otomatik değil, kararla yapılır.

Bu kararın yazılı olması, pazarlama ile satış arasındaki en sık tartışmalardan birini de kapatır: "lead bize gelmedi" ile "o zaten eski lead'di" arasındaki gri alanı. İki ekibi bir SLA etrafında hizalarken mükerrer kaydın ne sayılacağı da bu belgeye yazılmalıdır, çünkü rakamlar bu tanıma göre değişir.

Mükerrer oranı size hangi soruyu sorduruyor?

Mükerrer filtresi sadece temizlik aracı değil, bir ölçüm aracıdır. Engellenen tekrar sayısı formunuz hakkında konuşur. Oran aniden yükseldiyse ihtimaller sınırlıdır: teşekkür ekranı görünmüyordur, form yavaşlamıştır, aynı kampanya iki kanaldan aynı kitleye gitmiştir ya da bir liste yeniden gönderilmiştir.

Gönderim Takibi formun kaç kez görüntülendiğini, kaç gönderime dönüştüğünü ve dönüşüm oranını tek panelde verir; Kaynak ve Cihaz Kırılımı ise bunu UTM kaynağı, kampanya, yönlendiren site ve cihaz tipine göre ayırır. Tekrarın mobilde yoğunlaştığını görüyorsanız sorun büyük ihtimalle formun uzunluğunda ya da gönderim sonrası geri bildiriminde saklıdır. Değişikliği yapıp geri almanız gerekirse Sürüm Geçmişi kaydedilen her form yapılandırmasını saklar; farkı inceleyip tek tıkla eski sürüme dönersiniz.

Bir uyarı: "lead sayısı" tanımı mükerrer kuralına göre değişir. Filtre açıldığı gün rakam düşer, ama kayıp yoktur — sadece sayma biçimi düzelmiştir. Bu düşüşün panik yaratmaması için tanımın ortak olması gerekir; aynı rakamı herkesin aynı anlaması için bir metrik sözlüğü tutmak, filtreyi açtığınız hafta işinizi kolaylaştırır.

Kayıtları birleştirirken kişisel veri tarafında ne değişir?

Birleştirme, iki kayıttaki kişisel veriyi tek kimlik altında toplamak demektir; yani veri işleme biçiminiz değişir. Kişinin ilk gönderimde verdiği açık rıza ile ikinci gönderimde verdiği rıza aynı kapsamda olmayabilir. Pratik kural: rızaları birleştirmeyin, en dar olanı uygulayın ve her ikisini de gönderim kaydında ayrı ayrı saklayın. Böylece "bu kişiye neden e-posta gönderdik?" sorusuna gönderim bazında cevap verebilirsiniz.

Saklama tarafı da bunun bir parçasıdır. Saklama ve Anonimleştirme gönderim verisine bir süre tanımlamanızı sağlar; süre dolduğunda kişisel alanlar otomatik anonimleştirilir, sayısal istatistikler durmaya devam eder. Birleştirilmiş kayıtta bu sürenin hangi gönderimden başladığı netleşmelidir — genellikle her gönderim kendi tarihinden sayılır, birleşme yeni bir süre başlatmaz.

Kayıt tutma yükümlülükleri de bu tabloya girer. Hangi verileri hangi amaçla topladığınızı ve ne kadar sakladığınızı beyan etmek gerekiyorsa, form alanlarınız ve saklama süreniz bu beyanla uyumlu olmalıdır; VERBİS kaydının kimler için zorunlu olduğunu ve nasıl yapıldığını anlatan yazı bu tarafın çerçevesini veriyor. Formdan çıkan veri, envanterinizde göründüğü haliyle tutarlı olmalıdır.

Formu yayına almadan önce hangi sırayla kurulur?

Sıra önemlidir, çünkü her adım bir sonrakinin doğru çalışmasını mümkün kılar. Önce alanları CRM alanlarına eşleştirin — eşleştirme yoksa mükerrer filtresi bakacak yer bulamaz. Sonra anahtar önceliğini ve telefon normalleştirme kuralını yazın. Ardından eşleşme durumunda uygulanacak eylemi ve alan bazlı üzerine yazma politikasını belirleyin. Bot tuzağı, hız sınırı ve reCAPTCHA eşiğini bunların önüne koyun.

Sonra gerçek bir test yapın: kendi e-postanızla iki kez, farklı telefon formatlarıyla iki kez, bir kez de tamamen yeni bir kimlikle gönderin. Beklediğiniz sonucu görmüyorsanız sorun filtrede değil, çoğunlukla alan eşleştirmesindedir. Kampanya trafiği bekliyorsanız Form Yük Testi ile formu yayına almadan önce eşzamanlı gönderim altında sınayın; yanıt süresi uzayıp teşekkür ekranı geç geldiğinde tekrar gönderim oranının nasıl yükseldiğini ölçümle görürsünüz. Yoğun kayıt dönemleri yaşayan kurumlar için bu adım kritiktir; kayıt hattını CRM üzerinden yürüten eğitim kurumlarında aynı veli aynı gün üç kez form doldurabilir.

Kurulumu bitirdikten sonra bir kez daha bakılacak tek şey kalır: spam kovası. Filtre ile spam katmanı arasında yanlış eleme olup olmadığını ilk hafta gözden geçirin, sonra rutine bırakın. Kendi formunuzda bu akışı uçtan uca denemek isterseniz Rocketly hesabınızı açıp bir test formuyla iki gönderimin nasıl tek kişide birleştiğini aynı gün görebilirsiniz.

Sıkça sorulan sorular

Mükerrer filtresi ikinci gönderimi siler mi?

Hayır. Gönderim kaydı olarak durur, yalnızca CRM'de ikinci bir kişi kaydı açılmaz. İkinci gönderimin içeriği aynı kişinin altında görünür; hangi kampanyadan geldiği ve ne yazdığı kaybolmaz.

Aynı şirketten iki farklı kişi form doldurursa ne olur?

Anahtarınız e-posta ya da telefonsa bunlar farklı kişi olarak açılır ve doğrusu da budur. Aynı firmaya bağlanmalarını istiyorsanız bu bağ kişi seviyesinde değil, firma seviyesinde kurulur.

Eşleşme penceresi ne kadar olmalı?

Teknik tekrarlar için birkaç dakika yeterlidir. Kimlik tekrarları içinse pencere koymamak genellikle daha doğrudur: aynı e-posta altı ay sonra da aynı kişidir. Kampanya bazlı sayım yapmak istiyorsanız pencereyi sayıma koyun, birleştirmeye değil.

Filtreyi sonradan açarsam eski kayıtlar da birleşir mi?

Hayır, form tarafındaki filtre bundan sonraki gönderimler için çalışır. Geçmişteki kalabalık ayrı bir temizlik işidir ve toplu işlemlerle tek seferde yapılır.