Dowód w liczbach: wykorzystanie Big Data do osiągania wyników

Opublikowany: 2022-07-22

Na pewnym etapie swojej kariery jako menedżer produktu możesz napotkać problemy o dużej skali, które są mniej zdefiniowane, obejmują szersze przyczyny i obszary oddziaływania oraz mają więcej niż jedno rozwiązanie. Kiedy zaczynasz pracować ze złożonymi zestawami danych — kiedy zaczynasz myśleć o liczbach w milionach, a nie tysiącach — potrzebujesz odpowiednich narzędzi, które umożliwią skalowanie w tym samym tempie.

W tym miejscu zarządzanie produktami oparte na danych może przynieść ogromną wartość biznesową. W poniższych przykładach, zaczerpniętych z przypadków z mojej własnej kariery, zastosowanie analityki danych do pozornie nierozwiązywalnych problemów przyniosło rozwiązania, które przyniosły ogromne zyski moim pracodawcom – od milionów dolarów do setek milionów.

Zdobycie umiejętności analizy danych może pomóc wytyczyć kolejną ścieżkę rozwoju w Twojej karierze zarządzania produktem. Rozwiążesz problemy szybciej niż Twoi koledzy, zamienisz oparte na dowodach spostrzeżenia na twarde zwroty i wniesiesz ogromny wkład w sukces Twojej organizacji.

Wykorzystaj dane na dużą skalę

Zastosowanie data science w zarządzaniu produktem i analityce produktu nie jest nową koncepcją. Nowością jest oszałamiająca ilość danych, do których firmy mają dostęp za pośrednictwem swoich platform, oprogramowania do gromadzenia danych lub samych produktów. A jednak w 2020 roku firma Seagate Technology poinformowała, że ​​68% danych gromadzonych przez firmy nie jest wykorzystywane. W białej księdze IBM z 2014 r. porównano to marnotrawstwo danych do „fabryki, w której duże ilości surowców leżą nieużywane i rozrzucone w różnych punktach wzdłuż linii montażowej”.

Menedżerowie produktów z umiejętnościami w zakresie analizy danych mogą wykorzystać te dane, aby uzyskać wgląd w kluczowe wskaźniki, takie jak aktywacja, zasięg, utrzymanie, zaangażowanie i monetyzacja. Te metryki mogą być dostosowane do różnych typów produktów, takich jak handel elektroniczny, treść, interfejsy API, produkty SaaS i aplikacje mobilne.

Krótko mówiąc, nauka o danych polega mniej na tym, jakie dane gromadzisz, a bardziej na tym, jak i kiedy z nich korzystasz, zwłaszcza gdy pracujesz z nowymi i wyższymi liczbami.

Zagłęb się w dane, aby znaleźć przyczyny źródłowe

Kilka lat temu pracowałem u dostawcy technologii turystycznych z ponad 50 000 aktywnych klientów w 180 krajach, 3700 pracownikami i 2,5 miliarda dolarów rocznych przychodów. W korporacji tej wielkości zarządzasz dużymi zespołami i ogromnymi ilościami informacji.

Kiedy zacząłem tam pracować, pojawił się następujący problem: Pomimo posiadania aktualnych planów działania i pełnych zaległości, wynik NPS spadł, a odpływ klientów wzrósł w ciągu dwóch lat. Koszty związane z obsługą klienta znacznie wzrosły, a działy wsparcia stale gasiły pożary; w ciągu tych dwóch lat liczba wezwań do wsparcia wzrosła czterokrotnie.

W ciągu pierwszych trzech miesięcy studiowałem, jak działała firma, od negocjacji dostaw do rozwiązywania reklamacji. Przeprowadziłam wywiady z wiceprezesem ds. produktu i jej zespołem, powiązaną z wiceprezesami z zespołów sprzedażowych i technologicznych oraz szeroko rozmawiałam z działem obsługi klienta. Wysiłki te przyniosły użyteczne spostrzeżenia i pozwoliły mojemu zespołowi sformułować kilka hipotez, ale nie dostarczyły żadnych twardych danych, które mogłyby je poprzeć lub ustalić podstawy do ich odrzucenia. Możliwe wyjaśnienia niezadowolenia klientów obejmowały brak funkcji, takich jak możliwość edycji zamówień po ich złożeniu; zapotrzebowanie na produkty dodatkowe; oraz niewystarczająca pomoc techniczna i/lub informacje o produkcie. Ale nawet gdybyśmy mogli zdecydować się na jeden kierunek działania, przekonanie różnych działów, by się na to zgodziły, wymagałoby czegoś mocniejszego niż możliwość.

W mniejszej firmie mógłbym zacząć od przeprowadzenia wywiadów z klientami. Jednak przy setkach tysięcy użytkowników końcowych podejście to nie było ani pomocne, ani wykonalne. Chociaż dałoby mi to morze opinii – niektóre słuszne – musiałem wiedzieć, że informacje, z którymi pracowałem, reprezentowały większy trend. Zamiast tego, przy wsparciu zespołu Business Intelligence, pobrałem wszystkie dane dostępne z działu call center i działu obsługi klienta.

Przypadki wsparcia z poprzednich sześciu miesięcy przyszły do ​​mnie w czterech kolumnach, każda po 130 000 wierszy. Każdy wiersz reprezentował żądanie obsługi klienta, a każda kolumna została oznaczona obszarem problemu klienta w miarę postępu procesu opieki. Każda kolumna miała od 11 do 471 różnych etykiet.

Ilustracja zatytułowana „Dane obsługi klienta”. Ilustracja przedstawia 130 000 wierszy, w których udokumentowano dane, z czterema kolumnami obszarów problemowych, zidentyfikowanych jako pierwszy obszar problemowy, drugi obszar problemowy, trzeci obszar problemowy i czwarty obszar problemowy. Liczba etykiet obszarów problemowych w każdej kolumnie to odpowiednio 11 etykiet, 58 etykiet, 344 etykiety i 471 etykiet.
Dane obsługi klienta, obejmujące 130 000 indywidualnych przypadków, każdy z czterema obszarami problemowymi.

Stosowanie filtrów i sortowanie ogromnego zestawu danych nie przyniosło jednoznacznych wyników. Etykiety z indywidualnymi problemami były niewystarczające, aby uchwycić szerszy obraz. Klient może początkowo zadzwonić, aby zresetować swoje hasło, i chociaż to połączenie zostanie zarejestrowane jako takie, inny problem główny może stać się widoczny po rozważeniu wszystkich czterech problemów jako ciągu. W 130 000 wierszach z milionami możliwych ciągów szukanie wzorców poprzez przeglądanie każdego wiersza z osobna nie wchodziło w grę. Stało się jasne, że identyfikacja problemu na taką skalę polegała w mniejszym stopniu na zapewnieniu wglądu biznesowego, a bardziej na rozwiązaniu problemu matematycznego.

W celu wyizolowania najczęściej występujących ciągów użyłem próbkowania prawdopodobieństwa proporcjonalnego do rozmiaru (PPS). Ta metoda ustawia prawdopodobieństwo wyboru dla każdego elementu, aby było proporcjonalne do jego miary rozmiaru. Chociaż matematyka była złożona, w praktyce to, co zrobiliśmy, było proste: próbkowaliśmy przypadki na podstawie częstotliwości każdej etykiety w każdej kolumnie. Ta metoda, będąca formą wieloetapowego próbkowania, pozwoliła nam zidentyfikować ciągi problemów, które dały bardziej żywy obraz tego, dlaczego klienci dzwonią do centrum wsparcia. Najpierw nasz model zidentyfikował najczęstszą etykietę z pierwszej kolumny, następnie w ramach tej grupy najczęstszą etykietę z drugiej kolumny i tak dalej.

Ilustracja zatytułowana „Dane obsługi klienta po próbkowaniu PPS”. Ilustracja przedstawia 130 000 wierszy, w których udokumentowano dane, z czterema kolumnami obszarów problemowych, zidentyfikowanych jako pierwszy obszar problemowy, drugi obszar problemowy, trzeci obszar problemowy i czwarty obszar problemowy. Liczba etykiet obszarów problemowych w każdej kolumnie to odpowiednio 11 etykiet, 58 etykiet, 344 etykiety i 471 etykiet. Dodatkowo, podświetlone pola są dodawane, aby przedstawić identyfikację często występujących etykiet w każdym obszarze problemowym.
Dane centrum obsługi klienta po zastosowaniu próbkowania PPS, ze zidentyfikowanymi najczęściej występującymi ciągami etykiet.

Po zastosowaniu próbkowania PPS wyizolowaliśmy 2% przyczyn źródłowych, które stanowiły około 25% wszystkich przypadków. To pozwoliło nam zastosować algorytm kumulacji prawdopodobieństwa, który ujawnił, że ponad 50% przypadków wynikało z 10% przyczyn źródłowych.

Ten wniosek potwierdził jedną z naszych hipotez: Klienci kontaktowali się z call center, ponieważ nie mieli możliwości zmiany danych zamówienia po złożeniu zamówienia. Rozwiązując pojedynczy problem, klient może zaoszczędzić 7 milionów dolarów na kosztach wsparcia i odzyskać 200 milionów dolarów przychodu przypisywanego odpływowi klientów.

Wykonuj analizę w czasie rzeczywistym

Znajomość uczenia maszynowego była szczególnie przydatna w rozwiązaniu problemu analizy danych w innej firmie turystycznej o podobnej wielkości. Firma służyła jako łącznik między hotelami i biurami podróży na całym świecie za pośrednictwem strony internetowej i interfejsów API. Ze względu na rozpowszechnienie metawyszukiwarek, takich jak Trivago, Kayak i Skyscanner, ruch API wzrósł o trzy rzędy wielkości. Przed rozpowszechnieniem się metasearch stosunek look-to-book (całkowita liczba wyszukiwań w interfejsie API do łącznej liczby rezerwacji w interfejsie API) wynosił 30:1; po rozpoczęciu metawyszukiwania niektórzy klienci osiągnęliby stosunek 30 000:1. W godzinach szczytu firma musiała obsłużyć do 15 000 żądań API na sekundę bez poświęcania szybkości przetwarzania. Koszty serwera związane z API odpowiednio wzrosły. Jednak zwiększony ruch z tych usług nie spowodował wzrostu sprzedaży; przychody pozostały stałe, powodując ogromne straty finansowe dla firmy.

Firma potrzebowała planu obniżenia kosztów serwerów spowodowanych wzrostem ruchu, przy jednoczesnym utrzymaniu doświadczenia klienta. Kiedy firma próbowała blokować ruch dla wybranych klientów w przeszłości, rezultatem był negatywny PR. Dlatego zablokowanie tych silników nie wchodziło w grę. Mój zespół zwrócił się do danych, aby znaleźć rozwiązanie.

Przeanalizowaliśmy około 300 milionów żądań API pod kątem szeregu parametrów: czas żądania, miejsce docelowe, daty zameldowania/wymeldowania, lista hoteli, liczba gości i rodzaj pokoju. Na podstawie danych ustaliliśmy, że pewne wzorce były powiązane ze wzrostem ruchu w metasearchu: pora dnia, liczba żądań na jednostkę czasu, alfabetyczne wyszukiwania w miejscach docelowych, uporządkowane listy hoteli, określone okno wyszukiwania (daty zameldowania/wymeldowania) oraz konfiguracja gościa.

Zastosowaliśmy nadzorowane podejście do uczenia maszynowego i stworzyliśmy algorytm podobny do regresji logistycznej: obliczał prawdopodobieństwo dla każdego żądania na podstawie tagów wysłanych przez klienta, w tym znacznika czasu delta, znacznika czasu, miejsca docelowego, hotelu(ów), daty zameldowania/wymeldowania oraz liczba gości, a także tagi wcześniejszych próśb. W zależności od podanych parametrów algorytm określi prawdopodobieństwo, że żądanie serwera API zostało wygenerowane przez człowieka lub przez silnik metawyszukiwarki. Algorytm działałby w czasie rzeczywistym, gdy klient uzyskiwał dostęp do interfejsu API. Jeśli ustali wystarczająco wysokie prawdopodobieństwo, że żądanie było kierowane przez człowieka, żądanie zostanie wysłane do szybkiego serwera. Gdyby wyglądało to na metawyszukiwanie, żądanie zostałoby przekierowane do serwera buforującego, który był tańszy w obsłudze. Wykorzystanie nadzorowanego uczenia pozwoliło nam nauczyć model, prowadząc do większej dokładności w trakcie rozwoju.

Model ten zapewniał elastyczność, ponieważ prawdopodobieństwo można było dostosować do klienta w oparciu o bardziej szczegółowe reguły biznesowe niż te, które stosowaliśmy wcześniej (np. oczekiwane rezerwacje na dzień lub poziom klienta). Dla konkretnego klienta zapytania mogły być kierowane w dowolnym momencie powyżej 50% prawdopodobieństwa, natomiast dla bardziej wartościowych klientów moglibyśmy wymagać większej pewności, kierując je, gdy przekroczą próg 70% prawdopodobieństwa.

Ilustracja zatytułowana „Sortowanie klientów za pomocą algorytmu uczenia maszynowego”. Ta ilustracja jest schematem blokowym pokazującym możliwe ścieżki, według których żądania są sortowane w zależności od ich miejsca pochodzenia. Początek schematu blokowego ma dwa możliwe źródła: „Użytkownicy Internetu” i „Metawyszukiwania”. Oba prowadzą do „XML, API Server”. Prowadzi to do „Naturalnego wyszukiwania?” Jeśli wynik to „Tak”, następnym krokiem jest „Serwer o dużej szybkości”. Jeśli wynik to „Nie”, następnym krokiem jest „Serwer buforowania”. Następnie oba są kierowane z powrotem do „XML, API Server”.
Ścieżka, według której żądania były sortowane do szybkiego serwera lub serwera buforowania, w zależności od ich miejsca pochodzenia.

Po wdrożeniu algorytmu klasyfikacji firma przekierowała do 70% zapytań w danym przedziale czasowym do tańszego stosu i zaoszczędziła około 5 do 7 milionów dolarów rocznie na kosztach infrastruktury. Jednocześnie firma usatysfakcjonowała bazę klientów, nie odrzucając ruchu. Zachował współczynnik rezerwacji przy jednoczesnym zabezpieczeniu przychodów.

Użyj odpowiednich narzędzi do pracy

Te studia przypadków pokazują wartość wykorzystania nauki o danych do rozwiązywania złożonych problemów produktowych. Ale od czego powinna zacząć się Twoja przygoda z nauką o danych? Są szanse, że masz już podstawową wiedzę na temat szerokich obszarów wiedzy. Nauka o danych jest działalnością interdyscyplinarną; obejmuje głęboko techniczne i koncepcyjne myślenie. To mariaż wielkich liczb i wielkich idei. Aby rozpocząć, musisz rozwijać swoje umiejętności w:

Programowanie. Strukturalny język zapytań lub SQL to standardowy język programowania do zarządzania bazami danych. Python to standardowy język do analizy statystycznej. Chociaż oba mają nakładające się funkcje, w bardzo podstawowym sensie SQL służy do pobierania i formatowania danych, podczas gdy Python służy do przeprowadzania analiz, aby dowiedzieć się, co dane mogą powiedzieć. Excel, choć nie tak potężny jak SQL i Python, może pomóc w osiągnięciu wielu tych samych celów; prawdopodobnie będziesz wzywany do częstego korzystania z niego.

Badania operacyjne. Kiedy masz już swoje wyniki, co wtedy? Wszystkie informacje na świecie są bezużyteczne, jeśli nie wiesz, co z nimi zrobić. Badania operacyjne to dziedzina matematyki poświęcona zastosowaniu metod analitycznych w strategii biznesowej. Wiedza o tym, jak korzystać z badań operacyjnych, pomoże Ci podejmować rozsądne decyzje biznesowe poparte danymi.

Nauczanie maszynowe. Wraz ze wzrostem AI postępy w uczeniu maszynowym stworzyły nowe możliwości dla analiz predykcyjnych. Wykorzystanie w biznesie analiz predykcyjnych wzrosło z 23% w 2018 r. do 59% w 2020 r., a oczekuje się, że do 2026 r. rynek doświadczy skumulowanego rocznego wzrostu o 24,5%. Nadszedł czas, aby menedżerowie produktu poznali możliwości tej technologii.

Wizualizacja danych. Nie wystarczy zrozumieć swoje analizy; potrzebujesz narzędzi, takich jak Tableau, Microsoft Power BI i Qlik Sense, aby przekazać wyniki w formacie łatwym do zrozumienia dla nietechnicznych interesariuszy.

Lepiej jest samemu zdobyć te umiejętności, ale przynajmniej powinieneś mieć znajomość potrzebną do zatrudniania ekspertów i delegowania zadań. Dobry menedżer produktu powinien znać rodzaje możliwych analiz i pytania, na które może pomóc. Powinni rozumieć, jak przekazywać pytania analitykom danych i jak przeprowadzane są analizy, a także być w stanie przekształcić wyniki w rozwiązania biznesowe.

Wykorzystaj moc, aby uzyskać zwroty

Badanie przeprowadzone przez NewVantage Partners 2022 Data and AI Leadership Executive Survey pokazuje, że ponad 90% uczestniczących organizacji inwestuje w inicjatywy AI i danych. Przychody generowane z Big Data i analityki biznesowej wzrosły ponad dwukrotnie od 2015 roku. Analiza danych, niegdyś umiejętność specjalistyczna, jest obecnie niezbędna do udzielania właściwych odpowiedzi dla firm na całym świecie.

Zatrudnia się menedżera produktu, który ma prowadzić zwroty, określać strategię i pozyskiwać najlepszą pracę od współpracowników. Autentyczność, empatia i inne miękkie umiejętności są przydatne w tym względzie, ale to tylko połowa równania. Aby być liderem w swojej organizacji, przedstawiaj fakty, a nie opinie. Narzędzia do opracowywania spostrzeżeń opartych na dowodach nigdy nie były potężniejsze, a potencjalne zyski nigdy nie były większe.