görünürlük.

Siteme gelenler neden iletişim formunu doldurmuyor?

Ziyaret var ama iletişim formu dolmuyor mu? Gerçek gönderimi, ölçüm hatalarını, ziyaretçi niyetini ve mobil form engellerini ayırıp ilk düzeltmeyi seçin.

Siteme gelenler neden iletişim formunu doldurmuyor?

Sitenize gelenler iletişim formunu doldurmuyorsa neden her zaman formun uzunluğu değildir. Ziyaretçi henüz teklif istemiyor olabilir, ne elde edeceğini anlamayabilir veya formu kullanırken hata yaşayabilir. Bazen de talep gönderilir ama size ulaşmaz ya da ölçüm raporunda görünmez.

Önce formun çalıştığını ve neyi saydığınızı doğrulayın. Ardından ziyaretçinin geldiği sayfayı, formdaki soruları ve gönderim sonrasını inceleyin. Böylece yalnızca butonun rengini değiştirerek çözülmeyecek bir teslimat sorunuyla, kullanıcının başlamasını zorlaştıran bir sorunu birbirinden ayırabilirsiniz.

Önce formun gerçekten gönderilip gönderilmediğini kontrol edin

Kendi sitenizde veya kontrol yetkiniz olan bir formda, size ait ve hassas olmayan test bilgileriyle bir deneme yapın. Mesaja bunun bir test olduğunu yazın. Hem telefonda hem bilgisayarda şu yolu kontrol edin:

  1. İlgili hizmet sayfasından forma ulaşabiliyor musunuz?
  2. İstenen bilgileri girdiğinizde form geçerli girdiyi kabul ediyor mu?
  3. Gönderim sonrasında açık bir başarı veya hata bildirimi geliyor mu?
  4. Talep, sitenizin kullandığı gerçek hedefte görülebiliyor mu: yönetim paneli, müşteri kayıt sistemi veya e-posta kutusu?

Ekranda “gönderildi” yazmasıyla kaydın doğru yere ulaşmasını ayrı kontrol edin. Kayıt oluştuğu halde e-posta bildirimi gelmiyorsa sorun, ziyaretçinin formu doldurmaması değildir. Bildirim adresi, istenmeyen posta klasörü ve varsa gönderim hatası kayıtları incelenmelidir. Test talebini gerçek müşteri sayısına katmayın.

Bazı sitelerde buton yalnızca kullanıcının e-posta uygulamasında bir taslak açar. Bu akışta kullanıcı e-postayı ayrıca göndermelidir. Taslak açılmasını, site tarafından alınmış talep olarak raporlamayın; buton ve açıklama da bu davranışı doğru anlatmalıdır.

MDN’nin form doğrulama rehberi, tarayıcıdaki kontrol ile sunucudaki doğrulamanın farklı olduğunu açıklar. Form tarayıcıda kabul ediliyor ama sunucuda reddediliyorsa teknik neden araştırılmalıdır. Sorunu çözmek için güvenlik veya spam önlemlerini bütünüyle kapatmak yerine, hangi adımın geçerli gönderimi durdurduğunu bulun.

Ziyaret, form başlangıcı ve tamamlanan talebi ayrı sayın

Toplam site ziyareti, iletişim formunu gören veya kullanmaya başlayan kişi sayısı değildir. Kullanıcı başka bir yazıyı okuyup formun bulunduğu bölüme hiç gelmeden ayrılmış olabilir. Önce hangi sayfalara ziyaret geldiğini inceleyin; bunun için Google’dan gelen ziyaretleri ölçme rehberinden yararlanabilirsiniz.

GA4 kullanıyorsanız geliştirilmiş ölçüm açıklamasındaki form_start ve form_submit olaylarını ayırın. İlki bir oturumda formla ilk etkileşimi, ikincisi form gönderme etkileşimini kaydeder. Bu olayların kendi formunuzda doğru çalıştığını test edin. Bir etkileşim kaydı, tek başına talebin sunucuda kabul edildiğini veya e-postanın ulaştığını kanıtlamaz.

Gözleminiz Önce neyi kontrol etmelisiniz?
Sayfa ziyaret alıyor, form başlangıcı görünmüyor Başlangıç ölçümü çalışıyor mu; kullanıcı forma ulaşabiliyor ve neden dolduracağını anlayabiliyor mu?
Başlangıç var, doğrulanmış tamamlanma az Alanlar, hata mesajları, teknik gönderim ve ziyaretçinin hazır oluşu
Gönderme olayı var, hedefte kayıt yok Olayın tanımı, sunucu yanıtı ve gerçek teslimat yolu
Gerçek talep var, raporda yok Ölçüm kurulumu ve izin koşulları; bunu otomatik olarak sıfır talep saymayın

Oran karşılaştırırken aynı formu, dönemi ve sayım birimini kullanın. Oturum, tekil kişi, olay sayısı ve müşteri kaydı birbirinin yerine geçmez; tekrar gönderimler de sonucu değiştirebilir. Google’ın uyarısına uygun olarak ad, e-posta, telefon veya mesaj içeriğini analiz olaylarına göndermeyin. Eksik ölçümü düzeltmek için kişisel verileri rapora taşımak gerekmez.

Gelen kişinin niyetiyle istediğiniz adımı eşleştirin

Form çalışıyorsa sıradaki soru, ziyaretçinin o anda iletişime geçmek isteyip istemediğidir. Bir sorunun cevabını öğrenmek için gelen kişiyle hizmetinizden teklif almak isteyen kişinin ihtiyacı aynı olmayabilir. İkisini tek ziyaret toplamında değerlendirmek, formu olduğundan başarısız gösterebilir.

Örneğin “çalışma masası yüksekliği kaç olmalı?” yazısını okuyan biri yalnızca ölçü arıyor olabilir. Özel ölçü masa hizmetinizi inceleyen biri ise teslim süresini, hizmet bölgesini ve teklif için ne gerektiğini öğrenmek isteyebilir. Bu varsayımsal örnekte ilk ziyaretçiyi hemen ayrıntılı teklif formuna yönlendirmek yerine, ilgili hizmeti inceleyebileceği anlaşılır bir bağlantı sunmak daha uygun bir sonraki adım olabilir.

Ziyaretin geldiği kaynak, giriş sayfası ve o sayfada verilen söz birlikte incelenmelidir. Reklamda fiyat bilgisi bekleten bir ifade kullanıp sayfada yalnızca uzun bir başvuru formu göstermek, beklentiyle karşılaşılan adımı ayırır. Hizmet vermediğiniz bölgeden gelen talepleri de form tasarımıyla çözmeye çalışmayın.

Ziyaretçi telefon veya e-posta gibi başka bir yoldan gerçekten iletişime geçiyorsa bunu da ayrıca değerlendirin. Bağlantıya tıklanmasını tamamlanmış görüşme saymayın. Formun az kullanılmasını, bütün iletişim yollarının başarısız olduğu şeklinde yorumlamayın.

Formu telefonda ve klavyeyle baştan sona deneyin

Ziyaretçinin hangi alanda zorlandığını, yalnızca tasarıma bakarak bulamazsınız. Gerçek telefonda formu açın; klavye görünürken alanlar, açıklamalar ve gönderme butonu kullanılabiliyor mu diye deneyin. Bilgisayarda da fare kullanmadan Tab tuşuyla alanlar arasında ilerleyin. Odaklanan alanın belli olması, sıranın anlaşılması ve bir pencerenin formu kapatmaması gerekir.

Her sorunun ilk görüşmeye katkısını sorgulayın. GOV.UK soru tasarımı yaklaşımı, her sorunun neden sorulduğunu bilmeyi ve gerçekten gereken bilgiyi istemeyi önerir. İlk değerlendirmede kullanmadığınız ayrıntıları sonraya bırakabilirsiniz. Ancak talebin uygunluğunu anlamak için gereken bir bilgiyi yalnızca form kısalsın diye kaldırmayın. Zorunlu ve isteğe bağlı alanlar anlaşılır olmalıdır.

W3C’nin alan etiketleme rehberine göre alanların amacı, ilgili kontrolle ilişkilendirilmiş etiketlerle belirtilmelidir. Sıradan bir iletişim formunda açıklamanın yalnızca yazı yazınca kaybolan yer tutucu metinde kalmamasına dikkat edin. “Mesaj” gibi geniş bir alan için “Hangi hizmete ihtiyaç duyuyorsunuz?” açıklaması yardımcı olabilir.

E-posta ve telefon alanlarını da kendi bilgilerinizle deneyin. Geçerli bir telefon biçimi gereksiz yere reddediliyor mu? Tarayıcının önerdiği bilgi doğru alana geliyor mu? web.dev otomatik doldurma rehberi, uygun autocomplete değerlerinin tarayıcıya alanı tanıtmaya yardımcı olduğunu açıklar.

Bir hata olduğunda kullanıcı neyi düzelteceğini anlayabilmelidir. W3C bildirim rehberi, anlaşılır hata açıklamalarını ve başarı bilgisini vurgular. “Bir hata oluştu” yerine gerçekten hatalı alanı ve gereken düzeltmeyi belirtin; sorun yalnızca renkle anlatılmasın. Doğru girilmiş bilgileri tekrar tekrar yazdıran, belirsiz bir uyarıyla gönderimi durduran veya geçerli kullanıcıyı engelleyen doğrulama adımlarını düzeltme listesine alın.

İletişime geçmenin nedenini ve sonrasını açıklayın

Kullanıcı formu gördüğü halde başlamıyorsa, hangi sonucu beklemesi gerektiğini anlayıp anlamadığına bakın. Formun üzerinde sunulan hizmeti, kimler için uygun olduğunu ve gönderimden sonra ne yapılacağını kısa biçimde açıklayın. Formu doldurmadan önce karar vermesi gereken temel bilgileri kullanıcıdan saklamayın.

Butondaki ifade gerçek işlemi anlatmalıdır. Örneğin “Teklif iste” yazan bir buton fiyatın hemen gösterileceği anlamına gelmemelidir. Gerçekte önce ihtiyaç değerlendirilecekse bunu açıklayın. Akış yalnızca e-posta taslağı hazırlıyorsa “E-posta taslağını aç” gibi bir ifade daha doğru beklenti kurar.

Bilgilerin kime ulaşacağı ve hangi amaçla kullanılacağı da anlaşılır olmalıdır. Gerçek iletişim bilgilerinizi ve ilgili gizlilik açıklamasını erişilebilir tutun. Kullanıcının soru sormak için form dışında başvurabileceği gerçek bir iletişim yolu da bulunmalıdır.

Karşılayamayacağınız yanıt süresi veya ücretsiz hizmet sözü vermeyin. Aynı şekilde güven oluşturmak için olmayan müşteri yorumları eklemeyin. Kullanıcıya sunduğunuz gerçek süreç, etkileyici ama belirsiz bir vaat yerine somut bir sonraki adım vermelidir.

İlk düzeltmeyi bulgunuza göre seçin

Önce yeniden üretebildiğiniz engeli giderin. Geçerli gönderimi kabul etmeyen veya alınan talebi doğru yere ulaştırmayan bir formda, başlık denemesinden önce işleyiş düzeltilmelidir. Form çalışıyor fakat kullanıcı başlamıyorsa, sayfanın sunduğu değer ve istenen adım arasındaki ilişkiye bakın.

Varsayımsal bir örnekte, telefondan gelen kullanıcılar formu başlatıyor ancak uluslararası kodla yazılmış geçerli telefon numaraları reddediliyor olsun. Bu bulgu, “mobil kullanıcılar form sevmiyor” sonucunu desteklemez. Önce kabul edilen biçimi ve açıklamayı düzeltip aynı girdiyi yeniden deneyin. Ardından talebin hedefe ulaştığını da kontrol edin. Burada anlatılan bir test sonucu veya ölçülmüş artış değildir; belirli bir hatadan hareket etme örneğidir.

Değişiklik kaydınız kısa olabilir:

Sorun hangi cihaz ve adımda görüldü? Ne değiştirdik? Aynı denemede engel kalktı mı? Talep gerçek hedefe ulaştı mı? Sonraki dönemde hangi tanımlı sayımı izleyeceğiz?

Çalışan bir formdaki iyileştirmeyi değerlendirirken farklı trafik kaynaklarını, dönemleri veya sayım tanımlarını birbirine karıştırmayın. Az sayıdaki ziyaretle kesin neden çıkarmayın. Aynı anda reklamı, teklifi ve formu değiştirirseniz sonuçtaki farkın yalnızca formdan kaynaklandığını söyleyemezsiniz. Gönderim sayısıyla birlikte gerçek ve uygun talepleri de değerlendirin.

Görünürlük analizinde ziyaretçinin hangi noktaya kadar geldiğini incelemek, sonraki çalışmayı seçmeye yardımcı olur. İletişim formunun az doldurulmasını tek bir tasarım kusuru olarak kabul etmek yerine, gözlediğiniz adımı ve doğruladığınız hatayı esas alın.

BLOG / BİLGİDEN UYGULAMAYA

Okumaya devam edin.

Bütün yazılar