Perakende Uygulama İzleme: Neyi, Hangi Sıklıkla İzlemeli

Rakip perakende uygulamalarını sürekli izlemek: kapsam nasıl tanımlanır, hangi alan hangi sıklıkla toplanır, hangi değişiklik alarm hak eder.

Çoğu ekip uygulama verisiyle ilk kez bir çalışma olarak tanışır. Birisi bir haftalık rakip uygulama fiyatını çeker, sunumdaki slaytta uygulama fiyatının web fiyatının yedi puan altında olduğu görülür, herkes bunun önemli olduğunda hemfikir olur — ve hiçbir şey değişmez. Çalışma bir soruyu bir kez cevaplar; fiyat kararı ise her hafta verilir.

İzleme bunun tersidir: yazılı bir kapsam, alan bazında seçilmiş bir toplama sıklığı, karşılaştırmaya yetecek kadar uzun yaşayan seriler ve kampanya hâlâ sürerken birinin aksiyona çevirdiği alarmlar. Uygulamayı ayrı bir kanal yapan şeyi mobil uygulamada olan, web sitesinde olmayan veri yazısında, toplamanın kendisinin nasıl çalıştığını mobil uygulamadan veri nasıl toplanır yazısında anlatmıştık. Bu yazı ikisinin üstündeki katman: perakendecinin fiilen işlettiği program.

Kapsam, uygulama listesi değil çift listesidir

"Dört büyük market uygulamasını izliyoruz" bir kapsam tanımı değildir. Bu kanalda gözlem birimi bir çifttir: uygulama x ürün x konum, çoğu zaman bir de x kullanıcı profili. Dört uygulama, üç yüz ürün ve beş şehir, daha profiller sayıya girmeden altı bin seri eder.

Bu sayı maliyeti belirler ve sıklığı kısıtlar; dolayısıyla bir istek listesinden devralınmak yerine bilerek seçilmesi gerekir. İşe yarayan biçim şu: dar bir ürün listesi, geniş bir konum listesi. Fiyat algısını taşıyan ürünler (KVI'lar, kendi çok satanlarınız, kategori ekibinin üzerinde tartıştığı ürünler), rakiplerinizin farklı fiyatladığı her bölgede gözlenir. Mantık mağaza mağaza fiyat farkı yazısındakiyle aynı, sadece burada daha keskin: uygulamada konum isteğe bağlı bir filtre değil, zorunlu bir girdi.

Bunun tersi olan biçim — tek şehirde beş bin ürün — sessizce başarısız olur. Büyük bir veri kümesi üretir ama yalnızca tek bir şehir hakkında soru cevaplayabilir; oysa size sorulan soru, bir bölgede diğerine göre pahalı olup olmadığınızdır.

Beş alan ve her birinin beslediği karar

Cazip olan, yanıtın taşıdığı her şeyi saklamaktır. Disiplinli olan ise her alanın hangi kararı beslediğini yazmak ve hiçbir kararı beslemeyen alanları listeden çıkarmaktır.

• Ürün fiyatı değil, ödenen toplam. Teslimat ücreti, servis bedeli, sepet eşiği ve uygulama içi kuponlar müşterinin gerçekte ne ödediğini belirler. Üründe sizden iki puan pahalı ama teslimatı ücretsiz olan rakip daha ucuzdur; yalnızca ürün fiyatını taşıyan bir akış size bunun tersini raporlar.
• Bulunabilirlik. Rakibin stokta olmayan ürünü, süresi belli bir talep penceresidir; teslim edemediği üründe yaptığı indirim ise indirim değildir. Bunun uzun gerekçesini "stokta yok" da bir sinyaldir yazısında kurmuştuk.
• Sıralama ve yerleşim. Kategori listesinde, aramada, banner rotasyonunda nerede göründüğünüz. Bu, uygulama içi görünürlüğün kendisidir ve fiyatlamayı değil ticari pazarlamayı besler.
• Kampanya mekaniği. İndirim üründe mi, teslimatta mı, sepet eşiğinde mi; yalnızca yeni kullanıcıya mı açık. Karşı kampanyanın neye benzeyeceğine ve ne zaman kurulacağına bu bilgi karar verir.
• Ürün gamı. Yalnızca uygulamada beliren ürünler, çoğu zaman bir gam denemesinin ya da özel marka lansmanının web'e ulaşmasından haftalar önceki ilk görünür işaretidir.

Toplama sıklığı uygulamanın değil, alanın özelliğidir

Bir uygulamanın tamamı için tek bir toplama sıklığı ya israftır ya da geç kalır; çünkü alanlar farklı hızlarda eskir.

İki kural bu tabloyu dürüst tutar. Aksiyon alabileceğinizden daha sık toplamayın: haftalık fiyat toplantısını besleyen saatlik veri, avantaj değil depolama maliyeti üretir. Alanın değişme hızından daha seyrek de toplamayın; yoksa seri, hiç var olmamış durumların ortalamasını kaydeder — dört saatte bir yeniden dizilen bir listede günde tek sıralama çekimi, üzerine zaman damgası vurulmuş bir yazı turadan ibarettir.

Sıralamanın ayrı bir notu hak eden yanı şu: her gün aynı saatlerde toplanmalı. 09:00 gözlemini 18:00 gözlemiyle karşılaştırmak rakibin konumunu değil platformun gün dilimini ölçer. Sıklık ne olursa olsun bir niyet değil bir taahhüt olmalıdır; bunun gerekçesi veri güncelliği bir SLA'dir yazısında.

Programların çoğu alarm kurgusunda ölür

Perakende uygulamaları sürekli değişir. Her değişikliğe alarm kurarsanız kanal iki hafta içinde arka plan gürültüsüne dönüşür; hiçbirine kurmazsanız rakibin kampanyasıyla aylık sunumda, bittikten sonra tanışırsınız. Gerçek bir kategori ekibiyle temasa dayanan dört kural var.

• Değişikliğe değil, karar eşiğine alarm kurun. "Rakibin fiyatı değişti" değil, "rakip üç bölgede bir KVI'da taban fiyatımızın altına indi".
• Süreklilik koşulu koyun. Alarm ateşlenmeden önce iki ya da üç ardışık gözlem arayın; yoksa on beş dakikalık bir fiyat hatası ve geri alınışı birini gece üçte uyandırır ve ona kanalı sessize almayı öğretir.
• Yükseltmeden önce toplulaştırın. Tek bir ucuz ürün gürültüdür. İzlenen sepetin dün yüzde dördü, bu sabah yüzde on sekizi rakipte daha ucuzsa bu bir toplantıdır.
• Sahibine yönlendirin. Fiyat fiyatlamaya, sıralama ve yerleşim ticari pazarlamaya, ürün gamı kategori yönetimine. Sahibi olmayan alarm bülten olur.

Bir alarmdan çıkması gereken şey bir sayı değil, önerilen bir aksiyondur; gözlemden karara giden zinciri rakip verisinden fiyat aksiyonuna yazısında ele almıştık.

Uygulama ile web arasındaki fark, başlı başına bir metriktir

Aynı ürünün uygulama gözlemi ile web gözlemini iki ayrı seri olarak tutun; aradaki fark izlenebilir bir sayıya dönüşür. Rakip bazında kanal farkının zaman içindeki seyri, hangi markaların uygulamayı sadakat aracı olarak işlettiğini, uygulamaya özel kampanyalarının ne zaman başlayıp ne kadar sürdüğünü ve kendi farkınızın bir karar mı yoksa kaza mı olduğunu gösterir.

Yönetimin adını koyarak istediği ilk metrik genellikle budur, çünkü şirketin müşterisinin gerçekten satın aldığı kanalda rekabet edip etmediğini cevaplayan metrik budur.

İzleme sessizce bozulur; izlemeyi de ölçün

Buradaki bozulma biçimi kesinti değildir. Toplama, geçerliliğini yitirmiş bir uygulama sürümüne karşı çalışmayı sürdürür, adı değişen bir alan boş gelmeye başlar, bir konum sessizce platformun varsayılanına düşer — ve gösterge paneli bunların üzerinden çizgisini çizmeye devam eder. Toplama tarafındaki şema doğrulamasını mobil uygulamadan veri nasıl toplanır yazısında anlatmıştık; programın da iş metriklerinin yanında kendi sağlık sayıları olmalı:

• çift başına günlük gözlem sayısı, beklenen sayıya karşı
• alan başına boş değer oranı, geçen haftaya karşı
• her serinin hangi uygulama sürümünden toplandığı
• zaman damgası gecikmesi, yani serideki en yeni gözlemin yaşı

Yanında bunlar olmayan bir fiyat ölçüm değil, iddiadır.

İki kitle, iki sistem

Fiyatlama, tek bir ürün ve konum için en son gözlemi, sorgu zaman aşımının içinde ve gün boyu ister. Kategori ve finans ise rakibin promosyon derinliğinin geçen sezona göre değişip değişmediğini cevaplamak için on sekiz aylık geçmişe ihtiyaç duyar. Tek bir tablo ikisine de iyi hizmet etmez; bu ayrımı operasyonel mi, analitik mi yazısında anlatmıştık.

Bunu programın başında karara bağlamak, operasyonel deponun sessizce kimsenin sorgulayamadığı bir ambara dönüşmesini beklemekten iyidir.

Sonuç

Perakende uygulama izleme, önem kazandığı noktada artık bir veri toplama sorusu olmaktan çıkıp bir işletme sorusuna dönüşmüştür: hangi çiftler, hangi alanlar, hangi sıklıkla, kime alarm, nasıl denetlenerek. Toplama bizim kurduğumuz kısım — mobil uygulama veri toplama çalışmamızın yaptığı iş bu ve web verisinin beslediği fiyat takibi platformunu aynı şekilde besler. Kapsam, eşikler ve sahiplik ise sizin olmak zorunda. Bunlar olmadan program rapor üretir; bunlarla birlikte karar üretir.