Hangi indirme kanalı daha kaliteli siparişler üretiyor?
İndirme başı maliyeti (CPI) bilmek çok da zor değil ancak bir uygulamayı indirtmek, hangi kanala nasıl bütçe dağıtacağınızı belirlemek sadece CPI ile yürüteceğiniz bir iş olamaz, olmamalı.
Neyi savunuyoruz?
Müşterimizin app growth ekibiyle bir planlama toplantısında kanal maliyetleri hakkında konuşurken aslında hepimiz maliyetlere, CPI'lara, hacimlere hakimdik. CPI trendi belli, bütçeler bu trende göre dağıtılacak durumdaydı ancak bizim için hiçbir zaman hedef bir sayı olmadı.
Neye göre karar vermeliydik; panellerde gördüğümüz ciroya ya da sipariş sayısına mı yoksa gerçekten başarılı olmuş siparişlere göre mi?
Bunlar aynı sayılar değil elbette. Bir e-ticaret uygulamasında siparişlerin azımsanmayacak bir kısmı gerçekten ciroya dönüşmeyebiliyor; kargolanmadan iptal ediliyor ya da teslimattan sonra iade ediliyor. Burada da genel alışkanlık hep siparişin oluştuğu anı hesap ederek karar vermek oluyor.
Bu aşamada sormamız gereken soru aslında çok net.
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 de siparişin akıbetini biliyor ancak ikisi de diğerinin bildiğini bilmiyor. Bu yüzden “kanal kalitesi” diye bir metrik hiçbir rapor ekranında görünmüyor. Cevap belki bu sistemlerin içinde yok ama bizim ommetrics olarak belirlediğimiz "app install" yaklaşımımızda var.
İki tarafı sipariş bazında eşleştirerek; MMP’den install kaynağı, kampanya, platform ve sipariş numarasını, ERP’den de siparişlerin güncel durumlarını aldık. İster MMP olsun ister Google Analytics ya da başka bir entegrasyon olsun, her seferinde kurulumları çok detaylı yapmanın gelecekte bizim işimizi kolaylaştıracağını daha önce defalarca tecrübe etmiştik. Nitekim, bu detaycı yaklaşımımız bu sistemi hızlıca sağlıklı sonuçlar veren bir yapıya dönüştürdü.
Kanal kalitesi, kanal maliyetinden çok daha fazla değişiyor
Tüm kanalların iptal + iade ortalaması yüzde 20’nin biraz altındaydı. Kanalların değerleri de yüzde 11 ile yüzde 38 arasında değişiyordu.
Buradaki 27 puanlık fark aslında temas ettiğimiz şeyin ne kadar doğru olduğunun da küçük bir kanıtıydı bizim için çünkü bu farkı sadece ürünle açıklayamazsınız. Farkı yaratan, kanalın kimi getirdiği.
En başarısız olanlar ortak bir yapıya sahipti: Android’de retargeting ve 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 Email ve push'tu; çünkü kampanya yapımıza göre oradan gelen müşteri aklında bir ürünle ya da belirli bir niyetle 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ü.
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. Bu açıdan baktığında "evet, bu oran benim ortalamama yakın, fena değil aslında." denilebilecek bir oran. Bu kırılımları yapmanın ne kadar önemli olduğunu bir kez daha görmüş olduk.
En çok siparişi getiren kanal, en çok başarılı siparişi getiren kanal değildi. Toplantının özeti bu tek cümleydi.
Aynı kategori her platformda aynı davranmıyor
Android siparişleri iOS siparişlerine göre belirgin biçimde daha fazla iptal veya iade ediliyordu, hesap genelinde yaklaşık 10 puan fark vardı. İlginç olan farkın sabit olmaması: bir kişisel bakım kategorisinde 14 puana yakınken, telefonda 6 puan.
Burası aslında analizi karara çeviren yer. Soru “Android’e daha çok mu harcasak?” olmaktan çıkıp “hangi kategoriyi hangi platformda, hangi kanalla öne çıkaralım?” oluyor. Çünkü itiraf edelim, Android platformunda elde edilen indirmelerin ucuza mal edilmesi nicelik odaklı hedefleri yakalamak için ekiplerin kaçış noktası oluyor fakat bu indirmelerden geriye kalan, şişen "uninstall" sayıları ve değişmeyen aylık aktif kullanıcı sayıları oluyor.
Kategoriden de derine gitmek
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.
Bu farkın oluşması için çok fazla sebep var elbette.
Eşleşmenin kendini ikinci kez amorti ettiği yer burası. Kanalları sıraladığımız tablo mantığıyla ürünleri de sıraladığımızda ikisinin kesiştiği yerler. var. Toplamda vasat görünen ya da göze çarpmayan bir kanal, başarıyla tamamlanmış siparişlerdeki ürünler için en iyi kanal olabiliyor.
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ı
Bu analizi bir kere yaptıtkan sonra artık bir altyapıya bağlı olarak her sabah ç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.
Kimse export almıyor. Çalışmaya henüz başlanan bir kanal bile hemen bu rapora entegre oluyor ve kalitesi hemen anlaşılıyor.
Burada değerli olan şey aslında bu sonuçları bulmaktan ziyade bunu kalıcı hale getirip bir "yaklaşım" mantığı yaratmak. Biz app hedeflerine koşarken niceliğe değil, niteliğe bakarız diyebilmek. Niteliğin kurallarını da kendi değişkenlerimize göre belirlemek.
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, Data Engineering ve BigQuery işlerinin parçası olarak kuruyoruz, çıktısını App Growth Consultancy hizmetimiz içinde kanal bazında hedef koymak için kullanıyoruz. Ve tüm bu çalışmaları müşterilerimize özel olarak onların sahibi olduğu veri ortamlarında kuruyor ve geliştiriyoruz.
Bu vakada yer alan sayılar, kanal isimleri ve kategori isimleri değiştirildi, hiçbir müşteri tanımlanmıyor.
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?
