Hangi install kaynağı, siparişini iptal etmeyen müşteriyi getiriyor?

Install başına maliyeti virgülden sonra iki hane bilen bir ekip, o install'ların getirdiği siparişlerin kaçının iptal edildiğini bilmiyordu. Sayı kimsenin elinde yoktu, çünkü tek bir sistemin içinde durmuyor.

Soruyu biz sorduk

Perakendecinin app growth ekibiyle bir planlama toplantısındaydık. Kanal maliyetleri masadaydı, herkes rakamları biliyordu. Şunu sorduk:

Siz hangi ciroya göre optimize ediyorsunuz? Sipariş verildiği anda görünen ciroya mı, yoksa gerçekten tamamlanan siparişlerin ürettiği ciroya mı?

Bu ikisi aynı sayı değil. Bir perakende uygulamasında siparişlerin azımsanmayacak bir kısmı hiç ciroya dönüşmüyor; kargolanmadan iptal ediliyor ya da teslimattan sonra iade ediliyor. Ekip ikinci sayıyı ölçmüyordu, dolayısıyla bütçeyi birinci sayıya göre dağıtıyordu.

Soru bundan sonra kendiliğinden netleşti: doğru kanallardan mı install alıyoruz, daha çok install’a mı ihtiyacımız var yoksa daha kaliteli install’a mı?

Cevap hiçbir sistemin içinde yok

MMP müşteriyi hangi kanalın getirdiğini biliyor. ERP hangi siparişin ayakta kaldığını biliyor. İkisi de diğerinin bildiğini bilmiyor. Bu yüzden “kanal kalitesi” diye bir metrik hiçbir rapor ekranında görünmüyor.

İki tarafı sipariş bazında eşleştirdik. MMP’den install kaynağı, kampanya, platform ve atfedilen sipariş numarası. ERP’den her siparişin durumu; satıldı, iptal edildi, iade edildi, üçü ayrı ayrı.

Bu işin tıkandığı yer genelde anahtarın kendisi. E-ticaret altyapıları çoğunlukla iki sipariş numarası taşıyor, mağaza numarası ve ERP numarası, MMP ise yalnızca birini görüyor. Eşleşmeyi bütün veriyi çalıştırmadan önce örneklemde doğrulamak, bu tür projelerde tek seferlik bir adım değil, projenin ayakta kalıp kalmayacağını belirleyen adım.

Neden sipariş bazında, ciro bazında değil

Toplantıdaki soru ciro üzerineydi, ama oranı ciroya göre hesaplamadık. Sebebi şu: ciroya göre ağırlıklandırınca birkaç büyük sipariş, sürekli iptal eden müşteri getiren bir kanalın üstünü örtüyor. Yüksek tutarlı siparişler yüksek adetli siparişlerden farklı davranıyor, ve bizim ölçtüğümüz şey sepet büyüklüğü değil, kanalın getirdiği müşterinin niyeti.

İptalle iadeyi de ayrı tuttuk. İptal genelde stok, fiyat ya da ödeme sürtünmesi demek, ya da baştan tamamlamaya niyeti olmayan bir müşteri. İade, ürünün eline ulaştığı ve beklentiyi karşılamadığı demek. İkisini tek oranda ortalamak, veri setindeki en işe yarar sinyali siliyor.

Bir de taban filtre: “tamamlandı” değil, “iptal edilmemiş”. Hazırlık aşamasındaki siparişler analitik olarak gerçek siparişler. Yalnızca tamamlanmışa filtre atmak hacmi küçük gösteriyor ve oranı birkaç puan şişiriyor.

Kanal kalitesi, kanal maliyetinden çok daha fazla değişiyor

Install kaynağına göre iptal ve iade oranı, on kanal ve yüzde 19,4 hesap ortalaması

Hesap ortalaması yüzde 20’nin biraz altındaydı. Kanallar yüzde 11 ile yüzde 38 arasında değişiyordu.

Bulgu bu aralığın kendisi. Aynı katalog, aynı dönem, arkasında aynı operasyon varken en iyi ve en kötü kaynak arasında 27 puan fark. Bunu ürünle açıklayamazsınız. Farkı yaratan, kanalın kimi getirdiği.

En kötüler ortak bir şekle sahipti: Android’de programatik retargeting ve grafikte ACE olarak geçen Google Ads App Campaigns for Engagement. İkisi de iade değil iptal ağırlıklıydı, yani ürün hayal kırıklığı değil niyet problemi. Dokunan, sipariş veren, daha kargo çıkmadan vazgeçen müşteriler. En temiz kaynaklar Apple Search Ads ve sadakat programıydı; oradan gelen müşteri aklında bir ürünle ya da bir sebeple geliyor.

İki Google Ads uygulama kampanyası tipinin grafiğin iki ucunda durması ayrıca dikkat çekici. Install kampanyaları, yani ACI, iyi tarafta. Zaten uygulamayı kullanan kişiye giden engagement kampanyaları, yani ACE, en kötüsü. Raporda “Google Ads app” diye tek satırda toplandıklarında ortalamaları hiçbir şey anlatmıyor.

Aynısı tek bir programatik ağın içinde de geçerliydi. Aynı tedarikçi, aynı kreatif, aynı katalog: Android’de yüzde 38, iOS’ta yüzde 17. Kanal tek satır raporlandığı için kimsenin görmediği 21 puan.

En çok siparişi getiren kanal, en çok kalan siparişi getiren kanal değildi. Toplantının özeti bu tek cümleydi.

Aynı kategori her platformda aynı davranmıyor

Ürün kategorisi ve işletim sistemine göre iptal ve iade oranı, Android ve iOS karşılaştırması

Android siparişleri iOS siparişlerine göre belirgin biçimde daha sık iptal veya iade ediliyordu, hesap genelinde yaklaşık on puan. İlginç olan farkın sabit olmaması: bir kişisel bakım kategorisinde on dört puana yakınken, telefonda altı puan.

Bu, analizi karara çeviren yer. Soru “Android’e daha çok mu harcasak” olmaktan çıkıp “hangi kategoriyi hangi platformda, hangi kanalla öne çıkaralım” oluyor.

Kategori de en küçük anlamlı birim değil

Tek bir kişisel bakım kategorisinin içinde ürünler yüzde 12 ile yüzde 42 arasında değişiyordu. Yüzde 24’lük bir kategori ortalamasının altında 29 puanlık aralık.

Desen rastgele değildi. Üstte kalanlar müşterinin fotoğrafa bakarak karar veremeyeceği ürünlerdi: renk, oturma, yüzey, kutudan çıkanın ilandakinden farklı görünebileceği her şey. Altta kalanlar, müşterinin uygulamayı açmadan önce zaten karar verdiği, teknik özelliği belli ürünlerdi.

Tek bir kategorideki yedi ürünün iptal ve iade oranı, yüzde 24,4 kategori ortalamasına karşı

Eşleşmenin kendini ikinci kez amorti ettiği yer burası. Kanalları sıralayan tablo ürünleri de sıralıyor ve ikisi kesişiyor. Toplamda vasat görünen bir kanal, geri dönmeyen ürünler için en iyi kanal olabiliyor.

Pazaryeri ile kendi envanteri arasındaki fark da aynı mantıkla çıktı. Toplam oranları birbirine yakındı, bileşimleri tersti: kendi envanteri daha çok iptal ediliyordu, pazaryeri yaklaşık üç kat daha fazla iade ediliyordu. Biri operasyon problemi, diğeri satıcı kalitesi problemi. Tek bir harmanlanmış KPI ikisini de “aşağı yukarı aynı” diye raporlardı.

Ne değişti

En kötü iki kanalda bütçe büyütülmek yerine küçültüldü; o zamana kadar hacimleri başarı sayılıyordu. Hedefler hesap bazında değil kanal bazında konuldu. Kategori ve platform eşleştirmesi kampanya planlamasına girdi. Tedarikçi ve marka kırılımında raporlama eklendi, çünkü aynı eşleşme hangi tedarikçinin hangi kanalla beslendiğini de cevaplıyor.

Sonra proje olmaktan çıktı

MMP ve ERP verisi sipariş bazında eşleşip her gece BigQuery modeline dönüşüyor

Analiz bir kere soru olarak çalıştı, artık her sabah altyapı olarak çalışıyor. MMP verisi ve ERP sipariş durumu her gece BigQuery’ye düşüyor, sipariş numarasında eşleşiyor, iptal ve iadeden arındırılmış tek bir tabloya modelleniyor. Üstünde ekibin gerçekten açtığı üç görünüm var: kanal kalitesi, kategori ve platform, aylık yeniden dağıtım.

Kimse export almıyor. Bu hafta açılan bir kanal, ilk siparişinin ertesi sabahı raporda kendi kalite oranıyla beliriyor.

Değerli olan bulgu değildi, bulgu bir çeyrek içinde eskidi. Değerli olan, sorunun kalıcı olarak cevaplanabilir hale gelmesiydi.

Sizde nasıl kurarız

Ölçekli app kampanyası yürütüyor ve install kaynağına göre iptal ve iade oranınızı söyleyemiyorsanız, eksik analitik değil yapısal: MMP’niz ile ERP’niz hiç tanıştırılmamış.

Bu eşleşmeyi Mobile Measurement & MMP ve Data Engineering & BigQuery işlerinin parçası olarak kuruyoruz, çıktısını App Growth Consultancy içinde kanal bazında hedef koymak için kullanıyoruz. Genelde bir Measurement Audit ile başlıyor, çünkü eşleşme ancak altındaki event verisi kadar güvenilir.

SSS

İade neden ciro yerine sipariş bazında ölçülüyor?

Sipariş numaralarımız sistemler arasında eşleşmiyorsa?

Bunun için veri ambarı şart mı?

Bu vakadaki sayılar gerçek mi?

Verinizin doğruyu söylediğinden emin değil misiniz?