Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Konta z kampaniami na aplikacje mobilne przejmuję rzadziej niż zwykłe konta Google Ads, ale prawie za każdym razem wyglądają podobnie: jedna kampania na wszystkie kraje, jeden cel „instalacje”, kilka nagłówków wpisanych w pośpiechu i żadnego zdarzenia z wnętrza aplikacji przekazywanego do Google. Do tego pretensja, że system „przepala budżet na przypadkowych użytkowników”.
Problem polega na tym, że kampania promująca aplikację jest najbardziej zautomatyzowanym typem kampanii w Google Ads. Nie ustawiasz w niej słów kluczowych, nie wybierasz miejsc docelowych i nie budujesz reklam — wgrywasz zasoby, ustalasz cel i przekazujesz dane. Jeśli któregoś z tych trzech elementów brakuje, nie masz żadnego punktu zaczepienia, a jedyne, co możesz zrobić, to podnosić albo obniżać stawkę.
Poniżej opisuję, jak podchodzę do takiej kampanii: co przygotować przed startem, jak wybrać cel i stawkę, na czym stoją zasoby i co realnie da się optymalizować po pierwszych tygodniach.
Kampania promująca aplikację nie ma grup reklam ze słowami kluczowymi ani gotowych reklam, które projektujesz od pierwszej do ostatniej linijki. Wgrywasz nagłówki, teksty, obrazy i wideo, a Google składa z nich formaty i wyświetla je w kilku miejscach naraz: w sieci wyszukiwania, w sklepie Google Play, na YouTube, w sieci reklamowej i w innych aplikacjach, oraz w Discover.
To oznacza, że klasyczne dźwignie optymalizacji tu nie istnieją: nie wykluczysz zapytania, nie przesuniesz budżetu między sieciami, nie ustawisz korekt stawek jak w kampanii tekstowej. Zostają cztery rzeczy, na które faktycznie masz wpływ: jakość i różnorodność zasobów, cel kampanii i strategia stawek, dane o konwersjach, które przekazujesz, oraz kierowanie geograficzne i językowe. Jeśli ktoś obiecuje Ci w takiej kampanii „ręczne dopracowanie targetowania”, nie wie, o czym mówi.
Jest jeszcze piąty element, o którym łatwo zapomnieć, bo nie leży w Google Ads: karta aplikacji w sklepie. Zrzuty ekranu, ikona, opis i oceny decydują o tym, ilu ludzi z niej faktycznie zainstaluje aplikację.
To warunek wstępny, nie etap „do zrobienia później”. Kampania optymalizuje się na podstawie tego, co dostaje z aplikacji — a sama instalacja jest najsłabszym możliwym sygnałem.
W praktyce mam dwie drogi. Pierwsza to Google Analytics dla Firebase: SDK w aplikacji, powiązanie projektu Firebase z kontem Google Ads i import wybranych zdarzeń jako konwersji. Druga to zewnętrzny partner atrybucji w rodzaju AppsFlyer, Adjust czy Branch. Trzeba wybrać jedno źródło prawdy i pilnować, żeby te same zdarzenia nie liczyły się podwójnie.
Instalacje z Google Play na Androidzie mierzą się po samym powiązaniu konta, więc łatwo uznać, że pomiar „jest”. Nie jest. Interesują mnie zdarzenia po instalacji: rejestracja, ukończenie samouczka, zakup, powrót drugiego dnia. Dopiero one odróżniają użytkownika, który został, od tego, który odinstalował aplikację po dwóch minutach.
Osobny temat to iOS. Od wprowadzenia przez Apple zgody na śledzenie w kwietniu 2021 dane z tego systemu przychodzą zagregowane i z opóźnieniem, a część konwersji jest modelowana. Ustawieniami w Google Ads tego nie naprawisz — nie porównuj iOS z Androidem jeden do jednego.
Wybieram jeden z trzech wariantów i to decyzja, której w tej samej kampanii już nie zmienię.
Rozdzielam też rynki. Jedna kampania na dziesięć krajów o różnym koszcie instalacji kończy się tym, że budżet spływa tam, gdzie instalacje są najtańsze, a nie tam, gdzie użytkownicy są najwartościowsi. Osobne kampanie dla rynków o podobnym profilu dają kontrolę nad podziałem pieniędzy.
Wybór strategii to miejsce, w którym najczęściej widzę błąd nie do naprawienia zasobami.
Docelowy koszt instalacji jest najprostszy: podaję, ile chcę płacić za pobranie, system dowozi wolumen. Problem jest oczywisty — algorytm dostarczy to, o co go poprosisz, czyli instalacje. Niekoniecznie użytkowników.
Docelowy CPA za działanie w aplikacji przenosi optymalizację na zdarzenie, które naprawdę Cię interesuje: rejestrację, ukończenie procesu, zakup. Wymaga jednak, żeby tych zdarzeń było regularnie na tyle dużo, by algorytm miał się na czym uczyć.
Docelowy ROAS ma sens tam, gdzie z aplikacji płynie mierzalny przychód — w grach z mikropłatnościami i w sklepach. Warunek jak w webie: do Google Ads musi trafiać wartość transakcji, a nie samo zdarzenie zakupu.
Moje podejście jest kolejnościowe. Startuję od kosztu instalacji, żeby zebrać wolumen. Kiedy wiem już, które zdarzenie po instalacji koreluje z pieniędzmi, przechodzę na docelowy CPA za to zdarzenie. Cel zmieniam małymi krokami — każda większa zmiana stawki i każda wymiana wielu zasobów naraz cofa kampanię do fazy nauki.
Budżet dzienny musi być przy tym wyraźnie większy od docelowego kosztu jednej instalacji. Kampania, która wyczerpuje środki po kilku konwersjach, nie ma jak przetestować niczego.
Skoro reklam nie projektuję, całą kreatywną pracę wykonuję na zasobach. Kampania przyjmuje do pięciu nagłówków i do pięciu tekstów, a do tego obrazy, materiały wideo i pliki HTML5. Google sam decyduje, które kombinacje pokaże w którym miejscu.
Z tego wynika praktyczna zasada: zasoby muszą pokrywać różne formaty i proporcje. Wideo poziome, pionowe i kwadratowe, obrazy w kilku proporcjach, teksty o różnej długości. Jedno wideo poziome zamyka kampanii dostęp do miejsc wymagających pionu — a to dziś znacząca część zasięgu na YouTube i w aplikacjach.
Jeśli nie wgrasz żadnego wideo, Google potrafi złożyć materiał automatycznie z elementów karty aplikacji w sklepie. Traktuję to jako zabezpieczenie systemu, nie jako rozwiązanie.
Nagłówki piszę tak, żeby każdy działał samodzielnie, bo nie wiem, z czym zostanie połączony: jeden mówi, co aplikacja robi, drugi — dla kogo jest, trzeci — co użytkownik zyska.
Raport skuteczności zasobów pokazuje, które z nich radzą sobie lepiej, a które słabo. Wymieniam pojedynczo te najsłabsze i dopisuję nowe warianty, zamiast raz na kwartał podmieniać wszystko.
Pierwsza rzecz: cierpliwość. Kampania potrzebuje okresu nauki i w pierwszych dniach wyniki bywają rozchwiane. Ocenianie jej po trzech dniach to najprostszy sposób, żeby nigdy nie dowiedzieć się, do czego jest zdolna.
Druga: patrzę na to, co dzieje się po instalacji, a nie na jej koszt. Jeżeli w Firebase widzę, że użytkownicy z jednego rynku instalują tanio i znikają następnego dnia, to nie jest sukces kampanii. Tanie instalacje bez retencji są łatwiejsze do kupienia niż drogie — i dlatego algorytm je znajdzie, jeśli o nic więcej go nie poprosisz.
Trzecia: zmiany robię pojedynczo i notuję je z datą. Nie mam raportu, który powie mi, dlaczego wynik się zmienił — mam tylko własną historię działań. Bez niej po miesiącu nie odróżnię efektu nowego wideo od efektu podniesionego celu.
I ostatnia rzecz, mniej techniczna: kampania na aplikację ma sens dopiero wtedy, gdy aplikacja utrzymuje użytkownika. Jeśli produkt sypie się na pierwszym uruchomieniu — długi start, wymuszona rejestracja, niejasny pierwszy ekran — żadne ustawienie w Google Ads tego nie odwróci.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |