Jak połączyć AppsFlyer i Firebase w aplikacji sprzedażowej?
AppsFlyer i Firebase nie powinny raportować dwóch konkurencyjnych prawd. AppsFlyer odpowiada za atrybucję instalacji, kampanii i deep linków, Firebase/GA4 za zachowania w aplikacji, a backend za zakup, zwrot i wartość zamówienia. Warstwy łączą wspólne identyfikatory oraz udokumentowany kontrakt zdarzeń.
Podział odpowiedzialności
AppsFlyer rejestruje instalację, re-atrybucję, źródło kampanii i deep link. Firebase zbiera ekrany, wyszukiwania, koszyk i checkout. Backend potwierdza płatność, zamówienie, zwrot i finalną wartość. Ten podział ogranicza rozbieżności oraz ułatwia audyt.
Identyfikatory i prywatność
Nie wolno wysyłać adresów e-mail ani danych osobowych jako nazw zdarzeń czy otwartych parametrów. Korzystajcie z pseudonimowego customer_id po uwierzytelnieniu, transaction_id dla zamówienia i campaign_id dla kampanii. Zgody oraz ATT muszą sterować odpowiednimi SDK przed zbieraniem danych wymagających pozwolenia.
Deep link od reklamy do produktu
Link powinien otworzyć konkretny produkt lub promocję, zachować kampanię i poprawnie obsłużyć przypadek bez zainstalowanej aplikacji. Po instalacji deferred deep link prowadzi użytkownika do właściwego miejsca. Zdarzenia kampanii, otwarcia produktu i zakupu muszą mieć wspólne identyfikatory bez dublowania przy powrocie aplikacji z tła.
QA i uzgadnianie raportów
Przed uruchomieniem kampanii wykonajcie kontrolny zakup z oznaczonym źródłem. Sprawdźcie, czy AppsFlyer pokazuje kampanię, Firebase pełny lejek, a backend jedno zamówienie o tej samej wartości. Różnica nie powinna być ukrywana przez ręczne poprawki w dashboardzie; trzeba znaleźć warstwę, która zgubiła lub zdublowała event.
Typowe błędy integracji
Najczęstszy błąd to dwa niezależne purchase: jeden z aplikacji, drugi z serwera, bez wspólnego transaction_id. Kolejne problemy to utrata kampanii po logowaniu, ponowne wysłanie deep linku przy powrocie z tła, różne waluty między narzędziami oraz wysyłanie identyfikatora użytkownika przed zgodą lub uwierzytelnieniem.
Drugą klasą błędów jest niespójny release. Marketing uruchamia kampanię zanim nowa wersja aplikacji trafi do wystarczającej liczby użytkowników, więc część ruchu nie zna nowych eventów. Dashboard powinien zawsze umożliwiać segmentację po app_version i platformie.
Bezpieczny rollout w trzech krokach
Najpierw uruchomcie integrację w środowisku testowym i na wewnętrznych urządzeniach. Następnie wypuśćcie wersję na mały udział użytkowników bez zwiększania budżetu kampanii. Dopiero po potwierdzeniu kompletności lejka, braku duplikatów i zgodności przychodu z backendem skalujcie akwizycję.
- Debug: jedno urządzenie, jeden scenariusz, pełny log.
- Canary: mały udział użytkowników i kontrolna próbka zamówień.
- Scale: monitoring różnic, błędów i udziału wersji aplikacji.
Źródła
AppsFlyer SDK integration: https://dev.appsflyer.com/hc/docs/rn_getting_started
Firebase Analytics: https://firebase.google.com/docs/analytics
Apple ATT: https://developer.apple.com/documentation/apptrackingtransparency
Najczęstsze pytania
- Który system powinien raportować purchase?
- Źródłem prawdy powinien być backend zamówień. Może przekazać potwierdzone zdarzenie do narzędzi analitycznych i atrybucyjnych z tym samym transaction_id.
- Czy AppsFlyer zastępuje GA4?
- Nie. AppsFlyer skupia się na atrybucji i kampaniach mobilnych; GA4/Firebase na zachowaniach i raportowaniu produktu.
- Jak uniknąć podwójnego raportowania zakupu?
- Ustal jeden system emitujący potwierdzony purchase, stosuj wspólny transaction_id i deduplikuj zdarzenia w odbiorcach. Aplikacja może raportować rozpoczęcie płatności, ale nie powinna konkurować z backendem o finalny wynik.
Treść zaktualizowano: 26 sierpnia 2026
Google Preferred Sources
Czytaj GMI częściej w Google
Dodaj gmi.software do preferowanych źródeł. Google może częściej wyróżniać nasze nowe materiały w Top Stories i obsługiwanych widokach AI.