Chcesz zlecić projekt dashboard w Data Studio, ale nie jesteś technicznym specjalistą. Wiesz czego chcesz – raportu który pokazuje wyniki, który działa, który jest bezpieczny. Ale jak zweryfikować czy wykonawca potrafi to zrealizować, skoro sam nie wiesz jak to technicznie wygląda? To problem asymetrii informacji: kupujesz coś, czego nie możesz ocenić przed zakupem. Ten artykuł daje Ci 8 konkretnych pytań, które pozwolą Ci ocenić specjalistę – nawet bez żadnej technicznej wiedzy.
Pytania techniczne – czy naprawdę zna Data Studio?
Te pytania brzmią technicznie, ale nie musisz rozumieć odpowiedzi słowo w słowo. Słuchasz tonu odpowiedzi i tego, czy specjalista myśli o Twoich potrzebach, czy o własnej wygodzie.
Pytanie 1: "Połączysz nasze dane z GA4 przez konektor bezpośredni czy przez BigQuery – i dlaczego?"
To pytanie otwierające, które natychmiast ujawnia poziom specjalisty. Osoba bez głębszego doświadczenia powie "przez konektor GA4, to najprostsze". Osoba z doświadczeniem odpowie: "zależy od skali danych i liczby użytkowników raportu. Konektor bezpośredni jest dobry dla prostych przypadków, ale ma limity zapytań API – przy wielu użytkownikach lub złożonych raportach zaczyna throttlować i spowalniać. BigQuery jako pośrednia warstwa eliminuje ten problem i daje nam historię danych której GA4 konektor nie przechowuje."
Dobra odpowiedź pokazuje znajomość kompromisów, nie tylko jedną ścieżkę. Jeśli specjalista mówi "zawsze BigQuery" lub "zawsze konektor" bez zadania pytania o Twój kontekst – to sygnał braku doświadczenia z różnorodnymi projektami.
Pytanie 2: "Co zrobisz gdy liczby w Data Studio różnią się od tych w GA4?"
Rozbieżności między GA4 a Data Studio to realne zjawisko, z którym zetknie się każdy projekt. Dobry specjalista wie dlaczego to się dzieje: GA4 stosuje sampling (próbkowanie danych) przy złożonych zapytaniach, atrybucja sesji może różnić się w zależności od ustawień strefy czasowej i definicji sesji, a data studio może keszować dane które nie są jeszcze aktualne.
Dobra odpowiedź: specjalista opisuje konkretne przyczyny rozbieżności, metody ich diagnozowania (np. porównanie z surowym eksportem BigQuery) i sposoby minimalizacji (np. unikanie zbyt granularnych wymiarów w jednym widoku, używanie BigQuery zamiast konektora dla danych historycznych). Odpowiedź "to normalne, zawsze tak jest" bez wyjaśnienia – to czerwona flaga.
Pytanie 3: "Jak zabezpieczysz raport żeby nasz manager widział tylko swój region?"
To pytanie o Row-Level Security – jedno z najważniejszych zagadnień bezpieczeństwa w BI. Specjalista powinien opisać podejście oparte o filtrowanie danych na poziomie źródła w oparciu o email zalogowanego użytkownika. Konkretnie: w BigQuery dane mają kolumnę z przypisanym regionem i emailem użytkownika, filtr w Data Studio sprawdza email aktualnie zalogowanej osoby i pokazuje tylko jej wiersze.
Jeśli specjalista odpowiada "dam każdemu dostęp do osobnej kopii raportu" – to rozwiązanie działa, ale nie jest skalowalne. Jeśli nie wie co to Row-Level Security – prawdopodobnie nie realizował projektów z wymaganiami bezpieczeństwa danych.
Pytania o proces i projekt
Pytanie 4: "Pokaż mi case study z podobnej branży"
Portfolio to minimum. Ale samo portfolio bez kontekstu niewiele mówi. Zdjęcie dashboardu może być zrobione przez kogoś innego lub nie odzwierciedlać skali projektu. Proś o case study z opisem: jaki był problem klienta, jakie dane były zaangażowane, co zbudowałem, jaki był efekt.
Dobra odpowiedź zawiera: opis sytuacji wyjściowej (np. "klient miał dane w 4 systemach i eksportował je ręcznie co tydzień"), opis rozwiązania technicznego ("zbudowałem pipeline BigQuery, który łączy te systemy i odświeża dane co 6 godzin") i mierzalny efekt ("czas przygotowania raportu spadł z 8 godzin do 0, bo raport aktualizuje się automatycznie"). Jeśli specjalista nie jest w stanie opisać żadnego projektu w takim formacie – prawdopodobnie nie ma dojrzałego portfolio.
Pytanie 5: "Jak wygląda projekt od briefu do odbioru – ile trwa?"
To pytanie pozwala ocenić dojrzałość procesu wykonawcy. Chaotyczne projekty BI bez zdefiniowanego procesu kończą się opóźnieniami i niezadowoleniem obu stron.
Dobra odpowiedź: specjalista opisuje etapy (odkrycie i briefing → projekt architektury → prototyp → review z klientem → finalna realizacja → szkolenie i odbiór) i orientacyjne ramy czasowe (2–6 tygodni w zależności od złożoności). Ważne: mówi o review z klientem jako osobnym etapie – nie "daję gotowe i tyle", tylko "pokażę prototyp, zbierzemy feedback, dostosujemy".
Pytanie 6: "Kto będzie właścicielem raportu po zakończeniu projektu?"
To pytanie o vendor lock-in. Nieuczciwi wykonawcy pozostawiają raporty przypiętę do swoich kont Google, przez co klient nie może dokonać żadnych zmian bez powrotu do wykonawcy. Dobra praktyka: raport i wszystkie źródła danych są przekazane do konta klienta. Klient jest właścicielem, może edytować, udostępniać, duplikować – bez zależności od wykonawcy.
Dobra odpowiedź: "Raport jest Twój. Przekażę Ci dostęp do wszystkich źródeł danych, dam dokumentację struktury i przeprowadzę szkolenie tak, żebyś mógł samodzielnie zarządzać raportem. Jeśli będziesz potrzebował pomocy – chętnie, ale nie zależy Ci ode mnie operacyjnie."
Pytania o zaawansowane tematy
Pytanie 7: "Co to jest blending i kiedy go używasz zamiast złączenia w SQL?"
Blending danych to funkcja Data Studio pozwalająca łączyć kilka źródeł bezpośrednio w raporcie bez pośredniego BigQuery. Brzmi wygodnie – ale ma istotne ograniczenia, które specjalista powinien znać i umieć wyjaśnić.
Dobra odpowiedź: blending wykonuje tylko LEFT JOIN (nie INNER JOIN ani RIGHT JOIN), obsługuje maksymalnie 5 źródeł naraz, przy dużych wolumenach danych jest znacznie wolniejszy od złączenia SQL w BigQuery, i nie pozwala na zaawansowane transformacje (GROUP BY, subzapytania). Dlatego preferuję łączenie danych w BigQuery i prezentację gotowego widoku w Data Studio – raport jest szybszy i bardziej przewidywalny. Blendingu używam tylko dla małych, prostych przypadków gdzie BigQuery byłby przerostem formy nad treścią.
Pytanie 8: "Jak reagujesz gdy API Google zmienia limity lub konektor przestaje działać?"
To pytanie o odporność systemu i profesjonalizm wykonawcy. Konektory danych mają to do siebie, że zmieniają się bez ostrzeżenia – Google aktualizuje API GA4, zmienia limity zapytań, deprecjonuje pola. Dobrze zaprojektowany system powinien być na to odporny.
Dobra odpowiedź: "Dlatego preferuję architekturę z BigQuery jako buforem – dane są tam przechowywane niezależnie od aktualnego stanu API. Jeśli konektor przestaje działać, dane historyczne w BigQuery są bezpieczne. Do tego konfiguruję alerty monitorujące świeżość danych – jeśli tabela nie odświeżyła się przez X godzin, dostaję powiadomienie zanim klient to zauważy."
Czerwone flagi – kiedy nie zlecać
Pięć sygnałów, które powinny Cię skłonić do rezygnacji ze współpracy:
1. Brak portfolio lub portfolio bez opisu kontekstu. "Oto moje dashboardy" bez wyjaśnienia co stało za każdym projektem – to za mało. Każdy potrafi zrobić zrzut ekranu cudzego raportu.
2. Niemożność wyjaśnienia różnicy między konektorem GA4 a BigQuery. To podstawowa wiedza w projektach BI. Brak znajomości tej różnicy oznacza brak doświadczenia z projektami przekraczającymi poziom hobbystyczny.
3. Wyłącznie rozliczenie godzinowe bez stałej ceny za projekt. Nie jest to automatyczny dyskwalifikator, ale brak umiejętności wyceny zakresu sugeruje brak dojrzałości projektowej. Fixed-price wymaga dobrego planowania – bez tego nie da się go zaproponować.
4. Brak pytań o Twoje dane i odbiorców raportu przed wyceną. Specjalista który wycenia projekt bez zrozumienia kontekstu, wycenia "cokolwiek" – a potem okazuje się, że scope był zupełnie inny.
5. "Zrobię to w 2 dni" dla projektu multi-source. Projekt łączący GA4, Google Ads, CRM i BigQuery z RLS i harmonogramem PDF to minimum kilka tygodni przy zachowaniu jakości. Obietnica "w 2 dni" to albo kłamstwo, albo brak rozumienia zakresu prac.
Jak ocenić odpowiedzi bez technicznej wiedzy
Nie musisz rozumieć technikaliów, żeby ocenić jakość rozmowy. Kilka praktycznych wskazówek:
Dobry specjalista mówi "to zależy". Na każde pytanie o architekturę, narzędzie czy podejście dobra odpowiedź uwzględnia kontekst. "Zawsze BigQuery" lub "zawsze konektor" to sygnał myślenia szablonowego, nie ekspercyjego.
Dobry specjalista zadaje Tobie pytania. Zanim odpowie na Twoje pytania, powinien zapytać: jakie masz dane, ilu masz użytkowników raportu, jakie decyzje ma wspierać. Specjalista który odpowiada bez pytania o kontekst, projektuje rozwiązanie dla siebie, nie dla Ciebie.
Dobry specjalista mówi o problemach, nie tylko o rozwiązaniach. "Blending jest fajny, ale ma swoje limity" to lepsza odpowiedź niż "blending działa świetnie". Ekspert zna pułapki swojego narzędzia i mówi o nich otwarcie.
Dobry specjalista nie obiecuje zbyt wiele zbyt szybko. Jeśli po 10 minutach rozmowy dostajesz ofertę na 5 stron specyfikacji i cenę – coś jest nie tak. Dobra wycena wymaga zrozumienia danych, a to wymaga czasu.
"Wybór specjalisty BI to decyzja o tym, kto będzie wiedział więcej o Twoich danych niż Ty. Warto to zlecić komuś, komu możesz zaufać – nie tylko komuś, kto jest najtańszy."