Jak przypisać przychód z reklam do źródła pozyskania użytkownika w aplikacji mobilnej

Kupujesz ruch, zarabiasz na reklamach, a dashboard MMP pokazuje zero przychodu przy każdej kampanii. Zespół UA optymalizuje pod instalacje i retencję. Zespół monetyzacji widzi przychód według sieci, formatu i kraju w dashboardzie mediacji, ale nie według źródła pozyskania. Nikt nie odpowiada na pytanie, od którego zależy budżet na przyszły miesiąc: które kampanie przynoszą użytkowników generujących więcej przychodu z reklam, niż kosztowało ich pozyskanie.

Pomiar oparty na zakupach nie widzi przychodu z reklam

Większość konfiguracji MMP opiera się na zdarzeniach, które aplikacja wysyła sama: install, rejestracja, zakup z ceną. Ad revenue działa inaczej. Użytkownik niczego nie płaci. Przychód to suma wielu drobnych wartości impressions, ustalanych w aukcji wewnątrz warstwy mediacji. Aplikacja nie zna tych wartości, dopóki nie zgłosi ich SDK mediacji.

Jeśli nikt tych wartości nie przekazuje, MMP nie ma czego przypisać. Zero w dashboardzie to nie błąd, tylko brak danych wejściowych. Rozwiązanie polega na połączeniu dwóch źródeł prawdy na poziomie użytkownika: przychodu z mediacji i atrybucji z MMP. O tym, dlaczego sama liczba instalacji nie wystarcza, pisaliśmy w tekście [Nie tylko instalacja: czego zespoły mobile naprawdę potrzebują od pomiaru](/blog/nie-tylko-instalacja-pomiar-mobile).

Impression-level revenue jest podstawą atrybucji według źródła

Platformy mediacyjne udostępniają w SDK callback z przychodem dla każdej impression. AppLovin MAX, AdMob i IronSource mają taki mechanizm. Każdy callback przekaż do MMP jako zdarzenie ad revenue. MMP wie już, z której kampanii przyszedł użytkownik, więc każda impression automatycznie dziedziczy to źródło.

Przekazuj więcej niż samą wartość. Te pola przydadzą się później:

• Wartość przychodu i walutę, dokładnie tak, jak raportuje je SDK mediacji.
• Format reklamy i ad unit, żeby rozdzielić rewarded, interstitial, banner i offerwall.
• Sieć, która wygrała aukcję, żeby porównać źródła popytu w każdej kohorcie pozyskania.
• Flagę precyzji. Platformy mediacyjne oznaczają, czy wartość jest dokładna, szacowana czy zdefiniowana przez wydawcę. Zachowaj to rozróżnienie.

Alternatywą jest alokacja zagregowana. Pobierasz dzienny przychód z API raportowych sieci i dzielisz go między kohorty według udziału w sesjach albo impressions. To działa, gdy nie możesz zmienić SDK. Ale to model, a nie pomiar. Zakłada, że użytkownicy z każdego źródła zarabiają tyle samo na impression, a właśnie to założenie chcesz sprawdzić.

Każdy format reklamowy wymaga osobnego podejścia

Rewarded video i interstitiale

Te formaty dają mniej impressions o wyższej wartości. Przychód zwykle koncentruje się u zaangażowanych użytkowników, więc niewielka grupa może zdominować średnią kohorty. Patrz na rozkład w każdym źródle, nie tylko na średnią. Hipotetyczny przykład: dwie kampanie mają podobny średni przychód na użytkownika, ale w jednej odpowiada za niego garstka graczy, a w drugiej szeroka baza. To dwie różne decyzje budżetowe.

Banery

Odświeżanie banerów generuje dużo impressions o niskiej wartości. Sprawdź, czy konfiguracja MMP obsłuży taki wolumen zdarzeń. Jeśli agregujesz lokalnie w ramach sesji przed wysłaniem, zachowaj atrybuty formatu i sieci.

Offerwall

Przychód z offerwalla pojawia się, gdy użytkownik ukończy ofertę, często jest potwierdzany później po stronie serwera i może zostać cofnięty. Traktuj go jako osobny strumień. Wysyłaj go server-to-server ze stabilnym identyfikatorem użytkownika i akceptuj korekty. Nie mieszaj go z przychodem z impressions w raportach z pierwszego dnia, bo wczesne kohorty będą wyglądać gorzej, niż są.

Ad ROAS w kohortach zamienia atrybucję w decyzję budżetową

Gdy przychód ma przypisane źródło, zbuduj kohorty według daty instalacji i źródła. Porównaj skumulowany przychód z reklam na użytkownika w wybranym dniu z kosztem instalacji. To ad ROAS, często nazywany eROAS. W aplikacjach hybrydowych dodaj do tego samego widoku przychód z zakupów in-app pomniejszony o prowizje sklepów, ale w osobnej kolumnie, żeby każdy zespół widział swoją liczbę.

Okno zwrotu zależy od pionu i rynku. Ustalaj cele na podstawie własnych krzywych, nie branżowych benchmarków.

Na iOS użytkownicy, którzy odmówili zgody w ATT, nie są atrybuowani na poziomie użytkownika. Ich ad revenue trafia do ciebie tylko zbiorczo przez conversion values w SKAN, więc schemat conversion values powinien kodować przedziały przychodu z reklam. Szczegóły opisaliśmy w tekście [SKAN w 2026: praktyczny poradnik pomiaru](/blog/skan-2026-measurement-playbook).

Miejsce pomiaru ad revenue to kwestia umowy z dostawcą

Jeśli oceniasz albo wymieniasz MMP, zadaj cztery pytania. Czy atrybucja ad revenue jest w planie, czy sprzedawana jako dodatek? Które integracje z mediacją są obsługiwane natywnie? Czy ad revenue można wysyłać jako postbacki do sieci reklamowych na potrzeby biddingu pod ROAS? Jak zdarzenia ad revenue liczą się do rozliczenia? Jeśli dziś korzystasz z Adjust, AppsFlyer lub Kochava, zadaj te same pytania swojemu opiekunowi klienta i poproś o odpowiedzi na piśmie.

AdShift mierzy ad revenue w tym samym SDK co atrybucję instalacji i deep linki, w modelu pay-per-conversion zamiast MTU. Niezależnie od wybranej platformy odpowiedzi na te cztery pytania znaczą więcej niż logo. Szerszy kontekst znajdziesz w tekście [Czym jest MMP i jak działa AdShift?](/blog/understanding-mmps-and-adshift).

Atrybucja ad revenue nie naprawi strategii monetyzacji

Attribution dobrze odpowiada na jedno pytanie. Na te nie odpowiada:

• Optymalny ad load. Więcej reklam może podnieść przychód na sesję i obniżyć retencję. Ten kompromis rozstrzygają tylko kontrolowane eksperymenty.
• Wahania eCPM wynikające z sezonowości albo popytu reklamodawców. Atrybucja pokaże je w kohortach, ale im nie zapobiegnie.
• Konfiguracja mediacji. Kolejność waterfalla, ustawienia biddingu i floor prices to osobna praca.
• Wartości szacowane. Jeśli sieć raportuje szacunek, przypisana liczba nadal jest szacunkiem.
• Dane na poziomie użytkownika z iOS dla osób, które nie zgodziły się na śledzenie.

Daje natomiast wystarczająco dużo, żeby przesuwać budżet: widok według źródła, który pokazuje, czy pozyskani użytkownicy zarabiają na swój koszt.