Pierwsza kampania retargetingowa aplikacji: jak ustawić pomiar, zanim ruszy budżet

Zespół uruchamia pierwszą kampanię retargetingową. Po dwóch tygodniach partner raportuje jedną liczbę powrotów, panel MMP pokazuje inną, a finanse pytają, dlaczego suma UA i retargetingu jest większa niż całość. Nic nie jest zepsute. Pięć decyzji zapadło po starcie zamiast przed nim i teraz każda liczba wymaga wyjaśnienia.

Ten tekst jest o tych pięciu decyzjach. Zakłada, że prowadzisz już płatne UA, masz bazę zainstalowanych użytkowników, a partner, samoobsługowy DSP albo kampania re-engagementowa w dużej sieci reklamowej zaraz zacznie pokazywać reklamy osobom, które mają Twoją aplikację.

Partner pracuje tylko na tym, co wysyła Twój MMP

Partner retargetingowy buduje grupy odbiorców z aktywności, którą dostaje. Nie widzi Twojej bazy danych. Widzi postbacki: instalacje, sesje, eventy w aplikacji, każdy z identyfikatorem urządzenia i znacznikiem czasu. Wynikają z tego cztery rzeczy.

• Postbacki muszą obejmować użytkowników organicznych. Grupa „co najmniej pięć sesji, brak sesji od 14 dni” powstaje ze wszystkich, którzy używają aplikacji, nie tylko z tych, których partner pozyskał. Jeśli reguła postbacków mówi „tylko ruch przypisany do tego partnera”, grupy zostają puste.
• Lista eventów wynika z listy grup, nie odwrotnie. Grupa użytkowników, którzy otworzyli konkretną sekcję aplikacji, potrzebuje eventu dla tej sekcji. Najpierw spisz grupy, potem sprawdź, które eventy istnieją, a brakujące dodaj do najbliższego wydania SDK.
• Zgody sprawdza się w dwóch miejscach. MMP sprawdza, czy użytkownik zgodził się na przekazywanie danych. Nie sprawdza, czy partner jest na liście dostawców w Twojej platformie zgód. To drugie sprawdzenie należy do Ciebie i musi się odbyć przed startem postbacków.
• Zegar partnera rusza od pierwszego postbacku. Jeśli grupa wymaga 30 dni nieaktywności, pierwszy użytkownik zakwalifikuje się mniej więcej miesiąc po uruchomieniu integracji. Albo przyjmujesz ten rozbieg, albo zaczynasz od krótszych okien, albo pytasz partnera, czy przyjmie listę historyczną.

Jeśli duża część Twojego przychodu pochodzi z reklam, a nie z zakupów, ten sam plan postbacków decyduje o tym, czy partner może optymalizować pod użytkowników, którzy generują ad revenue. O tym, jak ten przychód w ogóle trafia do MMP, pisaliśmy w tekście o przypisywaniu przychodu z reklam do źródła.

Trzy okna, trzy decyzje

Atrybucją retargetingu w MMP rządzą trzy okna. Mają podobne nazwy, ustawia się je w różnych miejscach i każde odpowiada na inne pytanie. Nazwy różnią się też między MMP, a to samo słowo może oznaczać inne okno w innym narzędziu, więc sprawdź definicje w swoim. Przykłady niżej są hipotetyczne i używają okrągłych liczb, żeby było widać mechanikę.

Okno nieaktywności decyduje, komu wolno przypisać efekt

Okno nieaktywności to minimalna liczba dni bez otwarcia aplikacji, po której klik lub wyświetlenie reklamy może przypisać użytkownika do kampanii retargetingowej. W zależności od MMP ustawia się je raz dla aplikacji albo osobno dla każdego partnera; w AdShift to ustawienie aplikacji, obowiązujące wszystkie jej linki retargetingowe. Niektóre duże sieci i tak trzymają własną wartość w swojej integracji, więc sprawdź oba miejsca.

Przy zerze klik może przypisać kogoś, kto używał aplikacji wczoraj. Liczby rosną, ale część tych osób wróciłaby sama. Przy siedmiu dniach przypiszesz tylko użytkowników nieaktywnych od co najmniej tygodnia. Liczby spadają i zbliżają się do tego, co kampania faktycznie spowodowała. Okno nie decyduje, kto zobaczy reklamę; o tym decydują grupy partnera. Decyduje, kogo policzysz.

Rozsądna wartość na start to najkrótszy okres nieaktywności w grupach partnera. Jeśli najciaśniejsza grupa to „brak sesji od siedmiu dni”, okno siedmiodniowe oznacza, że każdy użytkownik, do którego partner celuje, może też zostać przypisany, a ktoś aktywny dwa dni temu nie. Zero nie jest błędem, a niektóre sieci zalecają je dla własnych kampanii. Błędem jest dopiero zero, którego nikt nie pamięta wybrać.

Okno re-engagementu decyduje, jak długo trwa przypisanie

Okno re-engagementu zaczyna się, gdy użytkownik, który ma już aplikację, otworzy ją po kontakcie z reklamą retargetingową. Dopóki okno jest otwarte, jego eventy są przypisywane do źródła retargetingowego. Gdy się zamknie, eventy wracają do pierwotnego źródła pozyskania. Kolejny klik z tej samej kampanii w trakcie okna nie otwiera nowego re-engagementu.

Właściwa długość wynika z zachowania, za które chcesz płacić. Aplikacja z codziennym użyciem i szybką konwersją może pracować na godzinach. Aplikacja subskrypcyjna albo e-commerce, w której użytkownik decyduje przez kilka dni, potrzebuje dni lub tygodni. Domyślna wartość w Twoim MMP może być w jednym miejscu w godzinach, a w innym w dniach, więc odczytaj ją tam, gdzie faktycznie siedzi link albo konfiguracja partnera, zamiast zakładać.

Okno ponownej atrybucji decyduje, kiedy reinstalacja jest nową instalacją

Okno ponownej atrybucji działa, zanim uruchomisz retargeting. Liczy dni od ostatniej zaliczonej instalacji na urządzeniu i decyduje, jak traktować reinstalację. Pobranie, które nie zostało zaliczone jako install, go nie zeruje.

Przy hipotetycznym oknie 90 dni cztery przypadki pokrywają prawie wszystko:

• Zwykła kampania UA, reinstalacja po 40 dniach: nie przypisana do kampanii i nie liczona jako nowa instalacja.
• Zwykła kampania UA, reinstalacja po 100 dniach: nowa instalacja, przypisana do kampanii jako UA.
• Link retargetingowy, reinstalacja po 40 dniach: ponowna atrybucja, przypisana do źródła retargetingowego i raportowana jako retargeting.
• Link retargetingowy, reinstalacja po 100 dniach: nowa instalacja, przypisana do źródła retargetingowego, ale raportowana jako UA.

Dwie konsekwencje liczą się przy starcie. Po pierwsze, okno ponownej atrybucji zmienia liczbę instalacji raportowanych przez kampanie UA, więc nie zmieniaj go tego samego dnia, w którym startujesz z retargetingiem; nie odróżnisz potem jednego efektu od drugiego. Po drugie, linki akwizycyjne muszą mieć retargeting wyłączony. Link do kampanii preinstalacyjnej albo UAC z włączonym retargetingiem zamienia reinstalacje w ponowne atrybucje i po cichu przenosi instalacje z jednego raportu do drugiego.

Raporty pokażą trzy sumy i tylko jedna z nich się zgadza

Gdy kampania ruszy, MMP raportuje te same eventy z trzech stron. Widok UA przypisuje wszystko do źródła, które pierwotnie pozyskało użytkownika. Widok retargetingu przypisuje eventy z okna re-engagementu do źródła retargetingowego. Widok łączny liczy każdy event raz i rozstrzyga konflikt na rzecz ostatniego kwalifikującego się kontaktu.

W oknie re-engagementu event pojawia się jednocześnie w widoku UA i w widoku retargetingu. Dodaj te dwa widoki i dostaniesz więcej niż suma łączna. Tak ma być: zespół UA nadal widzi pełną wartość użytkowników, których pozyskał, a zespół retargetingu widzi wartość użytkowników, których sprowadził z powrotem. Powiedz to finansom przed startem, nie po pierwszym raporcie.

• Budżet na retargeting: czytaj widok retargetingu.
• Budżet na pozyskanie: czytaj widok UA.
• Łączny przychód i łączne instalacje: czytaj widok łączny. To jedyna liczba, która powinna zgadzać się z Twoim backendem.
• Uzgodnienie z partnerem: porównaj liczbę re-engagementów w panelu partnera z widokiem retargetingu w MMP za jeden pełny dzień. Różnica, która utrzymuje się powyżej kilku procent, wskazuje na postbacki, zgody albo rozjazd okien.

Przypisanie to nie przyczyna, więc ustal, jak ocenisz kampanię

Każda liczba wyżej odpowiada na pytanie „kto dostaje przypisanie”. Żadna nie odpowiada na pytanie „czy ten użytkownik wróciłby i tak”. Kampania retargetingowa, która trafia głównie do użytkowników będących w drodze powrotnej do aplikacji, będzie wyglądać świetnie w każdym widoku i nie zmieni niczego w Twoim biznesie.

Minimalny test to grupa kontrolna. Weź użytkowników, którzy kwalifikują się do grup partnera, część z nich wyłącz z kampanii i porównaj obie grupy po pierwszym pełnym oknie: ilu wróciło i ile przychodu dali per użytkownik. Grupy partnera już definiują populację, więc jedyna dodatkowa praca to wyłączenie jej części. Jeśli baza jest za mała na czysty podział, porównaj wskaźnik powrotów grupy sprzed startu ze wskaźnikiem po starcie i powiedz głośno, że w tej liczbie siedzi sezonowość.

Pytanie, które ostatecznie rozstrzyga o przedłużeniu współpracy z partnerem, jest proste: ile kosztował powrót użytkownika, który bez kampanii by nie wrócił, w porównaniu z kosztem pozyskania nowego użytkownika o tej samej wartości? Wszystko w tym tekście jest po to, żeby po pierwszym cyklu na nie odpowiedzieć, zamiast zgadywać.

Checklista przed pierwszą impresją

1. Lista grup partnera z progami: sesje, dni nieaktywności, eventy.
2. Lista eventów wynikająca z tych grup, wydana w SDK i widoczna w MMP.
3. Partner na liście dostawców w platformie zgód.
4. Postbacki do partnera obejmują użytkowników organicznych.
5. Okno nieaktywności ustawione, z zapisanym powodem.
6. Okno re-engagementu ustawione świadomie w linku albo w konfiguracji partnera.
7. Okno ponownej atrybucji bez zmian, z zanotowaną wartością.
8. Retargeting wyłączony we wszystkich linkach akwizycyjnych.
9. Finanse i zespół UA wiedzą, że UA plus retargeting przekracza widok łączny.
10. Grupa kontrolna albo baza porównawcza ustalona przed pierwszą impresją.

Lista wygląda na długą jak na kampanię, która może zacząć od małego budżetu. Jest krótsza niż spotkanie, na którym ktoś próbuje po fakcie wyjaśnić, dlaczego trzy raporty się nie zgadzają. Pomiar po instalacji to trudna część marketingu mobilnego, a retargeting to miejsce, w którym to widać; pisaliśmy o tym osobno.

Czego ta konfiguracja nie rozwiąże

Okna i postbacki sprawiają, że liczby są spójne. Nie sprawiają, że kampania jest dobra. Nie naprawią kreacji, stawek, częstotliwości ani logiki grup po stronie partnera i nie zastąpią testu incrementality, gdy retargeting stanie się dużą częścią budżetu. W tym momencie formalny test z grupą kontrolną i progiem istotności jest jedynym sposobem, żeby wiedzieć, czy wydatek cokolwiek zmienia.

Nie odzyskają też historii. Jeśli partner zaczyna dostawać postbacki dzisiaj, nic, co ustawisz w MMP, nie powie mu, co użytkownicy robili w zeszłym miesiącu. Zaplanuj rozbieg albo listę historyczną, zanim ogłosisz datę startu.