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

Wdrożenie podejścia DataOps – jak ograniczyć wydatki?

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.

Z czego wynikają koszty 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.

Dlaczego raporty z domyślnego eksportu GA4 są drogie?

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?

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.

Wypłaszczanie tabel

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.

Tworzenie tabel w sposób inkrementalny

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.

Partycjonowanie i klasteryzacja

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.

Unified ID i system DataOps

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 optymalizacji

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.

Podsumowanie

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.

The post Jak obniżyć koszt BigQuery? Wszystko przez eksport GA4! first appeared on Conversion.

Branża: Serwis rekrutacyjny
Klient: Grupa Pracuj S.A. (Warszawa, Polska)
Strona: www.pracuj.pl

Punkt wyjścia

Pracuj.pl to największy serwis rekrutacyjny w Polsce, w którym analityka danych odgrywa kluczową rolę w rozwoju produktów, e-commerce oraz działań B2C i B2B. Od lat współpracujemy z klientem w modelu opieki analitycznej, który zakłada stałe wsparcie zarówno w obszarze technicznym, jak i strategicznym.

Taki model współpracy wymaga elastyczności, szybkiego reagowania oraz zdolności łączenia celów biznesowych z zaawansowaną analityką. Naszym zadaniem było zapewnienie ciągłości działań analitycznych i przejęcie odpowiedzialności za cały ekosystem: od GTM, przez GA4, po procesy i rekomendacje wspierające decyzje biznesowe.

Wyzwania

Współpraca w modelu opieki analitycznej odbywa się w dynamicznym środowisku, w którym potrzeby biznesowe często się zmieniają, a zgłoszenia wymagają szybkiej reakcji.

Najważniejsze wyzwania obejmowały:

• wielu interesariuszy po stronie klienta (Ecommerce, Product, B2C, B2B) i konieczność stałej priorytetyzacji zadań,
• szeroki zakres współpracy obejmujący zarówno warstwę techniczną, jak i strategiczną w całym ekosystemie analitycznym,
• dużą liczbę wdrożeń oraz pilnych zgłoszeń typu „asap”.

Kluczowe było wypracowanie procesu, który pozwoli utrzymać tempo prac, jakość danych oraz terminowość realizacji.

Nasze podejście

Pracę oparliśmy na sprawdzonych zasadach, które pozwalają zachować wysoką jakość i przewidywalność działań. Dzięki wieloletniej współpracy bardzo dobrze znamy kontekst biznesowy klienta oraz specyfikę techniczną jego systemów.

Za bieżącą realizację odpowiada zespół kilku analityków, a w razie potrzeby korzystamy ze wsparcia ad hoc innych specjalistów. Przepływ zadań porządkujemy w Jirze, co zapewnia transparentność i jasny ownership.

Co dwa tygodnie wspólnie z interesariuszami porządkujemy backlog pod kątem terminów, złożoności oraz wpływu na wyniki biznesowe. Każde zadanie posiada „ownera” po stronie klienta, a dobra znajomość niestandardowej architektury GTM oraz GA4 pozwala skrócić czas potrzebny na diagnozę i wdrożenia.

Efekty

Dzięki uporządkowaniu procesów i jasno zdefiniowanym zasadom współpracy udało się osiągnąć wymierne efekty:

• regularna i terminowa realizacja ticketów,
• eliminacja opóźnień dzięki jasnemu ownershipowi zadań,
• uporządkowany ekosystem analityczny,
• przejrzysta struktura GTM i GA4,
• zauważalna poprawa jakości danych,
• usprawniona komunikacja pomiędzy zespołami (Ecommerce, Product, B2C, B2B),
• krótszy czas ustaleń i mniejsza liczba zwrotek,
• szybsza reakcja na priorytety biznesowe.

W skrócie, efektem prac była lepsza jakość danych, która przełożyła się na pewniejsze decyzje oraz mierzalny wzrost wyników.

Opinia Pracuj.pl na temat przeprowadzonego projektu

Zdaniem Pracuj.pl, współpraca w ramach opieki analitycznej przełożyła się przede wszystkim na pewniejsze decyzje biznesowe i mierzalny wzrost wyników.

Podsumowanie

Współpraca z Pracuj.pl pokazuje, jak w praktyce wygląda opieka analityczna przy dużej organizacji i wielu interesariuszach.

Stałe wsparcie, jasne procesy oraz bieżąca priorytetyzacja pozwalają skutecznie odpowiadać na potrzeby biznesowe i utrzymywać wysoką jakość danych analitycznych.

The post Pracuj.pl – Uporządkowanie analityki (GA4 + GTM) dla największego serwisu rekrutacyjnego w Polsce first appeared on Conversion.

Branża: Sprzęt komputerowy
Klient: X-kom (Warszawa, Polska)
Strona: www.x-kom.pl

Punkt wyjścia

X-kom to jedna z najbardziej rozpoznawalnych marek e-commerce w Polsce, łącząca sprzedaż online z siecią sklepów stacjonarnych. Skala działalności oraz intensywne działania marketingowe sprawiają, że jakość danych analitycznych ma bezpośredni wpływ na podejmowane decyzje biznesowe.

W momencie rozpoczęcia współpracy zespół X-kom przygotowywał się do uruchomienia kampanii marketingowej, w której kluczowe znaczenie miała możliwość bieżącego monitorowania wyników i reagowania na zmiany w trakcie jej trwania. Warunkiem koniecznym była wysoka precyzja danych zbieranych w Google Analytics 4.

Klient zauważał jednak, że jakość danych eventowych może być obarczona błędami, które utrudniają rzetelną analizę skuteczności działań marketingowych. Potrzebne było szybkie i zdecydowane działanie.

Wyzwania

Główne wyzwania, z jakimi mierzył się zespół X-kom, obejmowały:

• konieczność poprawy jakości danych zbieranych w GA4 przed startem kampanii marketingowej,
• podejrzenie występowania błędów w konfiguracji Google Tag Managera,
• ograniczony czas na analizę i wdrożenie poprawek,
• potrzebę zachowania pełnej spójności danych w trakcie dynamicznych działań marketingowych.

Celem było szybkie zidentyfikowanie problemów oraz wdrożenie rekomendacji, które realnie wpłyną na wiarygodność danych.

Nasze podejście

Nasz zespół rozpoczął współpracę od kompleksowego audytu Google Analytics 4 oraz Google Tag Managera. W ramach prac sprawdziliśmy również poprawność wdrożenia Consent Mode, który ma istotny wpływ na sposób zbierania danych.

Analiza pozwoliła zidentyfikować trzy kluczowe problemy w konfiguracji GTM, które bezpośrednio wpływały na sposób zliczania eventów. Jednym z najważniejszych efektów tych błędów była duplikacja zdarzeń, zaburzająca obraz rzeczywistych zachowań użytkowników.

Wnioski z audytu zostały przez nas uporządkowane i sklasyfikowane pod względem ich istotności biznesowej. Dzięki temu mogliśmy skupić się w pierwszej kolejności na tych elementach, które miały największy wpływ na jakość danych.

Równolegle prowadziliśmy bieżącą komunikację z zespołem X-kom, dokładnie wyjaśniając zidentyfikowane problemy oraz rekomendowane zmiany. Pozwoliło to na szybkie wdrożenie poprawek po stronie klienta.

Efekty

Pierwsze rezultaty współpracy były widoczne bardzo szybko:

• eliminacja problemu zduplikowanych eventów,
• redukcja liczby eventów o 23%,
• zauważalna poprawa jakości danych już kilka dni po rozpoczęciu prac,
• większa precyzja danych wykorzystywanych do oceny skuteczności kampanii marketingowych.

Dzięki szybkiemu wdrożeniu rekomendacji zespół X-kom mógł w pełni skupić się na realizacji kampanii, mając pewność, że dane analityczne stanowią solidną podstawę do podejmowania decyzji.

Opinia X-kom.pl na temat przeprowadzonego projektu

Zdaniem X-kom nasz zespół wykazał się wysokim poziomem profesjonalizmu i sprawnością działania. Pierwsze wnioski z analizy oraz rekomendacje dotyczące poprawek zostały przekazane do X-kom’u już w ciągu 2 dni od uzyskania dostępu do audytowanych narzędzi.

Podsumowanie

Case study X-kom pokazuje, jak istotny wpływ na skuteczność działań marketingowych ma jakość danych analitycznych. Szybki audyt GA4 i GTM, precyzyjna identyfikacja problemów oraz sprawna komunikacja pozwoliły w krótkim czasie przywrócić spójność danych i wyeliminować duplikację eventów, bez ryzyka dla trwających działań biznesowych.

The post X-kom – 23% mniej eventów w Google Analytics dzięki audytowi GA4 i GTM first appeared on Conversion.

Punkt wyjścia

Klient z branży Retail B2B regularnie prowadził badania użytkowników z wykorzystaniem HotJar. Aby lepiej targetować ankiety, agencja marketingowa przygotowała listę kontrahentów opartą na unikalnych ID użytkowników.

Problem pojawił się na etapie wdrożenia tej listy w Google Tag Managerze. Konfiguracja została przygotowana w sposób nieefektywny, zamiast kilku lub kilkunastu zmiennych utworzono aż 64 zmienne.

W praktyce oznaczało to, że każde kolejne badanie lub aktualizacja listy wymagały dużej ilości ręcznej pracy.

Wyzwanie

Główne wyzwanie nie dotyczyło samego uruchomienia ankiet, ale skalowalności całego procesu.

Przy 64 zmiennych każda aktualizacja ID użytkowników wymagała ręcznej modyfikacji wielu elementów w GTM. To powodowało trzy problemy:

• proces był czasochłonny,
• konfiguracja była podatna na błędy,
• GTM był nadmiernie obciążony liczbą zmiennych.

Nawet gdyby limit techniczny narzędzia nie był problemem, sama obsługa takiej konfiguracji pozostawałaby trudna organizacyjnie. Każde kolejne badanie oznaczałoby powtarzalną, ręczną pracę zamiast prostego i skalowalnego procesu.

Nasze podejście

Zaczęliśmy od diagnozy konfiguracji i identyfikacji elementów, które niepotrzebnie komplikowały cały proces.

Następnie zaproponowaliśmy prostsze rozwiązanie, którego celem było ograniczenie liczby zmiennych oraz uporządkowanie sposobu zarządzania listą kontrahentów w GTM.

W ramach projektu:

• przeanalizowaliśmy obecną konfigurację,
• wskazaliśmy, które elementy można uprościć,
• zaproponowaliśmy bardziej efektywny model działania,
• dostosowaliśmy rozwiązanie do cyklicznych badań HotJar,
• wspieraliśmy zespół klienta zarówno technicznie, jak i strategicznie.

Kluczowe było nie tylko naprawienie jednorazowego problemu, ale stworzenie konfiguracji, którą da się łatwo aktualizować przy kolejnych badaniach.

Efekty

Optymalizacja konfiguracji GTM przyniosła trzy konkretne efekty.

Po pierwsze, liczba zmiennych została zmniejszona z 64 do 12. To znacząco uprościło zarządzanie listą kontrahentów i planowanie kolejnych badań.

Po drugie, ograniczono czas potrzebny na aktualizację ID użytkowników. Zespół nie musiał już ręcznie modyfikować dużej liczby zmiennych przy każdej zmianie listy.

Po trzecie, poprawiono wydajność GTM. Mniejsza liczba zmiennych przełożyła się na stabilniejszą konfigurację i łatwiejszą skalowalność badań HotJar.

Co zmieniło się biznesowo?

W projektach analitycznych problemem często nie jest samo wdrożenie narzędzia, ale sposób jego konfiguracji.

W tym przypadku GTM działał, ale konfiguracja była zbyt złożona, trudna w utrzymaniu i podatna na błędy. Redukcja liczby zmiennych z 64 do 12 uprościła proces, zmniejszyła obciążenie operacyjne i pozwoliła klientowi łatwiej skalować cykliczne badania HotJar.

The post Case Study – Jak optymalizacja konfiguracji odblokowała skalowalność badań HotJar? 64 → 12 zmiennych w GTM first appeared on Conversion.

Branża: E-commerce
Klient: Kratki.pl Marek Bal (Polska)
Strona: www.kratki.com

Punkt wyjścia

Kratki.com rozwijało swój sklep internetowy w oparciu o Magento 2.0, z frontendem opartym o technologię PWA (Progressive Web App). W momencie wdrożenia nowego rozwiązania firma potrzebowała poprawnie skonfigurowanej analityki Google Analytics, która pozwoliłaby mierzyć pełną ścieżkę zakupową oraz skuteczność działań marketingowych.

Problem polegał na tym, że w wyniku błędu we wtyczce do Google Tag Managera oraz specyfiki PWA firma traciła dane o co najmniej 10% użytkowników (a w niektórych przypadkach nawet do 70%). Zgodność danych po pierwszej implementacji wynosiła zaledwie około 30%.

Analityka opierała się głównie na Google Ads i Google Analytics, a wykorzystywane metryki ograniczały się przede wszystkim do liczby sesji i nowych użytkowników. Takie podejście było niewystarczające do świadomego zarządzania budżetami SEO i PPC, szczególnie przy ruchu pochodzącym z ponad 12 źródeł oraz sprzedaży prowadzonej na 21 rynkach.

Wyzwania

Najważniejsze wyzwania obejmowały:

• utratę części danych użytkowników w wyniku implementacji PWA,
• brak poprawnie skonfigurowanego śledzenia pełnej ścieżki zakupowej,
• konieczność rozdzielenia ruchu B2B i B2C,
• potrzebę zachowania spójności danych sprzedażowych (waluty, wersje językowe, lokalizacja),
• wybór odpowiedniego modelu atrybucji przy ruchu z wielu źródeł.

Dodatkowym wyzwaniem była migracja do Magento 2.0 oraz integracja analityki z ERP, który stanowił centralne źródło informacji o produktach.

Nasze podejście

Współpracę rozpoczęliśmy od warsztatu biznesowego z udziałem wszystkich kluczowych interesariuszy. Celem było zrozumienie procesów, potrzeb oraz celów biznesowych, a także określenie, jakie dane powinny być dostępne w docelowym ekosystemie analitycznym.

Kolejnym krokiem był szczegółowy audyt dotychczasowej konfiguracji Google Analytics oraz przygotowanie kompleksowego planu tagowania. Dokumentacja obejmowała instrukcje wdrożeniowe, uzgodnienia projektowe oraz przyszłościowe potrzeby raportowe.

Wdrożenie zostało podzielone na sprinty i realizowane etapami według trzystopniowej skali priorytetów. Takie podejście pozwoliło szybko uzyskać pierwsze dane oraz równolegle identyfikować i rozwiązywać problemy związane z technologią PWA.

Oprócz implementacji GA zoptymalizowaliśmy również inne kluczowe kody śledzące, m.in. Google Ads, Ceneo, Hotjar, Piksel Facebook, Pinterest oraz TikTok, aby zapewnić pełniejszy obraz zachowań użytkowników.

Efekty

Wdrożenie nowej architektury analitycznej pozwoliło:

• uszczelnić śledzenie w środowisku PWA i znacząco ograniczyć utratę danych,
• osiągnąć realną zgodność danych użytkowników,
• poprawnie mierzyć pełną ścieżkę zakupową,
• rozdzielić ruch B2B i B2C,
• uzyskać dedykowane widoki dla wszystkich wersji językowych sklepu,
• podejmować decyzje budżetowe w oparciu o wiarygodne dane sprzedażowe i behawioralne.

Dzięki uporządkowanej analityce Kratki.com zyskało przejrzysty wgląd w skuteczność działań marketingowych oraz możliwość świadomego skalowania sprzedaży na kolejnych rynkach.

Opinia Kratki.com na temat przeprowadzonego projektu

Zdaniem Kratki.com współpraca dała im pewność wchodzenia na nowe rynki oraz umożliwiła podejmowanie decyzji w oparciu o rzetelne, rzeczywiste dane.

Podsumowanie

Case study Kratki.com pokazuje, jak duży wpływ na jakość danych ma technologia PWA oraz sposób implementacji narzędzi analitycznych.

Kompleksowy audyt, przemyślany plan tagowania oraz iteracyjne wdrożenie pozwoliły odzyskać kontrolę nad danymi i oprzeć rozwój e-commerce na wiarygodnej analityce.

The post Kratki.com – Uszczelnienie śledzenia w PWA i odzyskanie nawet 70% utraconych danych first appeared on Conversion.