Zawsze czułem, że dane dotyczące użycia raportu wyciągnięte z Power BI to po prostu za mało. Dane z „usage report” są fajne, ale zagregowane do poziomu dziennego, a Activity logs trzeba przechowywać, bo znikają. Nie da się też wyciągnąć np. użycia slicerów. Możemy zrobić to lepiej!

Pozwól, że przedstawię Ci tracking pixel – rozwiązanie znane i nienawidzone w całym internecie. W skrócie: dodając URL do obrazka o wielkości piksela zmuszamy Power BI do wysłania żądania GET na adres URL, który w pełni kontrolujemy. Zbieramy wszystkie parametry i zwracamy obrazek piksela.

Postawienie serwera WWW, który będzie to obsługiwał, może być kosztowne, ale tutaj możemy po prostu wykorzystać serverless Logic App w Azure. Jest tanie i skalowalne, dając nam pełną kontrolę nad tym, co robimy z danymi.

Konfiguracja storage i zwracanie piksela

Najpierw utwórzmy konto storage na Azure. Będziemy tam zbierać wszystkie dane. To naprawdę najprostsze rozwiązanie do przechowywania, ale zachęcam do eksploracji SQL Server lub innych usług.

Następnie tworzę prostą logic app i zaczynam budować workflow. Pomysł jest prosty: użyjemy wyzwalacza HTTP, który da mi URL z parametrami w środku. Parametry będziemy przekazywać przy użyciu DAX.

Następnie używamy modułu compose, aby zbudować piksel png:

iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQMAAAAl21bKAAAAA1BMVEUAAACnej3aAAAAAXRSTlMAQObYZgAAAApJREFUCNdjYAAAAAIAAeIhvDMAAAAASUVORK5CYII=

to base64 reprezentujący piksel png.

Druga operacja compose konwertuje base64 na binarny:

Skopiuj i wklej: base64ToBinary(outputs('Compose'))

Teraz wszystko jest gotowe, by zwrócić piksel użytkownikowi. Używamy modułu Response. Body to output z Compose 2.

I to już działa! Jeśli wejdziesz w URL z wyzwalacza i wkleisz go w przeglądarce, zobaczysz piksel!

W historii uruchomień zobaczysz także testowe wartości, które zostały podane w URL (zamiast wartości w nawiasach {}).

Zapisywanie danych

Teraz musimy jakoś zapisać te parametry, a może też UserAgent, w storage. Ponownie – jest wiele sposobów, ale stworzenie pliku na Blob to prawdopodobnie najprostsze.

Trzeci moduł Compose wyciągnie UserAgent:

Kod do wklejenia: triggerOutputs()['headers']['User-Agent']

Następnie moduł compose będzie użyty do stworzenia prostego wiersza z wszystkimi danymi. Między elementami dodałem “|”, które posłużą jako delimitery.

Dzięki temu możemy teraz przejść do tworzenia blobu na Blob Storage. Nazwa pliku będzie losowa, aby mieć pewność, że żadne dane nie zostaną nadpisane. Zawartość pobierana jest z Compose 4.

Po odświeżeniu URL w przeglądarce tworzony jest nowy plik:

Power BI

Teraz, gdy backend jest gotowy, czas przejść do tworzenia raportu. Plan jest prosty. Dwie strony, obie z tym samym parametrem what-if na slicerze. Pixel wyciągnie email użytkownika, nazwę raportu, nazwę strony i wartość slicera. Można to zmienić zgodnie z wymaganiami. Jedynym limitem jest DAX, więc sprawdzenie, czy slicery są używane, czy użytkownicy zaznaczają wiele wartości – wszystko to może być śledzone!

Pierwszy krok to stworzenie nowego raportu. Użyjemy „enter data” i stworzymy prostą tabelę. Dodatkowo stworzymy parametr what-if i dodamy slicer na stronę:

Następnie, używając DAX stworzymy URL do Logic App, którą wcześniej przygotowaliśmy. URL wyzwalacza znajduje się w pierwszym bloku aplikacji:

Używając wbudowanych funkcji DAX możemy przekazać zarówno user principal name, jak i wartość parametru do URL:

W “Measure tools” bardzo ważne jest ustawienie Data Category na “Image URL”:

Teraz, gdy dodamy tę miarę do tabeli, Power BI wyśle zapytanie do URL i otrzyma piksel. Przekaże również wszystkie parametry, które zostaną zapisane w blob storage.

Widok ze Storage:

Obraz będzie odświeżany za każdym razem, gdy użytkownik wejdzie w interakcję ze stroną, co naturalnie umożliwia śledzenie użycia raportu na dużo wyższym poziomie szczegółowości. Możliwe jest nawet obliczanie wskaźnika „Bounce rate” – czyli ilu użytkowników zamknęło raport od razu po otwarciu.

Wymaga to jednak pewnej konserwacji. Każda strona musi mieć osobną miarę oraz tabelę z tą miarą, dodaną i ukrytą.

Jak widać w tabeli, można wyciągnąć zdecydowanie więcej danych o sposobie użycia raportu. Nie polecam śledzenia wartości miar, ale użycie funkcji takich jak ISFILTERED() czy HASONEVALUE() może dać cenne informacje o tym, jak raporty są używane. To rozwiązanie może być postrzegane jako dość inwazyjne w niektórych organizacjach, więc proszę potwierdzić podejście z biznesem. Poza tym ograniczeniem jest tylko DAX!

Daj znać, co sądzisz,

Michał