Formuły i pola obliczeniowe w Data Studio – kompletny przewodnik z przykładami

Pola obliczeniowe to jedna z tych funkcji Data Studio, które odróżniają prosty raport od narzędzia analitycznego. Bez nich masz statyczne kolumny ze źródła danych – z nimi możesz tworzyć wskaźniki KPI, kategoryzować dane, czyścić tekst i budować logikę warunkową, której nie da się zrobić na wykresie. Problem w tym, że dokumentacja Google jest lakoniczna, przykłady szkoleniowe kończą się na SUM(Revenue), a realne formuły biznesowe wymagają obsługi NULL-i, dzielenia przez zero i zagnieżdżonych warunków.

Ten przewodnik zbiera w jednym miejscu wszystko, co musisz wiedzieć o formułach w Data Studio – od podstaw składni, przez najczęstsze pułapki, aż po 10 gotowych formuł biznesowych, które możesz skopiować i wkleić do swojego raportu.

Czym jest pole obliczeniowe i jak je utworzyć

Pole obliczeniowe (calculated field) to wirtualna kolumna, która nie istnieje w Twoim źródle danych. Tworzysz ją formułą bezpośrednio w Data Studio – może ona łączyć istniejące pola, wykonywać obliczenia matematyczne, przekształcać tekst lub stosować logikę warunkową. Kluczowe: pole obliczeniowe nie modyfikuje danych źródłowych. Działa wyłącznie na poziomie warstwy prezentacji.

Żeby utworzyć nowe pole:

1. Otwórz raport w trybie edycji.
2. Kliknij Zasób > Zarządzaj dodanymi źródłami danych.
3. Przy wybranym źródle kliknij Edytuj.
4. Na dole listy pól kliknij Dodaj pole (niebieska ikona +).
5. Wpisz nazwę pola i formułę. Kliknij Zapisz.

Alternatywnie – możesz utworzyć pole bezpośrednio na wykresie. Kliknij wykres, w panelu właściwości znajdź sekcję wymiarów lub danych, kliknij Dodaj pole. Pole utworzone w ten sposób istnieje tylko w kontekście tego jednego wykresu.

Dwa poziomy: źródło danych vs. wykres

Data Studio rozróżnia dwa miejsca, w których możesz tworzyć pola obliczeniowe – i ta różnica ma realne konsekwencje.

Pole na poziomie źródła danych (data source level) – definiujesz je w edytorze źródła danych. Jest widoczne we wszystkich wykresach, które korzystają z tego źródła. Jeśli zmienisz formułę, zmiana propaguje się do każdego wykresu. Idealne do uniwersalnych wskaźników KPI, które pojawiają się w wielu miejscach raportu.

Pole na poziomie wykresu (chart level) – definiujesz je w panelu właściwości konkretnego wykresu. Istnieje tylko w tym jednym wykresie. Nie jest widoczne w innych wykresach ani w edytorze źródła. Idealne do jednorazowych kalkulacji, eksperymentów i formuł, które mają sens tylko w określonym kontekście.

CASE WHEN – logika warunkowa krok po kroku

CASE WHEN to najpotężniejsza konstrukcja w formułach Data Studio. Pozwala tworzyć nowe kategorie, grupować wartości, nadawać etykiety i budować dowolną logikę IF/ELSE – a wszystko to w jednym polu obliczeniowym.

Składnia podstawowa:

CASE
  WHEN warunek_1 THEN wynik_1
  WHEN warunek_2 THEN wynik_2
  ELSE wynik_domyślny
END

Przykład 1 – grupowanie źródeł ruchu:

CASE
  WHEN REGEXP_MATCH(Source, "google|bing|yahoo") THEN "Wyszukiwarki"
  WHEN REGEXP_MATCH(Source, "facebook|instagram|linkedin") THEN "Social Media"
  WHEN Source = "(direct)" THEN "Bezpośredni"
  WHEN Medium = "email" THEN "Email Marketing"
  ELSE "Inne"
END

Ta formuła zamienia dziesiątki wartości pola Source na 5 czytelnych kategorii. Używam REGEXP_MATCH zamiast serii warunków Source = "google" OR Source = "bing" – jest krócej i łatwiej dodać nowe źródło.

Przykład 2 – scoring leadów:

CASE
  WHEN Liczba_wizyt > 10 AND Czas_na_stronie > 300 THEN "Hot Lead"
  WHEN Liczba_wizyt > 5 THEN "Warm Lead"
  WHEN Liczba_wizyt > 1 THEN "Cold Lead"
  ELSE "Nowy użytkownik"
END

Przykład 3 – kwartał z daty:

CASE
  WHEN MONTH(Data) IN (1, 2, 3)   THEN "Q1"
  WHEN MONTH(Data) IN (4, 5, 6)   THEN "Q2"
  WHEN MONTH(Data) IN (7, 8, 9)   THEN "Q3"
  ELSE "Q4"
END

CASE WHEN można zagnieżdżać – jeden CASE wewnątrz THEN innego. Ale jeśli zagnieżdżenie przekracza dwa poziomy, to sygnał, że logika powinna trafić do BigQuery jako widok SQL, a nie do pola obliczeniowego.

Agregacje i pułapka average of ratios

To najczęstszy błąd w raportach Data Studio – i jednocześnie najtrudniejszy do wychwycenia, bo raport "wygląda dobrze", ale pokazuje złe liczby. Dotyczy każdego wskaźnika, który jest ilorazem dwóch wartości: CTR, CPC, konwersja, średnia cena, ROAS.

Błędna formuła:

Kliknięcia / Wyświetlenia

Dlaczego jest źle? Ponieważ Data Studio najpierw agreguje (sumuje, uśrednia) każde pole osobno, a potem dzieli wyniki. Jeśli masz dwie kampanie – jedną z CTR 10% (1000 kliknięć / 10 000 wyświetleń) i drugą z CTR 1% (10 kliknięć / 1000 wyświetleń) – formuła Kliknięcia / Wyświetlenia z domyślną agregacją AVG policzy (10% + 1%) / 2 = 5,5%. Realne CTR to 1010 / 11 000 = 9,18%. Różnica jest ogromna.

Prawidłowa formuła:

SUM(Kliknięcia) / SUM(Wyświetlenia)

Zasada jest uniwersalna: każdy wskaźnik będący ilorazem musi używać SUM(licznik) / SUM(mianownik). Nigdy nie dziel pól bez jawnej agregacji SUM. To dotyczy CTR, CPC, CPM, ROAS, konwersji, średniej wartości zamówienia – wszystkiego.

Funkcje tekstowe: CONCAT, REPLACE, REGEX

Dane ze źródeł rzadko trafiają do raportu w idealnym formacie. Nazwy kampanii zawierają kody, URLe mają parametry UTM, a nazwy produktów są zapisane wielkimi literami. Funkcje tekstowe pozwalają czyścić i formatować dane bez ingerencji w źródło.

CONCAT – łączenie pól tekstowych:

CONCAT(Miasto, " – ", Region)

Wynik: "Warszawa – Mazowieckie". Przydatne gdy potrzebujesz wymiaru łączącego dwa pola w jednym wierszu tabeli.

REPLACE i REGEXP_REPLACE – zamiana tekstu:

// Proste zastąpienie
REPLACE(Nazwa_kampanii, "PL_", "")

// Z wyrażeniem regularnym – usuń parametry UTM z URL
REGEXP_REPLACE(Strona_docelowa, "\\?.*$", "")

REGEXP_EXTRACT – wyciąganie fragmentów z tekstu:

// Wyciągnij domenę z URL
REGEXP_EXTRACT(URL, "^https?://([^/]+)")

// Wyciągnij kod produktu z nazwy "SKU-12345 – Buty sportowe"
REGEXP_EXTRACT(Nazwa_produktu, "^(SKU-[0-9]+)")

LOWER, UPPER, TRIM – normalizacja:

LOWER(TRIM(Email))  // "  Jan@Firma.PL  " → "jan@firma.pl"

Czyścisz dane na potrzeby grupowania – bez LOWER i TRIM ten sam email pojawi się w raporcie jako dwa osobne wiersze, bo Data Studio traktuje "Jan@Firma.PL" i "jan@firma.pl" jako różne wartości.

Funkcje dat: YEAR, QUARTER, TODATE

Data Studio ma ograniczony, ale wystarczający zestaw funkcji dat. Najczęstsze zastosowania: grupowanie danych po tygodniu/miesiącu/kwartale, obliczanie różnicy czasowej i konwersja formatu.

Wyciąganie składowych daty:

YEAR(Data)       // 2026
MONTH(Data)      // 5
DAY(Data)        // 17
QUARTER(Data)    // 2
WEEK(Data)       // 20 (numer tygodnia w roku)
DAYOFWEEK(Data)  // 7 (niedziela = 1, sobota = 7)

Tworzenie etykiety miesiąca:

CONCAT(
  CAST(YEAR(Data) AS TEXT),
  "-",
  LPAD(CAST(MONTH(Data) AS TEXT), 2, "0")
)
// Wynik: "2026-05"

Użyj LPAD, żeby miesiące jednocyfrowe miały wiodące zero – bez tego sortowanie "2026-1", "2026-10", "2026-11", "2026-2" będzie alfabetyczne zamiast chronologicznego.

TODATE – konwersja tekstu na datę:

TODATE(Pole_tekstowe, "%Y-%m-%d", "%Y%m%d")

Pierwszy argument to pole, drugi to format wejściowy, trzeci to format wyjściowy. Przydatne gdy źródło danych przechowuje daty jako tekst (np. "20260517" z BigQuery partycji).

DATE_DIFF – różnica między datami:

DATE_DIFF(Data_zamknięcia, Data_utworzenia)
// Wynik: liczba dni między datami

Klasyczne zastosowanie: czas cyklu sprzedaży (ile dni od leada do zamknięcia), czas od rejestracji do pierwszego zakupu, wiek konta klienta.

Obsługa NULL i dzielenie przez zero

Dane produkcyjne zawsze mają luki. Puste komórki w arkuszu, brakujące pola w GA4, nieistniejące wymiary w CRM – w formułach Data Studio pojawiają się jako NULL. Jeśli nie obsłużysz NULL-i jawnie, Twój wykres pokaże puste miejsca, a tabele – dziwne agregaty.

IFNULL – zamień NULL na wartość domyślną:

IFNULL(Region, "Brak regionu")
IFNULL(Przychód, 0)

NARY_MAX i NARY_MIN – zwróć większą/mniejszą z wartości:

NARY_MAX(Marża, 0)  // ujemna marża → 0
NARY_MIN(Rabat, 50) // rabat max 50%

Dzielenie przez zero – najczęstsza przyczyna błędów w raportach:

CASE
  WHEN SUM(Wyświetlenia) = 0 THEN 0
  ELSE SUM(Kliknięcia) / SUM(Wyświetlenia)
END

Bez tej ochrony, kampania z zerowymi wyświetleniami wygeneruje błąd dzielenia, a cały wykres przestanie się renderować. Zawsze owijaj ilorazy w CASE WHEN sprawdzający mianownik.

Pełny wzorzec bezpiecznego wskaźnika – łączący obsługę NULL i dzielenia przez zero:

CASE
  WHEN SUM(IFNULL(Mianownik, 0)) = 0 THEN 0
  ELSE SUM(IFNULL(Licznik, 0)) / SUM(IFNULL(Mianownik, 0))
END

10 gotowych formuł biznesowych

Poniższe formuły są gotowe do skopiowania. Zmień tylko nazwy pól na te, które masz w swoim źródle danych.

Kiedy przenieść logikę do BigQuery

Pola obliczeniowe Data Studio mają swoje granice. Nie obsługują JOIN-ów, subquery, tabel lookup, okienkowych funkcji analitycznych ani GROUP BY. Jeśli Twoja logika przekracza którykolwiek z tych progów – pora ją przenieść do BigQuery.

Sygnały, że pole obliczeniowe to za mało:

• Potrzebujesz danych z dwóch źródeł (np. koszt reklamy + przychód z CRM) – blending w Data Studio obsługuje tylko LEFT JOIN i potrafi sypać się przy dużych zbiorach.
• Formuła ma więcej niż 3 zagnieżdżone CASE WHEN – czytelność spada, debugowanie jest niemożliwe.
• Potrzebujesz funkcji okienkowych – running total, ranking, moving average. Data Studio nie ma OVER(PARTITION BY).
• Raport ładuje się ponad 10 sekund – skomplikowane pola obliczeniowe spowalniają rendering, bo przeliczane są przy każdym odświeżeniu.
• Potrzebujesz tabeli lookup – np. mapowania kodu kraju na nazwę regionu. W BigQuery to zwykły JOIN; w Data Studio trzeba budować 50-linijkowy CASE WHEN.

Schemat przenoszenia: Utwórz widok SQL w BigQuery, który wykonuje transformację danych. Podłącz ten widok jako źródło danych w Data Studio. Raport korzysta z gotowych, przeliczonych kolumn – bez żadnych pól obliczeniowych. To szybsze, łatwiejsze do utrzymania i umożliwia testowanie logiki SQL niezależnie od raportu.

-- Widok BigQuery zamiast 10 pól obliczeniowych
CREATE OR REPLACE VIEW `projekt.dataset.raport_kampanii` AS
SELECT
  kampania,
  data,
  SUM(koszt) AS koszt,
  SUM(klikniecia) AS klikniecia,
  SUM(wyswietlenia) AS wyswietlenia,
  SAFE_DIVIDE(SUM(koszt), SUM(klikniecia)) AS cpc,
  SAFE_DIVIDE(SUM(klikniecia), SUM(wyswietlenia)) AS ctr,
  SAFE_DIVIDE(SUM(przychod), SUM(koszt)) AS roas
FROM `projekt.dataset.surowe_dane`
GROUP BY kampania, data

Funkcja SAFE_DIVIDE w BigQuery automatycznie zwraca NULL zamiast błędu dzielenia przez zero – nie musisz pisać CASE WHEN dla każdego ilorazu.

Przenoszenie logiki do BigQuery ma jeszcze jedną zaletę: wersjonowanie. Widoki SQL możesz trzymać w repozytorium Git, przeglądać zmiany i wracać do poprzednich wersji. Pola obliczeniowe w Data Studio nie mają historii zmian – jeśli ktoś nadpisze formułę, stara wersja przepada.