Rewardful, Tolt i FirstPromoter dla aplikacji mobilnych: czy webowe narzędzia partnerskie działają przy zakupach w aplikacji?

Jak webowe narzędzia partnerskie śledzą sprzedaż

Rewardful, Tolt, FirstPromoter i PartnerStack działają według tego samego schematu. Odwiedzający klika link partnera, skrypt na Twojej stronie zapisuje ID polecenia w pliku cookie, a przy płatności polecenie jest przypisywane do klienta w Twoim systemie płatności. Gdy system zgłasza płatność, odnowienie lub zwrot, narzędzie nalicza prowizję partnera albo ją cofa.

Dla SaaS sprzedawanego w sieci przez Stripe lub Paddle to rozwiązanie niemal idealne. Kliknięcie i płatność odbywają się w tej samej przeglądarce, źródłem prawdy jest system płatności, a prowizja cykliczna automatycznie podąża za subskrypcją. Te narzędzia od lat dopracowują właśnie ten przepływ: panele dla partnerów, śledzenie kuponów, reguły antyfraudowe i integracje z webowym stosem płatności.

Gdzie zakupy w aplikacji przerywają łańcuch

W aplikacji mobilnej prawie każdy krok tego łańcucha wygląda inaczej:

• Żaden plik cookie nie przetrwa sklepu. Link partnerski otwiera App Store lub Google Play, a aplikacja jest instalowana stamtąd. Plik cookie ustawiony w przeglądarce nie jest dostępny w aplikacji, więc polecenie przepada, chyba że aplikacja dostanie kod inną drogą.

• Tej płatności nie widzisz. Subskrypcje w aplikacji są sprzedawane przez StoreKit i Google Play Billing. Pieniądze przechodzą przez Apple i Google, a nie przez Twoje konto Stripe, więc narzędzie nasłuchujące Stripe nigdy nie dowie się o sprzedaży.

• Odnowienia i zwroty dzieją się w sklepie. Odnowienie w siódmym miesiącu i zwrot w ósmym zapisują Apple lub Google. Prowizja cykliczna wymaga tych zdarzeń, zweryfikowanych, dla każdego subskrybenta.

• Dowodem jest transakcja w sklepie. Aby bezpiecznie wypłacać prowizję, zakup musi potwierdzić sklep: przez usługę taką jak RevenueCat albo przez App Store Server API i Google Play Developer API.

• Śledzenie kuponów nie sięga sklepu. Narzędzia webowe mogą naliczyć prowizję partnerowi, gdy klient wpisze jego kupon w checkoutcie Stripe. Zakupy w App Store i Google Play nigdy nie przechodzą przez ten checkout, więc kod, który twórca podaje w filmie, trzeba przechwycić w samej aplikacji.

To nie wada narzędzi webowych. Powstały dla webowych płatności, a płatności w aplikacji po prostu nimi nie są.

Co obsługuje każde narzędzie (sprawdzone 31 października 2026)

Dane ze stron z cennikiem i dokumentacji integracji każdego dostawcy z 31 października 2026. Ceny są miesięczne, a kwoty przychodów w nawiasach to limity planów publikowane przez dostawców.

Kiedy narzędzie webowe to dobry wybór

Jeśli większość przychodu rozliczasz w sieci, zostań przy narzędziu webowym. Zrobi to lepiej niż platforma mobilna. Typowe przypadki:

• Subskrypcje oparte na webie. Użytkownicy rejestrują się i płacą na Twojej stronie przez Stripe lub Paddle, a aplikacja służy do korzystania z tego, co kupili.

• Oprogramowanie B2B z klientem mobilnym. Konta sprzedaje się w sieci, według liczby stanowisk lub planu, a aplikacje na iPhone'a i Androida służą tylko do logowania.

• Płatność w sieci, do której kierujesz użytkowników aplikacji. W USA, od orzeczenia sądu w sprawie Epic v. Apple z 2025 r., aplikacje mogą linkować do zewnętrznej płatności w sieci; zasady różnią się zależnie od kraju i sklepu, więc sprawdź aktualne wytyczne Apple i Google. To, co tam sprzedajesz, jest rozliczane w sieci i można to śledzić jak każdą sprzedaż webową, o ile cookie z poleceniem trafi do przeglądarki, w której użytkownik płaci.

Szybki test: sprawdź, gdzie wpływają pieniądze. Jeśli większość pokazuje Stripe lub Paddle, narzędzie webowe pasuje. Jeśli większość widać w App Store Connect i Play Console, nie pasuje — choćby było świetne w sieci.

Twoje opcje, jeśli sprzedajesz w aplikacji

Jeśli przychód idzie przez StoreKit lub Google Play Billing, realne są te drogi:

• Platforma partnerska stworzona dla aplikacji mobilnych. Narzędzia zbudowane dla aplikacji, takie jak InfluTo, Insert Affiliate, WinWinKit i GoMarketMe, mają SDK, które rejestruje polecenie w aplikacji (wpisany kod, link, referrer ze sklepu) i weryfikuje zakupy w Apple i Google albo przez RevenueCat. Porównaj je pod kątem tego, kto płaci twórcom, co weryfikują i ile kosztują przy Twoim poziomie przychodu.

• RevenueCat Web Billing dla sprzedaży w sieci. Jeśli sprzedajesz też w sieci, RevenueCat Web Billing — płatność oparta na Stripe, zarządzana przez RevenueCat — wysyła zakupy webowe tym samym webhookiem co zakupy w aplikacji, więc platforma czytająca zdarzenia RevenueCat może zaliczyć oba. Tak InfluTo zalicza płatności w sieci: przez RevenueCat Web Billing albo przez płatność Stripe połączoną z RevenueCat.

• Most, który budujesz sam. Na przykład API śledzenia FirstPromoter przyjmuje sprzedaż z systemów płatności, których nie obsługuje. Musiałbyś przekazywać ze swojego serwera każdy zweryfikowany zakup, odnowienie i zwrot ze sklepu, a w aplikacji nadal sam ustalałbyś, od którego partnera przyszedł dany użytkownik, bo cookie z przeglądarki tam nie dociera.

• Przenieś płatności do sieci. Sprzedawaj przez Stripe w sieci tam, gdzie pozwalają na to zasady, i zostaw narzędzie webowe. Wymieniasz wygodę rozliczeń w sklepie na płatność, nad którą masz kontrolę, a cookie partnera nadal musi przetrwać drogę od linku twórcy do Twojej płatności.

Jedno ograniczenie: InfluTo nie obsługuje zwykłej płatności Stripe bez RevenueCat. Jeśli prowadzisz własną płatność Stripe w sieci, prostszym sposobem na objęcie tej części przychodu pozostaje webowe narzędzie partnerskie.

Przenoszenie partnerów aplikacji z narzędzia webowego

1. 1

   Podziel przychód według miejsca rozliczenia. Przychód rozliczany w sieci może zostać w narzędziu webowym. Przychód z aplikacji wymaga platformy, która weryfikuje zakupy w sklepach.

2. 2

   Wybierz źródło zakupów. Webhook RevenueCat, jeśli używasz RevenueCat, albo walidacja bezpośrednio w sklepach z kluczem App Store Server API i kontem usługi Google Play. Jedna droga na platformę.

3. 3

   Dodaj SDK i pole na kod. SDK sprawdza atrybucję przy pierwszym uruchomieniu, a pole na kod łapie twórców, którzy podają kod w filmach i podcastach, gdzie nie ma linku do kliknięcia.

4. 4

   Odtwórz program i zaproś partnerów. Ustaw prowizję, a potem wyślij dotychczasowym partnerom link do dołączenia; każdy dostaje kod i link przypisane do aplikacji. W InfluTo zasilasz też przedpłacony portfel, od 50 $, z możliwością zwrotu, z którego twórcy dostają wypłaty 1. dnia każdego miesiąca.

5. 5

   Powiedz partnerom, którego linku gdzie używać. Rejestracje w sieci — przez link z narzędzia webowego, instalacje aplikacji — przez nowy kod i link. Dzięki temu żadne polecenie nie przepadnie.

Jeśli rozliczasz w obu miejscach, przez jakiś czas będziesz używać obu narzędzi. To normalne: jedno obsługuje płatności w sieci, drugie sklepy, a każde pokazuje twórcom sprzedaż, którą zaliczyło.