Wspólna analiza Google Ads i Meta Ads: budowa dashboardu w Looker Studio

Wspólny dashboard Google Ads i Meta Ads ułatwia kontrolę łącznych wydatków reklamowych. Połączenie przypisanych konwersji to inne zadanie: obie platformy mogą przypisać sobie ten sam zakup. Złączenie po dacie nie usuwa takiego powtórzenia. Instrukcja rozdziela więc przegląd kosztów od wyraźnie opisanych wskaźników, w których ten sam zakup może być policzony wielokrotnie.

1. Określenie porównywalnych danych dziennych

Konektor Google Ads dostarcza dane Google. Dane Meta mogą pochodzić z wybranego konektora zewnętrznego albo utrzymywanego eksportu. Uprawnienia, obsługiwane pola, odświeżanie i ewentualne opłaty wymagają oceny; ogólne zapewnienie o certyfikacji nie zastępuje kontroli jakości.

W przykładzie każda platforma dostarcza datę, wydatki, jawnie wybraną liczbę zakupów i odpowiadającą wartość zakupów. Ogólne pole Meta Results nie oznacza automatycznie porównywalnej liczby zakupów. Wybór konwersji Google musi również wykluczać inne działania, na przykład zapisy do newslettera. Mapowanie pól API i ustawienia atrybucji należą do dokumentacji źródła.

Wszystkie pola pieniężne, także koszty, wymagają wspólnej waluty i udokumentowanej reguły przeliczenia. Daty potrzebują zgodnej definicji dnia raportowego. Okna atrybucji, uwzględnienie kliknięć i wyświetleń, data konwersji lub interakcji, zwroty i opóźnienia aktualizacji nadal mogą się różnić. Te różnice powinny pozostać widoczne w opisie dashboardu.

2. Jeden wiersz na dzień raportowy

Blend łączy źródła danych w jedną tabelę. Złączenie, czyli join, dopasowuje ich wiersze według wspólnego pola, tutaj daty. Blend najpierw grupuje każde źródło według wybranych wymiarów. Przy porównaniu wyłącznie po dacie tabela każdej platformy powinna więc mieć tylko Datę jako wymiar grupowania oraz dzienne wartości nadające się do sumowania, np. wydatki i liczbę zakupów, a nie dzienne ilorazy. Filtry kont i kampanii są stosowane spójnie przed złączeniem. Dodanie Kampanii przy złączeniu wyłącznie po Dacie może zwielokrotnić dopasowane wiersze i zawyżyć sumy.

Wybór SUM nie usuwa takiego zwielokrotnienia. Natywne metryki Google Ads mogą mieć stałą agregację Auto; wymuszenie SUM w źródle nie zawsze jest możliwe. Kluczowe są wynikowy poziom szczegółowości i rzeczywiste sumy dzienne. W blendzie metryki źródłowe mogą stać się liczbami ponownie agregowanymi przez wykres.

3. Zachowanie dni dzięki kalendarzowi

Looker Studio obsługuje inner, left outer, right outer, full outer i cross join. Ten przykład świadomie wykorzystuje left outer joins z kalendarzem jako pierwszą tabelą. Kalendarz zawiera dokładnie jeden wiersz Daty dla każdego dnia raportowego. Google i Meta łączą się osobno z Datą kalendarza; Meta nie zależy od potencjalnie brakującej daty Google.

Wykres używa daty kalendarza jako wymiaru zakresu dat. Wszystkie trzy tabele wymagają zgodnych typów dat i filtrów. Dzięki temu pozostaje dzień z aktywnością wyłącznie Meta, a także dzień bez aktywności obu platform. Alternatywą jest full outer join między platformami, ale wymaga połączonego pola daty i nie tworzy dni nieobecnych w obu źródłach.

4. Wskaźniki liczone z sum

Poniższe nazwy są aliasami pól liczbowych w zweryfikowanym blendzie dziennym. Każde wyrażenie należy do osobnego pola obliczeniowego na poziomie wykresu; nazwa jest wpisywana oddzielnie. Takie pole nie może odwoływać się do innego pola obliczeniowego na poziomie wykresu, dlatego każdy iloraz powtarza potrzebne wyrażenia.

Łączne wydatki

IFNULL(SUM(Google_Cost), 0) + IFNULL(SUM(Meta_Spend), 0)

Suma przypisanych wartości zakupów podzielona przez wydatki

(IFNULL(SUM(Google_Purchase_Value), 0) + IFNULL(SUM(Meta_Purchase_Value), 0))
/ NULLIF(IFNULL(SUM(Google_Cost), 0) + IFNULL(SUM(Meta_Spend), 0), 0)

Koszt na sumę zakupów przypisanych przez platformy

(IFNULL(SUM(Google_Cost), 0) + IFNULL(SUM(Meta_Spend), 0))
/ NULLIF(IFNULL(SUM(Google_Purchases), 0) + IFNULL(SUM(Meta_Purchases), 0), 0)

IFNULL traktuje brak dopasowanego wiersza jako zero dopiero po potwierdzeniu kompletności źródła i braku aktywności w danym dniu. Awaria konektora albo niepełny eksport musi być pokazany jako brak danych, nie zerowe wydatki. NULLIF zamienia zerowy mianownik na brak zdefiniowanego wyniku; karta powinna pokazać brak wartości, zamiast mylącego zerowego CPA lub ROAS. Edytor formuł wymaga rzeczywistych pól blendu, a nie dowolnie wpisanych etykiet.

5. Weryfikacja przed prezentacją

Tabela dzienna powinna zawierać koszty, liczbę zakupów i wartość zakupów każdej platformy. Sumy źródeł i blendu muszą zgadzać się przy identycznych filtrach oraz okresie. Przydatne przypadki testowe to dzień tylko z Google, dzień tylko z Meta, dzień bez wydatków, dzień bez zakupów oraz granica miesiąca. Zmiana filtrów wymaga tych samych kontroli, ponieważ filtrowanie przed i po złączeniu może dawać różne wyniki.

Górny wiersz może pokazywać łączne wydatki i osobne liczby zakupów platform. Połączone wskaźniki wymagają opisu „zakupy przypisane przez platformy; ten sam zakup może być policzony dwukrotnie”. Czas odświeżenia i oznaczenia niekompletnych źródeł powinny być widoczne. Rzeczywisty przychód firmy albo zdeduplikowany wynik międzykanałowy wymaga danych zamówień, spójnej reguły atrybucji i uzgodnienia danych. Wspólne ID zamówienia samo nie rozstrzyga każdej kwestii atrybucji.