Tracking | SEO i atrybucja

Zweryfikowanezweryfikowano 2026-08-23

W skrócie

Analityka → Tracking | SEO odpowiada na pytanie, na które nie odpowiadają Raporty: na ile można ufać tym liczbom.

Raporty mówią, ile sprzedano. Tracking | SEO mówi, ile z tego widziała analityka i skąd to przyszło. To dwa różne pytania, dlatego są to dwa ekrany. Okres, e-shop i tryb VAT są przy tym wspólne: przejście między Raportami a Trackingiem niczego nie przestawia.

Ekran ma cztery karty:

Karta	Na co odpowiada
Przegląd	Ile zamówień i ile obrotu uchwycił pomiar.
Kanały	Skąd przyszły zamówienia.
SEO	Jak widzi nas wyszukiwarka.
Zamówienia	Rozbicie na poszczególne zamówienia.

Dwie prawdy, których nie wolno mylić

To najważniejsze rozróżnienie w całej Analityce.

Prawda handlowa to to, co naprawdę zostało sprzedane. Źródłem są zamówienia e-shopu. Według niej liczy się obrót, liczba zamówień i wszystkie wskaźniki finansowe.
Prawda analityczna to to, co uchwycił pomiar w przeglądarce. Jest zawsze mniejsza: część odwiedzających odmawia pomiaru, część go blokuje, a część zamówień w ogóle nie powstaje na stronie.

MitoOps nigdy nie podaje prawdy analitycznej jako handlowej. Obrót w raporcie to zawsze rzeczywisty obrót, nawet jeśli analityka nie wie o części zamówień.

Przegląd

Pokrycie zamówień i pokrycie obrotu

Dwie liczby, które mówią, na ile działa pomiar:

Pokrycie zamówień: z ilu zamówień, przy których można oczekiwać śladu w przeglądarce, analityka faktycznie zarejestrowała transakcję.
Pokrycie obrotu: ile obrotu tych samych zamówień uchwyciła.

Obie są pokazywane także dokładną wartością („82 ze 115”, „8 389 € z 10 851 €”), a nie tylko procentem.

Czego nie wlicza się do pokrycia

Do mianownika trafiają tylko zamówienia, przy których ślad w przeglądarce jest w sposób uzasadniony oczekiwany. Zamówienie utworzone ręcznie nigdy nie zostało klientowi wyświetlone, więc ślad nie mógł powstać; nie jest to brakujący pomiar i nie obniża pokrycia.

Nie liczy się też zamówień młodszych niż 48 godzin: analityka uzupełnia dane wstecz, a świeże zamówienie może jeszcze dotrzeć.

Porównanie e-shopów

Każdy podłączony e-shop ma własny wiersz z pokryciem i stanem pomiaru. Stan jest opisowy, a nie techniczny:

Stan	Co oznacza
W porządku	Pomiar rejestruje zdecydowaną większość zamówień.
Obserwować	Pokrycie spadło, ale nie ma jeszcze powodu do interwencji.
Niewystarczający pomiar	Brakuje istotnej części. Liczby kanałów dla tego e-shopu są niepełne.
Brak danych	Za okres nie ma z czego liczyć.

Progi są wspólne dla całej aplikacji, a nie ustawiane osobno przy każdej tabeli.

Zmiany w czasie

Wykres pokrycia zamówień i obrotu według dni. Brakujący rekord historyczny nie jest rysowany jako zero: dnia bez rekordu po prostu nie ma na wykresie. Zero twierdziłoby, że tego dnia pomiar niczego nie uchwycił, a to inne stwierdzenie niż „wtedy jeszcze nie mierzyliśmy”.

Kiedy ostatnio pobrano dane

Nad liczbami jest wiersz Ostatnia synchronizacja z czasem dla zamówień e-shopu, GA4 i GSC. Służy do jednej rzeczy: do odróżnienia sytuacji „pomiar nie uchwycił zamówienia” od „analityka jeszcze się nie pobrała”. Pierwsze to ustalenie, drugie tylko opóźnienie; bez tej informacji łatwo odczytać drugie jako pierwsze i szukać błędu, którego nie ma. Źródło, które nigdy nie było pobierane, jest oznaczone.

Ostrzeżenie o wyraźnym spadku pokrycia

Gdy pokrycie za ostatni okres wyraźnie spadnie w porównaniu ze zwykłym poziomem, nad liczbami pojawia się ostrzeżenie z obiema wartościami. Nie jest to błąd aplikacji: liczby pod nim są prawidłowe, pochodzą z zamówień e-shopu. Pomiar uchwycił ich mniej, więc podział według kanałów jest za ten okres mniej kompletny. Typowe przyczyny to awaria pomiaru, zmiana zgody na cookies lub przerwany import.

Porównanie odbywa się z medianą poprzednich okresów, a nie ze średnią: jeden zły tydzień obniżyłby średnią tak bardzo, że kolejna awaria nie uruchomiłaby już ostrzeżenia. Okresy z małą liczbą zamówień nie są brane pod uwagę: ostatni dzień bywa niepełny, a jedno nieuchwycone zamówienie z jednego zgłaszałoby awarię codziennie.

Kanały i atrybucja

Pięć warstw

Każde zamówienie należy do dokładnie jednej warstwy. Ich suma to zawsze cały wynik handlowy.

Warstwa	Kiedy należy do niej zamówienie
Zarejestrowane w analityce	Analityka zna transakcję. Kanał jest brany od niej.
Przypisane przez MitoOps	Analityka nie ma transakcji, ale istnieje jednoznaczny dowód: kupon partnera lub kod kampanii przypisany w rejestrze.
Nieprzypisany kod	Znany jest dokładny kod rabatowy, tylko nikt jeszcze o nim nie zdecydował.
Do sprawdzenia	Sygnał istnieje, ale nie jest jednoznaczny, na przykład dwa różne potwierdzone kody na jednym zamówieniu.
Nieatrybuowane	Nie ma żadnego dowodu pochodzenia zamówienia.

Nieprzypisany kod nie znika z zestawienia

Gdy zamówienie użyło kodu BF20, a nikt jeszcze nie zdecydował, co ten kod oznacza, MitoOps i tak zna deterministyczny fakt: zamówienie użyło tego kodu. Dostaje więc własny wiersz

Kod rabatowy · BF20 · znaczek Nieprzypisany

z rzeczywistą liczbą zamówień i obrotem. Nie znika w anonimowej grupie, z której obrotu nie da się prześledzić.

Gdy kod zostanie później przypisany, wiersz przy najbliższym obliczeniu sam zmieni nazwę na Kampania · Black Friday · BF20 lub Affiliate · partner · kod, także wstecz, dla okresów historycznych. Zamówienia nie są przy tym modyfikowane; zmienia się tylko sposób ich odczytu.

Dlaczego nic nie jest szacowane

Brakujące zamówienia nigdy nie są rozdzielane między istniejące kanały według proporcji. Wyglądałoby to na dokładniejsze, a byłoby wymyślone: gdyby awaria pomiaru dotknęła akurat jednego kanału (co po zmianie na stronie zdarza się często), rozliczenie rozmazałoby ją na wszystkie i ukryło dokładnie to, co powinno być widoczne.

Nieatrybuowane zamówienie to prawidłowy wynik, a nie błąd. Celem Trackingu nie jest twierdzenie, że wiadomo wszystko, lecz dokładne oddzielenie tego, co wiadomo, od tego, czego nie wiadomo.

Kiedy MitoOps sam przypisuje zamówienie

Tylko wtedy, gdy ma jednoznaczny ustrukturyzowany dowód, a analityka nie ma transakcji. Kolejność jest stała:

Analityka zna transakcję → kanał należy do niej. Nawet jeśli nie potrafi podać kanału: wtedy jest to Zarejestrowane, kanał nieznany. Kupon na takim zamówieniu go nie nadpisze; w przeciwnym razie to samo zamówienie zostałoby policzone dwa razy z dwoma różnymi pochodzeniami.
Analityka nie ma transakcji, a na zamówieniu jest kupon partnera → Affiliate · nazwa partnera · kod.
Analityka nie ma transakcji, a na zamówieniu jest kod kampanii → Kampania · nazwa · kod.
Kod jest znany, ale nieprzypisany → własny wiersz Kod rabatowy · kod ze znaczkiem Nieprzypisany.
Na zamówieniu są dwa różne potwierdzone kody → Do sprawdzenia.
Brak dowodu → Nieatrybuowane.

Kod rabatowy nie oznacza automatycznie affiliate. Decyduje to, co jest o kodzie zapisane, a nie to, jak wygląda jego nazwa.

Notatki wewnętrzne nie są parsowane

Notatka do zamówienia to wolny tekst pisany przez człowieka. MitoOps nigdy nie wywodzi z niej atrybucji: szukanie nazwy wyrażeniem regularnym to zgadywanie z ładną twarzą. Notatka może pomóc administratorowi przy ręcznej decyzji, ale nie trafia do raportu jako źródło.

Kody rabatowe

Tabela Kody rabatowe pokazuje wszystkie kody, które pojawiły się w okresie na zamówieniach, przypisane i nieprzypisane. Karty nad tabelą przełączają między Wszystkie, Nieprzypisane i Przypisane, a pole wyszukiwania znajdzie kod także według nazwy przypisania. Kod, który zostanie przypisany, nie znika więc z ekranu i można go w każdej chwili odnaleźć wstecz.

Do wyboru jest:

Affiliate: kod partnera,
Kampania: akcja marketingowa,
Wewnętrzny: własny kod obsługi, a nie kanał marketingowy,
Ignoruj: świadoma decyzja o nieprzypisywaniu kodu.

Dopóki decyzja nie zapadnie, zamówienia z takim kodem mają własny wiersz Kod rabatowy · … ze znaczkiem Nieprzypisany: obrót i liczby są rzeczywiste, brakuje tylko przypisania. System może zaproponować przypisanie, ale propozycja nigdy sama nie staje się regułą.

Dwie kolumny, których nie wolno mylić

W tabeli przy każdym kodzie są dwie różne liczby:

Kolumna	Co oznacza
Zamówienia z kodem	Ile zamówień zawierało ten kod.
Przypisane	Ile z nich MitoOps faktycznie przypisał według tego kodu.

Różnią się, ponieważ analityka ma pierwszeństwo. Zamówienie, które analityka widziała, przypisuje analityka według źródła wizyty, nawet jeśli był na nim kupon. W przeciwnym razie to samo zamówienie byłoby w sumach dwa razy.

Przykład z danych produkcyjnych: kod GROUNDING20 był na 5 zamówieniach jednego e-shopu, ale przypisane według niego było 1; pozostałe 4 znała już analityka.

Gdy na jednym zamówieniu jest kilka kodów, zalicza je sobie tylko ten, który wygrał przypisanie. W przeciwnym razie oba twierdziłyby, że to one przyniosły zamówienie.

Własna kategoria atrybucji

Pięć klas powyżej to struktura, a nie lista sposobów rozróżniania własnych źródeł. Kto wysyła newsletter, popup i remarketing, ma trzy różne rzeczy pod jedną nazwą.

W wyborze przypisania jest więc opcja + Własna kategoria…. Okno z nazwą i opcjonalnym kolorem otwiera się od razu po wybraniu: niczego nie trzeba osobno potwierdzać. Gdy okno zostanie zamknięte bez utworzenia, wybór wraca do pierwotnego przypisania; po zapisaniu kategoria pojawia się w ofercie przy każdym kodzie rabatowym, a kod, z którego została utworzona, od razu do niej trafia. W zestawieniu otrzymuje wiersz nazwa kategorii · kod.

Kategoria obowiązuje dla całego konta, a przypisanie działa wstecz: raport za starszy miesiąc wyrenderuje się z takim samym podziałem, ponieważ przypisanie żyje w rejestrze kodów, a nie w zamówieniach. Zmiana nazwy kategorii przejawia się więc także w starych raportach: nazwa nie jest nigdzie kopiowana.

Nazwę można zmienić tam, gdzie się ją wybiera: w wyborze przypisania jest opcja Zarządzaj własnymi kategoriami (pojawia się tylko wtedy, gdy jakaś istnieje). Otwiera okno z listą; przy każdej kategorii jest Edytuj, które zamienia nazwę na pole. Nowa nazwa obowiązuje wstecz dla całego okresu: zamówienia ani obrót się nie zmieniają, a surowe dane z analityki (źródło, medium, strona odsyłająca) nie zmieniają się wcale. Dwie takie same nazwy nie zostaną zapisane: w raporcie powstałyby dwa wiersze, których nikt nie odróżni.

Kategorię, której przestaje się używać, można zarchiwizować (przestaje być proponowana). Nie można jej usunąć, dopóki jest do niej przypisany kod: w przeciwnym razie stary raport nie potrafiłby powiedzieć, do czego zamówienie było przypisane.

Kupony wydane partnerom przez moduł Affiliate tu nie trafiają: są przypisane już przez to, że istnieją.

Wizyty nie są wymyślane

Przy kanale, który powstał z własnego sygnału atrybucji, analityka nie zarejestrowała żadnej wizyty. W kolumnie Wizyty jest więc kreska, a nie zero. Zero twierdziłoby, że nikt nie przyszedł.

AI i modele językowe

Ruch z wyszukiwarek AI (ChatGPT, Claude, Perplexity, Gemini, Copilot, Grok) ma własne wiersze i wspólny wiersz sumaryczny. Wiersz sumaryczny nie jest wliczany do łącznych liczb po raz drugi: to podsumowanie wierszy nad nim, a nie kolejny kanał.

Gdy analityka nie jest podłączona

Bez podłączonej analityki pokrycia nie da się policzyć, a MitoOps mówi to zamiast pokazywać zero.

Zero oznaczałoby „pomiar zawiódł przy każdym zamówieniu”. To coś zupełnie innego niż „pomiar nigdy nie działał” i prowadziłoby do szukania awarii tam, gdzie wystarczy podłączyć konto.

W takim stanie:

pokrycie zamówień i obrotu to kreska, a nie 0 %,
Przegląd Raportów pokazuje Pokrycie trackingu jest niedostępne i proponuje link do podłączenia,
Kanały zawierają ostrzeżenie, że atrybucja jest niepełna,
liczby handlowe pozostają: obrót i liczby zamówień pochodzą z e-shopu i nie są związane z analityką.

To samo dotyczy okresu, za który dane z analityki nie zostały jeszcze pobrane.

SEO

Dane z Search Console: kliknięcia, wyświetlenia, CTR i średnia pozycja, łącznie, według e-shopów i w rozbiciu według zapytań, stron, krajów lub urządzeń.

Do 22.08.2026 ten obszar był w Przeglądzie Raportów. Został przeniesiony tutaj, ponieważ jest to pomiar, a nie wynik finansowy.

Zamówienia

Rozbicie na poszczególne zamówienia: numer zamówienia, e-shop, data, kwota, status i to, czy analityka je uchwyciła.

Bez danych klientów. W tabeli nie ma imienia i nazwiska, e-maila, telefonu ani adresu: atrybucja ich nie potrzebuje, a tabele raportowe ich nie przechowują.

Statusy są takie same jak dotychczas: Wykryta, Wysłana przez serwer, Brak w GA4, Śledzenie nieoczekiwane, Czeka na dane, Nieznany status. Przy ocenie należy patrzeć na Brak w GA4: pozostałe obniżają pokrycie w sposób uzasadniony.

Kolumna Atrybucja

Przy każdym zamówieniu widać, gdzie przypisał je raport: kanał z analityki (Organic, Direct, Paid Google…), własny sygnał (Affiliate · nazwa · kod, Kampania · nazwa · kod, nazwa własnej kategorii · kod), Kod rabatowy · … przy nieprzypisanym kodzie, Do sprawdzenia przy sporze lub Nieatrybuowane.

Pod wartością jest znaczek źródła: GA4, gdy przypisanie ustaliła analityka, nazwa aplikacji, gdy ustalił je własny sygnał, lub bez źródła, gdy przypisania nie ma. Kolumna nazywała się wcześniej Przypisanie (MitoOps), choć wyświetlały się w niej także kanały z analityki; nazwa twierdziła więc coś innego niż zawartość.

Wyszukiwanie na liście

Pole nad tabelą wyszukuje według numeru zamówienia, kodu rabatowego i nazwy atrybucji (a więc także kanału). Wpisanie GROUNDING20, Newsletter lub Direct zawęża listę do odpowiednich zamówień w wybranym okresie.

Według imienia i nazwiska, e-maila, telefonu ani adresu klienta nie wyszukuje się, a ekran ich nie wyświetla: odnalezienie konkretnej osoby należy do Zamówień, a nie do pomiaru.

Jest to wartość wyprowadzona. Zamówienie w e-shopie się przez to nie zmienia i do analityki nic nie jest zapisywane: przypisanie odbywa się tą samą logiką, według której powstają sumy w raporcie, więc lista i sumy nie mogą mówić dwóch różnych rzeczy.

Nazwa partnera affiliate to dana osobowa. Kto ma uprawnienie do Trackingu, ale nie do Affiliate, zobaczy przypisanie bez nazwy; kod pozostaje, więc zamówienie da się odnaleźć. Magazynier ani obsługa klienta w ogóle nie mają dostępu do listy.

Kto ma dostęp

Tracking | SEO jest powiązany z uprawnieniem Tracking i atrybucja, które jest oddzielone od uprawnienia do Raportów i do Kosztów firmy.

Dzięki temu można zbudować rolę, która widzi kanały, atrybucję i SEO, ale nie widzi zysku brutto, cen zakupu ani kosztów firmy. Ustawia się to w Ustawienia → Użytkownicy.

Częste problemy

Pokrycie jest niskie. Warto sprawdzić, ile z tego to Brak w GA4. Zamówienia ręczne i świeże obniżają pokrycie w sposób uzasadniony.
Dużo zamówień jest Nieatrybuowanych. Oznacza to, że nie ma dowodu ich pochodzenia. Pomoże wyższe pokrycie pomiaru lub przypisanie używanych kodów rabatowych.
U partnera zgadza się więcej zamówień niż w raporcie. Zestawienie affiliate i raport kanałów odpowiadają na różne pytania. Gdy analityka zna transakcję, kanał należy do niej: partner może mieć prawo do prowizji, ale druga sprzedaż w raporcie nie powstanie.
Kanał nie ma wizyt. Kanały z własnego sygnału atrybucji nie mają żadnej zarejestrowanej wizyty. Kreska to prawidłowa odpowiedź.
Wykres zmian jest pusty. Za okres nie ma jeszcze rekordów historycznych. Powstają codziennie.