Jak przekształcić dane o użyciu produktu w raport adopcji funkcji (2026)

Eksport danych o użyciu to długa lista zdarzeń: ID użytkownika, nazwa zdarzenia, znacznik czasu, może jedna lub dwie właściwości. Raport z adaptacji funkcji to pojedyncza wartość procentowa. Różnica między nimi to kwestia trzech decyzji, a no nie wzoru.

Którzy użytkownicy powinni znaleźć się w mianowniku. Co kwalifikuje się jako skorzystanie z funkcji. Oraz w jakim przedziale czasowym dokonujesz pomiaru.

Zmień dowolną z tych rzeczy, a wynik przesunie się o dziesiątki punktów procentowych. Raport nadal będzie wyglądał na poprawny – i w tym tkwi problem.

Ten poradnik omawia, co należy ustalić na samym początku, trzy ręczne metody oraz momenty, w których każda z nich zawodzi.

Co jest potrzebne przed rozpoczęciem

Potrzebujesz wierszy na poziomie pojedynczych zdarzeń, a nie wstępnie zagregowanego podsumowania. Jeden wiersz na zdarzenie, zawierający identyfikator użytkownika i znacznik czasu.

Potrzebujesz nazwy zdarzenia, która rzeczywiście reprezentuje daną funkcję. Rzadko jest to tak proste, jak się wydaje, ponieważ większość funkcji wywołuje kilka różnych zdarzeń. Wskaźnik adaptacji funkcji jest tylko tak dokładny, jak to mapowanie.

Musisz również wiedzieć, kto w ogóle mógł z niej skorzystać. Jeśli funkcja została wdrożona za pomocą flagi tylko dla części kont, cała reszta nie powinna znaleźć się w mianowniku.

Szybka weryfikacja poprawności pozwala zaoszczędzić godzinę pracy później. Policz unikalnych użytkowników w wyeksportowanych danych i porównaj tę liczbę ze znaną liczbą aktywnych użytkowników. Jeśli te wartości mocno się różnią, eksport został przefiltrowany w sposób, którego nie zauważyłeś.

Trzy decyzje, które zmieniają wynik

Mianownik. Wszyscy zarejestrowani użytkownicy, aktywni użytkownicy w skali miesiąca lub tylko użytkownicy kwalifikujący się do korzystania z funkcji. Dają one trzy różne wartości procentowe z tych samych zdarzeń. Każdy wskaźnik adaptacji funkcji to ułamek, więc zdefiniuj obie jego części, zanim cokolwiek obliczysz.

Wybór użytkowników kwalifikujących się jest zazwyczaj najbardziej uczciwym podejściem w przypadku nowo wdrożonej funkcji. Wszyscy zarejestrowani użytkownicy to liczba, która wygląda najgorzej, ale najłatwiej obronić ją jako podejście ostrożne.

Co oznacza „użycie”. Wywołanie zdarzenia raz, dwa razy czy w dwóch osobnych sesjach. Pojedyncze kliknięcie podczas samouczka to nie adaptacja – większość zespołów przekonuje się o tym na własnej skórze.

Wybierz próg i zapisz go w raporcie. Dwa użycia w dwa różne dni to powszechna i łatwa do uzasadnienia reguła.

Przedział czasowy. Adaptacja nie jest punktem w czasie. To odsetek kwalifikujących się użytkowników, którzy wykonali daną czynność w określonym okresie, więc ten okres jest częścią definicji.

Oto udokumentowany niuans, który warto poznać, zanim skopiujesz metodologię jakiegoś narzędzia. Amplitude's retention documentation wyjaśnia, jak działają te obliczenia. Narzędzie „oblicza dane dotyczące retencji, porównując datę zdarzenia początkowego z datą określonego zdarzenia powrotnego”.

Zakres dat dotyczy wyłącznie pierwszego zdarzenia. Amplitude wprost stwierdza, że „użytkownicy nie muszą wywołać zdarzenia powrotnego w tym okresie, aby zostać uwzględnionymi w analizie”.

To rozsądne zachowanie, które często zaskakuje ludzi. Arkusz kalkulacyjny, który filtruje oba zdarzenia do tego samego przedziału czasowego, nie będzie zgodny z wynikami z narzędzia – i żadne z tych podejść nie jest błędne.

Jak zrobić to ręcznie

Opcja 1: Policz unikalnych użytkowników, a następnie podziel

Zacznij od deduplikacji, ponieważ surowa liczba zdarzeń nie odzwierciedla liczby osób, które zaadoptowały funkcję. Wyciągnij listę unikalnych użytkowników za pomocą funkcji UNIQUE.

Następnie policz, ilu z tych użytkowników wywołało zdarzenie powiązane z funkcją, używając funkcji COUNTIFS z nazwą zdarzenia i zakresem dat. Podziel wynik przez liczbę kwalifikujących się użytkowników.

Przechowuj obie te liczby w widocznych komórkach, zamiast zagnieżdżać je w jednej formule. Ktoś na pewno zapyta, jaki był mianownik, a Ty chcesz mieć możliwość bezpośredniego wskazania go.

Ograniczeniem tej metody jest to, że daje ona jedną suchą liczbę. Wiesz, że poziom adaptacji wynosi 18%, ale nie wiesz nic o tym, kim są ci użytkownicy.

Opcja 2: Zbuduj tabelę flag na poziomie użytkownika

Jeden wiersz na każdego kwalifikującego się użytkownika, jedna kolumna na każde pytanie. Czy wywołali zdarzenie, ile razy i w ile różnych dni.

Teraz możesz segmentować dane. Adaptacja według planu taryfowego, kohorty rejestracji, wielkości konta czy tego, czy ukończyli proces wdrożenia.

To właśnie tutaj wskaźnik adaptacji funkcji staje się podstawą do działania, a nie tylko suchym raportem. Ogólny wynik 18% ukrywa fakt, że wśród nowych użytkowników wskaźnik ten wynosi 40%, a wśród tych z zeszłego roku – zaledwie 4%.

Ta różnica to kluczowy wniosek. Nasz przewodnik po analizie kohortowej wyjaśnia, dlaczego ogólny wskaźnik zmienia się za każdym razem, gdy zmienia się liczba rejestracji, nawet jeśli zachowanie użytkowników pozostaje bez zmian.

Ograniczeniem jest tu objętość danych i łączenie tabel. Eksport zawierający milion wierszy połączony z tabelą kont to moment, w którym praca z formułami przestaje być przyjemna.

Opcja 3: Stwórz zakładkę z definicjami obok danych liczbowych

Zapisz nazwę zdarzenia, próg, przedział czasowy, mianownik oraz informację o tym, kto się kwalifikował.

To właśnie dzięki temu raport będzie można porównać w przyszłym miesiącu. Jest to jednak również ta zakładka, która jest pomijana, gdy ktoś potrzebuje danych w dziesięć minut.

Ograniczenie polega na tym, że samo udokumentowanie definicji nie oznacza jej zastosowania. Ktoś i tak w każdym cyklu musi od nowa ustawiać te same pięć filtrów.

Wspólne ograniczenie. Wszystkie trzy metody zakładają, że nazwy zdarzeń są uporządkowane. Gdy po refaktoryzacji kodu to samo działanie wywołuje zdarzenia pod trzema różnymi nazwami, prawdziwym wyzwaniem staje się ich uzgodnienie przed rozpoczęciem jakichkolwiek obliczeń.

Gdzie ręczna metoda zaczyna zawodzić

Przygotowanie pierwszego raportu zajmuje jedno przedpołudnie. Czwartego – znacznie dłużej, ponieważ do tego czasu definicja zdążyła już po cichu ulec zmianie.

Nazwy zdarzeń zmieniają się wraz ze zmianami w produkcie. Zmiana nazwy w kodzie staje się nagłym spadkiem na wykresie, co wygląda dokładnie tak, jakby użytkownicy porzucili daną funkcję. W ten sposób wykres adaptacji funkcji zaczyna raportować zmiany w kodzie, a nie decyzje klientów.

Zmiany w procesie wdrażania zaburzają mianownik. Funkcja trafia do 100% kont, a wskaźnik adaptacji pozornie spada, ponieważ populacja kwalifikujących się użytkowników wzrosła trzykrotnie.

Istnieje również błąd w obliczeniach, który utrzymuje się najdłużej. Sumowanie liczby zdarzeń zamiast unikalnych użytkowników sztucznie zawyża wskaźnik adaptacji za każdym razem, gdy garstka zaawansowanych użytkowników intensywnie korzysta z danej funkcji.

Istnieje jeszcze jeden koszt, który ujawnia się dopiero pod presją czasu. Gdy ktoś pyta: „czy to dobry wynik?”, pojedyncza wartość procentowa nie daje odpowiedzi, a przygotowanie porównania staje się osobnym projektem.

Jak zbudować raport za pomocą Powerdrill Bloom

Krok 1: Prześlij wyeksportowane dane o użyciu

Prześlij wyeksportowane zdarzenia lub pliki zdarzeń i kont razem. Powerdrill Bloom profiluje kolumny zaraz po przesłaniu, dzięki czemu niespójne nazwy zdarzeń i brakujące identyfikatory użytkowników zostaną wykryte przed obliczeniem jakichkolwiek wartości procentowych.

Krok 2: Opisz definicję w języku naturalnym

Określ reguły, zamiast je budować. Podaj nazwę zdarzenia, próg, przedział czasowy oraz to, którzy użytkownicy się kwalifikują.

Następnie zadaj pytania, które pozwolą uniknąć pułapek. Zapytaj, czy któreś z nazw zdarzeń wyglądają na niemal identyczne duplikaty. Zapytaj, ilu unikalnych użytkowników wywołało zdarzenie w porównaniu do łącznej liczby wywołanych zdarzeń oraz jak wskaźnik adaptacji funkcji różni się w zależności od miesiąca rejestracji.

Krok 3: Wyeksportuj wykres, raport lub prezentację

Pobierz trend adaptacji, tabelę z podziałem na segmenty lub slajd zawierający zarówno dane liczbowe, jak i definicję.

Dlaczego to rozwiązanie jest lepsze od tworzenia raportu na nowo w każdym cyklu

	Metoda ręczna	Powerdrill Bloom
Deduplikacja użytkowników na podstawie zdarzeń	Kolumny pomocnicze w każdym pliku	Zapytanie o unikalnych użytkowników
Podział według kohorty lub planu	Połączenie i przebudowanie tabeli	Zapytanie o szczegółowy podział
Zmienione nazwy zdarzeń po wydaniu nowej wersji	Zauważenie tego dopiero później na wykresie	Wykrywane automatycznie przy przesłaniu
Zmiana populacji kwalifikujących się użytkowników	Przebudowanie mianownika	Określenie nowej reguły

Trzeci wiersz to miejsce, w którym decyduje się kwestia dokładności danych. Zmiana nazwy zdarzenia i rzeczywisty spadek wyglądają identycznie na wykresie liniowym, a tylko jedna z tych sytuacji wymaga reakcji ze strony zespołu produktowego.

Najczęstsze błędy

Liczenie zdarzeń zamiast użytkowników. Dziesięć tysięcy zdarzeń wygenerowanych przez dwieście osób to nie adaptacja. Zawsze najpierw przeprowadzaj deduplikację.

Używanie wszystkich zarejestrowanych użytkowników jako mianownika dla funkcji ograniczonej flagą. Jeśli tylko jedna trzecia kont ma do niej dostęp, pozostałe dwie trzecie to nie są osoby, które zrezygnowały z funkcji. Oni po prostu się nie kwalifikują.

Traktowanie jednego kliknięcia jako adaptacji. Pojedyncze zdarzenie podczas wdrożenia to jedynie zapoznanie się z funkcją. Jeśli chcesz, aby ta liczba miała jakiekolwiek znaczenie, wymagaj wielokrotnego użycia w różne dni.

Porównywanie ogólnego wskaźnika na przestrzeni miesięcy. Nowi i dotychczasowi użytkownicy adaptują funkcje w różnym tempie, więc sama zmiana proporcji tych grup wpływa na ostateczny wynik. Przed wyciągnięciem wniosków dokonaj podziału na kohorty.

Ignorowanie zmian nazw zdarzeń. Refaktoryzacja kodu powoduje nagły spadek, który wygląda jak odejście użytkowników. Zanim zaczniesz badać zachowanie użytkowników, sprawdź słownik zdarzeń.

Kopiowanie przedziału czasowego z narzędzia bez sprawdzenia, jak ono działa. Udokumentowane okna retencji często filtrują wyłącznie pierwsze zdarzenie, więc wyniki w arkuszu kalkulacyjnym filtrującym oba zdarzenia będą się różnić.

Raportowanie wartości procentowej bez dołączonej definicji. Liczba ta jest bezużyteczna bez mianownika i progu. Umieść obie te informacje na wykresie, tak samo jak dobry pulpit nawigacyjny KPI etykietuje swoje metryki.

Podsumowanie

Określ populację kwalifikującą się, ustal próg użycia, wyznacz przedział czasowy i przeprowadź deduplikację użytkowników przed wykonaniem dzielenia. Te cztery kroki zamienią wskaźnik adaptacji funkcji w konkretne dane, na podstawie których zespół produktowy może podjąć działania.

Kosztownym elementem jest to, że definicja musi przetrwać zmiany w produkcie. Zmiany nazw zdarzeń i rozszerzenie wdrożenia wpływają na wynik bez konieczności modyfikacji samego raportu przez kogokolwiek.

Jeśli na to właśnie marnujesz czas w swoim cyklu raportowania, wypróbuj Powerdrill Bloom na swoich wyeksportowanych danych o użyciu. Zobacz również nasz przewodnik po tworzeniu wykresu retencji kohortowej, zestawienie narzędzi AI do analityki produktowej oraz stronę asystenta AI do plików CSV.

Najczęściej zadawane pytania

Czym jest adaptacja funkcji?

To odsetek kwalifikujących się użytkowników, którzy użyli danej funkcji w określonym przedziale czasowym, mierzony jako unikalni użytkownicy, a nie liczba zdarzeń. Definicja ta ma sens tylko wtedy, gdy określono mianownik i próg użycia.

Jak obliczyć ten wskaźnik na podstawie wyeksportowanych zdarzeń?

Policz unikalnych użytkowników, którzy wywołali zdarzenie powiązane z funkcją w wybranym przedziale czasowym, a następnie podziel tę liczbę przez liczbę kwalifikujących się użytkowników. Pamiętaj o wcześniejszej deduplikacji, ponieważ jeden użytkownik może wygenerować setki zdarzeń.

Czy mianownikiem powinni być wszyscy użytkownicy, czy tylko aktywni użytkownicy?

Użyj populacji kwalifikującej się, czyli użytkowników, którzy rzeczywiście mieli dostęp do danej funkcji. Uwzględnienie wszystkich zarejestrowanych użytkowników daje zaniżony wynik i nie oddaje rzeczywistej adaptacji funkcji wdrażanej stopniowo za pomocą flagi.

Jak długi powinien być przedział czasowy pomiaru?

Na tyle długi, aby obejmował normalny cykl użytkowania – czyli tygodniowy dla produktów używanych codziennie i miesięczny dla tych używanych okresowo. Zachowaj stały przedział w różnych raportach, ponieważ jego zmiana wpływa na ostateczny wynik.

Dlaczego mój wynik różni się od tego z narzędzia analitycznego?

Zazwyczaj wynika to z przedziału czasowego lub reguły deduplikacji. Udokumentowane obliczenia retencji często nakładają filtr daty wyłącznie na pierwsze zdarzenie, czego nie da się odtworzyć w arkuszu kalkulacyjnym filtrującym oba zdarzenia.