Form dönüşümleri nasıl artırılır: alan bazında ölç, düzelt ve test et

Form dönüşümleri nasıl artırılır? Önce formu başlatıp göndermeyen kullanıcıların hangi alanda bıraktığını ölçersin, sonra en çok kişiyi kaybettiren alandaki sorunu düzeltir ve değişikliği kontrol grubuyla test edersin. Kullanılabilirlik yönergeleri neyin düzeltilebileceğini söyler, kendi alan verin ise hangisinden başlayacağını.

Lead'in hangi kanaldan geldiği, teklifin kendisi ve açılış sayfasının bütünü bu yazının konusu değil. Burada yalnızca formun kendisine, yani ziyaretçinin doldurduğu alanlara ve gönderim anına bakılıyor.

Formu tek bir dönüşüm oranıyla izlemek, kaybın formdan önce mi yoksa formun içinde mi olduğunu saklar. Aynı dönem ve aynı birimle, tercihen tekil kullanıcıyla, dört sayı tut: formu gören, formu başlatan, formu başarıyla gönderen ve başlatıp göndermeden ayrılan kullanıcılar. Gören ile başlatan arasındaki kayıp çoğunlukla sayfanın ve teklifin konusudur. Başlatan ile gönderen arasındaki kayıp ise formun içinden gelir ve Türkçe kaynaklarda bu paya form terk oranı ya da form terk etme oranı deniyor.

Google Analytics 4 (GA4) bu sayıların ikisini hazır verir. Gelişmiş ölçüm olayları sayfasına göre form_start kullanıcı bir oturumda formla ilk kez etkileşime geçtiğinde, form_submit ise kullanıcı formu gönderdiğinde tetiklenir. Yani form_start formu görenleri değil, formla etkileşime geçenleri sayar.

Formu görenler için formun ekranda göründüğü anı ayrı bir olayla kaydetmen gerekir. Olayların form_id ve form_name gibi parametrelerini raporlarda kullanmak için de onları özel boyut olarak tanımlaman gerekiyor.

"Gönderdi" ile "başarıyla gönderdi" aynı şey değil. Google Tag Manager'ın form gönderme tetikleyicisi belgesine göre Check Validation seçeneği işaretliyse tetikleyici yalnız form başarıyla gönderildiğinde çalışır. Seçenek işaretli değilse kullanıcı formu her göndermeye çalıştığında çalışır.

Hatalı denemeleri gönderim saymamak için başarıyı teşekkür sayfası ya da sunucunun onayı gibi bir sinyale bağla. Kendi test gönderimlerini ve spam diye elenen kayıtları da sayımın dışında tut.

GA4'ün gelişmiş ölçüm belgesinde form olayları için sayılan parametreler formun kimliğini, adını, gönderildiği adresi ve gönder düğmesinin metnini taşır. Bu listede kullanıcının hangi alanda kaldığını söyleyen bir parametre yok. Alan bazında terki görmek için kendi özel olaylarını kurman gerekir. Bir başlangıç planı beş olaydan oluşabilir:

• form_view: form ekranda göründüğünde, formun kimliğiyle.
• form_field_leave: kullanıcı bir alandan çıktığında, alanın adı ve durumu (boş, dolu, hatalı) ile.
• form_error: bir doğrulama hatası gösterildiğinde, alanın adı ve hata türüyle (boş zorunlu alan ya da biçim).
• form_success: sunucu gönderimi onayladığında.
• form_abandon: kullanıcı formu başlattıktan sonra başarılı gönderim olmadan sayfadan ayrılırken, son etkileştiği alanın adıyla.

Bu olaylara alanın içeriğini asla koyma, yalnız adını gönder. Google'ın kişisel bilgi göndermeme rehberi, ziyaretçilerin form alanlarına kişisel bilgi yazdığını hatırlatıyor ve bu bilginin Analytics'e gitmeden önce temizlenmesini istiyor. Alan adlarını raporda görmek için alan adı parametresini özel boyut olarak tanımla. Google 500'den fazla olası değeri olan boyutları yüksek kardinaliteli sayıyor, bir formun alan adları bu sınırın epey altında kalır.

Bu plan bir yöntem, GA4'ün hazır bir özelliği değil. Özellikle form_abandon olayının sayfa kapanırken her seferinde ulaşacağı belgelenmiş değil, bu bir varsayım. Kurulumu yayına almadan önce formu kendin doldur, farklı alanlarda bırak ve olayların gelip gelmediğini DebugView ekranında izle.

Google'a göre DebugView, hata ayıklama modu açıkken bir kullanıcıdan toplanan olayları gerçek zamanlı gösterir. Bazı ayrılmalar kaydedilmiyorsa son alan sayıları gerçek terkin altında kalır. Eksikliğin belli bir cihazda ya da tarayıcıda toplanıp toplanmadığına da bak.

Alanları GA4'te huni adımı olarak dizmek ilk akla gelen yol, ama yanıltabilir. Huni keşfi belgesine göre bir adımı atlayan kullanıcı huniden düşer ve sonraki adımlarda sayılmaz. Kullanıcılar alanları atlayıp geri dönebildiği için alan sırası huni adımı yapılınca formu bitiren kişiler de kayıp görünebilir. Bırakanları son etkileştikleri alana göre dağıtmak bu sorunu taşımaz.

Varsayımsal bir B2B (işletmelere satış yapan) sitenin demo talep formunda altı alan var: ad soyad, iş e-mail'i, telefon, şirket adı, çalışan sayısı ve isteğe bağlı mesaj. 28 günde 12.000 kullanıcı formu gördü, 3.000'i formu başlattı.

Başlatanların 1.800'ü aynı oturumda başarılı gönderim yaptı, 1.200'ü göndermeden ayrıldı. Bu 1.200 kişiyi son etkileştikleri alana göre dağıtınca en büyük pay 400 kişiyle Telefon alanına düşüyor:

Telefon alanı bırakanların %33,3'ünü taşıyor ve etkileşen kullanıcılara oranla da en yüksek bırakma payı orada. İki sıralama da aynı alanı gösterdiği için ilk inceleme Telefon alanından başlar.

Satırlar ardışık huni adımları değil, her satırın paydası o alanla etkileşen kullanıcılar. Bir kullanıcı alan atlayıp geri de dönebilir. Gönder satırındaki 140 kişi düğmeye bastı, hata aldı ve başarılı gönderim yapmadan ayrıldı.

Telefon alanındaki 400 kişi, sorunun dokunduğu kullanıcı sayısıdır, düzeltmenin kazancı değil. Alanı düzeltmek bu kişilerin bir kısmını geri getirebilir, ama bir kısmı başka bir nedenle yine ayrılacaktı. Kazancı yalnız bir test ölçebilir.

Sorunun türü ilk testi belirler. Telefon alanıyla etkileşen 2.620 kullanıcının 520'si (%19,8) en az bir hata mesajı gördü. Bırakanları hata görüp görmediklerine göre ayırınca hangi değişikliğin önce deneneceği değişebilir:

İki durumda da bırakan sayısı 400 ve hata gören sayısı 520 sabit, yalnız bırakanların içinde hata görenlerin payı değişiyor. A durumunda kayıp çoğunlukla biçim hatasıyla birlikte geliyor: alan boşluklu, +90'lı ya da parantezli yazımı reddediyor olabilir. B durumunda kullanıcılar hata görmeden ayrılıyor, yani telefon numarası vermek istememiş olabilirler. Bu da telefonu isteğe bağlı yapmayı ya da neden istendiğini alanın yanında açıklamayı aday yapar.

Alan verisi kullanıcının nerede ayrıldığını gösterir, neden ayrıldığını göstermez. B durumundaki "numara vermek istemedi" yorumu bir çıkarımdır. Bunu sınamak için o alanda biten birkaç oturum kaydını izleyebilir ya da birkaç kişiye formu doldurtup nerede durduklarını sorabilirsin.

Ayrıca form_start oturum başına sayıldığı için formu bugün bırakıp yarın gönderen kullanıcı bugünün verisinde bırakan görünür. Aynı oturuma göre hesaplanan bırakma, gerçek kaybı olduğundan büyük gösterebilir.

Tablolardaki rakamlar varsayımsal. Kişi sayıları tam, yüzdeler bir ondalık basamağa yuvarlandı.

Gereksiz alan, World Wide Web Consortium'ın (W3C) erişilebilir form eğitiminde ilk uyarılardan biri. W3C'nin Web Erişilebilirliği Girişimi (WAI) tarafından hazırlanan form eğitimine göre kullanıcılar genellikle kısa ve sade formları tercih ediyor, ilgisiz ya da fazla bilgi istendiğinde formu bırakma olasılıkları artıyor. Her alan için bu bilginin ilk değerlendirmede gerekip gerekmediğini sor. Bir alanı çıkarmanın satış tarafındaki maliyetini de hesaba katan bir plan için alan sayısını azaltma testine bakabilirsin.

Kalan alanların düzeni de doldurmayı etkiler. NN/g'nin 2016 tarihli form tasarımı yönergeleri alanları tek sütunda göstermeyi öneriyor, çünkü birden fazla sütun formda aşağı doğru ilerleyişi bölüyor. Aynı yönergeler şehir ve posta kodu gibi kısa ya da mantıksal olarak bağlı alanların aynı satırda durabileceğini söylüyor. Kendi formunda bu kararı tek sütun ve iki sütun testiyle sınayabilirsin.

NN/g alan sırasında da alışılmış diziyi izlemeyi öneriyor: kart numarası, son kullanma tarihi ve güvenlik kodu gibi. Seçeneklerde en sık seçileni başa koymak da aynı yönergelerde geçiyor. Kolay alanla başlamak ise ayrı bir soru, çünkü zor alanı sona taşımak terki yalnızca ileri itebilir. En kolay alanı başa koyma testi bu yüzden sonucu başlama oranıyla değil gönderimle değerlendiriyor.

Etiket, alanın ne istediğini söyleyen kalıcı metindir. W3C'nin etiket rehberi kullanıcıların çoğunun formu anlamak için görünür etiketi tercih ettiğini ya da buna ihtiyaç duyduğunu yazıyor. Aynı sayfaya göre etiketi alanın üstüne koymak az gören ve mobil cihaz kullanan kişiler için yatay kaydırmayı azaltıyor.

W3C bu faydanın çevredeki alanlara ve içeriğe bağlı olduğunu, her formda ayrıca değerlendirilmesi gerektiğini de ekliyor. Üstte ve solda etiketi kendi formunda karşılaştırmak için etiket konumu testi hazır bir plan.

Alanın içindeki örnek metin (placeholder) etiketin yerini tutmaz. W3C'nin form talimatları sayfası bunu doğrudan söylüyor. NN/g'nin 2014 tarihli placeholder yazısı da yazmaya başlayınca kaybolan metnin, alanda ne istendiğini hatırlamayı zorlaştırdığını anlatıyor.

Biçim kuralı varsa (GG/AA/YYYY gibi) etikette ya da alanın altında kalıcı olarak yaz. Alan altı açıklamanın hata oranını düşürüp düşürmediğini yardım metni testiyle ölçebilirsin.

Zorunlu alanları tek tek işaretle. NN/g'nin 2019 tarihli zorunlu alan yazısı, kullanıcıların formun başındaki "tüm alanlar zorunludur" notunu okumadığını ya da unuttuğunu anlatıyor ve çözüm olarak her zorunlu alanı işaretlemeyi öneriyor. İsteğe bağlı alanlara "isteğe bağlı" yazmak şart değil, ama aynı yazıya göre kullanıcının bilişsel yükünü hafifletiyor.

NN/g'nin form yönergeleri isteğe bağlı alanları bir ya da ikiyle sınırlamayı da öneriyor. İşaretlemenin doldurmaya etkisini zorunlu ve isteğe bağlı alan testi ile sınayabilirsin.

Hata mesajı hem hatalı alanı hem de düzeltme yolunu söylemeli. Web İçeriği Erişilebilirlik Yönergeleri (WCAG) içinde, sürüm 2.2'deki 3.3.1 Hata Tanımlama ölçütüne göre bir giriş hatası otomatik olarak tespit edilirse hatalı öğe belirtilir ve hata kullanıcıya metinle açıklanır. 3.3.3 Hata Önerisi ölçütü, düzeltme önerisi biliniyorsa güvenliği ya da amacı tehlikeye atmadıkça bu önerinin de verilmesini istiyor.

W3C'nin örneğine göre "E-mail geçerli değil" gibi bir mesaj 3.3.1'i karşılar. Beklenen biçimi de söyleyen bir mesaj ("E-mail adresini ad@alanadi.com biçiminde yaz" gibi) ikisini birden karşılar.

Hatanın ne zaman gösterildiği de önemli. NN/g'nin 2019 tarihli form hataları yönergeleri hatayı çoğu durumda kullanıcı alanı bitirip sonrakine geçene kadar göstermemeyi öneriyor. Baymard Institute'un kullanıcı testleri bunun nedenini gösteriyor. 9 Ocak 2024 tarihli satır içi doğrulama araştırmasına göre aşırı erken doğrulama, kullanıcıya girişini doğru yazma fırsatı bulamadan yanlış olduğunu söylüyor.

Baymard'a göre satır içi doğrulama gönderimdeki hata gösterimini tamamen gereksiz kılmıyor, çünkü kullanıcı hatalı alanlarla da göndermeyi deneyebilir. Gönderimden sonra hata çıkarsa W3C'nin bildirim rehberi odağı hatalı ilk alana taşımayı öneriyor. NN/g'nin form yönergeleri de hatalı girişin silinmeden korunmasını istiyor, böylece kullanıcı yalnız hatayı düzeltir.

Kullanıcı tek bir doldurma denemesinde aynı hatayla üç ya da daha fazla kez karşılaşıyorsa NN/g bunu arayüzde daha derin bir sorunun işareti sayıyor. form_error olayını alan adına göre sayarsan bu alanları raporda görürsün.

Doğrulama kuralı da esnek olmalı. W3C'nin doğrulama rehberi telefon numaralarının farklı ayırıcı ve rakam gruplamalarıyla yazıldığını, birden fazla yazımı yorumlayabilen formun daha kolay kullanıldığını yazıyor. Aynı rehbere göre tarayıcıdaki doğrulama tek başına güvenlik sağlamaz, veri sunucuda da doğrulanmalıdır. Örnekteki A durumu tam olarak bu tür bir düzeltmenin adayı.

Tarayıcının otomatik doldurması, kullanıcının kayıtlı adını, adresini ya da telefonunu tek dokunuşla alana koyar, ama yalnız alanın amacını tanıyabilirse. Mozilla'nın MDN Web Docs (MDN) sitesindeki autocomplete özniteliği belgesine göre bu öznitelik tarayıcıya alanda hangi tür bilginin beklendiğini söyler. Ad için name, e-mail için email, telefon için tel gibi standart değerleri kullan.

MDN, autocomplete="off" değerinin tarayıcının kayıtlı veriyi önermesini engellediğini ve birçok kullanıcının dayandığı bir özelliği kaldırdığını yazıyor. Uydurma değerler de benzer sonuç verir, çünkü tarayıcı alanı tanıyamaz. Doğru değerler erişilebilirlikle de örtüşüyor: MDN'ye göre geçerli autocomplete değerleri, WCAG 2.2'nin 1.3.5 Giriş Amacını Belirleme ölçütünü karşılıyor. Bu ölçüt, kullanıcı hakkında bilgi toplayan alanların amacının programla belirlenebilmesini istiyor.

Tarayıcının otomatik doldurması ile sitenin kendi sunduğu otomatik tamamlama önerileri (adres ya da şirket adı listesi gibi) farklı şeyler. İlki kullanıcının tarayıcıda kayıtlı verisini kullanır, ikincisi senin öneri kaynağını. Öneri listesinin tamamlamayı ve veri doğruluğunu nasıl etkilediğini otomatik tamamlama testiyle ölçebilirsin.

Tarayıcının otomatik doldurmasını ölçmek için ise web.dev'in otomatik doldurma ölçüm rehberi her alanda dört durumu ayırıyor: boş bırakılan, elle doldurulan, otomatik doldurulan ve otomatik doldurulup değiştirilen. Bu durumu form_field_leave olayının durum bilgisine ekleyebilirsin.

Mobilde doğru klavye yazım hatasını azaltır. Baymard'ın 2015 tarihli dokunmatik klavye araştırmasında, sayısal girişler için standart klavyeye dayanan sitelerde yazım hataları belirgin biçimde daha sık görüldü. Aynı araştırma ad, adres ve e-mail gibi sözlükte olmayan girişlerde otomatik düzeltmenin kötü çalıştığını gözlemlemiş.

MDN'nin inputmode özniteliği belgesi, telefon numarası isteyen girişlerde genellikle type="tel" kullanılmasını söylüyor. Dokunma hedefleri için de WCAG 2.2'nin 2.5.8 Hedef Boyutu (Minimum) ölçütü, yeterli boşluk gibi istisnalarla en az 24 × 24 CSS (Cascading Style Sheets) pikseli istiyor.

Uzun bir formu adımlara bölmek, kaç alan sorduğunu değiştirmez. Baymard'ın 26 Haziran 2024 tarihli ödeme akışı araştırmasına göre bir ödeme akışında form alanı sayısı, genel kullanılabilirliği adım sayısından çok daha fazla etkiliyor. Bulgu ödeme akışlarından geliyor, demo ya da kayıt formlarına taşımak bir çıkarım. Yine de adım sayısını tartışmadan önce alan sayısına bakmak için bir gerekçe.

Formu adımlara böleceksen W3C'nin çok sayfalı form rehberi ilk adımda kaç adım geleceğini söylemeyi ve her adımda ilerlemeyi göstermeyi öneriyor. Aynı süreçte, WCAG 2.2'nin 3.3.7 Tekrarlı Giriş ölçütü daha önce girilen bir bilgi yeniden gerekiyorsa otomatik olarak doldurulmasını ya da seçilebilir olmasını istiyor. Ölçütün istisnaları var ve bilgiyi oturumlar arasında saklamayı şart koşmuyor.

Önceki adıma dönmek veriyi koruyorsa düzeltmeyi kolaylaştırır, geri dönüş testi de ölçümden önce bunu doğrulamanı istiyor. Ölçümde her adımın numarasını alan olaylarına parametre olarak ekle.

Formun modal pencerede mi sayfa içinde mi açılacağı ve kayıt formuna sosyal hesapla giriş eklenip eklenmeyeceği, alanlar aynı kalırken sunumu değiştiren kararlar. Modal kararını alan verisiyle değil, modalı hiç açmayanlar dahil formu görme şansı olan bütün ziyaretçilerle ölçmek gerekir. Modal ve sayfa içi form testi bu kitleyi tanımlıyor.

Sosyal girişte ise kayıt sayısının yanında aktivasyonu ve kullanıcının daha sonra tekrar giriş yapabilmesini izlemek gerekir. Bunun planı sosyal hesapla giriş testinde duruyor.

Önce ve sonra karşılaştırması, değişikliğin etkisini sezondan, kampanyadan ve trafik karışımından ayıramaz. web.dev'in form verisi modülü düzeltmeyi yayına almayı ve birkaç gün sonra etkisini ölçmeyi öneriyor. Bu yaklaşım sorunun sürüp sürmediğini görmek için işe yarar, ama kazancı kanıtlamaz. Aynı haftalarda reklam bütçesi değişirse fark ondan da gelebilir.

Yönergelerin toplu etkisi laboratuvarda ölçüldü. Seckler ve arkadaşlarının 2014'te yayımlanan kontrollü göz izleme deneyinde 65 katılımcı, gerçek şirket sitelerinden alınmış formların özgün ya da yönergelerle iyileştirilmiş sürümünü doldurdu.

İyileştirilmiş formlarda doldurmaların %78'i ilk denemede gönderildi, özgün formlarda %42'si. Gönderim denemesi sayısındaki fark üç formun hepsinde anlamlıydı. Araştırmacıların değişiklikten önce iyi kalitede saydığı formda ise tamamlama süresindeki fark anlamlı çıkmadı. Sonuç yirmi yönergenin birlikte etkisini gösteriyor, tek bir değişikliğin senin formunda ne yapacağını göstermiyor.

Kendi testinde kullanıcıları formu ilk gördükleri anda rastgele iki gruba ata ve sonuçları atandıkları gruba göre karşılaştır, değişikliği görüp görmediklerine göre değil. Kontrol grubu formun mevcut halini görmeye devam eder. Ana metrik atanan kullanıcı başına başarılı gönderim olsun: varsayımsal örnekte bu oran %15,0, yani 12.000 kullanıcıdan 1.800 başarılı gönderim.

Gerekli kullanıcı sayısını bu başlangıç oranı ve fark etmek istediğin en küçük etkiyle örneklem büyüklüğü hesaplayıcısında bul. İki grubu aynı sürede ve tam haftalar boyunca izle.

Karar kuralını testten önce yaz. Örneğin telefon doğrulamasını esneten varyant, önceden hesaplanan örnekleme ulaşıldığında atanan kullanıcı başına başarılı gönderimde kontrolden anlamlı biçimde yüksekse yayına alınır. Koruma metriğini de baştan belirle: telefonu isteğe bağlı yapan bir varyantta, satış ekibinin telefonla ulaşabildiği taleplerin payı. Bu pay önceden yazdığın sınırın altına düşerse testi durdur.

Sonuç belirsiz çıkarsa "etkisi yok" değil "belirsiz" diye kaydet ve test aracının "kazanan" etiketini karar sayma. Grupların büyüklüğü ve atamanın kontrolü için kontrol grubu yazısına bakabilirsin.

Bu sıra, formun içindeki en büyük kaybı bulup ilk testi kurmana yeter:

1. Formu gören, başlatan ve başarıyla gönderen kullanıcıları ayrı olaylarla say, başarıyı sunucunun onayına bağla.
2. Alan olaylarını kur, alan içeriği göndermediğini ve olayların DebugView'a geldiğini formu kendin doldurarak kontrol et.
3. Dört hafta veri topla, bırakanları son alana göre dağıt ve en çok kaybettiren alanda hata görenleri ayrı say.
4. O alan için tek bir değişiklik, bir ana metrik, bir koruma metriği ve bir karar kuralı yaz, sonra değişikliği kontrol grubuyla test et.

Testi bitirdiğinde aynı alan tablosunu iki grup için yeniden çıkar. Kazanan varyant kaybı başka bir alana taşıdıysa sıradaki test oradan başlar.