Data governance w analityce internetowej — funkcja, nie projekt z datą końca

Zarząd patrzy na spadek konwersji i pyta, czemu leci sprzedaż. Sprzedaż nie leci. Ktoś tydzień temu zmienił selektor w GTM i połowa transakcji przestała się liczyć. W tym samym czasie marketing rozlicza kampanie na ROAS zawyżonym przez podwójne odpalenia purchase. Trzy działy, trzy różne liczby na to samo pytanie — i nikt, kto w pięć minut powie, która jest prawdziwa.

To nie awaria narzędzia. To brak governance. A w analityce internetowej governance wygląda inaczej niż w klasycznej hurtowni — i większość zespołów podchodzi do tego od złej strony.

Data governance w analityce internetowej to funkcja, nie projekt

Najczęstszy błąd: potraktować data governance jak projekt z datą końca. Wdrożymy tracking plan, spiszemy konwencję nazewnictwa, odhaczymy i wracamy do roboty. Nie. Governance (po polsku: ład danych) to funkcja, która działa tak długo, jak długo zbierasz dane — bo dane psują się codziennie, przy każdym deployu frontu i każdej nowej integracji marketingowej.

Trzy rzeczy odróżniają dane behawioralne od transakcyjnych z ERP i dlatego przenoszą punkt ciężkości:

Nie ma schematu tabeli, jest taksonomia eventów. GA4 to strumień eventów z parametrami. Kontrolujesz nie kolumny w bazie, tylko nazwy eventów i ich parametry — a te trzyma tracking plan, nie baza.
Zbieranie dzieje się w cudzej przeglądarce. Środowisko, w którym powstają dane, nie należy do Ciebie. Deploy frontu, bloker reklam, odmowa zgody — każde z nich obcina kompletność, zanim event zdąży opuścić urządzenie.
Nie ma drugiego podejścia. GA4 trzyma dane na poziomie użytkownika 2 albo 14 miesięcy. Źle otagowany dzień to dane stracone bezpowrotnie — wstecz ich nie przeliczysz.

Wniosek z tych trzech punktów jest przewrotny: governance w web analytics zaczyna się przy zbieraniu danych, nie przy hurtowni. Błąd złapany w Preview mode GTM to minuta pracy analityka. Ten sam błąd odkryty kwartał później — gdy zarząd zdążył już podjąć decyzję na zatrutej liczbie — kosztuje tę decyzję. To ten sam mechanizm, który opisywałem przy fundamencie danych pod AI: model będzie tak dobry, jak dane na wejściu, a governance jest warstwą, która trzyma te dane w ryzach.

Ramą pojęciową jest tu DAMA-DMBOK. Nie musisz wdrażać wszystkich jedenastu obszarów — w web analytics realnie pracują cztery: governance (role i decyzje), jakość danych, metadane (tracking plan) i bezpieczeństwo. Reszta to przerost.

Kto decyduje — role i RACI

Governance bez przypisanej odpowiedzialności to dokument w szufladzie. Trzy role, rozdzielone celowo — bo mieszanie ich to najczęstsza przyczyna paraliżu:

Rola	Kto to	Za co odpowiada
Data Owner (Właściciel Danych)	Senior biznesowy (Head of Analytics / E-commerce)	Decyduje. Zatwierdza polityki, budżet, definicje metryk. Jeden człowiek na domenę
Data Steward (Opiekun Danych)	Analityk / analytics engineer	Wykonuje. Codzienna jakość, tracking plan, egzekwowanie reguł
Data Custodian (Kustosz Danych)	Inżynier platformy	Techniczne zabezpieczenia: IAM, policy tags, retencja, dostępy

Rozdzielenie roli Data Owner, Steward i Custodian brzmi jak biurokracja, dopóki nie zobaczysz, co się dzieje bez niego: analityk sam sobie nadaje dostępy do surowych danych „bo wygodnie”, sam zmienia definicję konwersji i sam ją potem raportuje. Nikt tego nie kontroluje, bo wszystko robi jedna osoba.

Spina to macierz RACI budowana per typ decyzji, nie per osoba. Weźmy duży marketplace — miliony sesji dziennie, dwie strony rynku, wysoka ekspozycja regulacyjna (RODO, DMA). Tam stawka błędu jest na tyle wysoka, że warto to rozpisać wprost:

Decyzja	Owner	Steward	Custodian	IOD	Marketing
Dodanie nowego eventu	A	R	C	—	I
Zmiana definicji „konwersji”	A	R	I	I	C
Dostęp do datasetu BigQuery	A	C	R	I	I
Zmiana w Consent Mode	A	R	C	A	I

(R — wykonuje, A — decyduje, C — konsultowany, I — informowany.)

Świadomie zostawiłem IOD (Inspektor Ochrony Danych) poza dodawaniem eventów. Konsultowanie inspektora przy każdym nowym evencie to przerost — zwykły add_to_cart czy view_item nie dotyka danych osobowych. Inspektor wchodzi (jako C) dopiero wtedy, gdy event ma nieść dane identyfikujące: NIP, nazwę firmy, nazwę merchanta, e-mail. To wyjątek, nie reguła — i w tym cały sens RACI: nie „wszyscy o wszystkim”, tylko właściwa osoba przy właściwej decyzji.

Zwróć uwagę na ostatni wiersz: zmiana w Consent Mode ma dwa „A” — Owner i IOD. To nie błąd. Decyzja techniczna i decyzja prawna spotykają się tu w jednym punkcie, i żadna nie może przejść bez drugiej. W marketplace, gdzie regulator patrzy na ręce, to różnica między „zmieniliśmy tag” a „zmieniliśmy tag i mamy to udokumentowane, zanim ktoś zapyta”.

Tracking plan jako źródło prawdy

Jedna zasada, na której wisi reszta: tracking plan jest źródłem prawdy, nie GTM. Każda zmiana w trackingu wchodzi najpierw do planu, dopiero potem do kontenera. Minimalny rekord planu: nazwa eventu, kiedy się odpala, parametry z typami, które platformy go odbierają, cel biznesowy, właściciel.

Do tego dwie tanie rzeczy, które robią różnicę nieproporcjonalną do wysiłku:

Konwencja nazewnictwa. Spójne prefiksy w GTM (GA4 - Event - Purchase, trigger Event - purchase, zmienna DL - ecommerce.value) i nazwy eventów w snake_case, zgodne z rekomendowanymi eventami GA4 e-commerce. Najtańszy mechanizm governance i najczęściej pomijany.
Specyfikacja data layer — kontrakt między programistami a analityką. Programiści gwarantują strukturę dataLayer.push, analityka gwarantuje, że GTM ją poprawnie czyta. Zmiana struktury = zmiana w planie + powiadomienie obu stron. Bez tego kontraktu każdy deploy frontu to ruletka.

Proces zmiany domyka się schematem, który i tak znasz z pracy z GTM: workspace → test w Preview → wzajemna recenzja (peer review) przy istotnych zmianach → publikacja z notką wersji → aktualizacja dokumentacji. Zasada twarda: żadnej zmiany na produkcji bez śladu w tracking planie.

I tu wraca teza: plan nie jest dokumentem, który raz spisujesz i zamykasz. Bez kogoś, kto go pilnuje po każdym deployu, gnije w tydzień — zostaje Ci artefakt, który kłamie, a to gorsze niż jego brak.

Jakość na wejściu, nie po fakcie

Tu governance przestaje być dokumentem i staje się kodem. Dwa poziomy, które działają razem:

Asercje (Dataform/dbt) — deklaratywne testy jakości. Assertion to zapytanie SQL, które szuka wierszy łamiących regułę; jeśli coś zwróci, test pada i blokuje publikację modelu w dół. Odpala się przy każdym uruchomieniu pipeline’u. Zacznij od transakcji:

-- Jedna transakcja = jeden transaction_id
config { type: "assertion" }
SELECT transaction_id
FROM ${ref("fct_purchases")}
GROUP BY transaction_id
HAVING COUNT(*) > 1

Ten jeden test łapie podwójne purchase — dokładnie te, które zawyżają ROAS i wpuszczają zarząd w maliny. Drugi obowiązkowy to null-check na value i currency. To fundament, od którego zaczynam każdy audyt jakości.

Observability (obserwowalność danych) — monitoring ciągły oparty na uczeniu maszynowym (narzędzia data observability: Monte Carlo, Metaplane, Soda), który łapie to, czego asercje nie przewidziały: nagły spadek wolumenu eventów, zmianę schematu po deployu, opóźnione dane. Różnica jest prosta: asercje sprawdzają znane reguły, observability wykrywa nieznane odchylenia. To krok, który wprowadzasz dopiero gdy skala uzasadnia koszt narzędzia — nie na start.

Asercje w Dataform mają jeszcze jeden efekt, o którym się nie mówi: przenoszą spór o liczby z maili do repo. Gdy definicja „konwersji” żyje w wersjonowanym modelu, a nie w głowie analityka, trzy działy przestają liczyć po swojemu — bo nie mają jak. Testy same tego nie definiują, ale pilnują, żeby to, co wyliczył model, nie rozjechało się po cichu po następnym deployu.

Prywatność — właściciel i proces, nie technikalia

Governance danych behawioralnych spotyka się z prawem w trzech punktach: Consent Mode v2 jako warunek zbierania danych z UE/EOG, zakaz PII (danych osobowych) w GA4 (za naruszenie Google może usunąć dane z całej property) i retencja. Nie będę tego rozwijał — mechanizm zgód i najczęstsze wpadki opisałem przy błędach wdrożenia GA4. Z perspektywy governance liczy się jedno: te decyzje mają właściciela (IOD w RACI) i przechodzą przez proces, a nie dzieją się przy okazji.

Od czego zacząć

Nie odpalasz tego naraz — i nie odhaczasz jak etapów projektu z odbiorem. To kolejność uruchamiania funkcji, którą potem po prostu utrzymujesz. Ustawiłbym ją wg zwrotu z włożonej pracy:

Tracking plan + konwencja nazewnictwa. Grosze roboty, największy zwrot. Fundament, na którym stoi cała reszta.
Consent Mode v2 + CMP. Bez tego tracisz dane z UE/EOG i wchodzisz w ryzyko prawne — tego nie da się odłożyć „na potem”.
Role i RACI. Przypisz Ownera i Stewarda. Inaczej po miesiącu nikt nie pilnuje punktu 1 i wszystko się sypie.
Asercje na krytycznych tabelach. Zacznij od purchase — unikalność i null-check.
Policy tags na kolumnach wrażliwych w BigQuery.
Katalog i lineage (pochodzenie danych) w Dataplex — gdy pipeline rośnie i przestajesz pamiętać, co skąd płynie.
Observability — na końcu, gdy skala uzasadnia koszt narzędzia.

Sygnał, że potrzebujesz tego „na wczoraj”, jest tylko jeden: ktoś na spotkaniu pyta, czemu te dwie liczby się nie zgadzają, a nikt nie umie odpowiedzieć w pięć minut. Jeśli to brzmi znajomo — nie masz problemu z narzędziem. Masz problem z funkcją, której nikt nie pełni. A data governance w analityce internetowej to właśnie ta funkcja — nie projekt, który kiedyś odbierzesz i zamkniesz.