Po co w ogóle łączyć kanały w jednym raporcie

Nie robię tego, żeby zaoszczędzić klientowi klikania po panelach. Robię to dla dwóch rzeczy, których w pojedynczym panelu po prostu nie ma.

Pierwsza to porównywalność w czasie. Każdy panel ma inne domyślne okno atrybucji, inny model zliczania i inną strefę czasową. Dopóki dane siedzą osobno, każda rozmowa o tym, który kanał rośnie, sprowadza się do porównywania rzeczy nieporównywalnych. Wspólny raport wymusza jedną definicję okresu i jedną definicję konwersji dla całego zestawienia.

Druga to widok kosztu całkowitego. Media to nie jedyny wydatek, a bez SEO i treści obraz jest niepełny. Zestawienie płatnych kanałów z ruchem organicznym pokazuje coś, czego nie widać w Google Ads: że część zapytań, za które płacimy, i tak przychodzi z wyników organicznych, a część wzrostu w kampaniach brandowych jest efektem działań, których nikt nie rozliczał.

Trzeci powód jest mniej szlachetny, ale prawdziwy: raport, który powstaje sam, jest raportem, który faktycznie powstaje. Ręczne zestawienia w arkuszu robi się przez trzy miesiące, a potem przestaje.

Skąd wziąć dane: konektory i ich koszty

Tu kończy się demokracja. Google Ads, GA4, Search Console i BigQuery mają w Looker Studio konektory od Google, bezpłatne i całkiem znośne. Meta Ads i TikTok Ads — nie mają, i to jest pierwsza pozycja w kosztorysie takiego raportu.

• Konektory Google — bierz je zawsze, gdy wystarczają. Do Google Ads polecam raczej konektor niż eksport przez API, dopóki nie potrzebujesz danych historycznych sprzed założenia konta w narzędziu.

• Konektory partnerskie do Meta i TikTok — płatne, rozliczane najczęściej od liczby źródeł albo kont. Różnią się nie ceną, a tym, jak radzą sobie z limitami API i jak długo trzymają dane po stronie dostawcy. Zanim wybierzesz, sprawdź w umowie, gdzie te dane fizycznie leżą; przy kliencie z działem prawnym to bywa pytanie rozstrzygające.

• Własny import do BigQuery — najdroższy w budowie i najtańszy w utrzymaniu przy większej liczbie kont. Wybieram go, gdy raport ma żyć dłużej niż rok albo gdy potrzebuję łączyć dane reklamowe z zamówieniami z systemu klienta.

Po stronie SEO mam dwa źródła i oba są niepełne. Search Console pokazuje wyświetlenia i kliknięcia z wyszukiwarki, ale z limitem wierszy i bez pełnego obrazu długiego ogona. GA4 pokazuje sesje organiczne, ale liczy je własną metodą i nie zgodzi się z Search Console nigdy. Nie próbuję ich uzgadniać — pokazuję obok siebie i podpisuję, skąd pochodzi która liczba.

Wspólny model danych, czyli najnudniejsza część

To etap, na którym powstaje albo ginie sensowność raportu, i jednocześnie ten, który klienci najchętniej by pominęli.

Muszę mieć jeden zestaw wymiarów, które znaczą to samo we wszystkich źródłach. W praktyce sprowadzam wszystko do czterech: data, kanał, kampania i typ działania (prospecting, remarketing, brand, sprzedaż produktowa). Kanał i typ działania nie istnieją w żadnym panelu w takiej formie — trzeba je wyprodukować z nazw kampanii.

Dlatego konwencja nazewnicza kampanii jest warunkiem wstępnym, nie ozdobą. Jeśli w Meta kampanie nazywają się „nowa promocja 03″, a w TikTok „test_2″, żadne pole obliczane tego nie naprawi. Zwykle wygląda to tak, że przed budową raportu przez tydzień porządkuję nazwy, i to jest praca, którą trzeba wycenić osobno.

Miary ujednolicam ostrożniej. Koszt i kliknięcia są bezpieczne. Wyświetlenia już nie — definicja wyświetlenia w wyszukiwarce, w feedzie i w krótkim wideo to trzy różne rzeczy, a suma tych trzech liczb nie znaczy nic. Konwersje zostawiam rozdzielone na kanały i nigdy nie sumuję ich w jednej karcie wyniku.

Blending w Looker Studio i jego pułapki

Łączenie źródeł w Looker Studio działa dobrze pod jednym warunkiem: łączysz po kluczu, który faktycznie istnieje w obu tabelach.

Najbezpieczniejszy klucz to data. Zestawienie kosztów z czterech źródeł dzień po dniu jest poprawne i wystarcza do większości pytań o budżet. Kłopot pojawia się, gdy chcesz łączyć po kampanii — nazwy nie pasują, a nawet gdy pasują, jedna tabela ma wiersze, których druga nie ma, i przy niewłaściwym typie złączenia zaczynasz cicho gubić dane.

Dwie rzeczy, które sprawdzam za każdym razem po zbudowaniu złączenia. Po pierwsze, czy suma kosztu w połączonym źródle równa się sumie z każdego źródła osobno — jeśli nie, złączenie coś zjadło albo zdublowało. Po drugie, czy raport zachowuje się poprawnie w dniu bez wydatków w jednym z kanałów; to najczęstszy moment, w którym wykres nagle się rozjeżdża.

Gdy złączeń robi się więcej niż trzy albo pojawiają się liczone udziały procentowe między kanałami, przenoszę logikę do BigQuery i podaję do Looker Studio gotową tabelę. Utrzymanie skomplikowanej logiki w interfejsie raportu to proszenie się o kłopoty przy pierwszej zmianie w źródle.

Czego z takiego raportu nie wolno odczytać

Ta sekcja w moich raportach jest osobną stroną i nie usuwam jej na życzenie.

Konwersje z Google Ads, Meta i TikTok nakładają się. Każda platforma raportuje konwersje wobec własnych kontaktów z użytkownikiem, według własnego okna i własnego modelu. Ta sama transakcja może być policzona w dwóch panelach naraz, a przy udziale trzech kanałów w ścieżce — w trzech. Suma tych kolumn jest zawsze wyższa od rzeczywistej liczby zamówień i nie ma współczynnika, którym można to „skorygować”.

Do tego dochodzi modelowanie. Część konwersji w panelach to wartości modelowane, uzupełniające luki po użytkownikach bez zgody na pomiar albo bez możliwości powiązania sesji. To rozsądne rozwiązanie po stronie platform, ale znaczy, że porównujesz liczby o różnym stopniu pewności.

Dlatego liczbę zamówień i przychód biorę zawsze z jednego źródła prawdy — systemu sklepowego albo CRM — i to ona jest w raporcie mianownikiem. Dane z paneli służą do oceny kanałów względem siebie i do decyzji o budżecie, nie do raportowania sprzedaży.

Struktura raportu, która broni się na spotkaniu

Układam trzy poziomy i pilnuję, żeby nie mieszały się na jednej stronie.

Pierwsza strona odpowiada na pytanie o pieniądze: całkowity koszt mediów, przychód z systemu klienta, udział kosztu w przychodzie, dynamika wobec poprzedniego okresu. Bez podziału na kanały i bez wykresów, które trzeba tłumaczyć.

Druga warstwa to kanały obok siebie — jeden wiersz na kanał, te same cztery kolumny, ta sama definicja okresu. Tu wolno porównywać koszt i ruch, a przy konwersjach zawsze pilnuję podpisu, że dane pochodzą z panelu i się nakładają.

Trzecia warstwa to strony szczegółowe: osobno kampanie w każdej platformie, osobno widoczność organiczna. Na stronie SEO trzymam wyświetlenia, kliknięcia i średnią pozycję z Search Console oraz zestaw najważniejszych zapytań, a od niedawna także wydzielony ruch z asystentów AI — GA4 dostał w tym roku dla niego własny kanał w domyślnej grupie i wreszcie nie muszę tego liczyć na własnym wyrażeniu regularnym.

Wydajność i utrzymanie

Raport, który ładuje się czterdzieści sekund, po dwóch tygodniach przestaje być otwierany.

Trzy rzeczy pomagają najwięcej: krótszy domyślny zakres dat na starcie, mniej złączeń w interfejsie i mniej pól obliczanych na poziomie wykresu. Jeśli mimo tego jest wolno, to sygnał, że logika powinna zejść do warstwy danych, a nie że trzeba usuwać wykresy.

Utrzymanie kosztuje więcej, niż większość osób zakłada. Konektory tracą autoryzację, platformy zmieniają nazwy pól w API, konta reklamowe przechodzą reorganizację, a nazwy kampanii wracają do chaosu przy pierwszej kampanii robionej w pośpiechu. Raz w miesiącu przechodzę cały raport i sprawdzam, czy wszystkie źródła nadal odświeżają się i czy suma kosztu zgadza się z fakturami. To nudne pół godziny, które ratuje wiarygodność wszystkich decyzji podjętych na podstawie tego raportu.

Ostatnia uwaga, bardziej o ludziach niż o narzędziu: raport ma odpowiadać na pytania, które ktoś faktycznie zadaje. Widziałem sporo pięknych pulpitów z dwudziestoma wykresami, do których nikt nie zaglądał, bo odpowiedź na jedno pytanie zadawane co tydzień trzeba było z nich składać samodzielnie.