E-Ticaret Sitesi Satış Yapmıyor mu? Sırayla Teşhis Rehberi

E-ticaret sitesi satış yapmıyor görünüyorsa teşhis sırayla yapılır ve sıranın ilk sorusu ölçümdür: satış gerçekten mi yok, yoksa Analytics satın almayı mı görmüyor? Sipariş panelindeki sayı ile Analytics'teki satın alma sayısı birbirini tutmuyorsa, sonraki her yorum yanlış bir sayı üzerine kurulur. Ölçüm doğrulandıktan sonra sıra trafiğe, trafiğin doğru kişi olup olmadığına, ürün sayfasına, sepete ve en son ödeme adımına gelir.

Bu sıra, sorunu en ucuz kontrolden en pahalı değişikliğe doğru daraltır. Tasarımı yenilemek, kampanya açmak ya da altyapı değiştirmek sıranın sonundadır; çünkü kaybın hangi adımda olduğu bilinmeden yapılan değişikliğin işe yarayıp yaramadığı da ölçülemez. Yüzde ya da sektör ortalaması vermiyoruz: dışarıdan alınan bir dönüşüm oranı, kendi mağazanızın hangi adımda takıldığını göstermez.

İlk soru: satış mı yok, Analytics mi görmüyor?

Teşhisin ilk adımı, son otuz günün sipariş sayısını iki kaynaktan alıp yan yana koymaktır: e-ticaret panelindeki tamamlanmış siparişler ve Google Analytics 4'teki satın alma olayı sayısı. İki sayı kabaca birbirine yakınsa ölçüm çalışıyordur. Panelde sipariş varken Analytics sıfır ya da çok düşük gösteriyorsa sorun satışta değil ölçümdedir. Panelde de sipariş yoksa teşhis bir sonraki adıma geçer.

Bu karşılaştırmada birebir eşitlik beklenmez. Çerez onayı vermeyen ziyaretçiler, reklam engelleyiciler ve ödeme sonrası teşekkür sayfasına dönmeden sekmeyi kapatan alışverişçiler Analytics'te eksik görünebilir. Bakılacak şey küçük bir fark değil, iki kaynağın birbirinden kopmuş olmasıdır: panelde haftada onlarca sipariş görünürken Analytics'te birkaç tane görünmesi ya da tersine, Analytics'te panelden fazla satın alma görünmesi.

İkinci durum da bir ölçüm hatasıdır ve gözden kaçması daha kolaydır. Analytics'in panelden fazla satış göstermesi, satın alma olayının aynı sipariş için birden fazla kez gönderildiğini düşündürür; örneğin teşekkür sayfası yenilendiğinde. Bu durumda mağaza satış yapıyor sanılır, sorun ise başka yerde aranmaz.

Satın alma olayını doğrulamak

Google'ın e-ticaret ölçümü belgesi satın almanın nasıl ölçüleceğini tek cümleyle tarif eder: "Measure a purchase by sending a purchase event with one or more items defined with the relevant fields." Yani Analytics'te satış görünmesi için ödeme tamamlandığında purchase adlı bir olayın, sipariş edilen ürünlerin bilgisiyle birlikte gönderilmesi gerekir. Aynı belge sepete ekleme için add_to_cart, ödeme sürecinin başlangıcı için begin_checkout olaylarını tanımlar; bu üç olay teşhisin geri kalanında da kullanılacak.

Satın alma olayının en önemli alanı sipariş numarasıdır. Google'ın işlem kimliği belgesi bunu şöyle tanımlar: "A transaction ID is a unique identifier that you can create for each transaction, such as an order confirmation number." Analytics aynı işlem kimliğiyle gelen ikinci satın alma olayını tekrarlanmış sayıp ayıklar; belge bu ayıklamanın yalnızca web akışlarında çalıştığını da not eder: "Transaction ID deduplication only works for data collected through web streams, not app streams." Sipariş numarası olayla birlikte gönderilmiyorsa ya da her seferinde değişiyorsa, yenilenen teşekkür sayfası satışları çift sayabilir.

Olayın gerçekten gönderildiğini görmenin yolu DebugView ekranıdır. Belgeye göre bu ekran Analytics'in bir kullanıcıdan topladığı olayları gerçek zamanlı gösterir ve kullanmak için hata ayıklama modunun açılması gerekir: "You must enable debug mode to use DebugView." Kontrol şöyle yapılır: hata ayıklama modu açıkken mağazada bir test siparişi verilir, DebugView'da add_to_cart, begin_checkout ve purchase olaylarının sırayla düştüğü, purchase olayının sipariş numarasını ve tutarı taşıdığı görülür. Test siparişi sonrasında iptal edilir.

Trafik var mı: ziyaretçi sayısını doğru okumak

Ölçüm doğrulandıktan sonraki soru basittir: mağazaya satış yapacak kadar ziyaretçi geliyor mu? Bir ayda birkaç yüz oturum alan yeni bir mağazanın birkaç satış yapması ya da hiç yapmaması, bir sayfa sorununa değil trafik eksikliğine işaret edebilir. Bu durumda ürün sayfasını değiştirmek yerine trafiğin nereden geleceğini planlamak gerekir.

Trafiği okurken toplam sayıya değil, ürün ve kategori sayfalarına gelen oturumlara bakın. Ana sayfaya ya da blog yazısına gelen ziyaretçi, ürün sayfasına hiç ulaşmıyorsa satış ihtimali başlamadan biter. Analytics'te sayfa raporu ürün sayfalarının kaç kez görüntülendiğini gösterir; e-ticaret olaylarından view_item kuruluysa ürün görüntülemeleri doğrudan sayılabilir.

Trafik az ise yeni kurulan bir mağaza için bu beklenen bir durumdur ve organik aramanın ya da reklamın etkisi zaman ve bütçe ister. Pazaryerinde satış geçmişi olan bir işletme kendi sitesine trafik çekmekte zorlanıyorsa, iki kanalın birbirine göre nasıl konumlanacağı pazaryeri mi kendi e-ticaret sitesi mi kararının bir parçasıdır.

Gelen ziyaretçi doğru kişi mi?

Trafik yeterli görünüyor ama satış gelmiyorsa ikinci soru, gelen kişinin satın almaya niyetli olup olmadığıdır. Analytics'te trafik kanalına ve giriş sayfasına göre ayrılmış bir tablo bunu gösterir: satış yapmayan ziyaretlerin hangi kanaldan ve hangi sayfadan girdiği.

Üç durum ayırt edilebilir. Birincisi, ziyaret bilgi arayan aramalardan geliyordur: "nasıl temizlenir", "hangisi daha iyi" gibi sorgularla blog yazısına giren kişi o an alışveriş yapmayı düşünmüyor olabilir. İkincisi, reklam yanlış sorgulara gösteriliyordur: ürünle ilgisiz ya da yalnızca fiyat karşılaştırması yapan aramalar bütçeyi tüketir. Bu durumda reklamın arama terimi raporuna bakmak gerekir; sırası reklam bütçesi gidiyor dönüşüm yok teşhisinde verildiği gibi ilerler. Üçüncüsü, ziyaret satın alacak kişiden geliyordur ama sayfa onu karar verdirecek kadar bilgilendirmiyordur; bu durumda teşhis ürün sayfasına geçer.

Kanal bazında okuma yapmak, mağazanın toplam performansını tek bir kanalın sorununa bağlamayı önler. Toplamda satış yokmuş gibi görünen bir mağazada organik arama satış getirirken reklam hiç getirmiyor olabilir; çözüm mağazanın tamamını değil, reklamın hedeflemesini değiştirmektir.

Ürün sayfası karar verdiriyor mu?

Ürün sayfası, alışverişçinin "bu ürün bana uygun mu, ne zaman gelir, beğenmezsem ne olur" sorularına cevap aradığı yerdir. Bu sorulardan biri cevapsız kaldığında kişi sepete eklemeden sayfadan çıkar. Analytics'te view_item sayısına göre add_to_cart sayısı düşükse sorun bu adımdadır.

Ürün sayfası güven bilgisi şu kalemlerden oluşur: ürünün farklı açılardan ve ölçeği anlaşılır fotoğrafları, ölçü ve malzeme bilgisi, varyant seçiminin (beden, renk, boyut) açık olması, stok durumu, kargo ücreti ya da ücretsiz kargo eşiği, tahmini teslim süresi, iade koşulu ve satıcının kim olduğunu gösteren iletişim bilgisi. Bu bilgilerin bir kısmı mesafeli satış mevzuatının istediği ön bilgilendirmenin de parçasıdır; bu yüzden ürün sayfasındaki bir eksik, e-ticaret sitesi açmak için gerekenler listesinde açılıştan önce kapatılması gereken bir yükümlülük de olabilir.

Varyantlı ürünlerde ayrı bir sorun görülebilir: seçilmesi gereken bir varyant seçilmeden "sepete ekle" düğmesine basıldığında hata mesajının görünmemesi ya da tükenmiş varyantın seçilebilir görünmesi. Kategori ve varyant yapısının ürün sayfasına nasıl yansıdığını varyant kurgusu ve kategori mimarisi üzerinden kontrol etmek bu tür hataları baştan önler. Birkaç ürünü bir alışverişçi gibi telefondan satın almaya çalışmak, raporların göstermediği bu takılmaları bulmanın doğrudan bir yoludur.

Sepete ekleme var, satış yok: sepet adımı

add_to_cart olayı düzenli geliyor ama begin_checkout gelmiyorsa kayıp sepet ekranındadır. Alışverişçi ürünü sepete atmış, toplam tutarı görmüş ve ödeme sürecine başlamamıştır. Bu adımda bakılacak üç şey var.

İlki toplam tutarın sürprizidir. Ürün sayfasında görünmeyen bir kargo ücreti sepette ilk kez ortaya çıkıyorsa kişi o anda vazgeçebilir. İkincisi sepet ekranının kendisidir: ödemeye geçiş düğmesinin mobilde ilk ekranda görünüp görünmediği, kupon alanının dikkati ödeme düğmesinden çekip çekmediği, sepetteki ürün adedini değiştirmenin çalışıp çalışmadığı. Üçüncüsü üyelik zorunluluğudur: ödemeye geçmek için hesap açmak gerekiyorsa sepet ile ödeme başlangıcı arasında bir duvar oluşur.

Sepet adımında kaybı ölçmek için Analytics'te sepete ekleyen kullanıcı sayısı ile ödemeye başlayan kullanıcı sayısını aynı tarih aralığında karşılaştırmak yeterlidir. Bu oranı bir sektör ortalamasıyla değil, kendi mağazanızın önceki haftalarıyla karşılaştırın; bir değişiklik yaptığınızda oranın hangi yöne gittiği, değişikliğin işe yarayıp yaramadığını söyler.

Ödeme adımı: başlayan ödeme neden tamamlanmıyor?

begin_checkout geliyor ama purchase gelmiyorsa kayıp ödeme sürecindedir ve bu adımın iki ayrı nedeni vardır: alışverişçinin bilgi eksikliği yüzünden vazgeçmesi ve ödemenin teknik olarak başarısız olması. İlkinde kargo, teslim, iade ve ödeme güvenliği bilgisinin ödeme ekranında görünüp görünmediği kontrol edilir; hangi bilginin hangi anda görünmesi gerektiği ve ödeme akışının adım adım nasıl ölçüleceği ödeme adımında vazgeçme ve eksik bilgi ilişkisi üzerinden ayrıca değerlendirilmelidir. İkincisinde ise kart reddi, banka doğrulama adımında yarım kalan işlem ya da ödeme sağlayıcısındaki bir bağlantı sorunu aranır; başarısız ödeme denemeleri ayrıca kaydedilmezse terk gibi görünür. Ödeme sağlayıcısı tarafındaki sorunlar için sanal POS başvurusu için gerekenler arasındaki test ve sözleşme soruları kullanılabilir.

Mobil ve hız: her adımda ayrı bakılacak katman

Hız ve mobil uyum, teşhis sırasında ayrı bir adım değil, her adımın içinde bakılacak bir katmandır. Aynı ürün sayfası masaüstünde sorunsuz çalışıp mobilde görsellerin geç yüklenmesi yüzünden terk ediliyor olabilir; toplamda bakıldığında bu ayrım görünmez. Bu yüzden yukarıdaki her oran, cihaz türüne göre ayrı okunmalıdır.

Hızın satışı ne ölçüde etkilediği, sayfanın hangi kısmının yavaş olduğuna ve alışverişçinin hangi adımda beklediğine bağlıdır. Hızı satışla ilişkilendirmeden önce hangi ölçümün hangi sırayla alınacağı site hızı satışı etkiler mi sorusunu cevaplamanın ön koşuludur; laboratuvar puanı ile gerçek kullanıcı verisi aynı şeyi söylemez. Teşhis açısından pratik kural şudur: mobilde bir adımın oranı masaüstündekinden belirgin biçimde düşükse, o adımın mobil hızına ve ekran düzenine bakılır.

Belirti, kontrol, sorumlu tablosu

Teşhis sırasını tek tabloda toplamak, kimin neye bakacağını da netleştirir. Küçük bir işletmede "sorumlu" sütunundaki rollerin birkaçı aynı kişi olabilir; önemli olan her satırın bir sahibi olmasıdır.

Tablodaki satırlar sırayla kontrol edilir; bir satırda sorun bulunduğunda bir sonrakine geçmeden o satırdaki sorun giderilir ve oran yeniden ölçülür.

Değişikliği tek tek yapmak ve sonucu ölçmek

Teşhis bir sorun bulduğunda aynı anda birkaç değişiklik yapmak caziptir: kargo ücretini görünür yapmak, ürün fotoğraflarını yenilemek ve sepeti yeniden tasarlamak. Üçü birlikte yapıldığında oran iyileşse bile hangisinin işe yaradığı bilinmez; kötüleşirse hangisinin geri alınacağı da bilinmez.

Daha güvenli yol, her değişikliği bir tarihle kaydetmek ve ilgili adımın oranını değişiklikten önceki ve sonraki eşit uzunluktaki dönemler için karşılaştırmaktır. Değişiklik günü bir not olarak Analytics'e de eklenebilir; böylece grafikteki kırılmanın nedeni sonradan hatırlanır. Kampanya dönemleri, bayram ve özel indirim günleri bu karşılaştırmayı bozar; mümkünse benzer günler karşılaştırılır.

Mağazanın kurulumunda ölçümün baştan doğru yerleştirilmesi, bu teşhisin ilk adımını gereksiz kılar. E-ticaret sitesi kurulumu kapsamında sepet ve ödeme adımlarını gerçek siparişle test ediyor, sepete ekleme, sepeti açma ve ödemeyi tamamlama adımları arasındaki düşüşü ölçülebilir hale getiriyoruz; satış sayısı taahhüdü vermiyoruz.

Bir haftalık teşhis takvimi

Teşhisi bir haftaya yaymak, her günün tek bir soruya ayrılmasını sağlar. Takvim, haftalık rutinin yanında yürütülebilecek kadar kısa tutuldu.

Haftanın sonunda elinizde "site satış yapmıyor" cümlesi yerine "ürün görüntüleniyor ama mobilde sepete eklenmiyor" gibi bir adım ve bir cihaz adı olur. O cümle, neyin değişeceğini ve neyin ölçüleceğini birlikte söyler.

Sıkça Sorulan Sorular

E-ticaret sitesi satış yapmıyorsa ilk neye bakılmalı?

İlk bakılacak şey ölçümdür: e-ticaret panelindeki tamamlanmış sipariş sayısı ile Google Analytics 4'teki satın alma olayı sayısı aynı dönem için karşılaştırılır. Panelde sipariş varken Analytics göstermiyorsa sorun satışta değil ölçümdedir. Ölçüm doğrulandıktan sonra sırasıyla trafik miktarına, trafiğin doğru kişiden gelip gelmediğine, ürün sayfasına, sepete ve ödeme adımına bakılır.

Ziyaretçi var ama sipariş yoksa sorun nerede olabilir?

Kayıp, ziyaretçinin ürün sayfasına ulaşmamasında, ürün sayfasında sepete eklememesinde, sepette ödemeye geçmemesinde ya da ödemeyi tamamlamamasında olabilir. Google Analytics 4'te ürün görüntüleme, sepete ekleme, ödemeye başlama ve satın alma olayları kuruluysa bu adımlar arasındaki düşüş hangisinde yoğunlaşıyorsa teşhis oraya odaklanır. Trafiğin kanal ve giriş sayfasına göre ayrılması, ziyaretin bilgi aramasından mı alışveriş niyetinden mi geldiğini de gösterir.

Sepete ekleme var ama satış yoksa ne kontrol edilmeli?

Önce kaybın sepet ekranında mı ödeme sürecinde mi olduğu ayrılır: sepete ekleyen kullanıcı sayısı ödemeye başlayan kullanıcı sayısıyla, ödemeye başlayan da satın alma ile karşılaştırılır. Sepette kayıp varsa sonradan ortaya çıkan kargo ücreti, üyelik zorunluluğu ve mobil sepet ekranı kontrol edilir. Ödemede kayıp varsa ödeme ekranındaki bilgi eksikliği ve başarısız ödeme denemeleri ayrı ayrı incelenir.

Google Analytics 4'te satın alma olayı nasıl doğrulanır?

Google'ın belgelerine göre satın alma, ödeme tamamlandığında sipariş edilen ürün bilgileriyle birlikte bir purchase olayı gönderilerek ölçülür ve olayda sipariş numarası gibi benzersiz bir işlem kimliği yer alır. Doğrulama için hata ayıklama modu açılıp DebugView ekranında bir test siparişi verilir ve purchase olayının sipariş numarası ve tutarla birlikte düştüğü görülür. Teşekkür sayfası yenilendiğinde aynı siparişin tekrar sayılmaması da işlem kimliğine bağlıdır.

E-ticaret sitesinde değişikliğin işe yarayıp yaramadığı nasıl anlaşılır?

Her değişiklik tek başına ve tarihiyle kaydedilir, ardından ilgili adımın oranı, örneğin ürün görüntülemeye göre sepete ekleme, değişiklikten önceki ve sonraki eşit uzunluktaki dönemler için karşılaştırılır. Aynı anda birden fazla değişiklik yapıldığında hangisinin etkili olduğu bilinemez. Kampanya dönemleri ve özel günler karşılaştırmayı bozduğu için mümkünse benzer günler karşılaştırılır ve oran cihaz türüne göre ayrı okunur.