Rakamlarla Kanıt: Sonuçları Yönlendirmek için Büyük Veriyi Kullanma

Yayınlanan: 2022-07-22

Ürün yöneticisi olarak kariyerinizin belirli bir noktasında, daha az tanımlanmış, daha geniş nedenleri ve etki alanlarını içeren ve birden fazla çözümü olan büyük ölçekli sorunlarla karşılaşabilirsiniz. Kendinizi karmaşık veri kümeleriyle çalışırken bulduğunuzda -binlerce yerine milyonlarca sayılar hakkında düşünmeye başladığınızda- aynı oranda ölçek büyütmenizi sağlayacak doğru araçlara ihtiyacınız vardır.

İşte bu noktada veriye dayalı ürün yönetimi muazzam bir iş değeri sağlayabilir. Kendi kariyerimdeki vakalardan alınan aşağıdaki örneklerde, görünüşte zorlu sorunlara veri analitiği uygulamak, işverenlerime milyonlarca dolardan yüz milyonlara kadar değişen devasa getiriler getiren çözümler üretti.

Veri bilimi becerileri edinmek, ürün yönetimi kariyerinizde bir sonraki büyüme yolunu oluşturmanıza yardımcı olabilir. Sorunları meslektaşlarınızdan daha hızlı çözecek, kanıta dayalı içgörüleri kesin getirilere dönüştürecek ve kuruluşunuzun başarısına büyük katkılarda bulunacaksınız.

Büyük Ölçekli Verilerden Yararlanın

Ürün yönetimi ve ürün analitiğinde veri bilimini uygulamak yeni bir kavram değildir. Yeni olan, işletmelerin platformları, veri toplama yazılımları veya ürünlerin kendileri aracılığıyla erişebildiği şaşırtıcı miktarda veridir. Yine de 2020'de Seagate Technology, şirketler tarafından toplanan verilerin %68'inin kaldıraçsız kaldığını bildirdi. 2014 IBM teknik incelemesi, bu veri israfını “büyük miktarda hammaddenin kullanılmadığı ve montaj hattı boyunca çeşitli noktalara saçıldığı bir fabrika” ile karşılaştırdı.

Veri bilimi becerilerine sahip ürün yöneticileri, etkinleştirme, erişim, elde tutma, katılım ve para kazanma gibi temel metrikler hakkında bilgi edinmek için bu verilerden yararlanabilir. Bu ölçümler, e-ticaret, içerik, API'ler, SaaS ürünleri ve mobil uygulamalar gibi çeşitli ürün türlerine yönelik olabilir.

Kısacası, veri bilimi, hangi verileri topladığınızdan çok, özellikle yeni ve daha yüksek mertebeden sayılarla çalışırken, onu nasıl ve ne zaman kullandığınızla ilgilidir.

Kök Nedenleri Bulmak için Verileri İnceleyin

Birkaç yıl önce, 180 ülkede 50.000'den fazla aktif müşterisi, 3.700 çalışanı ve yıllık 2.5 milyar dolarlık geliri olan bir seyahat teknolojisi sağlayıcısında çalıştım. Bu büyüklükteki bir şirkette, büyük ekipleri ve büyük miktarda bilgiyi yönetiyorsunuz.

Orada çalışmaya başladığımda şu sorunla karşılaştım: Güncel yol haritalarına ve dolu iş listelerine rağmen, NPS puanı düştü ve iki yıl içinde müşteri kaybı arttı. Müşteri desteğiyle ilgili maliyetler önemli ölçüde arttı ve destek departmanları sürekli olarak yangınla mücadele ediyordu; bu iki yıl boyunca, destek çağrıları dört katına çıktı.

İlk üç ayımda, tedarik müzakeresinden şikayet çözümüne kadar işin nasıl çalıştığını inceledim. Ürün başkan yardımcısı ve ekibiyle, satış ve teknoloji ekiplerinden Başkan Yardımcıları ile bağlantılı görüşmeler gerçekleştirdim ve müşteri destek departmanıyla kapsamlı bir şekilde konuştum. Bu çabalar yararlı bilgiler sağladı ve ekibimin birkaç hipotez geliştirmesine izin verdi - ancak onları destekleyecek veya reddedilecek zeminler oluşturacak somut veriler sağlamadı. Müşteri memnuniyetsizliği için olası açıklamalar, siparişleri verildikten sonra düzenleme yeteneği gibi özelliklerin eksikliğini içeriyordu; ek ürünlere duyulan ihtiyaç; ve yetersiz teknik yardım ve/veya ürün bilgisi. Ancak tek bir hareket tarzına karar verebilsek bile, çeşitli departmanları buna uymaya ikna etmek için bir olasılıktan daha sağlam bir şey gerekir.

Daha küçük bir şirkette müşteri görüşmeleri yaparak başlayabilirdim. Ancak yüzbinlerce son kullanıcı tabanı ile bu yaklaşım ne yararlı ne de uygulanabilir oldu. Bana bir çok fikir vermiş olsa da -bazıları geçerli- üzerinde çalıştığım bilgilerin daha büyük bir eğilimi temsil ettiğini bilmem gerekiyordu. Bunun yerine iş zekası ekibinin desteğiyle çağrı merkezi ve müşteri destek departmanlarından mevcut tüm verileri çektim.

Önceki altı aya ait destek vakaları bana her biri 130.000 satırdan oluşan dört sütun halinde geldi. Her satır bir müşteri destek talebini temsil ediyordu ve her sütun, bakım sürecinde ilerledikçe müşterinin sorun alanıyla etiketlendi. Her sütunda 11 ila 471 farklı etiket vardı.

"Müşteri Destek Verileri" başlıklı bir çizim. Şekil, Birinci Sorun Alanı, İkinci Sorun Alanı, Üçüncü Sorun Alanı ve Dördüncü Sorun Alanı olarak tanımlanan dört sorunlu alan sütunu ile verilerin belgelendiği 130.000 satırı temsil etmektedir. Her sütundaki sorunlu alan etiketlerinin sayısı sırasıyla 11 Etiket, 58 Etiket, 344 Etiket ve 471 Etiket olarak belirtilmiştir.
Her biri dört sorun alanına sahip 130.000 ayrı vakadan oluşan müşteri destek verileri.

Filtre uygulamak ve devasa veri setini sıralamak, kesin sonuçlar vermedi. Bireysel sorun etiketleri büyük resmi yakalamada yetersizdi. Bir müşteri başlangıçta parolasını sıfırlamak için arayabilir ve bu çağrı bu şekilde günlüğe kaydedilirken, dört sorunun tümü bir dize olarak kabul edildikten sonra farklı bir kök sorunu ortaya çıkabilir. Milyonlarca olası dize içeren 130.000 satırda, her satırı ayrı ayrı inceleyerek kalıp aramak bir seçenek değildi. Sorunu bu ölçekte tanımlamanın iş anlayışı sağlamaktan daha az olduğu ve bir matematik problemini çözmekle daha karşılaştırılabilir olduğu ortaya çıktı.

En sık meydana gelen dizileri izole etmek için boyutla orantılı olasılık (PPS) örneklemesini kullandım. Bu yöntem, her öğenin seçim olasılığını, boyut ölçüsüyle orantılı olacak şekilde ayarlar. Matematik karmaşık olsa da, pratik açıdan yaptığımız şey basitti: Her sütundaki her bir etiketin sıklığına göre vakaları örnekledik. Çok aşamalı bir örnekleme biçimi olan bu yöntem, müşterilerin destek merkezini neden aradığına dair daha canlı bir tablo çizen sorun dizilerini belirlememizi sağladı. İlk olarak, modelimiz ilk sütundan en yaygın etiketi belirledi, ardından bu grup içinde ikinci sütundan en yaygın etiketi belirledi ve bu şekilde devam etti.

"PPS Örneklemesinden Sonra Müşteri Destek Verileri" başlıklı bir çizim. Şekil, Birinci Sorun Alanı, İkinci Sorun Alanı, Üçüncü Sorun Alanı ve Dördüncü Sorun Alanı olarak tanımlanan dört sorunlu alan sütunu ile verilerin belgelendiği 130.000 satırı temsil etmektedir. Her sütundaki sorunlu alan etiketlerinin sayısı sırasıyla 11 Etiket, 58 Etiket, 344 Etiket ve 471 Etiket olarak belirtilmiştir. Ek olarak, her sorun alanında yaygın olarak ortaya çıkan etiketlerin tanımlanmasını temsil etmek için vurgulanan kutular eklenir.
PPS örneklemesinin uygulanmasından sonra müşteri destek merkezi verileri, en sık görülen etiket dizileri tanımlanır.

PPS örneklemesini uyguladıktan sonra, toplam vakaların kabaca %25'ini oluşturan temel nedenlerin %2'sini izole ettik. Bu, vakaların %50'sinden fazlasının kök nedenlerin %10'undan kaynaklandığını ortaya çıkaran kümülatif bir olasılık algoritması uygulamamıza izin verdi.

Bu sonuç, hipotezlerimizden birini doğruladı: Müşteriler, sipariş verildikten sonra sipariş verilerini değiştirmenin bir yolu olmadığı için çağrı merkeziyle iletişime geçiyorlardı. Müşteri, tek bir sorunu düzelterek, 7 milyon dolarlık destek maliyetlerinden tasarruf edebilir ve müşteri kaybından kaynaklanan 200 milyon dolarlık geliri geri kazanabilir.

Gerçek Zamanlı Analiz Gerçekleştirin

Makine öğrenimi bilgisi, benzer büyüklükteki başka bir seyahat şirketindeki bir veri analizi sorununu çözmede özellikle yararlıydı. Şirket, bir web sitesi ve API'ler aracılığıyla dünyanın her yerindeki oteller ve seyahat acenteleri arasında bir bağlantı görevi gördü. Trivago, Kayak ve Skyscanner gibi meta arama motorlarının çoğalması nedeniyle, API trafiği üç kat büyüdü. Meta aramanın yaygınlaşmasından önce, kitaba bak oranı (toplam API aramalarının toplam API rezervasyonlarına oranı) 30:1'di; meta aramalar başladıktan sonra, bazı istemciler 30.000:1 oranına ulaşacaktı. Yoğun saatlerde şirket, işlem hızından ödün vermeden saniyede 15.000 API isteğine kadar yanıt vermek zorunda kaldı. API ile ilişkili sunucu maliyetleri buna göre arttı. Ancak bu hizmetlerden gelen artan trafik, satışlarda bir artışa neden olmadı; gelirler sabit kaldı ve şirket için büyük bir mali kayıp yarattı.

Şirket, müşteri deneyimini korurken trafik artışının neden olduğu sunucu maliyetlerini azaltmak için bir plana ihtiyaç duyuyordu. Şirket geçmişte belirli müşteriler için trafiği engellemeye çalıştığında, sonuç olumsuz PR idi. Bu motorları engellemek bu nedenle bir seçenek değildi. Ekibim bir çözüm bulmak için verilere yöneldi.

Yaklaşık 300 milyon API talebini bir dizi parametre üzerinden analiz ettik: talebin zamanı, varış yeri, giriş/çıkış tarihleri, otel listesi, misafir sayısı ve oda tipi. Verilerden, belirli kalıpların meta arama trafiği dalgalanmalarıyla ilişkili olduğunu belirledik: günün saati, zaman birimi başına istek sayısı, destinasyonlarda alfabetik aramalar, oteller için sıralı listeler, belirli arama penceresi (giriş/çıkış tarihleri) ve misafir konfigürasyonu

Denetimli bir makine öğrenimi yaklaşımı uyguladık ve lojistik regresyona benzer bir algoritma oluşturduk: Delta-zaman damgası, zaman damgası, varış yeri, otel(ler) dahil olmak üzere müşteri tarafından gönderilen etiketlere dayalı olarak her istek için bir olasılık hesapladı. giriş/çıkış tarihleri ​​ve misafir sayısı ile önceki taleplerin etiketleri. Verilen parametrelere bağlı olarak, algoritma, bir API sunucusu talebinin bir insan veya bir meta arama motoru tarafından oluşturulma olasılığını belirler. Algoritma, bir istemci API'ye eriştiğinde gerçek zamanlı olarak çalışır. İsteğin insan kaynaklı olduğuna dair yeterince yüksek bir olasılık belirlenirse, istek yüksek hızlı sunucuya gönderilir. Bir meta arama gibi görünüyorsa, istek, çalışması daha ucuz olan bir önbelleğe alma sunucusuna yönlendirilir. Denetimli öğrenmenin kullanılması, modeli öğretmemize izin vererek, geliştirme süreci boyunca daha fazla doğruluk sağladı.

Bu model esneklik sağladı, çünkü olasılık, daha önce kullandığımızdan daha spesifik iş kurallarına dayalı olarak müşteri başına uyarlanabiliyordu (örneğin, günlük beklenen rezervasyonlar veya müşteri katmanı). Belirli bir müşteri için, talepler %50 olasılığın üzerindeki herhangi bir noktaya yönlendirilebilirken, daha değerli müşteriler için daha fazla kesinlik talep edebilir ve onları %70 olasılık eşiğini geçtiğinde yönlendirebiliriz.

"Bir Makine Öğrenimi Algoritması ile İstemcileri Sıralama" başlıklı bir çizim. Bu çizim, isteklerin çıkış noktalarına göre sıralandığı olası yolları gösteren bir akış şemasıdır. Akış şemasının başlangıcının iki olası kaynağı vardır, “İnternet Kullanıcıları” ve “MetaAramalar”. Her ikisi de "XML, API Sunucusu"na yol açar. Bu "Doğal Arama?" Sonuç “Evet” ise bir sonraki adım “Yüksek Hızlı Sunucu”dur. Sonuç “Hayır” ise bir sonraki adım “Sunucuyu Önbelleğe Alma”dır. Bundan sonra her ikisi de “XML, API Sunucusu”na yönlendirilir.
Kaynak noktalarına bağlı olarak, isteklerin yüksek hızlı sunucuya veya önbelleğe alma sunucusuna göre sıralandığı yol.

Sınıflandırma algoritmasını uyguladıktan sonra şirket, belirli bir zaman çerçevesinde taleplerin %70'ini daha ucuz yığına yönlendirdi ve altyapı maliyetlerinde yılda yaklaşık 5 milyon ila 7 milyon dolar tasarruf sağladı. Aynı zamanda şirket, trafiği reddetmeyerek müşteri tabanını memnun etti. Geliri korurken rezervasyon oranını korudu.

İş İçin Doğru Araçları Kullanın

Bu vaka çalışmaları, karmaşık ürün problemlerini çözmek için veri bilimi kullanmanın değerini göstermektedir. Peki veri bilimi yolculuğunuz nereden başlamalı? Muhtemelen, zaten geniş bilgi alanları hakkında temel bir anlayışa sahipsiniz. Veri bilimi disiplinler arası bir faaliyettir; derinden teknik ve kavramsal düşünmeyi kapsar. Büyük sayıların ve büyük fikirlerin evliliğidir. Başlamak için aşağıdaki konularda becerilerinizi geliştirmeniz gerekir:

Programlama. Yapılandırılmış sorgu dili veya SQL, veritabanlarını yönetmek için standart programlama dilidir. Python, istatistiksel analiz için standart dildir. İkisinin örtüşen işlevleri olsa da, çok temel anlamda, verileri almak ve biçimlendirmek için SQL kullanılırken, verilerin size neler söyleyebileceğini bulmak için analizleri çalıştırmak için Python kullanılır. Excel, SQL ve Python kadar güçlü olmasa da, aynı hedeflerin çoğuna ulaşmanıza yardımcı olabilir; muhtemelen sık sık kullanmanız istenecektir.

Yöneylem araştırması. Sonuçlarını aldıktan sonra, ne olacak? Onunla ne yapacağınızı bilmiyorsanız, dünyadaki tüm bilgiler hiçbir işe yaramaz. Yöneylem araştırması, analitik yöntemleri iş stratejisine uygulamaya adamış bir matematik alanıdır. Yöneylem araştırmasının nasıl kullanılacağını bilmek, verilerle desteklenen sağlam iş kararları vermenize yardımcı olacaktır.

Makine öğrenme. Yapay zeka yükselişteyken, makine öğrenimindeki gelişmeler, tahmine dayalı analitik için yeni olanaklar yarattı. Tahmine dayalı analitiklerin iş kullanımı 2018'de %23'ten 2020'de %59'a yükseldi ve pazarın 2026'ya kadar %24,5 bileşik yıllık büyüme yaşaması bekleniyor. Şimdi ürün yöneticilerinin teknolojiyle nelerin mümkün olduğunu öğrenme zamanı.

Veri goruntuleme. Analizlerinizi anlamak yetmez; sonuçları teknik olmayan paydaşların anlayabileceği bir biçimde iletmek için Tableau, Microsoft Power BI ve Qlik Sense gibi araçlara ihtiyacınız var.

Bu becerileri kendiniz edinmeniz tercih edilir, ancak en azından uzmanları işe almak ve görevleri devretmek için gereken aşinalığa sahip olmalısınız. İyi bir ürün yöneticisi, olası analiz türlerini ve cevaplamaya yardımcı olabilecekleri soruları bilmelidir. Soruları veri bilimcilerine nasıl ileteceklerini ve analizlerin nasıl yapıldığını anlamalı ve sonuçları iş çözümlerine dönüştürebilmelidirler.

İadeleri Artırma Gücünü Kullanın

NewVantage Partners'ın 2022 Veri ve Yapay Zeka Liderliği Yönetici Anketi, katılımcı kuruluşların %90'ından fazlasının yapay zeka ve veri girişimlerine yatırım yaptığını ortaya koyuyor. Büyük veri ve iş analitiğinden elde edilen gelir 2015'ten bu yana iki katından fazla arttı. Bir zamanlar özel bir beceri olan veri analizi, artık her yerde şirketlere doğru yanıtları sağlamak için şart.

İadeleri yönlendirmek, stratejiyi belirlemek ve iş arkadaşlarından en iyi işi ortaya çıkarmak için bir ürün müdürü işe alınır. Özgünlük, empati ve diğer yumuşak beceriler bu açıdan faydalıdır, ancak bunlar denklemin sadece yarısıdır. Kuruluşunuzda lider olmak için fikirleri değil gerçekleri masaya yatırın. Kanıta dayalı içgörüler geliştirmeye yönelik araçlar hiç bu kadar güçlü olmamıştı ve potansiyel getiriler hiç bu kadar büyük olmamıştı.