Jakie typy fraudu powinna obejmować ochrona w MMP i za co płacisz osobno?

Jeśli kupujesz płatny ruch do aplikacji, na fakturze od MMP masz zapewne dwie pozycje: attribution i ochronę przed fraudem. Odnowienie umowy to dobry moment, żeby zapytać, co właściwie obejmuje ta druga. Moduł, który blokuje jeden typ oszustwa, a przepuszcza ten, na który narażone są Twoje kanały, jest kosztem, a nie ochroną. Do tego jeśli fałszywe installe liczą się jako płatne konwersje, zanim zostaną odrzucone, możesz płacić dwa razy: sieci reklamowej i dostawcy pomiaru.

Click injection i install hijacking przejmują installe, które już zdobyłeś

Install hijacking to efekt. Nieuczciwe źródło przypisuje sobie install, który wygenerował ktoś inny: inny płatny kanał albo ruch organiczny. Click injection to najlepiej znana technika. Złośliwa aplikacja na urządzeniu z Androidem wykrywa, że trwa instalacja innej aplikacji, i wysyła kliknięcie tuż przed jej zakończeniem. W ten sposób wygrywa last-click attribution.

Co to robi z danymi: łączna liczba installi praktycznie się nie zmienia, ale zasługa przechodzi od ruchu organicznego lub uczciwych partnerów do nieuczciwego źródła. CPI tego źródła wygląda atrakcyjnie, a udział organiki pozornie spada.

• Bardzo krótkie czasy od kliknięcia do installa, fizycznie nierealne przy pobieraniu ze sklepu.
• Kliknięcia zarejestrowane już po rozpoczęciu pobierania, widoczne po zestawieniu znaczników czasu z install referrera z czasem kliknięcia.
• Źródło, które świetnie wygląda w raporcie, podczas gdy na tych samych rynkach spadają installe organiczne.

Click flooding i SDK spoofing zniekształcają wolumen, a nie timing

Click flooding, nazywany też click spammingiem, to masowe wysyłanie kliknięć dla urządzeń, które nigdy nie widziały reklamy. Zakład jest prosty: część tych użytkowników zainstaluje aplikację organicznie, a źródło floodujące będzie miało ostatnie kliknięcie. Ślad to bardzo niska konwersja z kliknięć na installe i płaski rozkład czasu od kliknięcia do installa z długim ogonem. Przykład hipotetyczny: wstrzymujesz sieć w Czechach, a installe organiczne rosną mniej więcej o tyle, ile ta sieć wcześniej raportowała. Taki wzorzec wskazuje na flooding.

SDK spoofing idzie dalej. Tu nie istnieje żadne urządzenie. Oszuści wysyłają do serwerów pomiarowych żądania udające ruch z prawdziwego SDK i generują installe oraz eventy in-app. Ślad to installe bez kolejnych sesji, kombinacje urządzeń i wersji systemu niepasujące do Twojej realnej grupy odbiorców oraz eventy, które nie przechodzą walidacji lub weryfikacji podpisu. Sfałszowane eventy mogą też zepsuć sygnały zakupów i ad revenue, pod które optymalizujesz kampanie.

Device farms i incent abuse mogą zawyżać ad revenue, nie tylko installe

Device farms używają prawdziwych urządzeń lub emulatorów, żeby wielokrotnie instalować aplikacje i resetować identyfikatory między kolejnymi przebiegami. W odróżnieniu od spoofingu installe naprawdę się odbywają. W aplikacji monetyzowanej reklamami farmy mogą też generować wyświetlenia. To zawyża ad revenue kohorty, poprawia eROAS źródła i może zostać później cofnięte, gdy sieć reklamowa usunie nieważny ruch. Jeśli przypisujesz ad revenue do źródła pozyskania, to ten typ fraudu jest dla Ciebie najważniejszy. Więcej w tekście Jak przypisać przychód z reklam do źródła pozyskania użytkownika w aplikacji mobilnej.

• Nowe installe skupione w tych samych zakresach IP, na adresach centrów danych albo na wąskiej grupie modeli urządzeń.
• Krzywe retencji nienaturalnie równe albo załamujące się po pierwszej sesji.
• Ad revenue na użytkownika wysokie w dniu zero i znikające po korektach ze strony sieci.

Incent abuse to kierowanie ruchu motywacyjnego, w którym użytkownik dostaje nagrodę za instalację, do kampanii sprzedanych jako niemotywacyjne. Installe są prawdziwe, ale użytkownicy nie mają żadnej intencji. Retargeting abuse to wersja tego samego w re-engagement. Źródło przypisuje sobie istniejących użytkowników, którzy i tak by wrócili, często wysyłając kliknięcia do znanych użytkowników w oknie reattribution. Ślad to rosnąca liczba reattribution bez zmiany w zaangażowaniu ani w przychodzie na powracającego użytkownika. Jeśli planujesz kampanie re-engagement, ustaw to przed startem. Zobacz Pierwsza kampania retargetingowa aplikacji: jak ustawić pomiar, zanim ruszy budżet.

Umowa z MMP powinna odpowiadać na trzy pytania o fraud

Jeśli dziś korzystasz z Adjust, AppsFlyer lub Kochava albo porównujesz je z innymi dostawcami, nie porównuj modułów antyfraudowych po nazwie. Porównuj warunki, które da się sprawdzić w zamówieniu i na koncie testowym.

1. Zakres. Które z opisanych typów są objęte ochroną i czy wykrywanie działa przed attribution (install nigdy nie zostaje przypisany), czy po niej (install jest później przeklasyfikowany)? Zapytaj, czy zakres różni się dla attribution installi, eventów in-app i re-engagement.
2. Naliczanie. Czy ochrona przed fraudem to osobny moduł, wyższy pakiet, czy jest w cenie? Czy odrzucone installe lub konwersje są wyłączone z jednostki rozliczeniowej i czy jest to zapisane w umowie? Przy rozliczeniu za MTU albo za konwersję to decyduje, czy fraud podnosi Twój rachunek za pomiar.
3. Dostęp do odrzuconych danych. Czy widzisz odrzucone installe na poziomie wiersza, z powodem odrzucenia, źródłem, kampanią i znacznikami czasu? Czy możesz je wyeksportować? Bez tego nie zakwestionujesz faktury od sieci ani nie sprawdzisz fałszywych alarmów.

Szerszy kontekst porównywania dostawców znajdziesz w tekście Czym jest MMP i jak działa AdShift?. AdShift zawiera fraud prevention bez dopłaty i rozlicza się za konwersję, a nie za MTU. Niezależnie od wybranego dostawcy powyższe trzy pytania działają tak samo.

Pomiar nie rozwiąże komercyjnej strony fraudu

MMP może oznaczyć i odrzucić fałszywe installe. Nie odzyska pieniędzy już zapłaconych sieci. Zwroty zależą od zapisów w insertion orderach i od tego, czy sieć zaakceptuje dowody. O korektach ad revenue za nieważny ruch decydują sieci reklamowe, nie dostawca pomiaru. Techniki fraudu też się zmieniają, więc reguły, które działają w tym kwartale, wymagają przeglądu. Wykrywanie daje również fałszywe alarmy, co jest kolejnym powodem, by żądać dostępu do odrzuconych danych. Wreszcie żaden moduł antyfraudowy nie naprawi ruchu, który jest prawdziwy, ale słaby. Realny użytkownik bez intencji to problem zakupu mediów, nie pomiaru.