Sepet Terk Etme Hakkında Tartışmayı Bırakın: Ödeme Düzeltmelerini Onaylatın

Özet

Çoğu sepet terk etme tavsiyesi, engelin ödeme adımınız olduğunu varsayar—formlar, butonlar, adım sayısı. Eğer küçük bir dahili pazarlama ekibindeyseniz, asıl engel genellikle içseldir: kanıt isteyen teknik olmayan bir patron, geliştirici iş yığını, daha önce başarısız olmuş bir deney veya bunun "pazarlamanın işi olmadığı" yönündeki belirsiz bir his. Bu makale, bu itirazları kendi başlarına CRO sorunları olarak ele alır. "Bana verileri göster" ifadesini tek öğleden sonra yapılabilecek bir denetime nasıl dönüştüreceğinizi, kod değişikliklerini metin ve ayar değişikliklerinden nasıl ayıracağınızı ve güven olmadan yapılan sadeleştirmenin neden bir şey değiştirmeyeceğini gösterir. Ayrıca en çok duyacağınız beş itirazın bir tablosunu ve misafir ödemesinin ardındaki takas hakkında net bir yanıt alacaksınız. Amaç, bir sonraki talebinizi o kadar somut ve o kadar küçük hale getirmektir ki tartışma olmaktan çıkıp plan haline gelsin.

Sepet terk etme konusundaki tavsiyelerin çoğu, ödeme adımlarını zaten değiştirebilen insanlar için yazılmıştır. Size formu sadeleştirmenizi, misafir ödemesi eklemenizi, kargo ücretlerini son adımdan önce göstermenizi söyler; sanki daha iyi bir dönüşüm oranı ile aranızdaki tek şey ne yapmanız gerektiğini bilmekmiş gibi. Eğer küçük bir dahili pazarlama ekibindeyseniz, nadiren sorun budur. Nelerin düzeltilmesi gerektiğini zaten biliyorsunuz. Sorun, her düzeltmenin, bir şeye dokunmanıza izin verilmeden önce kanıt, zaman çizelgesi ve maliyet tahmini isteyen teknik olmayan bir patronla yapılan bir konuşmadan sağ çıkmak zorunda olmasıdır.

Aslında işe yarayan şey, daha uzun bir taktik listesi değil. Onay sürecinin kendisini dönüşüm optimizasyonu sorununun bir parçası olarak ele almak. Duyduğunuz direnç—"verilerimiz yok", "geliştirici zamanı alamıyoruz", "bunu daha önce denedik", "bu bizim işimiz değil"—gürültü değil. Her itiraz, projenin hangi bölümünü henüz somutlaştırmadığınızı söyler. İtirazı yanıtlayın; değişiklik bir talep olmaktan çıkıp plan haline gelir.

Bu makale, çoğu ödeme düzeltmesini durduran beş itirazı, süregelen bir örnekle ele alıyor ve bir sonraki bütçe toplantınıza getirebileceğiniz bir tabloyla bitiyor. Ana hat basit: Bu çeyrek yapabileceğiniz en iyi CRO hamlesi yeniden tasarım değil. Bir sonraki değişikliği, patronunuz kumar oynuyormuş gibi hissetmeden evet diyebileceği kadar küçük yapmak.

"Bana verileri göster" huniyi göster demektir

Diyelim ki küçük bir açık hava ekipmanı şirketinde çalışıyorsunuz. Patronunuz az önce size kargo ücretlerinin siparişleri öldürdüğünü söyledi. Arkasına yaslanıp "Bu güçlü bir iddia. Verimiz var mı?" diyor. Alışveriş yapanların nerede ayrıldığını gösteren bir aracınız yok. Oturum kayıtlarından ve etkinlik takibinden bahsetmeye başlıyorsunuz ve gözleri dalıyor. Proje toplantıda ölüyor.

Buradaki hata, "veri"nin sahip olmadığınız bir pano anlamına gelmesi gerektiğini varsaymak. Çoğu erken düzeltme için ihtiyacınız olan veri zaten mağazanızın içinde mevcut—sadece bir müşteri gibi ilerleyerek bunu gözden geçirmediniz. E-ticaret rehberleri, insanların sepeti terk etme nedenlerini sürekli küçük bir diziye indirger: beklenmedik maliyetler, karmaşık bir ödeme akışı, hesap oluşturmaya zorlanma, güven eksikliği, sınırlı ödeme seçenekleri ve yavaş teslimat. Bu liste sizin denetim kontrol listeniz.

İşte bu listenin nasıl kullanılacağı. Gizli bir pencere açın ve kendi ürün sayfanıza gidin. Sepete bir sırt çantası ekleyin. Şimdi her adımda ekran görüntüsü alarak yavaşça kaydırın. Müşteri toplam maliyeti, kargo dahil, ilk ne zaman görüyor? "Sepete ekle" ile "bu tutar tahsil edilecek" arasındaki ekranları sayın. Hesap oluşturmadan ödeme yapmayı deneyin ve engellendiğiniz anı not edin. İade politikasını bulun ve okumak için kaç tıklama gerektiğini not edin. Her zaman farklı davranan bir telefonda hepsini tekrar yapın.

On beş veya yirmi ekran görüntüsü ve şuna benzer gözlemlerle bitirirsiniz: "Sepet sayfasında kargodan hiç bahsedilmiyor. Ödeme sayfasında ilk kez kargo ücreti görünüyor. Ödeme işlemi, ödemeden önce hesap istiyor. İade politikası bağlantısı alt bilgide, altı paragraf aşağıda." Bu kanıttır ve tartışması zordur çünkü patronunuz bunu iki dakikada yeniden üretebilir.

Denetimi daha keskin yapan bir ayrıntı: siteyi hiç görmemiş bir iş arkadaşınızla yapın. Sisteme alışkın olduğunuzda gözden kaçırdıklarınız sizi şaşırtacak. Bir şey satın almaya çalışırken yüksek sesle konuşmalarını isteyin. Bir kullanılabilirlik laboratuvarı yürütmüyorsunuz; normal bir kişinin "bir dakika, ne?" dediği anları dinliyorsunuz. Sepetten çıkma nedenleri tam bu anlarda yaşar.

Denetimi sunarken düzeltmeyle başlamayın. Yeniden üretimle başlayın: "Bu ürünü ekleyin, sepete gidin ve kargoya bakın. Şimdi hesap oluşturmadan ödeme yapmayı deneyin." Patronun hayal kırıklığını kendisinin yaşamasına izin verin. Ödeme adımınız tarafından rahatsız edilmiş bir kişi artık şüpheci değil; bir müttefiktir.

Genel ilke: bir değişiklik istemeden önce yöneticinize inançla kabul etmesini istediğiniz bir iddia değil, görebileceği ve doğrulayabileceği bir şey verin. Bir ekran görüntüsü bir tahminden daha değerlidir. Bu tür bir denetim ayrıca küçük ekip CRO'sunun en yaygın başarısızlık modundan kaçınmanıza yardımcı olur—var olduğunu doğrulamadığınız bir sorun için düzeltme önermek. Sorununuzun ödeme adımının kendisi mi yoksa hunide daha önceki bir şey mi olduğunu merak ediyorsanız, sepet terk etmenin gerçek nedenini teşhis etme üzerine daha önceki bir makale yararlı bir sonraki adımdır.

"Geliştirici zamanımız yok" genellikle ayarları koddan ayırmadığınız anlamına gelir

Patronunuz "ödeme optimizasyonu" duyduğunda iki hafta çalışan bir geliştirici hayal eder. İş yığınının üç ay uzunluğunda olduğunu bilirsiniz, bu yüzden sormaya bile tenezzül etmezsiniz. Ancak standart terk etme listesindeki düzeltmelerin çoğu hiçbir geliştirici gerektirmez.

Dört büyük olanı ele alalım. Şeffaf fiyatlandırma: kargo ücretini veya "belirli bir tutarın üzerinde ücretsiz kargo" bildirimini göstermek genellikle sepet sayfasına ekleyebileceğiniz bir cümle veya platformunuzdaki bir ayardır. Misafir ödemesi: birçok e-ticaret platformunda bu, özel bir yapı değil ayarlardaki bir anahtardır. Ödeme seçenekleri: aslında yeni bir ödeme sağlayıcı eklemek tekniktir, ancak hangi seçenekleri kabul ettiğinizi göstermek ödeme adımındaki bir rozet veya simgedir—pazarlama alanıdır. İade politikası: net ve dürüst bir iade politikası metindir ve bağlantısını sayfa düzenleyebilen herkes taşıyabilir.

Kısa bir süreliğine açık hava ekipmanı şirketinize dönelim. İade politikası alt bilgide gömülü ve satın alma konusunda endişeli alışveriş yapanlar onu asla bulamıyor. Patronunuz bir düzeltmenin "alt bilgiyi ve şablonu yeniden oluşturmak" anlamına geldiğini varsayıyor. Ancak asıl düzeltme, Sepete Ekle düğmesinin altına bir satır metin eklemektir: "30 gün içinde iade, soru sorulmaz—politikamıza bakın." Bağlantı zaten var olan bir sayfaya gider. Bu bir CMS düzenlemesidir, bir maraton değil.

Ayar noktası da önemlidir. Platformunuzda misafir ödemesi seçeneği varsa, onu açmak bir kod değişikliği değil; bir yapılandırma değişikliğidir. Ayarı bulmanız, belgeleri okumanız ve bir kez test etmeniz gerekebilir—ama bu bir öğleden sonra işidir, geliştirici maratonu değil. Ayar sayfasına erişiminiz yoksa, bir kez erişim isteyin. İlk seferde bir geliştirici size yol gösterebilir; ikinci seferde kendiniz yapabilirsiniz.

Bir kategori daha: sipariş onay sayfası ve e-postası. Onay genel ise veya teslimat beklentilerini belirlemiyorsa, bu da pazarlamaya ait bir yüzeydir. Sipariş sistemine dokunmadan yeniden yazabilirsiniz. Sırada ne olacağını bilen müşteriler destek birimine e-posta göndermeye daha az meyillidir ve destek e-posta hacmi patronunuzun anlayacağı bir metriktir.

Uyarı açıkça belirtmeye değer: bazı düzeltmeler gerçekten kod gerektirir ve aksini iddia etmek size güvenilirlik kaybettirir. Ancak itiraz genellikle talep "ödeme adımını düzelt" yerine "sepet sayfasındaki bu cümleyi değiştir" olarak çerçevelendiği için ortaya çıkar. Onu pazarlamaya ait olacak kadar küçük çerçevelersen, direncin yarısı kaybolur. Gerçekten bir geliştiriciye ihtiyacınız olduğunda, "bu listedeki her şey metin ve ayar—yalnızca bu madde kod gerektiriyor" diyebilirseniz çok daha güçlü bir durumunuz olur.

"Sadeleştirmeyi zaten denedik" yanlış nedeni düzeltiyordunuz demektir

Altı ay önce ekibinizdeki biri ödeme formundan üç alanı kaldırdı. Patron bunu "CRO'yu zaten denedik" kanıtı olarak gösterdi. Siparişler değişmedi. Şimdi güvenle ilgili bir düzeltme öneriyorsunuz ve patron "Bu neden farklı olsun?" diyor.

Farklı olmasının nedeni, bir formu sadeleştirmek ve güven oluşturmanın farklı sorunları çözmesidir. Araştırma ve günlük deneyim, insanların mağazaya güvenmediklerinde sepeti terk ettiklerini gösterir—iade politikası belirsiz olduğunda, ödeme seçenekleri zayıf göründüğünde veya alan adı yabancı hissettirdiğinde. Kök neden buysa, daha kısa bir form işe yaramaz. Hiç duymadığınız bir mağazadan yüksek fiyatlı bir sırt çantası aldığınızı düşünün. Ödeme adımı üç alandan oluşuyor, olabildiğince temiz. Yine de tereddüt edersiniz çünkü risk form değildir—ürünün gelip gelmeyeceği ve gelmezse geri gönderip gönderemeyeceğinizdir. Bu tereddüt bir UX sorunu değil; bir ikna sorunudur.

Güvenin neden olup olmadığını nasıl anlarsınız? Ayrıntılara bakın. Ürünleriniz, dürtüsel bir müşterinin riske atacağı şeylere göre pahalı mı? Mağazanız yeni mi veya alan adı sıradışı mı görünüyor? Satın alma düğmesinin yakınında iade politikası yok mu? Hiç yorum yok mu veya çok az mı? Bunlardan birkaçına evet yanıtı verdiyseniz, güven muhtemelen form uzunluğundan daha büyük bir faktördür. Formunuz gerçekten uzunsa—on veya daha fazla alan ve geçerli olmayan isteğe bağlı alanlar varsa—o zaman karmaşıklık sorun olabilir. Önemli olan tahmin etmek değil, kontrol etmektir.

Güven mi yoksa karmaşıklığın mı kök neden olduğunu test etmenin pratik bir yolu: tek bir güven öğesi ekleyin—Sepete Ekle düğmesinin yanına iade politikası bağlantısı—ve forma dokunmayın. İade destek soruları veya çıkış davranışı iyileşirse, sorun muhtemelen güvendi. Hiçbir şey değişmezse, sıradaki karmaşıklığa bakın.

Burada yararlı bir karşıt görüş de var. Güven sinyalleri eklemek otomatik bir kazanç değildir. Ürün sayfanıza bir yorum widget'ı koyarsanız ve hiç yorumunuz yoksa, müşterilere "0 yorum" göstermiş olursunuz—bu hiç yorum göstermemekten daha kötüdür. Gerçek bir iade politikasıyla desteklenen basit, spesifik bir garanti satırı daha dürüsttür ve hiçbir maliyeti yoktur. Benzer şekilde, bir formu "sadeleştirmek" gerekli alanları gizlemekle aynı şey değildir. Gönderim adresine ihtiyacınız varsa, ona ihtiyacınız vardır; formu kısaltmak için onu kaldırmak yanlış teslimatlar ve iadeler yaratır. Sadeleştirme gereksiz yükü kaldırmalı, yükü başka bir yere gizlememelidir.

Bu incelik, ödeme adımında "her şeyi sadeleştirme" yaklaşımının bir yanılgı olmasının ardındaki mantığın aynısıdır. Sadeleştirme kötü değildir; sadeleştirme birçok kaldıraçtan biridir ve hangi nedene yöneldiğinizi bilmeden çekmek bir çeyreği boşa harcayabilir.

"Önce bir plana ihtiyacımız var" aslında bir süreç talebidir

Patronunuz "Tamam, beni bir sorun olduğuna ikna ettin. Şimdi bana bir plan yaz." diyor. Donup kalıyorsunuz çünkü istatistiksel anlamlılık ve bir yol haritası içeren yıllık bir deney programı hayal ediyorsunuz. Bunun için trafiğinizin veya bütçenizin olmadığını biliyorsunuz, bu yüzden oyalanıyorsunuz.

Bir planın iddialı olması gerekmez. Tek bir döngü olabilir: terk etme kontrol listesinden bir neden seçin, başarısız olduğu ekranı bulun, bir değişiklik yapın ve bir metriği izleyin. Sonra bir sonraki nedene geçin.

Bunu açık hava ekipmanı şirketiyle somutlaştıralım. Denetiminiz, kargonun ödeme sayfasında insanları şaşırttığını buldu. Bu ayki planınız: sepet sayfasına kargonun ödeme sırasında hesaplandığını ve her zaman ödemeden önce gösterileceğini söyleyen bir satır ekleyin. İzlediğiniz metrik, kargo hakkında soran destek e-postalarının sayısı artı ödeme sayfasına ulaşan kaç kişinin siparişi tamamladığına dair basit bir öncesi-sonrası incelemesidir. Bu kadar. Destek e-postaları azalırsa ve ödeme tamamlama düşmezse, deneyimi iyileştirdiniz. Gelecek ay iade politikası bağlantısını öne çıkaracaksınız. Onu takip eden ay, platformunuz izin veriyorsa misafir ödemesini açacaksınız. Bu bir plandır.

Somut olarak plan şöyle görünebilir. Birinci hafta: denetimi yaparsınız ve patrona ekran görüntülerini gösterirsiniz. İkinci hafta: sepet sayfasını kargodan bahsedecek şekilde düzenler ve müşteri desteğinden kargo sorularını işaretlemeye başlamasını istersiniz. Üçüncü hafta: misafir ödemesi için platform ayarını kontrol eder ve açar veya hesap istemi için metni hazırlarsınız. Dördüncü hafta: destek notlarını gözden geçirir ve ödeme tamamlama sayısına bakarsınız. Bu, patronunuzun takvime koyabileceği bir plandır; teknik olmayan bir yönetici için "plan" kelimesinin anlamı tam olarak budur.

Buradaki uyarı, aynı anda çok fazla şey değiştirmemekle ilgilidir. Küçük bir sitede hangi değişikliğin sonucu ürettiğini bilmeniz gerekir. Haftada veya ayda bir değişiklik övünmek için yavaştır ama öğrenmek için hızlıdır. A/B testleri bir lükstür; bariz bir başarısızlık için önemsediğiniz metriğe öncesi-sonrası bakmak genellikle bir sonraki adımı haklı çıkarmak için yeterlidir. Bu döngünün daha resmi bir versiyonunu istiyorsanız, e-ticaret müşterileri için tekrarlanabilir bir CRO süreci oluşturma rehberimiz adımları açıklar.

Bir şey daha: genel geliri değil, süreç metriği seçin. Gelir yüzlerce nedenden dolayı dalgalanır. Bir süreç metriği—"destek kargodan ne sıklıkla bahsediyor", "ortalama alışveriş yapan ayrılmadan önce ne kadar ilerliyor" veya "ödeme sayfası görünümlerinden kaçı siparişe dönüşüyor" gibi—belirli değişikliğin işini yapıp yapmadığını söyler. Bunun için analitiğiniz yoksa, insan geri bildirimini kullanın: müşteri desteğinden, bir müşteri kargo sürprizinden bahsettiğinde not tutmaya başlamasını isteyin. Bu da veridir.

"Bu pazarlamanın işi değil" mesaja sahip çıktığınızda ortadan kalkar

Bir toplantıda geliştirici ödeme adımının iyi olduğunu söylüyor. Ürün sorumlusu bunun bir iş akışı sorunu olduğunu söylüyor. Patronunuz birinin bunu sahiplenmesi gerektiğini söylüyor ve herkes yere bakıyor. Pazarlamanın ödeme üzerinde yetkisi olmadığından endişeleniyorsunuz, bu yüzden sessiz kalıyorsunuz.

İşte yeniden çerçeveleme: ödeme adımı, pazarlama vaadinizin test edildiği yerdir. Ürün sayfanız "belirli bir tutarın üzerinde ücretsiz kargo" diyorsa ve ödeme, açıklama yapmadan kargo ücreti alıyorsa, bu bir mesaj hatasıdır. Pazarlama, garantilerin ifadesini, maliyetlerin şeffaflığını ve güven sinyallerinin yerleşimini elinde tutar—ki bu terk etme kontrol listesinin çoğunluğudur. Piksel düzeni geliştiricinin alanıdır; müşterinin ödeme eşiğinde dururken okuduğu hikaye sizindir.

Bu yüzden fark yaratmak için kod tabanı üzerinde yetkiye ihtiyacınız yok. Şu anda başarısız olan mesajların bir listesine ihtiyacınız var ve bunu tam olarak huni denetimi üretir. Sunarken mimariyi değiştirmek için izin istemiyorsunuz; pazarlama mesajının belirli bir noktada koptuğunu bildiriyorsunuz. Patrona söyleyebileceğiniz yararlı bir ifade: "Ödeme adımına sahip olmak istemiyorum. Üzerindeki kelimelere sahip olmak istiyorum." Bu ayrım küçük ama güçlüdür—isteği bölgesel bir kapışmadan çok bir temizlik meselesi gibi gösterir.

Bu itirazın daha derin bir versiyonu var ve adlandırmaya değer. Şirketiniz CRO'yu bir uzmanın yaptığı bir iş olarak görüyorsa, küçük dahili ekip kendini genellikle yetersiz hisseder. Ancak bir mesaj hatasını yakalamak için istatistikçi olmanıza gerek yok. Sepet sayfasının bir şey vaat edip ödeme sayfasının başka bir şey sunduğunu fark eden kişi olmanız gerekir. Bu bir pazarlama becerisidir, veri bilimi derecesi değil. Süreç konusunda gerginseniz, tam olarak bu konumdaki ekipler için yazılmış gizli kaçak makalesiyle başlayın.

Bir sonraki bütçe toplantısı için referans tablosu

Artık desen net olmalı: her itiraz farklı bir taleptir—bana kanıt göster, küçük olduğunu göster, geçen seferin tekrarı olmadığını göster, planı göster, bize ait olduğunu göster. İşte yan yana ve genellikle işe yarayan yanıtla birlikte.

İtiraz	Gerçekte söylenen	Söylenecek veya yapılacak
"Verilerimiz yok"	"İnanmak için görmem gerekiyor."	Tek öğleden sonra yapılan bir denetim yapın ve tam başarısızlık noktasının ekran görüntülerini paylaşın.
"Geliştirici zamanı alamıyoruz"	"Büyük bir projeden korkuyorum."	Önce metin, ayar ve politika değişikliklerini önerin; kodu işin içinden çıkarın.
"Sadeleştirmeyi denedik"	"CRO daha önce işe yaramadı."	Sadeleştirme ve güvenin farklı nedenleri çözdüğünü gösterin ve hedeflediğiniz nedeni adlandırın.
"Önce bir plana ihtiyacımız var"	"Bir dilek değil, bir süreç istiyorum."	Bir aylık bir döngü sunun: bir neden, bir değişiklik, bir metrik.
"Bu pazarlamanın işi değil"	"Güvendiğim bir sahip istiyorum."	Ödeme adımında başarısız olan pazarlama mesajlarının ekran görüntülerini getirin.

"Ya işleri daha da kötüleştirirse?" adil bir cevabı hak ediyor

Son itiraz, insanları olduğu yerde durdurur çünkü akıllıcadır. Patronunuz "Misafir ödemesini açarsak, tüm sadık müşterilerimizi kaybederiz." diyor. Bu makul bir sonuç olduğu için kendinizi köşeye sıkışmış hissediyorsunuz.

Dürüst cevap, misafir ödemesinin ya hep ya hiç olmadığıdır. Takas gerçektir, ancak etrafını tasarlayabilirsiniz: insanların misafir olarak ödeme yapmasına izin verin ve ardından siparişten sonra gerçekten değer verdikleri bir avantajla—sipariş takibi, daha hızlı yeniden sipariş, sadakat puanları—hesap oluşturmalarını isteyin. Böylece dönüşüm avantajının çoğunu korurken müşterilere kaydolmak için bir neden vermiş olursunuz.

Ayrıca bunu bir pilot olarak çerçeveleyebilirsiniz: "Misafir ödemesini iki hafta çalıştıralım ve hesap oluşturmaya ne olduğunu izleyelim. Hesaplar düşerse ve gelir değişmezse, geri değiştirebiliriz." Geri döndürülebilir bir pilot, kalıcı görünen bir değişikliği düşük riskli bir teste dönüştürür.

Daha derin nokta, her dönüşüm düzeltmesinin bir takas olduğu ve takasın iş modelinize bağlı olduğudur. Hesaplara bağlı bir abonelik hizmeti yürütüyorsanız, koşulsuz misafir ödemesi size gerçekten zarar verebilir. Doğru soru "misafir ödemesi iyi mi?" değil, "ne takas etmeye razıyız ve bunun yerine ne yapabiliriz?" Bu, genel en iyi uygulama listelerinin kaçırdığı inceliktir ve küçük bir ekibin yargısının bir kontrol listesinden neden daha önemli olduğunu açıklar.

Aynı takas mantığı ödeme yöntemleri için de geçerlidir. Sınırlı ödeme seçenekleri yaygın bir terk etme nedenidir—ancak daha fazla seçenek eklemek bedava değildir. Her ek yöntem, kurulum, ücret, sahtekarlık riski ve destek soruları ekler. Müşterilerinizin çoğu zaten tek bir yoldan ödüyorsa, uzun bir logo listesi etkileyici görünebilir ancak davranışı değiştirmez. Yapılacak şey, bulabildiğiniz en büyük mağazayı taklit etmek değil, müşterilerinizin gerçekte ne kullandığını kontrol etmektir.

Hız için de geçerlidir. Yavaş teslimat terk etme listesindedir, ancak teslimat hızını bir ayarla genellikle düzeltemezsiniz. Yapabileceğiniz şey doğru beklentiler belirlemektir: bir ürünün gönderilmesinin bir hafta sürdüğünü biliyorsanız, bunu gizlemek yerine "5 iş günü içinde gönderilir" deyin. Beklemeyi bilen müşteri karar verebilen müşteridir; ödedikten sonra öğrenen müşteri bir iadedir.

Sonuç: bir sonraki değişikliği evet diyebilecek kadar küçük yapın

İtiraz yönetimi yumuşak bir beceri değildir. Önceliklendirmedir. Patronunuz veri istediğinde, projenin çok soyut olduğunu söylüyordur. Geliştirici zamanı olmadığını söylediğinde, projenin kulağa çok büyük geldiğini söylüyordur. Daha önce işe yaramadığını söylediğinde, nedenin hiçbir zaman doğrulanmadığını söylüyordur. Gerçek engeli adlandırın; çözüm daha küçük, daha görünür ve daha geri döndürülebilir hale gelir.

Tek sayfalık bir denetim, sepet sayfasındaki tek bir cümle, bir ayar olarak misafir ödemesi, karara bir tık daha yaklaşan bir iade politikası bağlantısı—bunların hiçbiri "gerçek" CRO yaptığınızı hissettirmez. Ancak bunlar teknik olmayan bir patronla yapılan bir konuşmadan sağ çıkacak değişikliklerdir çünkü az maliyetlidir, günler sürer ve işe yaramazlarsa geri alınabilirler. Zaten bildiğiniz tek kaçakla başlayın, patronunuza tıklayacak bir şey verin ve sonucun bir sonraki tartışmayı taşımasına izin verin.

Son bir uyarı: bunların hiçbiri dönüşüm artışını garanti etmez. Değişiklikleri yapıp hiçbir fark görmemeniz mümkündür çünkü gerçek engel, mağazanın içinden göremediğiniz bir şeydir. Bu olasılık, değişiklikleri küçük ve geri döndürülebilir tutmanızın tam da nedenidir. Yanılmanın maliyeti düşüktür; mükemmel kanıtı beklediğiniz için hiçbir şey yapmamanın maliyeti, kaçırılmış bir çeyreklik satıştır.