Wdrożenie podejścia DataOps – jak ograniczyć wydatki?
Z czego wynikają koszty Google BigQuery?
Dlaczego raporty z domyślnego eksportu GA4 są drogie?
Jak obniżyć koszty analizy danych?
Efekty wdrożenia optymalizacji
Podsumowanie
Istnieje jednak skuteczne rozwiązanie. Wdrożenie podejścia DataOps oraz dedykowanego modelu danych pozwala znacząco ograniczyć te wydatki – nawet kilkusetkrotnie. Koszt korzystania z Google BigQuery to jedna z kluczowych kwestii, które warto uwzględnić podczas planowania infrastruktury analitycznej. Eksport danych z GA4 oraz obsługa raportów GA4 za pośrednictwem Google BigQuery mogą znacząco wpłynąć na wysokość wydatków związanych z analizą danych. W tym wpisie opisuję, z czego wynika koszt Google BigQuery, dlaczego eksport danych z GA4 i tworzenie raportów przez BigQuery potrafi generować wysokie koszty oraz jak skutecznie je obniżyć.
Z perspektywy biznesowej zrozumienie struktury kosztów Google BigQuery pozwala lepiej zarządzać wydatkami na utrzymanie infrastruktury analitycznej. W pierwszej części artykułu wyjaśniam, jakie czynniki mają wpływ na wysokość kosztów. W drugiej części przedstawiam praktyczne wskazówki, które pozwalają zoptymalizować wydatki związane z obsługą raportów w Google BigQuery.
Koszt Google BigQuery wynika przede wszystkim z ilości danych przetwarzanych podczas zapytań oraz przechowywania danych. Szczegółowe omówienie tych aspektów znajduje się poniżej. Koszty korzystania z Google BigQuery składają się z dwóch elementów: opłat za przechowywanie danych oraz opłat za wykonywanie obliczeń na tych danych. Na stronie z cennikiem można znaleźć informacje o dostępnych bezpłatnych limitach, jednak są one niewielkie. Wysokość opłat zależy od regionu, w którym dane są przechowywane, a także od ilości i zakresu przetwarzanych danych. Zazwyczaj koszt korzystania z BigQuery jest niski.
Pojawia się jednak pytanie, dlaczego mimo niskich kosztów BigQuery, rachunki za wykorzystanie danych z Google Analytics 4 w raportach Looker Studio mogą być wysokie, zwłaszcza gdy Looker Studio jest połączone z Google BigQuery. Wynika to ze sposobu, w jaki zbudowane jest Google BigQuery. Dane są zorganizowane w strukturze zagnieżdżonych wartości, które trafiają do BigQuery na podstawie tzw. schematów danych. Struktury JSON różnią się od relacyjnych baz danych tym, że wszystkie informacje zapisane są w jednym wierszu, często w postaci zagnieżdżonej. W relacyjnych bazach danych dane są podzielone na oddzielne tabele, na przykład: zdarzenia, sesje, transakcje, produkty. Łączenie tych informacji następuje dopiero podczas tworzenia zapytania, gdzie dane z różnych tabel są łączone na podstawie relacji między nimi. Klucze umożliwiają powiązanie tabel, przykładowo: tabela z użytkownikami pozwala powiązać konkretnego użytkownika z transakcjami i sprawdzić, co kupił w danej transakcji. W kontekście analizy produktów, tablica z użytkownikami posiada klucz ID transakcji. Transakcje zawierają klucze ID produktów, dzięki czemu można pobierać szczegóły dotyczące tych produktów. W Google BigQuery wszystkie dane znajdują się w jednym wierszu. Szukając konkretnej informacji, należy przejść przez wszystkie kolumny danego wiersza, a nie tylko wybraną kolumnę.
Korzystając z domyślnego eksportu Google Analytics 4 do BigQuery, każdą kolumnę pliku JSON trzeba przeszukać, aby znaleźć konkretną informację, na przykład Page Location lub Transaction ID. Taka nieustrukturyzowana tabela, po podłączeniu narzędzi wizualizacyjnych czy narzędzi klasy BI, takich jak Looker Studio czy Power BI, wymaga każdorazowego rozpakowania dużego wiersza podczas zmiany zakresu dat, segmentacji czy filtrowania. Narzędzie musi za każdym razem przetworzyć tysiące rekordów, aby dotrzeć do szczegółowych informacji. Wraz ze wzrostem liczby użytkowników korzystających z tych narzędzi każda zmiana, segmentacja czy analiza raportu powoduje ponowne przetwarzanie i przerzucanie tysięcy danych.
Jak obniżyć koszty analizy danych? Poniżej przedstawiamy, jak podchodzimy do tego w Conversion na podstawie naszego modelu danych.
Nasz model danych został szczegółowo opisany na stronie, a poniżej opisujemy najważniejsze kroki, które pozwalają efektywnie obniżać koszty analiz.
Pierwszym etapem jest wypłaszczanie tabel, czyli tworzenie dedykowanych tabel według określonego schematu. Powstają między innymi tabela sesyjna, transakcyjna, produktowa oraz z użytkownikami.
Drugim krokiem jest tworzenie tych tabel w sposób inkrementalny. Zamiast codziennie przeliczać i generować tabele od nowa, dodajemy jedynie wartości inkrementalne, czyli dane przyrostowe. Zamiast przetwarzać całą historię danych od 2023 roku, przetwarzamy tylko dane z poprzedniego dnia i dopisujemy je do gotowej, wypłaszczonej tabeli.
Kolejnym elementem jest partycjonowanie i klasteryzacja. W naszym przypadku partycją jest data, a klastrem – nazwa eventów. Dzięki takiej organizacji tabel, podczas wyszukiwania wyników z Black Friday, Google BigQuery nie analizuje wszystkich danych, na przykład z lipca, tylko od razu sięga do odpowiedniego segmentu, w którym znajdują się potrzebne dane.
Czwarty element wykorzystywany w naszym modelu danych to Unified ID. Unified ID umożliwia łączenie różnych urządzeń przypisanych do jednego użytkownika w jeden wiersz danych, jeśli użytkownik został rozpoznany. Dzięki temu, podczas analizy danych, nie trzeba płacić za każdy rekord dotyczący trzech czy czterech urządzeń tego samego użytkownika. W praktyce Google BigQuery, korzystając z funkcji lub algorytmu Unified ID, traktuje różne urządzenia jako jednego użytkownika przypisanego do jednego Unified ID. Mniejsza liczba wierszy do przetworzenia oznacza niższy koszt analizy danych. DataOps stanowi kluczowy element strategii konwersyjnej, której Conversion przestrzega od półtora roku. W tej koncepcji analityka przypomina fabrykę. System analityczny działa jak linia produkcyjna, której celem jest generowanie wartościowych insightów biznesowych. Kluczowa staje się wydajność – nie ma potrzeby każdorazowej pracy z nieustrukturyzowanymi danymi.
Efekty wdrożenia DataOps są znaczące. Koszty analizy danych można obniżyć nawet 300-krotnie. Na poniższym przykładzie raportu widać rezultaty, jakie osiągnęliśmy dla klienta po wdrożeniu nowego modelu danych. Poniżej znajdują się założenia raportu. Analizując przypadek klienta, sprawdziliśmy dzienny oraz roczny wolumen danych eksportowanych z GA4 i wyliczyliśmy koszt ich przechowywania. Przeprowadziliśmy symulację dwóch podejść. Pozostając przy surowych danych z GA4, do analizy potrzebowaliśmy 3,17 GB. Natomiast w przypadku tabeli raportowej, wykorzystywanej do kluczowych raportów biznesowych, było to jedynie 11 MB.
Dla wybranych zakresów danych, przy symulacji pięciu zapytań dziennie, roczny koszt analizy surowych danych wyniósł 74 dolary. Z kolei przy analizie opartej na tabelach stworzonych według naszego modelu danych, koszt spadł do 0,25 dolara. Koszty utrzymania Google BigQuery przy rocznej symulacji okazały się ponad 300 razy niższe przy zastosowaniu zoptymalizowanego modelu danych. To jedna z kluczowych korzyści wynikających z wdrożenia naszego modelu danych. Model danych optymalizuje koszty Google BigQuery oraz naprawia dane pod względem atrybucji i źródeł ruchu. W GA4 występują błędy dotyczące tych zagadnień, dlatego agregacja wszystkich danych w jednym miejscu tworzy jedno, wiarygodne źródło prawdy. Model ten optymalizuje również koszt utrzymania systemu raportowania opartego na Google BigQuery. Dodatkowo, monitoruje dane, a w przypadku wykrycia nieprawidłowości w danych serwisu, automatycznie informuje o tym, na przykład za pomocą wiadomości na Slacku.
Model danych zawiera data-produkty, czyli produkty analityczne prezentujące wpływ działań na konkretne KPI oraz dostarczające insajtów dotyczących ich poprawy.
Częstym błędem w firmach jest podłączanie Looker Studio bezpośrednio do surowych danych z eksportu GA4 do Google BigQuery. Gdy coraz więcej osób zaczyna korzystać z tych raportów, koszty Google BigQuery gwałtownie rosną. Można tego uniknąć, wypłaszczając tabele, tworząc je w sposób inkrementalny, stosując klastrowanie i partycjonowanie, a także korzystając z Unified ID. Wszystkie opisane kroki można wykonać samodzielnie lub skorzystać z naszego modelu danych. W przypadku pytań zachęcam do kontaktu.
Tagi:
Historie sukcesów
Ostatnie wpisy na blogu
