Wpływ interfejsów raportowania Analytics na programy analityczne

W świecie analityki analitycy spędzają dużo czasu w produktach analitycznych, generując raporty. Każdy produkt analityczny ma nieco inne podejście do raportowania. Niektóre produkty analityczne zaczynają się bardziej od pustego płótna i wymagają od analityka przeciągnięcia elementów danych w celu przeprowadzenia analizy. Inne umożliwiają analitykom importowanie danych do arkuszy kalkulacyjnych. Niektóre wymagają użycia języka SQL. Niektóre udostępniają szablony raportów, które pozwalają analitykom wypełnić puste miejsce zdarzeniami i właściwościami. Chociaż żaden interfejs raportowania analitycznego nie jest koniecznie lepszy od innego, ważne jest, aby organizacje wybrały ten, który najlepiej odpowiada ich organizacji i konsumentom danych. Interfejs raportowania może mieć konsekwencje dla programu analitycznego jako całości. W tym poście przedstawię niektóre z interfejsów raportowania analitycznego, które widziałem, oraz ich wpływ na modele i programy dostarczania analityki.

Swobodne raportowanie

Jednym z najpopularniejszych interfejsów raportowania analitycznego jest to, co nazywam raportowaniem w dowolnej formie. W tym interfejsie raportowania analitycy mają puste płótno i mogą przeciągać lub wybierać dane i wymiary. W miarę dodawania elementów danych do kanwy dane mają postać tabeli z kolumnami i wierszami. To podejście zostało spopularyzowane przez narzędzia BI, takie jak Tableau i produkty do analityki cyfrowej, takie jak Adobe i Google Analytics.

Zaletą interfejsów raportowania o dowolnej formie jest to, że masz pełną kontrolę nad strukturą danych, które chcesz analizować. Możesz utworzyć wiele poziomów podziału i często dodawać filtry, aby zawęzić dane według wartości wymiarów. Zaawansowani analitycy lubią ten model, ponieważ zapewnia dużą swobodę i możliwość wykonywania zaawansowanych zapytań bez konieczności znajomości języka SQL.

Raportowanie nakazowe

Innym interfejsem raportowania analitycznego jest raportowanie nakazowe. Model ten zapewnia ramy dla rodzaju wykonywanej analizy i umożliwia analitykom wprowadzanie elementów potrzebnych do uruchomienia raportu. Lubię myśleć o tym modelu jako o podejściu do raportowania typu „wypełnij puste miejsce”. Każdy typ raportu wie, jakiego rodzaju dane, zdarzenia lub wymiary/właściwości są potrzebne, i umożliwia analitykom wybór odpowiednich opcji tworzenia raportu.

Takie podejście może być pod pewnymi względami ograniczające, ale także zapobiega popełnianiu przez analityków zbyt wielu błędów ze względu na swoją strukturę.

Import arkuszy kalkulacyjnych

Bez względu na to, jak zaawansowana jest dziedzina analityki, zawsze znajdą się tacy, którzy po prostu chcą przeprowadzić analizę w arkuszach kalkulacyjnych. Wiele produktów analitycznych zapewnia sposoby pobierania lub eksportowania danych do arkuszy kalkulacyjnych, dzięki czemu analitycy mogą w razie potrzeby manipulować danymi. Arkusze kalkulacyjne, zwłaszcza Microsoft Excel, są zwykle najniższym wspólnym mianownikiem dla analityków. Jednak jedną z wad korzystania z arkuszy kalkulacyjnych jest to, że trudniej jest je udostępniać, współpracować i mogą mieć problemy z kontrolą wersji.

SQL/R/Python

Ci, którzy uważają się za „naukowców danych”, często wolą analizować dane za pomocą SQL lub języków raportowania, takich jak R lub Python. Te interfejsy i języki programowania zapewniają dużą elastyczność i mogą być używane do przeprowadzania niestandardowych i zaawansowanych analiz. Chociaż obecnie coraz więcej odbiorców danych uczy się tych języków, nadal trudno je skalować, zwłaszcza w dużych przedsiębiorstwach.

Wpływ interfejsów raportowania

Tak więc przy wszystkich dostępnych możliwościach przeprowadzania analizy, w jaki sposób organizacje powinny wybrać odpowiedni dla siebie? Jak zwykle nie ma jednej właściwej odpowiedzi, ale poniżej znajdziesz kilka rzeczy, które należy wziąć pod uwagę przy dokonywaniu wyboru. Należy również pamiętać, że wiele organizacji będzie musiało używać więcej niż jednego dla różnych odbiorców wewnętrznych.

Typy konsumentów danych

Większość organizacji ma różne typy konsumentów danych. Często istnieje podstawowy zespół analityków, który codziennie przeprowadza analizy, a są też inni, którzy są bardziej przypadkowymi użytkownikami danych. Przypadkowi użytkownicy danych mogą obejmować kierownictwo lub osoby w firmie, które od czasu do czasu muszą zobaczyć dane, aby móc podejmować decyzje. Przykładem tego ostatniego może być właściciel produktu, który chce zobaczyć tygodniowe lub miesięczne wyświetlenia w witrynie produktów, którymi zarządza.

Potrzeby raportowania podstawowego zespołu analitycznego będą znacznie bardziej zaawansowane niż potrzeby zwykłych użytkowników. Główny zespół analityczny prawdopodobnie będzie chciał dokonać wielu podziałów danych i filtrować dane według wielu wymiarów/właściwości. Dla nich najlepszym rozwiązaniem może być posiadanie interfejsu raportowania w dowolnej formie lub użycie języka programowania. Jednak te zaawansowane interfejsy raportowania często mogą być onieśmielające lub przytłaczające dla osób, które tylko sporadycznie przeprowadzają analizy. Kierownicy mogą chcieć widzieć tylko pulpity nawigacyjne wysokiego poziomu z narzędzia BI.

Ważne jest, aby zrozumieć poziom umiejętności każdego wewnętrznego konsumenta danych i zapewnić każdemu interfejs raportowania, który odpowiada jego potrzebom i uzdolnieniom. Widziałem wiele organizacji, które poniosły porażkę, próbując zastosować podejście „jeden rozmiar dla wszystkich” i zmuszając wszystkich odbiorców danych do korzystania z tego samego interfejsu raportowania analitycznego. W takich sytuacjach główny zespół analityków, który jest bardziej zaawansowany, przyjmuje, że wszyscy odbiorcy danych mogą opanować interfejsy raportowania, które są albo zbyt złożone, albo zbyt mylące dla przypadkowych odbiorców danych. Nawet jeśli bardziej zaawansowane interfejsy raportowania są przeznaczone dla nowszych użytkowników danych, ci ostatni mają trudności z drążeniem danych i znajdowaniem potrzebnych odpowiedzi bez pomocy. Sam próbowałem szkolić przypadkowych konsumentów danych w zakresie zaawansowanych interfejsów raportowania tylko po to, aby zobaczyć, jak mają trudności z ich nauczeniem. W takich przypadkach bardziej pomocne jest udostępnienie wielu interfejsów raportowania analitycznego dostosowanych do odbiorców danych.

Modele dostarczania danych analitycznych

W świecie analityki dostępnych jest kilka modeli przeprowadzania analiz. Niektóre organizacje stosują model scentralizowany, w którym konsumenci danych przesyłają żądania analizy, a analiza jest wykonywana przez scentralizowany zespół. Inne organizacje próbują stosować zdecentralizowane podejście, w którym od każdego oczekuje się przeprowadzenia własnej analizy (często nazywanej demokratyzacją danych). Istnieją również podejścia hybrydowe, które wykorzystują scentralizowany model do niektórych rodzajów analizy i zdecentralizowane podejście do innych (możesz usłyszeć rozmowę na ten temat tutaj). Istnieją plusy i minusy każdego podejścia i jest to kolejna sytuacja, w której różne podejścia będą lepsze lub gorsze dla różnych organizacji.

Ale jedno, co zauważyłem, to to, że błędy popełnione w modelu raportowania mogą negatywnie wpłynąć na model dostarczania analiz. Na przykład wyobraźmy sobie, że Acme Corp, jako organizacja, wybiera do analizy zdecentralizowany model. Ale jednocześnie postanawiają ujednolicić interfejs raportowania danych analitycznych o dowolnej formie. Z biegiem czasu okazuje się, że wielu przypadkowych konsumentów danych ma trudności ze zrozumieniem danych podczas ich implementacji i sposobu ich raportowania. Powoli główny zespół analityków zaczyna otrzymywać e-maile i prośby o pomoc. Na początku mogą nadążyć i pokusić się o dodatkowe szkolenia, ale wkrótce zdają sobie sprawę, że konsumenci danych nie są w stanie samodzielnie się obsłużyć, a liczba żądań staje się przytłaczająca. W tej sytuacji, którą widziałem wiele razy, istniała wyraźna niezgodność między interfejsem raportowania a konsumentami danych, która złamała ogólny model dostarczania analiz. Dlatego uważam, że istnieje bezpośredni i ważny związek między interfejsem raportowania analityki a modelem dostarczania analityki.

Znalezienie idealnego miejsca

W ciągu dwudziestu lat pomagania organizacjom w analityce rzadko spotykałem się z tym, że jeden interfejs będzie działał dla wszystkich typów konsumentów danych i wszystkich modeli dostarczania danych analitycznych. Odnotowałem ograniczony sukces w szkoleniach dotyczących produktów analitycznych dla okazjonalnych konsumentów danych, ponieważ jeśli nie korzystasz zbyt często z narzędzia, trudno jest się tego nauczyć. Myślę, że najlepsze organizacje poświęcają czas, aby zrozumieć swoją kulturę korporacyjną, umiejętności różnych typów konsumentów danych i wykorzystują zarówno interfejs raportowania analitycznego, jak i model dostarczania danych analitycznych. Przeprowadziłem wiele warsztatów i szkoleń z organizacjami, aby pomóc im odkryć, które interfejsy i modele będą dla nich najlepsze. Zachęcam również organizacje do okresowego wypróbowywania nowych interfejsów raportowania dla różnych typów konsumentów danych, aby sprawdzić, czy ktoś „kliknie” nimi częściej niż ten, z którego obecnie korzystają. W firmie Amplitude staraliśmy się stworzyć interfejs raportowania, który byłby łatwy dla okazjonalnych użytkowników danych i jesteśmy dumni z faktu, że w niektórych organizacjach setki osób codziennie samoobsługuje. Dlatego stworzyliśmy łatwe sposoby dla zespołów analitycznych na wykorzystanie pracy wykonanej przez innych dostawców narzędzi analitycznych (Google i Adobe) do wysyłania danych do firmy Amplitude, aby sprawdzić, czy nasz interfejs raportowania może uzupełnić to, czego używa główny zespół analityczny.

W ostatecznym rozrachunku wszystkie organizacje chcą efektywnie wykorzystywać dane i zmniejszać czas potrzebny na przekształcenie danych we wgląd. Wybór odpowiedniego interfejsu raportowania analitycznego dla różnych odbiorców danych to świetny krok w kierunku poprawy ogólnej wartości programu analitycznego.