Pomiar konwersji w aplikacji: Jak mierzyć bez łamania RODO i zasad sklepów?

2026-08-14 | devqube

 

W skrócie: Rozjazd między raportem w panelu reklamowym a rzeczywistą sprzedażą ma zwykle trzy przyczyny: część zdarzeń nie dociera, bo SDK działa po stronie klienta; część użytkowników nie wyraziła zgody, więc znika z atrybucji; a część danych, które widzisz, pochodzi z modelu, a nie z pomiaru. Wszystkie trzy da się poprawić bez naruszania prawa, i to zwykle poprawia wyniki. Poniżej: co wolno mierzyć, jak przenieść pomiar na serwer, jak działa modelowanie konwersji i jak zbudować własną bazę danych zamiast polegać na SDK dostawców.

 

 

Gdzie jesteśmy w 2026: co zastąpiło stare metody śledzenia

 

Pomiar konwersji w aplikacji stał się w ostatnich latach jednym z najtrudniejszych wyzwań dla zespołów marketingowych i deweloperskich. Panel Meta pokazuje 340 instalacji z kampanii, Google Ads dokłada swoje, a w bazie masz 210 nowych kont. Ktoś na spotkaniu pyta, która liczba jest prawdziwa, i nie ma dobrej odpowiedzi. Brzmi znajomo?

 

Odruch jest taki, żeby szukać winy w kreacjach albo w sezonowości. A ta zwykle leży gdzie indziej. Od 2021 roku pomiar w aplikacjach mobilnych przestał być czynnością techniczną i stał się serią decyzji o tym, co wolno zebrać, od kogo i jaką drogą. Prawda jest taka, że spora część zespołów nigdy tych decyzji świadomie nie podjęła. Bo zostały podjęte za nich…przez domyślne ustawienia bibliotek.

 

Zacznijmy zatem od uporządkowania faktu, który w różnych, ogólnodostępnych źródłach wciąż krąży w nieaktualnej wersji.

 

Third-party cookies nie zniknęły. 22 kwietnia 2025 Google ogłosiło, że zostawia dotychczasowy model w Chrome. 17 października 2025 wycofało większość programu Privacy Sandbox, który miał je zastąpić, w tym Topics, Protected Audience, Attribution Reporting API oraz dwie propozycje androidowe: SDK Runtime i Protected App Signals. Powodem była niska adopcja. Zostały CHIPS, FedCM i Private State Tokens.

 

To było sześć lat przygotowań do zmiany, która…nie nastąpiła.

 

Dla Ciebie, z punktu widzenia pomiaru kampanii ma to jedną konsekwencję: nie ma jednej technologii, która rozwiąże ten problem (i obserwując rynkowe trendy, nie zapowiada się, żeby to się w najbliższym czasie zmieniło). Czyli innymi słowy nie przyjdzie nowy standard, który przywróci stary poziom widoczności. To, co działa dziś, to cztery osobne źródła danych, które (niestety) trzeba złożyć samemu:

 

Pomiar konwersji w aplikacji: Jak mierzyć bez łamania RODO i zasad sklepów?

 

W aplikacji mobilnej ciasteczek zresztą nigdy nie było. Cała dyskusja dotyczyła stron internetowych. W appce liczy się co innego: identyfikator reklamowy urządzenia, zgoda ATT i to, kiedy dokładnie odpalają się Twoje biblioteki.

 

 

Co faktycznie wolno mierzyć: RODO, Apple i Google

 

Zastrzeżenie: To nie jest porada prawna. Przed zmianami warto pokazać to prawnikowi, najlepiej razem z wytycznymi EROD 2/2023, które tłumaczą, dlaczego przepis o ciasteczkach dotyczy aplikacji.

 

Z góry zaznaczam, że to mocno uproszczona warstwa prawna, jakiej potrzebujesz do poprawnego mierzenia danych.

 

Obowiązują Cię trzy niezależne zestawy reguł.

 

  • Prawo (RODO oraz dyrektywa ePrivacy, w Polsce wdrożona jako art. 399 Prawa komunikacji elektronicznej) wymaga zgody przed odczytem lub zapisem czegokolwiek na urządzeniu użytkownika, w tym identyfikatora reklamowego.
  • Apple wymaga zgody ATT, zanim sięgniesz po IDFA albo połączysz swoje dane z danymi innych firm.
  • Google Play wymaga deklaracji w formularzu Data Safety i używania AAID zamiast innych trwałych identyfikatorów w celach reklamowych.

 

Kluczowa rzecz do zapamiętania: okno ATT nie jest zgodą w rozumieniu RODO, tylko wymogiem regulaminowym Apple. Zgodę prawną musisz zebrać osobno i osobno udokumentować.

 

Co zbierasz lub robisz Czy wymaga zgody prawnej Czy wymaga ATT Co z Google Play
Identyfikator reklamowy (IDFA, GAID) Tak, przed odczytem Tak, na iOS Używaj AAID, zadeklaruj w Data Safety
Własny identyfikator instalacji Tak, chyba że jest niezbędny do działania usługi Nie, dopóki nie łączysz z danymi innych firm Zadeklaruj jako „Device or other IDs”
Fingerprinting urządzenia Tak, choć sam w sobie jest ryzykowny Zakazany regulaminem niezależnie od zgody Niezgodny z polityką
Adres e-mail podany przy rejestracji Tak, na cel marketingowy osobno Nie, dopóki zostaje u Ciebie Zadeklaruj kategorię danych
Ten sam e-mail wysłany do Meta lub Google Tak, i potrzebna osobna podstawa Tak, Apple wymienia to jako przykład trackingu Podlega polityce reklamowej
Zdarzenia produktowe bez identyfikatora reklamowego Tak, jeśli cokolwiek zapisujesz na urządzeniu Nie Zadeklaruj kategorię
Dane łączone wyłącznie na urządzeniu, bez wysyłki na zewnątrz Tak, ale to najłagodniejszy przypadek Nie. Apple wprost wyłącza to z definicji trackingu Zależy od kategorii

 

Ostatni wiersz jest ważniejszy, niż na pierwszy rzut oka się wydaje (i wrócimy do niego w części o modelowaniu atrybucji).

 

Jeszcze jedna zasada, o której (co do zasady) mało kto wie, a potrafi zaskoczyć przy audycie App Review: Apple traktuje jako tracking samo umieszczenie w aplikacji cudzego SDK, które łączy Twoje dane z danymi z aplikacji innych deweloperów w celach reklamowych, nawet jeśli Ty z tej funkcji nie korzystasz. Czyli w praktyce…jest spora szansa, że odpowiadasz za to, co robi cudzy kod w Twoim produkcie.

 

 

Przeniesienie pomiaru na serwer: co zyskujesz i jak to działa

 

To jest najbardziej niedoceniana zmiana, jaką możesz wprowadzić, i jednocześnie ta, która najszybciej zwraca się w wynikach.

 

Na czym polega problem

 

Domyślnie Twoje zdarzenia lecą do Meta i Google prosto z urządzenia, przez SDK wbudowane w aplikację. Ta droga ma trzy słabe punkty. Zdarzenie ginie, gdy użytkownik zamknie aplikację w złym momencie albo straci zasięg. Nie masz kontroli nad tym, co dokładnie SDK wysyła, bo to cudzy kod. I nie masz jak sprawdzić stanu zgody przed wysyłką, bo decyzja zapada wewnątrz biblioteki.

 

Na czym polega rozwiązanie

 

Zdarzenia wysyłasz ze swojego serwera, przez API. Meta nazywa to Conversions API i ma osobną wersję dla zdarzeń aplikacyjnych, z parametrem action_source ustawionym na app. Zdarzenia trafiają do tak zwanego datasetu, czyli tego, co kiedyś nazywało się Pixel ID.

 

Pomiar konwersji w aplikacji: Jak mierzyć bez łamania RODO i zasad sklepów?

 

 

 

Co konkretnie zyskujesz:

 

  • Kontrolę nad zgodą. Serwer sprawdza w Twojej bazie, czy użytkownik wyraził zgodę, zanim cokolwiek wyśle. To jest jedyne miejsce, w którym możesz to zrobić naprawdę wiarygodnie.
  • Kompletność zdarzeń. Konwersja zapisana w Twojej bazie dotrze do Meta niezależnie od tego, co w tym momencie robi telefon użytkownika.
  • Wzbogacenie danych. Do zdarzenia dokładasz to, co masz w bazie, a czego SDK nie widzi: wartość zamówienia po zwrotach, status subskrypcji, przynależność do segmentu.
  • Jeden punkt integracji. Meta pozwala przez jeden endpoint wysyłać zdarzenia webowe, aplikacyjne, offline’owe i z komunikatorów.

 

Na co uważać

 

Deduplikacja jest obowiązkowa. Jeśli zostawisz SDK i dołożysz CAPI, Meta policzy każdą konwersję dwa razy, a Ty podejmiesz decyzje budżetowe na zawyżonych liczbach. Deduplikację robi się przez wspólne event_id przekazywane w obu ścieżkach. Meta stosuje ten sam mechanizm dla aplikacji, co dla stron, i wymaga go wobec wszystkich istniejących integracji zdarzeń aplikacyjnych, w tym SDK i MMP.

 

Dane osobowe trzeba hashować. Adres e-mail i numer telefonu muszą być znormalizowane i zahaszowane algorytmem SHA-256 przed wysyłką. Uwaga na typowe nieporozumienie: hashowanie nie zmienia statusu prawnego tych danych. Zahaszowany e-mail to nadal dane osobowe i nadal potrzebujesz podstawy do jego przekazania.

 

Hashowanie chroni dane w tranzycie, nie zwalnia z obowiązków.

 

Meta udostępniła w kwietniu 2026 uproszczoną konfigurację CAPI bez udziału dewelopera. Jest to wersja podstawowa: jeśli potrzebujesz decydować, które zdarzenia lecą i z jakimi parametrami, zostaje integracja bezpośrednia.

 

 

Modelowanie konwersji: co robi Google z użytkownikami bez zgody

 

Tu jest miejsce, w którym najłatwiej o pomyłkę, więc rozłóżmy to na dwa różne mechanizmy.

 

 

Consent Mode v2 to sposób, w jaki mówisz Google, na co użytkownik się zgodził. Cztery parametry: analytics_storage, ad_storage, ad_user_data, ad_personalization. Obowiązuje reklamodawców kierujących do Europejskiego Obszaru Gospodarczego od 6 marca 2024. W aplikacji ustawia się je przez Firebase, w wersjach minimum 21.5.0 na Androidzie i 10.17.0 na iOS.

 

Idea jest taka: użytkownik bez zgody nie znika z systemu, tylko zamiast danych zidentyfikowanych wysyłane są sygnały bez identyfikatorów. Google zna więc liczbę zdarzeń bez zgody i zna pełne dane zdarzeń ze zgodą. Na tej podstawie szacuje, ile konwersji ukrywa się w grupie bez zgody, i dopisuje je do raportu.

 

Trzy rzeczy, które musisz o tym wiedzieć. To jest oszacowanie, a nie pomiar; w raporcie widzisz konwersje, których nikt nie policzył. Model potrzebuje danych do nauki, więc przy małym ruchu może nie działać wcale. I najważniejsze: jeśli nie wdrożysz Consent Mode, nie dostaniesz nic. W EOG przestaje wtedy działać raportowanie konwersji do optymalizacji, budowanie i targetowanie list remarketingowych oraz raportowanie demograficzne. Danych z okresu bez sygnałów nikt nie odtworzy wstecz.

 

Mechanizm drugi: pomiar na urządzeniu i ICM

 

To jest nowsze i o wiele mniej znane. Integrated Conversion Measurement (ICM) to protokół Google dla kampanii aplikacyjnych, wdrażany od maja 2025 wspólnie z dostawcami pomiaru. Działa na pomiarze na urządzeniu: sygnały konwersji są przetwarzane lokalnie na telefonie i agregowane, zanim cokolwiek wyjdzie na zewnątrz.

 

I tu wraca ostatni wiersz tabeli z poprzedniej sekcji. Apple wprost wyłącza z definicji trackingu sytuację, w której dane są łączone wyłącznie na urządzeniu i nie opuszczają go w formie identyfikującej. Cały pomiar na urządzeniu jest zaprojektowany wokół tego zdania, dlatego działa u użytkownika, który odmówił zgody ATT.

 

ICM obejmuje trzy grupy uznawane wcześniej za stracone: użytkowników iOS bez zgody ATT, użytkowników Androida z EOG i wszystkich, którzy wyłączyli śledzenie na poziomie systemu. Na Google Marketing Live w maju 2026 Google zapowiedziało rozszerzenie zasięgu na EOG, Wielką Brytanię i Szwajcarię oraz objęcie ścieżek web-to-app i konwersji obejrzeniowych.

 

Praktyczna uwaga: ICM włącza się po stronie MMP i SDK, nie w panelu Google Ads. Jeśli Twój dostawca pomiaru tego nie obsługuje albo nikt nie włączył pomiaru na urządzeniu, po prostu tego nie masz.

 

 

First-party data: pięć miejsc w aplikacji, gdzie zbierasz dane naturalnie

 

Wszystko powyżej dotyczy tego, jak lepiej przekazać dane, które masz. Ta sekcja jest o tym, jak mieć ich więcej, nie naruszając niczyjego zaufania.

 

Zasada jest jedna i warto ją zapamiętać: Zbieraj dane tam, gdzie użytkownik i tak coś robi, i tam, gdzie widzi, co z tego ma. Wszystko inne to formularz, który psuje konwersję i generuje śmieciowe rekordy.

 

  • Rejestracja i logowanie. Najbardziej oczywiste i najczęściej zmarnowane. Zbierasz e-mail, ale nie zbierasz zgody marketingowej jako osobnej, dobrowolnej opcji, więc później nie możesz tego adresu użyć. Rozdziel zgodę na konto od zgody na marketing i zapisz obie z datą.
  • Onboarding z pytaniem o cel. Ekran typu „czego szukasz w aplikacji” z trzema kafelkami. Użytkownik dostaje spersonalizowany start, ty dostajesz segment na pierwszej sesji. To najlepszy stosunek wartości do tarcia w całej aplikacji.
  • Ustawienia powiadomień. Zamiast jednego przełącznika daj wybór kategorii. Dostajesz mapę preferencji, a przy okazji wyższy opt-in na powiadomienia, bo użytkownik nie musi godzić się na wszystko naraz.
  • Pierwsza transakcja lub pierwsze kluczowe działanie. Moment najwyższego zaufania w całej relacji. Tu pytasz o dane rozszerzające profil, na przykład o branżę albo wielkość firmy w produkcie B2B.
  • Zachowanie w produkcie. Nie pytasz o nic, tylko obserwujesz: które funkcje są używane, jaka jest częstotliwość powrotów, gdzie ludzie odpadają. To dane, których żadna sieć reklamowa ci nie da, i to one najlepiej przewidują wartość klienta.

 

Etyczne minimum przy każdym z tych pięciu punktów: powiedz, po co pytasz, pozwól pominąć, nie blokuj funkcji za zgodę marketingową. Ostatnie nie jest tylko kwestią przyzwoitości; zgoda wymuszona nie spełnia przesłanki dobrowolności i prawnie nie istnieje.

 

 

Jak połączyć własne dane z kampaniami Meta i Google

 

Zebrane dane trzeba uruchomić, bo inaczej są tylko kosztem przechowywania.

 

Customer Match w Google Ads

 

Wgrywasz listę zahaszowanych adresów e-mail lub numerów telefonów, Google dopasowuje je do kont użytkowników i tworzy z tego grupę odbiorców. Możesz do niej kierować reklamy, wykluczać ją albo używać jako sygnału do szukania podobnych osób.

 

Praktyczne parametry z polityki Google: lista ma maksymalny okres członkostwa 540 dni, a żeby pozostała aktywna, musi mieć co najmniej 100 członków dodanych lub zaktualizowanych w tym okresie. Dane muszą być zahaszowane algorytmem SHA-256. Konto musi spełniać wymogi dotyczące historii zgodności z politykami. W przypadku list opartych na identyfikatorach mobilnych uwzględniani są tylko użytkownicy aktywni w sieciach Google w ciągu ostatnich 30 dni.

 

Jedna zmiana techniczna do przekazania działowi IT: od 1 kwietnia 2026 stare usługi API do wgrywania list nie działają dla nowych integracji i Google kieruje do Data Manager API.

 

Conversions API w Meta

 

Ta sama logika, ale zamiast list odbiorców wysyłasz zdarzenia, opisane w poprzedniej sekcji. Zdarzenia aplikacyjne trafiają do datasetu i są przetwarzane tak samo jak te z SDK czy od MMP, z obowiązkową deduplikacją.

 

Warunek, który unieważnia wszystko powyżej

 

Do jednego i drugiego potrzebujesz podstawy prawnej na przekazanie danych konkretnie tym firmom. Zgoda na „przetwarzanie danych w celach marketingowych” wpisana ogólnikowo w regulamin sprzed trzech lat najprawdopodobniej nie wystarczy. Google wymaga tego wprost we własnej polityce zgody użytkowników z UE dla partnerów wgrywających listy.

 

To jest miejsce, gdzie rozmowa z prawnikiem realnie się opłaca, bo dotyczy jednego akapitu w twoim ekranie zgody, a decyduje o tym, czy możesz w ogóle korzystać z Customer Match.

 

 

Kolejność, w której to wszystko musi się uruchamiać

 

Zostaje jedna rzecz, bez której poprzednie sekcje nie zadziałają, i jest to najczęstszy błąd wdrożeniowy w aplikacjach.

 

Biblioteki analityczne startują przy uruchomieniu aplikacji, bo tak wygląda domyślna instrukcja instalacji. Ekran zgody jest elementem interfejsu i pojawia się kilka ekranów później. Kolejność wychodzi odwrotna do zamierzonej i nic tego nie sygnalizuje, bo nic się nie psuje.

 

Poprawna kolejność:

 

pomiar konwersji w aplikacji - poprawne kroki

 

Krok 2 jest pomijany najczęściej i wymaga jednej rzeczy od Twojego dewelopera. Google podaje cztery klucze do pliku info.plist, zaczynające się od GOOGLE_ANALYTICS_DEFAULT_ALLOW_, i pisze w dokumentacji wprost, że domyślnie żadne wartości zgód nie są ustawione. Nie ma domyślnej odmowy. Bez tych kluczy cały mechanizm zgód jest jedynie “ozdobą.”

 

Jak to wygląda w przypadku Androida?

 

W systemie Android odpowiednikiem ustawień z iOS jest plik AndroidManifest.xml. Wewnątrz znacznika <application> należy dodać analogiczne tagi <meta-data>, przypisując im wartość false. Dopiero po wywołaniu w kodzie metody setConsent() z wartościami wybranymi przez użytkownika, SDK na obu platformach bezpiecznie przełączy status zgód z DENIED na GRANTED.

 

Krok 3 przed krokiem 4 to nie chwyt marketingowy, tylko warunek świadomości zgody. Osoba, która nie wie jeszcze, do czego służy aplikacja, nie ma jak ocenić, czy chce się zgodzić. Przy okazji ta kolejność podnosi wskaźnik zgód, bo pytanie pada wtedy, gdy użytkownik już widzi wartość.

 

Gdy użytkownik wycofa zgodę na analitykę lub dane reklamowe, Google Analytics usuwa wszystkie właściwości użytkownika, w tym zapisaną zgodę na personalizację reklam. Trzeba ją potem przywrócić osobnym wywołaniem.

 

 

Jak samodzielnie sprawdzić, czy aplikacja wysyła dane przed zgodą? Wystarczy 15 minut

 

Podłącz urządzenie testowe do narzędzia przechwytującego ruch sieciowy, zainstaluj świeżą kopię aplikacji i uruchom ją. Nie dotykaj niczego.

 

Jeśli w pierwszych sekundach, zanim pojawi się ekran zgód, widzisz połączenia do domen dostawcy analityki, MMP albo sieci reklamowej, wiesz, od czego zacząć.

 

Chcesz mieć pewność, że Twoja aplikacja zbiera dane zgodnie z prawem i efektywnie? Zamów audyt Twojej aplikacji. Sprawdzamy kolejność inicjalizacji, konfigurację zgód, kompletność zdarzeń po stronie serwera, schemat wartości konwersji i deklaracje w obu sklepach. Dostajesz listę podzieloną na to, co naprawia zgodność, i to, co realnie poprawi wyniki kampanii.

 

 

Pomiar konwersji w aplikacji – podsumowanie

 

Jaka jest najważniejsza rzecz z tego artykułu? Zgodność z prawem i jakość danych to są równorzędne cele. Zespół, który uporządkuje kolejność startu, przeniesie zdarzenia na serwer i zbierze porządne zgody, dostaje jednocześnie mniejsze ryzyko prawne i pełniejsze raporty.

 

Kolejność działań, gdybyś miał zrobić to od zera:

 

  • Sprawdź, kiedy startują Twoje SDK. Jeśli przed ekranem zgody, to jest priorytet numer jeden i naprawa zajmuje godziny, nie tygodnie.
  • Wdróż Consent Mode v2, jeśli reklamujesz się w EOG. Bez tego tracisz optymalizację i remarketing, i nikt cię o tym nie poinformuje.
  • Zapytaj MMP o ICM. To najtańszy sposób na odzyskanie widoczności użytkowników bez zgody.
  • Przenieś kluczowe zdarzenia na serwer przez Conversions API, pamiętając o deduplikacji.
  • Uporządkuj pięć miejsc zbierania danych własnych i rozdziel zgodę na konto od zgody marketingowej.
  • Dopiero potem uruchamiaj Customer Match i podobne narzędzia, bo bez podstawy prawnej i bez danych nie mają z czego działać.

 

 

Najczęstsze pytania

 

Czy okno ATT wystarczy jako zgoda w rozumieniu RODO? Nie. ATT to wymóg regulaminowy Apple. Zgodę wymaganą przez RODO i ePrivacy trzeba zebrać osobno, udokumentować i umożliwić jej wycofanie.

 

Czy hashowanie e-maila zwalnia mnie z obowiązku zgody? Nie. Zahaszowany adres pozostaje danymi osobowymi. Hashowanie zabezpiecza dane w tranzycie i jest wymagane technicznie przez Google i Meta, ale nie zastępuje podstawy prawnej.

 

Czy Conversions API pozwala obejść ograniczenia prywatności? Nie i nie taki jest jego cel. Poprawia kompletność i kontrolę nad danymi, na które masz zgodę. Wysyłka z serwera bez zgody użytkownika jest naruszeniem tak samo jak wysyłka z urządzenia.

 

Czy stracę dane, jeśli użytkownik nie wyrazi zgody? Częściowo. Zostaje modelowanie konwersji przez Consent Mode, pomiar na urządzeniu przez ICM oraz agregujące frameworki Apple. Nie dostaniesz danych na poziomie pojedynczego użytkownika.

 

Czy third-party cookies zostały wycofane? Nie. Google odstąpiło od tego 22 kwietnia 2025, a 17 października 2025 wycofało większość Privacy Sandbox. W aplikacjach mobilnych ciasteczek i tak nie ma.

 

Od czego zacząć, jeśli mam ograniczony czas dewelopera? Od kolejności inicjalizacji SDK i domyślnych wartości Consent Mode. To najmniejszy nakład pracy o największym wpływie zarówno na zgodność, jak i na jakość danych.

 

 

Źródła

Dokumentacja i pomoc Google / Google Ads

 

Inicjatywa Privacy Sandbox

 

Dokumentacja Meta / Facebook

 

Dokumentacja Apple

 

Regulacje prawne i wytyczne organów (UE / PL)

 

Platformy analityczne i MMP (Mobile Measurement Partners)

 

Tekst nie stanowi porady prawnej. Stan dokumentacji na 6 sierpnia 2026. Dokumentacja platform zmienia się często, więc przed wdrożeniem zweryfikuj aktualność źródeł.