Kratak sud
Ceo framework je u tekstu, besplatno - ništa nije sakriveno iza forme: 25 lista publika u 6 stubova, sa tačnom konfiguracijom za svaku. A najvredniji deo nije nijedna lista, nego tri stvari koje GA4 Admin API ne ume da uradi i zaobilaznice koje sam izgradio umesto njih.
25
lista u property-ju (24 ciljne + 1 pomoćna)
6
stubova: Lifecycle, Value, Intent, Brand, Replenishment, Predictive
3
ograničenja Admin API-ja koja menjaju kako gradiš
2-4 ned
pre nego što lista napravljena danas išta znači
Ovaj framework sam izgradio kroz GA4 Admin API za jednu multi-brand skincare prodavnicu u UK-u koju vodim - 25 lista publika, komad po komad, sa svim greškama koje idu uz to. Ime naloga i imena brendova ne pominjem nigde u ovom tekstu; gde treba primer, brendovi su BR1 i BR2, kategorije su krema, SPF, suplementi. To nije oprez radi opreza - to je uslov pod kojim uopšte smem da pišem o živom nalogu.
Ono što je ispalo najkorisnije nije nijedna od 25 lista. Najkorisnije je ono što API odbija da uradi. Tri stvari se jednostavno ne mogu postaviti kroz GA4 Admin API onako kako bi logično očekivao, i za svaku od te tri postoji zaobilaznica koja menja kako gradiš celu listu - ne samo tu jednu, nego čitav stub. Ta sekcija je razlog zbog kog ovaj tekst postoji, i dobila je najviše prostora.
Ceo framework je ispod: naming konvencija, svih 25 lista sa tačnom GA4 konfiguracijom, redosled u kom ih gradiš i redosled u kom ih uključuješ u Google Ads. Nema forme, nema "preuzmi da vidiš ostatak". Ako hoćeš izvršnu verziju - markdown fajlove koje ubaciš direktno u Claude ili ChatGPT i PDF za arhivu - link je na kraju.
25 lista, 6 stubova: pravilo brojanja
Prvo brojanje, jer se tu najviše ljudi zabuni kad prvi put pogleda listu publika u nalogu. Framework ima 25 definicija lista: 24 ciljne publike raspoređene u 6 stubova, plus jedna pomoćna lista koja nikad nije ciljna publika.
Ta pomoćna lista se zove LCY_ALL_ActiveCustomers_45d i ima tačno jedan posao: u Google Ads-u se oduzima od replenishment lista. Zašto baš tako, objašnjeno je u sekciji o ograničenjima API-ja - njeno postojanje je direktna posledica jedne stvari koju GA4 ne ume sam.
U punoj postavci istu definiciju kloniraš na prozor koji kombinacija traži (25 dana za ciklus suplemenata, 120 dana za at-risk sloj), pa se 25 definicija u nalogu vidi kao 27 publika. Zato u tabelama ispod stoje i ActiveCustomers_25d i ActiveCustomers_120d - isti obrazac, drugi prozor.
Naming konvencija koju sam koristio na svih 25 je fiksna:
{PILLAR}_{SCOPE}_{Segment}_{Window}Pillar je jedna od šest troslovnih oznaka stubova. Scope je ili ALL (ceo nalog) ili oznaka brenda i kategorije - BR1, BR2, MOI, SUP, SPF. Window je membership prozor ili ciljni raspon - 90d, 540d, 45-120d.
Konvencija nije estetika. Kad imaš 25 stavki u jednoj listi u Google Ads-u, pretraga po prefiksu je jedini realan način da za tri meseca još uvek znaš šta je šta, a da ne otvaraš svaku i čitaš opis. Sortiranje po imenu grupiše stub uz stub, pa se cela lista publika čita kao šest odeljaka umesto kao 25 nasumičnih redova.
Punjenje lista i pragovi aktivacije
Dva mehanizma odlučuju da li publika može da se koristi za ciljanje ili ostaje u Observation-u: kako se lista puni i koliko članova traži kanal na kome hoćeš da je koristiš.
Punjenje: GA4 publika počinje da se puni od trenutka kreiranja, uz otprilike 30 dana unazad za korisnike koji već ispunjavaju uslov. Preko tih 30 dana retroaktivnog punjenja nema - ne postoji dugme koje listu popuni istorijom od pre godinu dana. Praktična posledica: lista koju napraviš danas postaje upotrebljiva za 2 do 4 nedelje. Zato je najbolji trenutak za gradnju publika pre nego što ti zatrebaju, a najgori onaj kad kampanja kreće sutra.
Pragovi isporuke: Search remarketing (RLSA) i Shopping traže minimum 1.000 aktivnih korisnika u poslednjih 30 dana. Display, YouTube i Demand Gen traže 100. To su Google-ovi minimumi, ne moji, i jedini put preko njih je da lista naraste. Dok je ispod praga, lista živi kao Observation - vidiš joj podatke, ne utiče na isporuku.
Ovde se većina priča o "publike ne rade za nas" završi pre nego što je počela: prodavnica napravi pet publika, nijedna ne pređe prag, i zaključak se sam napiše. Dobra vest je da prag od 100 za Display, YouTube i Demand Gen prelazi skoro svaka prodavnica sa iole prometa - pa remarketing kreće tamo dok Search liste rastu.
Lifecycle (LCY) - 6 lista
Lifecycle stub prati gde je kupac u odnosu sa nalogom - da li je tek stigao, da li se vratio, da li je nestao. Ovo je osnova na kojoj stoje skoro svi ostali stubovi, jer se pola RPL i VAL logike oslanja na LCY liste kao isključenja u Google Ads-u.
| Lista | Definicija | GA4 konfiguracija | Membership | Čemu služi |
|---|---|---|---|---|
| LCY_ALL_FirstTimeBuyers_180d | tačno 1 kupovina ikad, poslednja u 180 dana | Include: purchase event count = 1, at any point in time · AND purchase u bilo kom periodu od 180 dana | 180 dana | drugi order je KPI koji odlučuje da li brend raste; ova lista je jedina koja ga direktno gađa |
| LCY_ALL_RepeatBuyers_540d | 2+ kupovine | Include: purchase event count > 1, at any point in time | 540 dana | jezgro vrednosti naloga, bid boost, Similar seed |
| LCY_ALL_ActiveCustomers_90d | kupio u poslednjih 90 dana | Include: purchase (bar jednom) | 90 dana | isključenje iz akvizicije + osnova za cross-sell |
| LCY_ALL_Purchasers_365d | kupio bilo kad u 365 dana | Include: purchase (bar jednom) | 365 dana | sirovina za win-back: u Ads-u MINUS ActiveCustomers_90d = lapsed kupci |
| LCY_ALL_EngagedNonBuyers_30d | 2+ sesije u 30 dana, nikad kupovina | Include: session_start event count > 1 (UI: u periodu od 30 dana; API: at any point in time, prozor nosi membership) · Exclude: purchase, at any point in time | 30 dana | prospecting seed za Demand Gen i lookalike logiku |
| LCY_ALL_NewVisitors_7d | prva poseta u 7 dana, bez kupovine | Include: first_visit · Exclude: purchase, at any point in time | 7 dana | soft remarketing dok je pamćenje sveže, kratko članstvo je namerno |
Value / RFM (VAL) - 4 liste
Value stub sortira kupce po vrednosti, a ovde prvi put udaraš u ograničenje API-ja koje menja celu logiku gradnje - LTV percentile ne prolazi kroz API, pa se dve liste ovde grade preko frequency proxy-ja umesto preko prave vrednosti. Detaljno objašnjenje zašto je u sekciji o ograničenjima; ovde su konfiguracije koje iz toga proizlaze.
| Lista | Definicija | GA4 konfiguracija | Membership | Čemu služi |
|---|---|---|---|---|
| VAL_ALL_Champions_Top10_540d | top 10% po vrednosti | UI ruta: suggested audience template sa LTV percentilom (top 10%) · API ruta: frequency proxy - purchase event count > 2, at any point in time | 540 dana | zaštita, Similar seed, i pravilo da ovi ljudi nikad ne vide poruku sa popustom |
| VAL_ALL_HighValue_Top25_540d | top 25% po vrednosti | UI: LTV percentile top 25% · API: purchase event count > 1, at any point in time | 540 dana | tROAS pojačanje, prioritet u remarketingu |
| VAL_ALL_AtRisk_HighValue_120d | high value + nije kupio 120 dana | ista definicija kao HighValue_Top25, membership 120 dana · "nije kupio" se rešava u Ads-u (MINUS ActiveCustomers_120d) | 120 dana | "can't lose them" - najskuplji gubitak u nalogu |
| VAL_ALL_OneTimeLowValue_365d | 1 kupovina, donja polovina po vrednosti | Include: purchase event count = 1, at any point in time · (UI: presek sa LTV donjih 50%) | 365 dana | isključivanje iz skupog remarketinga - ne svaki kupac zaslužuje isti bid |
Intent (INT) - 4 liste
Intent stub je najtopliji sloj u nalogu - ljudi koji su krenuli kroz levak i stali. Ovo je i jedino mesto gde "temporarily exclude" stvarno radi kako izgleda da bi trebalo, jer se prozor uključenja i isključenja poklapaju. Zašto to nije slučaj svuda, objašnjeno je u trećem ograničenju API-ja ispod.
| Lista | Definicija | GA4 konfiguracija | Membership | Čemu služi |
|---|---|---|---|---|
| INT_ALL_CartAbandoners_14d | add_to_cart u 14 dana, bez kupovine | Include: add_to_cart u periodu od 14 dana · Exclude (temporarily): purchase u periodu od 14 dana | 14 dana | najtopliji sloj u nalogu, najveći bid |
| INT_ALL_CheckoutAbandoners_7d | begin_checkout u 7 dana, bez kupovine | Include: begin_checkout u periodu od 7 dana · Exclude (temporarily): purchase u periodu od 7 dana | 7 dana | hitni sloj; radi paralelno sa email flow-om, ne umesto njega |
| INT_ALL_ProductViewers_NoATC_30d | view_item u 30 dana, bez dodavanja u korpu | Include: view_item u periodu od 30 dana · Exclude (temporarily): add_to_cart u periodu od 30 dana | 30 dana | srednji sloj, jeftiniji bid, veći volumen |
| INT_ALL_SearchUsers_30d | koristio pretragu na sajtu u 30 dana | Include: view_search_results (ili search) u periodu od 30 dana | 30 dana | najjači zaboravljeni signal - čovek koji kuca u tvoju pretragu zna šta hoće |
Brand affinity (BRD) - 5 lista
Ovaj stub postoji zbog multi-brand naloga - kad prodaješ više brendova iz istog GA4 property-ja i moraš da im praviš odvojene poruke. Scope oznake BR1 i BR2 su tvoja dva brenda po prometu. Ako prodaješ jedan brend, ceo stub preskačeš i zamenjuješ ga kategorijama (na primer SER za serum, CLE za cleanser) - logika ostaje ista, menja se samo šta ide u scope.
| Lista | Definicija | GA4 konfiguracija | Membership | Čemu služi |
|---|---|---|---|---|
| BRD_BR1_Purchasers_365d | kupio glavni brend | Include: purchase gde item-scoped dimenzija item_brand = BR1 | 365 dana | jezgro najvećeg brenda |
| BRD_BR1_StepUp_Purchasers_365d | kupio napredniju liniju tog brenda | Include: purchase gde item_name sadrži token linije | 365 dana | kupac koji ulazi u obrazac pretplate - najbolji kandidat za rast vrednosti |
| BRD_BR1_Browsers_NoBuy_60d | gledao BR1, nije kupio | Include: view_item sa item_brand = BR1 u 60 dana · Exclude: purchase sa item_brand = BR1, at any point in time | 60 dana | brand-specifičan remarketing, poruka koja zna o čemu priča |
| BRD_BR2_Purchasers_365d | kupio drugi brend po prometu | isto kao BR1_Purchasers, sa BR2 | 365 dana | drugo jezgro |
| BRD_BR2_Browsers_NoBuy_60d | gledao BR2, nije kupio | isto kao BR1_Browsers_NoBuy, sa BR2 | 60 dana | remarketing |
Pre nego što gradiš BRD liste
Proveri da li item_brand uopšte stiže u GA4. U dosta prodavnica je to polje prazno ili nekonzistentno - feed ga ne šalje čisto, ili ga šalje pod drugim imenom za polovinu kataloga. Ako nema, fallback je page_location pattern (URL sadrži brand slug) ili item_category. Ova provera ide pre gradnje, ne posle - inače gradiš pet lista i otkriješ da su sve prazne.
Replenishment (RPL) - stub koji niko ne gradi
Od svih šest stubova, ovaj nosi najveću težinu, i to ne slučajno - u praksi je gotovo uvek prazan. Lifecycle i Intent liste pravi skoro svako ko otvori GA4 Audiences. Replenishment liste ne pravi skoro niko, jer traže nešto što nijedna druga lista ne traži: da znaš koliko dugo tvoj proizvod traje u upotrebi.
Ime nosi ciljni prozor - 45-120d - ali se u GA4 ne gradi kao raspon. Gradi se kao obična lista kupaca sa jednim membership prozorom (gornja granica), a donja granica nastaje tek kad tu listu u Google Ads-u umanjiš za listu nedavno aktivnih kupaca. To je direktna posledica trećeg ograničenja API-ja ispod - GA4 fizički ne ume da izgradi "kupio pre 45 do 120 dana" kao jedan uslov u jednoj listi.
| Lista | Definicija (efektivna) | GA4 konfiguracija | Membership | Ads exclusion | Čemu služi |
|---|---|---|---|---|---|
| RPL_MOI_Due_45-120d | kupio kremu pre 45-120 dana, ništa od tada | Include: purchase gde item_category (ili item_name) sadrži moisturiser token | 120 dana | MINUS ActiveCustomers_45d | krema traje 60-90 dana; oglas stiže kad kutija presušuje |
| RPL_SUP_Due_25-75d | kupio suplement pre 25-75 dana | Include: purchase gde kategorija = supplements | 75 dana | MINUS ActiveCustomers_25d (klon) | pakovanje od 60 kapsula = oko 2 meseca |
| RPL_SPF_Due_45-120d | kupio SPF pre 45-120 dana | Include: purchase gde kategorija = SPF | 120 dana | MINUS ActiveCustomers_45d | ciklus potrošnje + sezonski faktor |
Logika prozora je ista za sve tri: uzmi koliko pakovanje realno traje u upotrebi, i počni da oglašavaš na otprilike 70-80% tog ciklusa - ne na 100%, jer ako čekaš da kutija stvarno bude prazna, gubiš dane u kojima je odluka o sledećoj kupovini već doneta. Krema traje 60 do 90 dana, pa donja granica kreće na 45. Pakovanje od 60 kapsula traje oko dva meseca, pa donja granica kreće na 25 do 30.
Ako ne znaš ciklus svog proizvoda - a većina prodavnica ga ne zna dok ne pogleda - ne izmišljaš ga. Izvučeš ga iz sopstvenih podataka: prosečan razmak između prve i druge kupovine iste kategorije, po kupcu, usrednjeno preko dovoljno porudžbina da broj ima smisla. Ta cifra ti je realan ciklus, ne ono što piše na deklaraciji proizvoda ili ono što pretpostavljaš da "valjda traje mesec dana".
Predictive (PRD) i pomoćna lista
Predictive stub postoji samo ako property kvalifikuje, i to je bitna razlika u odnosu na svih pet stubova iznad - ovde ne biraš da li ćeš da ga gradiš, GA4 ti kaže da li si eligible.
| Lista | Definicija | Konfiguracija | Membership | Čemu služi |
|---|---|---|---|---|
| PRD_ALL_LikelyPurchasers_7d | Google ML predikcija kupovine u 7 dana | GA4 UI → Audiences → suggested → Predictive → "Likely 7-day purchasers". Ne postoji kroz API. | 30 dana | gorivo za tROAS |
| PRD_ALL_ChurnRisk_7d | ML predikcija odlaska | isto, "Likely 7-day churning purchasers" | 30 dana | email lista, ne oglasna - churn se leči porukom, ne bid-om |
Uslov za obe: property mora imati dovoljno pozitivnih i negativnih primera - Google traži red veličine 1.000 korisnika koji jesu i 1.000 koji nisu izvršili purchase u prozoru od 28 dana - i model mora ostati "eligible" u kontinuitetu. Male prodavnice ovde jednostavno ne kvalifikuju. To nije greška u setupu koju treba da tražiš i popravljaš; to je pitanje veličine naloga, i vremenom se rešava samo ako nalog naraste.
Pomoćna lista (nije stub, nikad se ne cilja)
| Lista | Definicija | GA4 konfiguracija | Membership | Čemu služi |
|---|---|---|---|---|
| LCY_ALL_ActiveCustomers_45d | kupio u poslednjih 45 dana | Include: purchase (bar jednom) | 45 dana | samo za isključenja u Ads-u (replenishment). Kloniraj na 25 dana za suplemente, na 120 za AtRisk. |
Tri ograničenja GA4 Admin API-ja
Ovo je deo zbog kog ceo tekst postoji. Dokumentacija ova tri ograničenja ne pominje, ili ih pominje usput, u fusnoti koju preskočiš. Na njih udariš tek kad pokušaš da izgradiš 25 lista programski i API vrati grešku - ili gore, ne vrati grešku, nego tiho izgradi nešto drugo od onoga što si tražio.
1. lifetimeValue ne prolazi u audience filterima kroz API
LTV percentile postoji samo kao UI template. Pokušaš isto kroz API i dobiješ grešku - i nema zaobilaznice na istom polju, ono jednostavno nije izloženo API-ju za ovu svrhu. Zaobilaznica je frequency proxy: Champions postaje "3+ kupovine" (eventCount > 2), HighValue postaje "2+ kupovine". Nije isto što i prava vrednost - kupac sa tri jeftine kupovine upada u Champions dok kupac sa jednom skupom ne upada - ali korelira dovoljno da bid odluka bude bolja nego bez ičega. Ako ti stvarno treba prava vrednost, ne gradiš je u GA4. Gradiš je u CRM-u, gde imaš pravu potrošnju po kupcu, i uvoziš je kao Customer Match.
2. Count filteri nemaju klizne prozore
eventCount radi samo uz atAnyPointInTime: true, što znači "ikad", ne "u poslednjih N dana". Ne postoji verzija ovog filtera koja broji događaje unutar pokretnog prozora. Zaobilaznica: prozor koji si hteo da postaviš na broj događaja prebacuješ na membership duration same liste. "2+ kupovine u poslednjih 540 dana" postaje "2+ kupovine ikad" plus membership 540 dana. Rezultat je blizak, ali nije identičan originalnoj nameri - kupac koji je svoje dve kupovine napravio pre tri godine, pa se sad vratio na sajt, ući će u tu listu iako tehnički ne pripada "poslednjih 540 dana" po kupovini. Za većinu remarketing odluka ta razlika ne menja ništa bitno; vredi je znati kad tumačiš zašto je neko u listi.
3. "Nije kupio u poslednjih N dana" se ne gradi u GA4
Ovo je ograničenje koje ruši pola svake win-back i replenishment ideje čim je zapišeš na papir. GA4 exclusion je uvek vezan za membership prozor same liste iz koje isključuješ, pa "temporarily exclude" radi kako očekuješ samo kad se prozori uključenja i isključenja poklapaju - što je slučaj kod INT lista, gde "u poslednjih 14 dana dodao u korpu" i "u poslednjih 14 dana kupio" dele isti window. Kod replenishment i win-back logike prozori se ne poklapaju po definiciji, pa se to jednostavno ne gradi u samom GA4. Zaobilaznica se seli u Google Ads: gradi se kao kombinacija dve liste - ciljna lista MINUS lista aktivnih kupaca. Zato se pomoćna ActiveCustomers definicija klonira na više prozora (45d, 25d, 120d, uz 90d listu koja ionako postoji u lifecycle stubu) - svaki window postoji zato što ga neka ciljna lista negde koristi kao isključenje.
Bonus, ako gradiš kroz API
Shema filtera je uvek andGroup → orGroup → leaf, i to se ne može preskočiti ni za najjednostavniji uslov. Postoji samo GREATER_THAN operator - nema GREATER_THAN_OR_EQUAL, pa "3+" pišeš kao "> 2", ne kao ">= 3". I opis liste je ograničen na otprilike 150 karaktera, što je manje nego što misliš dok ne pokušaš da u opis staviš i definiciju i Ads exclusion napomenu odjednom.
Redosled gradnje, sa proverama
Ne gradiš 25 lista odjednom. Gradiš u talasima, i posle svakog talasa proveravaš da li je prethodni sloj stvaran pre nego što nastaviš dalje - jer ako sloj ispod nije stvaran, sve iznad njega je lista koja pokazuje nulu i nikad neće pokazati ništa drugo.
view_item, add_to_cart, begin_checkout i purchase moraju stizati, GA4 property mora biti povezan sa Google Ads nalogom, Google signals uključen ako ti treba Display doseg. Provera: GA4 → Realtime, uradi test kupovinu, vidi purchase sa vrednošću.
ActiveCustomers_90d, Purchasers_365d i pomoćna ActiveCustomers_45d prve, pa FirstTimeBuyers, RepeatBuyers, EngagedNonBuyers, NewVisitors. Provera: svaka lista postoji, membership prozor je tačan, opis popunjen.
Sve četiri INT liste. Provera: posle 48h CartAbandoners ima članove. Ako nema, add_to_cart ne stiže u GA4 - i tu staješ, jer dalja gradnja bez ovog signala ne rešava ništa.
Kroz UI ako imaš LTV template dostupan, kroz API sa frequency proxy ako nemaš.
Tek posle provere item_brand u GA4. Provera: Explore izveštaj po item_brand za 30 dana - da li vrednosti postoje i da li su konzistentne kroz ceo katalog.
Provera: da li kategorije u feed-u i kategorije u GA4 nose iste tokene. Ako feed kaže "Moisturisers" a GA4 event nosi "moisturizer" ili nešto treće, filter ne pogađa ništa.
Ručno kroz UI, i samo ako je model eligible.
Proveri veličine svih lista, uključi Observation na Shopping i Search kampanjama, zapiši ko je prešao prag isporuke i ko još nije.
Stop pravilo
Ako talas 2 ne proradi - ako CartAbandoners posle 48h nema nijednog člana - dalja gradnja je gubljenje vremena. Publike ne popravljaju tracking. Ako add_to_cart ne stiže čisto u GA4, nijedna od preostalih lista neće raditi bolje, jer sve one zavise od istog sloja eventova koji upravo ne stiže. Popravi event prvo, pa se vrati na talas 3 - ova provera je ujedno najbrža dijagnoza trackinga koju imaš.
Aktivacija: Observation, isključenja, GA4 + CRM
Gradnja lista je pola posla. Druga polovina je redosled u kom ih puštaš da utiču na kampanje, i tu većina naloga koje sam video žuri - stave listu direktno na bid adjustment prvog dana, pre nego što ima dovoljno članova da bilo šta znači.
Prvi korak je uvek isti: sve liste idu prvo kao Observation na Shopping i Search kampanje. Observation nema nikakav uticaj na isporuku - ne sužava ciljanje, ne menja bid - ali posle dve nedelje imaš svoje brojke po publici umesto tuđih benchmark-ova iz nečije studije slučaja. Tek posle toga ide sledeći korak.
Isključenja se uključuju čim liste pređu prag isporuke: ActiveCustomers_90d izlazi iz akvizicionih tokova (nema smisla plaćati za nekoga ko je već kupio prošle nedelje), OneTimeLowValue izlazi iz skupog remarketinga. Bid podešavanja dolaze tek posle punjenja i tek na listama koje već imaju volumen - ne na listi koja tek treba da naraste.
Pravilo koje drži ceo sistem u perspektivi: GA4 je širina, CRM je preciznost. Isti segmenti koje gradiš u GA4 postoje i u tvom email alatu, gde imaš prave RFM cifre - tačan broj porudžbina, tačnu potrošnju po kupcu, ne proxy. Ti segmenti idu u Google Ads kao Customer Match. GA4 lista je aproksimacija izgrađena iz onoga što API dozvoljava. CRM lista je činjenica izgrađena iz onoga što se stvarno desilo. Koristiš obe - GA4 tamo gde ti treba domet i brzina gradnje, CRM tamo gde ti treba tačnost i gde greška u proxy-ju stvarno nešto košta.
| Cilj | Target lista | MINUS (exclusion) |
|---|---|---|
| Vraćanje uspavanih kupaca | LCY_ALL_Purchasers_365d | LCY_ALL_ActiveCustomers_90d |
| Vredan kupac u riziku | VAL_ALL_AtRisk_HighValue_120d | LCY_ALL_ActiveCustomers_120d |
| Ponovna kupovina - krema | RPL_MOI_Due_45-120d | LCY_ALL_ActiveCustomers_45d |
| Ponovna kupovina - suplementi | RPL_SUP_Due_25-75d | LCY_ALL_ActiveCustomers_25d |
| Ponovna kupovina - SPF | RPL_SPF_Due_45-120d | LCY_ALL_ActiveCustomers_45d |
| Čista akvizicija | (bez publike) | LCY_ALL_ActiveCustomers_90d |
| Prospecting Demand Gen | LCY_ALL_EngagedNonBuyers_30d | LCY_ALL_Purchasers_365d |
Najčešća pitanja
Zašto moje publike stoje na nuli?▼
Koliko dugo da čekam pre nego što ih koristim?▼
Da li mi treba Admin API ili može kroz UI?▼
Koji je maksimalni membership prozor?▼
Šta ako prodajem jedan brend?▼
Da li ovo radi za lead-gen, ne samo ecommerce?▼
Da li publike smeju u PMax?▼
Šta ako je moj item_brand prazan?▼
Zaključak
GA4 publike za ecommerce nisu spisak od 25 stavki za prekucavanje, nego sistem sa tri pravila koja nose sve ostalo. Liste se pune od dana kreiranja, pa se grade unapred, a ne u nedelji kad kampanja kreće. Pragovi isporuke odlučuju gde koja lista sme da radi, pa manji nalozi kreću od praga od 100 članova na Display, YouTube i Demand Gen, koji prelazi skoro svaka radnja. A ono što GA4 ne ume - vrednost u filterima, klizni prozori, "nije kupio skoro" - rešava se oduzimanjem lista u Google Ads-u, ne borbom sa API-jem.
Ako iz ovog teksta poneseš jednu akciju, neka bude ova: napravi lifecycle i intent liste danas i pusti ih da se pune dok radiš druge stvari. Za dve do četiri nedelje imaš sloj first-party podataka koji ti nijedan sledeći update platforme ne uzima - i kampanje koje znaju kome pričaju.
Ceo framework, spreman za izvršavanje
Isti framework kao gore, ali u izvršnoj formi - markdown fajlovi koje ubaciš direktno u Claude ili ChatGPT da ti izgrade konfiguraciju po listi, plus PDF za arhivu. Traži se samo email.
Preuzmi izvršnu verzijuPovezani vodiči
Besplatni video audit
Dobijte personalizovani video audit vašeg Google Ads naloga
Snimićemo 15-minutni pregled vaših kampanja gde pokazujemo tačno gde gubite novac i šta bi prvi popravili.
Besplatni personalizovani video audit
Želite video pregled vašeg Google Ads naloga?
Lično ću snimiti 15-minutni video u kome prolazim kroz vaše kampanje, pokazujem gde gubite novac i dajem 3 konkretne stvari za popravku odmah. Bez prodaje — samo vrednost.
Šta dobijate:
- 15-min personalizovana video analiza
- 3 konkretna quick wins za implementaciju
- Preporuke za budžet i bidding
Uslovi:
- Ad spend: €1.500+/mesečno
- Aktivan nalog minimum 3 meseca
- eCommerce ili Lead Gen biznis
Ograničeno na 5 audita mesečno. Odgovor u roku od 48h.