Pytanie stawia się zwykle jako wybór między darmowym narzędziem a płatnym projektem i to jest zła oś. Looker Studio w wersji podstawowej nie ma opłaty za samo narzędzie, a mimo to potrafi wyjść drożej niż własny panel. Koszt raportowania nie siedzi w wykresach, tylko w warstwie danych pod nimi.
Jest jedno pytanie, do którego wraca każda kolejna sekcja: czy wskaźnik, który ma trafić na ekran, da się policzyć sumą kolumny w jednym źródle, czy powstaje ze sklejenia kilku tabel i reguły biznesowej. Od odpowiedzi zależy kwota na wycenie — zakres i ceny dashboardów KPI rozpisaliśmy osobno.
Pięć przystanków liczby, zanim pokaże się na ekranie
Zanim wartość pojawi się na kafelku, mija pięć przystanków. Pierwszy to konektor: Google dostarcza własne do swoich usług, baz SQL i arkuszy, a system spoza tej listy wymaga konektora partnerskiego albo własnej integracji.
Drugi to tryb poświadczeń: źródło można odpytywać danymi właściciela raportu albo danymi widza, a przy poświadczeniach właściciela każdy widz dostaje ten sam zakres. Trzeci to pamięć podręczna i częstotliwość odświeżania — raport pokazuje stan z ostatniego odczytu, więc „na żywo” znaczy „na moment ostatniego zapytania”, a interwał ustawia się przy źródle. Czwarty to pola wyliczane: logika zapisana w raporcie, a nie w danych, działająca na tym, co konektor już wyciągnął. Piąty to sam wykres z agregacją i filtrami.
Skoro dane nie mieszkają w narzędziu, definicja wskaźnika ląduje w polu wyliczanym pojedynczego raportu albo w źródle. Pierwsza droga jest szybsza i kończy się trzema wersjami tej samej formuły w trzech raportach.
Kiedy Looker Studio wystarczy
Warunki są cztery i muszą zachodzić razem: liczby leżą w jednym albo dwóch źródłach z konektorem w standardzie (Arkusze Google, Google Analytics 4, BigQuery), wskaźnik liczy się sumą albo średnią kolumny, wszyscy odbiorcy widzą ten sam zakres, a przegląd jest tygodniowy albo miesięczny. Przy jednym arkuszu i trzech wskaźnikach własny panel jest wydatkiem bez pokrycia w korzyści.
Cztery ściany, o które opiera się raport
Kolejność liczenia. Raport potrafi połączyć dwa źródła po wspólnym kluczu, ale w kolejności, której nie widać: każde źródło najpierw agreguje swoje dane, a dopiero potem następuje złączenie. Marża na zleceniu — koszt materiału z magazynu plus godziny z arkusza brygadzisty — musi zostać policzona wcześniej, poza raportem. Klucz musi też istnieć po obu stronach w tej samej postaci: jeśli w CRM klient nazywa się „Kowalski sp. z o.o.”, a w księgowości identyfikuje go NIP, nie ma czego łączyć bez tabeli mapującej.
Uprawnienia. Udostępnia się raport i źródło, nie wiersz. Podział „handlowiec swoje zlecenia, kierownik oddział” robi się albo osobnymi raportami z zaszytym filtrem — wtedy każda zmiana definicji mnoży się przez liczbę kopii — albo ograniczeniem po stronie źródła, które wie, kto pyta. Do tego raport odświeża się na uprawnieniach osoby, która podpięła źródło — gdy traci ona dostęp do arkusza albo odchodzi z firmy, odświeżanie staje z błędem poświadczeń.
Źródła spoza ekosystemu Google. Drogi są trzy: konektor partnera w abonamencie, konektor napisany samodzielnie albo warstwa pośrednia, do której dane wrzuca integracja. Przy pierwszej sprawdź, czy opłata nalicza się od użytkownika, czy od źródła. Trzecia bywa najtańsza na starcie, ale wtedy to arkusz staje się najsłabszym ogniwem. W tym miejscu zaczyna się spięcie systemu, który nie ma gotowego konektora.
Alert kontra raport. Harmonogram wysyła raport o godzinie, niezależnie od tego, co raport pokazuje. Warunek „gdy marża na kodzie odpadu spadnie poniżej progu, napisz do kierownika oddziału” to inny mechanizm: coś musi sprawdzać dane przy zmianie. Raport pokazuje stan, alert reaguje na zmianę.
Piąta przeszkoda nie jest ścianą narzędzia, tylko właściwością źródła: arkusz, w którym bieżący stan nadpisuje poprzedni, nie odpowie na pytanie „ile mieliśmy zaległych faktur 1 marca”. Historię trzeba dopisywać wierszami, a decyduje się o tym przy budowie warstwy danych.
Co zmienia własny panel
Tu definicja wskaźnika żyje jako widok albo funkcja w bazie, a ekran tylko wykonuje zapytanie. Zakres widoczności rozstrzyga wtedy baza, nie link do raportu: w RAN-SIGMA odpowiada za to mechanizm RLS w Supabase, więc pracownik zewnętrzny nie widzi dokumentów innego działu — tak działa panel kolejki dokumentów z kontrolą dostępu na poziomie wiersza.
Z jednej definicji korzysta zestawienie miesięczne i warunek alertu; w CRM dla Ekohoryzontu jest nim umowa wygasająca w ciągu 30 dni, a dostęp rozkłada się tam na pięć ról z granularnymi uprawnieniami per moduł. Wynik da się rozłożyć na rekordy: dashboard marży według kodu odpadu w systemie RAN-SIGMA ma filtr po miesiącu i oddziale, a eksport wychodzi do Excela i PDF.
Różnica nie polega na tym, że własny panel ładniej rysuje, tylko na tym, że wie, skąd wzięła się liczba. Koszt idzie na bazę i definicje — stąd 8 000–20 000 PLN netto przy wielu źródłach.
Trzecia droga: Looker Studio nad własną bazą
Wybór „narzędzie albo panel” dotyczy warstwy prezentacji, a pieniądze i ryzyko siedzą w warstwie danych. Stąd wariant trzeci: dane odkładają się w bazie, wskaźnik liczy się w widoku, a Looker Studio podpina się konektorem SQL i tylko rysuje.
Reguła, która przesądza o koszcie zmiany
Definicja wskaźnika ma mieszkać w bazie — w widoku albo tabeli wyliczanej — nigdy wyłącznie w polu wyliczanym raportu. Wtedy przejście na własny panel to przepięcie warstwy prezentacji, a nie budowa każdego raportu od nowa.
Ten wariant nie załatwia wszystkiego: role i alerty progowe dalej robi się po stronie bazy albo scenariuszem automatyzacji, w czym pomaga porównanie Make.com, n8n i Zapiera do zasilania warstwy pośredniej. Wgląd w rekordy zależy od tego, co widok wystawi. Gotowe narzędzie wygrywa, dopóki proces mieści się w jego obiektach — to samo wychodzi z porównania systemów CRM, czyli porównanie dedykowanego CRM z HubSpotem, Salesforce i Pipedrive. Stąd kolejność prac: najpierw źródła i definicje, warstwa prezentacji na końcu.
Cztery pytania, które rozstrzygają wybór
Test robi się osobno dla każdego wskaźnika, nie dla firmy. Czy da się go policzyć sumą albo średnią kolumny w jednym źródle? Czy dwie osoby mają widzieć różny zakres tych samych danych? Czy ktoś ma się dowiedzieć w dniu przekroczenia progu? Czy z tej liczby powstaje dokument, na którym ktoś dalej liczy?
Jedno „nie” przy pierwszym pytaniu albo jedno „tak” przy pozostałych przesuwa liczenie do bazy — co nie znaczy, że Looker Studio przestaje być dobrym ekranem. Dlatego w tej samej firmie sprzedaż z arkusza spokojnie w nim zostaje, a rentowność zlecenia nie.
| Zakres | Raport w Looker Studio | Własny panel |
|---|---|---|
| Opłata za narzędzie | brak w wersji podstawowej | brak, koszt jest w projekcie i utrzymaniu |
| Gdzie liczy się wskaźnik | w polu wyliczanym raportu | w bazie, w widoku albo tabeli wyliczanej |
| Źródła spoza Google | konektor partnera albo warstwa pośrednia | integracja po API, bez abonamentu za konektor |
| Uprawnienia | raport i źródło, poświadczenia wspólne dla widzów | zakres wierszy zależny od roli |
| Alert progowy | poza narzędziem, scenariuszem automatyzacji | warunek sprawdzany przy zmianie danych |
| Wgląd w rekordy źródłowe | tyle, ile wystawia źródło | rozwinięcie kwoty do rekordów |
| Eksport | z narzędzia | XLSX, CSV lub PDF na firmowym szablonie |
| Cena netto u nas | od 3 000 PLN — wycena nie zależy od warstwy prezentacji | od 3 000 PLN za dashboard KPI, 8 000–20 000 PLN przy własnej bazie |
Wycenę przesuwa liczba źródeł i to, czy oddają dane na żądanie: analiza zajmuje 3–5 dni, pierwszy widok 5–7 dni.
Najczęstsze pytania o Looker Studio i własne panele
Dlaczego widz raportu widzi wszystko, chociaż udostępniłem mu tylko jeden widok?
Bo liczy się nie to, komu udostępniłeś raport, tylko czyimi danymi odpytywane jest źródło. Przy poświadczeniach właściciela każdy widz dostaje ten sam zakres, niezależnie od tego, kim jest. Zawężenie do osoby wymaga albo osobnych raportów z zaszytym filtrem, albo ograniczenia po stronie źródła, które musi wiedzieć, kto pyta.
Co znaczy, że raport pokazuje dane „na żywo”?
Że pokazuje stan z ostatniego odczytu ze źródła. Narzędzie nie przechowuje danych — pobiera je i zapamiętuje wynik na czas ustawionego interwału. „Na żywo” znaczy więc „na moment ostatniego zapytania”, a odczyt przy każdym otwarciu wymaga źródła, które odpowiada zawsze i szybko.
Dlaczego marży na zleceniu nie da się policzyć w samym raporcie?
Bo złączenie źródeł działa w kolejności, której nie widać: każde źródło najpierw agreguje swoje dane, a dopiero potem następuje połączenie po kluczu. Wskaźnik, który wymaga zestawienia pojedynczych rekordów — koszt materiału i godziny podpięte pod jeden numer zlecenia — musi zostać policzony wcześniej, w bazie albo w tabeli pośredniej.
Skoro narzędzie jest bez opłaty, skąd bierze się koszt wdrożenia?
Z trzech miejsc: z abonamentu za konektor partnerski do systemu, którego Google nie obsługuje, z warstwy, w której trzeba odłożyć dane, gdy źródło nie wytrzymuje odpytywania, i z pracy nad modelem oraz definicjami wskaźników. Ta ostatnia pozycja jest największa i to ona składa się na kwotę od 3 000 PLN netto.
Czy raport wyśle powiadomienie, gdy marża spadnie poniżej progu?
Nie w tym trybie. Harmonogram wysyła raport o ustalonej godzinie, niezależnie od tego, co raport pokazuje. Powiadomienie po przekroczeniu progu wymaga czegoś, co sprawdza dane przy zmianie i dopiero wtedy wysyła wiadomość — taki warunek buduje się obok raportu, po stronie bazy albo w scenariuszu automatyzacji.
Czy da się zacząć od Looker Studio, a później przejść na własny panel bez pisania wszystkiego od nowa?
Tak i zwykle jest to najtańsza kolejność, pod jednym warunkiem: definicje wskaźników siedzą w warstwie danych, w widoku albo tabeli wyliczanej, a nie wyłącznie w polach wyliczanych raportu. Wtedy zmienia się tylko warstwa prezentacji. Gdy formuły żyją w plikach raportów, każdy trzeba zbudować drugi raz.
Aktualizacja: 7 września 2026
Porozmawiajmy o Twoich raportach
Napisz, gdzie dziś leżą liczby, od którego wskaźnika zaczynamy i czy te systemy udostępniają API — tyle wystarczy do pierwszej oceny.