Google Ads brez CAPI: strežniško sledenje konverzij

Meta Conversions API ste nastavili, nakupi tečejo strežniško, Event Match Quality je zelen, in zdaj iščete Googlov CAPI, da bi isto uredili še na drugi polovici oglaševalskega proračuna. Zadetki so strani ponudnikov, ki obljubljajo "Google CAPI" in vam nato prodajo strežniški vsebnik. Takega produkta ni, in to je prva stvar, ki jo je vredno vedeti.

Kar Google Ads ima namesto tega, so štiri ločene funkcije, ki skupaj opravijo, kar Meta zapakira v CAPI: strežniško sledenje konverzij prek nalaganja po kliku, izboljšane konverzije, novi Data Manager API in za vztrajne še GA4 Measurement Protocol. Ta vodič vsak del Meta CAPI preslika v njegovo ime v Google Ads, en upload razloži korak za korakom in pojasni edino pravilo o konverzijskih akcijah, ki odloči, ali strežniško pošiljanje vašemu licitiranju pomaga ali tiho šteje vsako naročilo dvakrat.

Ali obstaja Google Conversions API?

Ne. Google Ads nima produkta z imenom Conversions API, "Google CAPI" pa je ime, ki ga ponudniki uporabljajo za svoje konektorje. Kar Google ponuja, je nalaganje konverzij prek Google Ads API, ki za vsak nakup sprejme ID klika, vrednost in heširane podatke o kupcu, ter izboljšane konverzije, kar je tisti del s heširanimi podatki, poslan iz vaše značke ali strežnika. Od leta 2025 se oboje seli v Data Manager API, Googlov enotni vhod za konverzije in občinstva v Google Ads, Analytics in Marketing Platform.

Zmeda je razumljiva, ker je naloga ista. Meta CAPI obstaja zato, da nakup doseže Meto tudi takrat, ko je brskalniški piksel blokiran, Googlovo nalaganje pa zato, da nakup doseže Google Ads tudi takrat, ko se Googlova značka ni nikoli sprožila. Mehanika se razlikuje v eni pomembni točki: Meta ujema hkrati na več signalih, Google pa ujema predvsem po ID-ju klika in heširane podatke o kupcu uporablja kot drugi ključ.

Google Conversions API ne obstaja. Obstajajo nalaganje konverzij po kliku, izboljšane konverzije in Data Manager API, odločitve pa se skrivajo v tem, kako jih sestavite.

Deli Meta CAPI in njihova imena v Google Ads

Vsako polje, ki ga že pošiljate Meti, ima v Google Ads svoj par, običajno z drugim imenom in včasih z drugačnim pravilom. Spodnja tabela je prevajalna plast, ki jo večina vodičev izpusti.

Zadnjo vrstico si zapomnite. Google Ads je edina platforma, ki vam dovoli konverzijo vzeti nazaj, kar vračila iz opombe v poročilu spremeni v signal za licitiranje, in k temu se spodaj še vrnemo.

Katero strežniško pot v Google Ads naj izbere vaša trgovina?

Za trgovino je prava pot nalaganje konverzij po kliku s pripetimi podatki izboljšanih konverzij, poslano iz sistema, ki ve, da je naročilo resnično. Preostale tri poti se vsaka ustavijo pred tem.

• Izboljšane konverzije prek značke. Googlova značka na strani zahvale hešira kupčev e-naslov in ga pošlje skupaj z brskalniško konverzijo. Poceni za vklop in vredno imeti, a odvisno od tega, da se značka sproži, zato izboljša ujemanje, ne obnovi pa izgubljenih dogodkov. Ko je obiskovalec zavrnil piškotke ali je značko požrl blokator oglasov, se ne pošlje nič.
• Nalaganje po kliku (Google Ads API). Vaš strežnik pošlje ID klika, vrednost naročila, ID naročila in heširane podatke o kupcu v 90 dneh po kliku. V brskalniku ne rabi preživeti nič; vir je naročilo v vaši bazi. To je najbližje CAPI-ju in pot, ki jo uporablja Enalitica.
• Data Manager API. Isto nalaganje prek Googlovega novejšega vhoda, ki streže tudi občinstvom Customer Match in Marketing Platformu. Od 15. junija 2026 so to edina odprta vrata za nove integracije; obstoječe imajo stara vrata še v prehodnem obdobju.
• GA4 Measurement Protocol. Pošiljanje nakupa v GA4 s strežnika in prepustitev uvoza povezavi z Google Ads. Deluje samo, kadar strežniški dogodek nosi iste ID-je odjemalca in seje kot brskalniška seja, sicer ga GA4 uvrsti pod (not set) in Google Ads ne vidi nobenega klika. ID klika, poslan kot parameter, atribucije ne obnovi.

Razlika med drugo in prvo potjo je celoten razlog, zakaj strežniško pošiljanje obstaja. Izboljšana konverzija prek značke izboljša ujemanje pri dogodkih, ki ste jih že zabeležili; nalaganje iz plasti naročil doda dogodke, ki jih brskalnik nikoli ni zabeležil, kar je na strogih trgih EU velik delež vseh nakupov, kot na resničnih trgovinah pokaže naš vodič po sledenju konverzij v WooCommerce.

Kako korak za korakom poteka nalaganje konverzije po kliku?

Nalaganje konverzije po kliku vzame ID klika, ki ga je Google pripel pristajalnemu URL-ju, ga shrani k naročilu in ga s konverzijo pošlje nazaj znotraj 90-dnevnega okna klika. Pet korakov, vsak s svojim načinom odpovedi, ki ga je vredno poznati.

1. Zajemite ID klika ob pristanku. Googlovo samodejno označevanje pripne gclid pri večini klikov ter gbraid ali wbraid pri klikih z iOS, kjer je bilo sledenje zavrnjeno. ID mora biti shranjen v lastniškem piškotku ali shrambi, preden obiskovalec odide naprej, in šele potem, ko to dovoli pasica za soglasje. Same parametre pokriva naš vodič po GCLID, GBRAID in WBRAID.
2. Zapišite ga na naročilo. Ob nakupu shranjeni ID postane metapodatek naročila, poleg kupčevega e-naslova, telefona, imena in naslova. WooCommerce in Shopify sama shranita pristajalni URL nakupne seje, nakup dva dni po kliku pa potrebuje piškotek.
3. Naložite znotraj okna. Konverzija nosi ID klika, čas konverzije (po kliku, nikoli pred njim), vrednost, valuto, order_id in signale soglasja. Klik, starejši od 90 dni, je zavrnjen; gclid iz brezplačnega zadetka v Shoppingu (predpona EAIa) je zavrnjen kot neplačan.
4. Ujemanje in štetje. Google konverzijo pripiše kampanji, skupini oglasov in ključni besedi za klikom ter jo prišteje konverzijski akciji. V poročilih jo pričakujte v približno enem dnevu, pri gbraid in wbraid do 72 ur, in upoštevajte, da povsem nova konverzijska akcija potrebuje nekaj ur, preden Google sploh sprejme nalaganja.
5. Pozneje jo popravite, če se naročilo spremeni. Preklic postane umik, delno vračilo prevrednotenje, oboje z istim order_id. Več o tem spodaj.

Večina postavitev pade na prvem in drugem koraku, ne na tretjem. Če ID klika nikoli ni prišel do naročila, ni kaj naložiti, zato se revizija sledenja konverzij začne s štetjem ID-jev klikov na plačanih naročilih, preden se dotakne kateregakoli API-ja.

Izboljšane konverzije: kaj dodajo heširani podatki o kupcu

Izboljšane konverzije ob ID klika dodajo drugi ključ ujemanja: kupčev e-naslov, telefonsko številko, ime in priimek, poštno številko in državo, vsak podatek normaliziran in heširan s SHA-256, preden zapusti vaš strežnik. Google heše primerja s prijavljenimi računi, kar mu omogoči pripisati nakup, katerega ID klika je bil izgubljen ali se je zgodil na drugi napravi, in mu omogoči šteti konverzije v EGP, ki bi jih pravila o soglasju sicer pustila neštete.

Tri pravila odločijo, ali ti podatki pomagajo ali gredo v koš. Normalizacija se mora natančno ujemati z Googlovo: male črke in obrezani presledki pri e-naslovu in imenih, oblika E.164 s plusom pri telefonskih številkah in ohranjeni šumniki v imenih, ker Google ime hešira tako, kot ga je vpisal lastnik računa. Naslov je vse ali nič: ime, priimek, koda države in poštna številka morajo biti vsi prisotni, sicer je identifikator naslova neveljaven. Račun pa mora v nastavitvah konverzij sprejeti Googlove pogoje za podatke o strankah, kljukico, ki je noben API ne more odkljukati namesto vas; dokler ni sprejeta, vsako nalaganje s podatki o kupcu pade z istim sporočilom o pogojih.

Panožni zapisi tipične stopnje ujemanja postavljajo med 55 in 70 odstotki za ameriški promet in nižje v EU, kjer manj obiskovalcev prestopi vrata soglasja, po vklopu izboljšanih konverzij pa poročajo o 5 do 25 odstotkih več pripisanih konverzij. Oboje berite kot razpone ponudnikov, ne kot obljube. Kar lahko preverite sami, je stopnja ujemanja, ki jo Google v diagnostiki pokaže na konverzijsko akcijo, na strani Enalitice pa, koliko naročil je bilo v zadnjih 30 dneh poslanih, neuspešnih ali preskočenih, tako da se pokvarjena postavitev pokaže kot številka, ne kot slutnja.

Primarna ali sekundarna akcija: kako preprečiti dvojno štetje?

Google vsako primarno konverzijsko akcijo šteje posebej, zato strežniško nalaganje nakupov, ustvarjeno ob obstoječi spletni znački za nakup, isto naročilo poroča dvakrat in Smart Biddingu izroči previsoko število konverzij. order_id vas ne reši, ker Google ID transakcije deduplicira samo znotraj ene konverzijske akcije. Dve akciji, dve štetji.

Pošteni izhodi so dva in samo eden je varen prvi dan. Spletno značko premakniti na sekundarno in licitirati na nalaganju zveni čisto, ampak nalaganje pokrije samo naročila z uporabnim ID-jem klika, zato je prvi dan podmnožica tega, kar vidi značka, in licitiranje nanj bi signal skrčilo. Če na sekundarno premaknete nalaganje, licitiranje računa ostane nedotaknjeno, medtem ko se nova akcija polni v stolpcu Vse konverzije, kjer lahko obe štetji primerjate drugo ob drugem.

Enalitica svoje nalaganje nakupov ustvari kot sekundarno konverzijsko akcijo, kadar ima račun že primarno akcijo za nakup. Preklop na primarno se zgodi pozneje, skupaj z vami, ko je nalaganje polnejši signal.

Sam preklop je petminutna sprememba v seznamu konverzijskih akcij, odločitev pa potrebuje nekaj tednov podatkov: ko naložena akcija v istem obdobju z istimi ID-ji naročil šteje več nakupov kot značka, je postala boljši signal za licitiranje in značka postane opazovalka. Koraki lijaka, kot sta dodajanje v košarico in začetek naročila, ostanejo sekundarni za vedno; so kontekst za poročila, nikoli cilj licitiranja.

Consent Mode v2 v EGP: koliko stane nedoločen signal

Vsaka konverzija, naložena v Google Ads, nosi dve polji soglasja, ad_user_data in ad_personalization, in pri obiskovalcih iz Evropskega gospodarskega prostora Google po njiju ravna. Konverzija, označena kot odobrena, je uporabljena v celoti, vključno s heširanimi podatki o kupcu. Konverzija, označena kot zavrnjena, sploh ne bi smela biti poslana. Konverzija, puščena nedoločena, je dragi primer: Google podatkov o kupcu ne uporabi za ujemanje in je pri prometu iz EGP ne šteje med vaše poročane konverzije.

Skušnjava je očitna in napačna: vse označiti kot odobreno, ker je kupec ob nakupu tako ali tako izročil naslov. Naslov za dostavo je dovoljenje za dostavo paketa, ne dovoljenje Googlu za prilagajanje oglasov, in ko platforma trgovine atribucijo beleži strežniško, so v vaši bazi tudi ID-ji klikov tistih, ki so zavrnili. Poštena izvedba zabeleži, kar je obiskovalec na pasici dejansko odgovoril, in pošlje ta odgovor; kjer ni nihče vprašal, na opt-out trgih, kot so ZDA, je odobreno točno, ker soglasje ni bilo potrebno.

Enalitica stanje pasice shrani z vsakim naročilom in ga razreši po naročilu, po državi kupca, zato slovenska trgovina, ki prodaja ameriškemu kupcu, to naročilo poroča po ameriških pravilih. Kjer je stanje na opt-in trgu neznano, gre nalaganje ven kot nedoločeno in Google ne šteje ničesar, kar je pravična cena za nevednost. Naš prispevek o tem, ali je sledenje brez piškotkov zakonito, pojasni, zakaj se bližnjica ne splača.

Vračila: popravki konverzij naučijo Smart Bidding obdržani prihodek

Vrnjeno naročilo ni konverzija, a skoraj vsak Google Ads račun jo še vedno vodi kot tako, ker so nalaganja v večini postavitev enosmerna. Googlovi popravki konverzij to odpravijo: umik (retraction) konverzijo odstrani v celoti (preklic, vračilo v celoti), prevrednotenje (restatement) pa ji spremeni vrednost (delno vračilo), oboje naslovljeno z order_id izvirnega nalaganja, v približno 54 dneh.

Bistvo je učinek na licitiranje. Smart Bidding optimizira proti vrednosti konverzij, ki jo vidi, zato kampanja, ki prodaja izdelke z dvakrat višjo stopnjo vračil od povprečja, izgleda bolje, kot je, dokler ne pridejo popravki. Z njimi ciljni ROAS licitira na prihodek, ki ste ga obdržali. Naš prispevek o POAS proti ROAS ob vračilih prežene dve kampanji z enakim ROAS in nasprotnima odločitvama, ko v račun vstopijo vračila.

Veljata dve omejitvi. Izvirna konverzija mora biti pri Googlu že obdelana, običajno dan po nalaganju, sicer je popravek zavrnjen kot prezgoden in ga je treba poskusiti znova. Umik pa je dokončen: umaknjene konverzije pozneje ni mogoče prevrednotiti, zato vračilo v celoti pošljite kot umik le, ko je naročilo res v celoti vrnjeno.

Data Manager API v 2026: kaj se spremeni pri nalaganju

Data Manager API je Googlova zamenjava za nalaganje konverzij prek Google Ads API. Od 15. junija 2026 stara storitev za nalaganje ne sprejema novih uporabnikov: razvijalski žeton, ki med decembrom 2025 in majem 2026 ni nalagal konverzij, dobi napako o seznamu dovoljenih, obstoječe integracije pa imajo prehodno obdobje za selitev. Dva meseca prej, aprila 2026, je Google ločeni nastavitvi izboljšanih konverzij za splet in za leade združil v eno stikalo, ki podatke o kupcih sprejema hkrati iz značke, iz Data Managerja in iz API-ja.

Za lastnika trgovine je sprememba večinoma nevidna, je pa pošteno vprašanje za vsako orodje, ki ga plačujete: kateri Googlov vhod uporablja vaše nalaganje in kdaj je datum vaše selitve? Orodje, ki ne zna odgovoriti, bo nehalo pošiljati konverzije, ko se njegovo okno zapre. Enalitica nalaga prek Googlove storitve za nalaganje konverzij, ki jo Google obstoječim integracijam ohranja odprto, prehod na Data Manager pa je načrtovan kot enakovredna zamenjava: isti ID-ji klikov, isti heširani podatki, isti signali soglasja, isti ID-ji naročil.

Vhod je manj pomemben od štirih stvari, ki jih nosi. Kakorkoli bo Google naslednjič preimenoval, konverzija, ki pride z ID-jem klika, ID-jem transakcije, pravilno heširanimi podatki o kupcu in poštenim signalom soglasja, bo šteta, tista brez njih pa ne.

Kako Enalitica pošilja Google Ads konverzije iz potrjenih naročil

Enalitica vsako potrjeno naročilo pošlje v Google Ads iz zapisa naročila, ne iz brskalnika: ID klika, zajet ob pristanku in shranjen 90 dni v lastniškem piškotku, vrednost in valuto naročila, številko naročila iz trgovine kot order_id, heširan e-naslov, telefon, ime in naslov za izboljšano ujemanje ter stanje soglasja, ki ga je obiskovalec dal na pasici. Naročila brez Googlovega ID-ja klika niso poslana in so prikazana kot preskočena, ker se nalaganje brez klika ne ujema z ničimer.

Postavitev vzame minute in ne razvijalskega sprinta. Dovolj je povezava Google Ads prek OAuth: ob prvem pošiljanju Enalitica poišče ali ustvari konverzijsko akcijo z imenom "Enalitica Purchase API", preveri, ali račun že licitira na drugi akciji za nakup, in v tem primeru svojo ustvari kot sekundarno. Zavihek Strežniško sledenje nato po platformah pokaže, ali pošiljanje deluje, koliko nakupov, povpraševanj in dogodkov lijaka je šlo ven v zadnjih 30 dneh, koliko jih je bilo preskočenih in zakaj, ter vodič za odpravo, kadar Google nalaganja blokira, najpogosteje zato, ker pogoji za podatke o strankah niso bili nikoli sprejeti.

Ista pot služi storitvenim podjetjem: povpraševanje z Googlovim ID-jem klika se naloži v ločeno akcijo "Enalitica Events API" s heširanim e-naslovom, tako da se Google Ads nauči, katere ključne besede prinašajo povpraševanja in ne samo klikov. Vsako noč zagon za dohitevanje znova poskusi vse, kar je Google zavrnil kot prezgodnje, drugi zagon pa naloži umike in prevrednotenja za naročila, ki so bila preklicana ali vrnjena. In ker ista naročila hranijo poročilo o atribuciji, vidite štetje platforme in lastno štetje naročil na enem zaslonu, primerjavo, za katero naš prispevek o modeliranih konverzijah proti resničnim naročilom trdi, da bi jo moral imeti odprto vsak lastnik.

Kontrolni seznam: strežniško sledenje konverzij v Google Ads

Osem preverjanj v vrstnem redu, v katerem naj jih trgovina opravi, preden zaupa strežniški postavitvi za Google Ads.

1. Samodejno označevanje je v Google Ads vklopljeno, pristajalna stran pa gclid, gbraid in wbraid ohrani skozi vsako preusmeritev.
2. ID klika je po soglasju shranjen lastniško in živi vsaj 90 dni, ne samo za sejo.
3. Vsako plačano naročilo nosi ID klika v svojih metapodatkih; delež, ki ga nosi, je vaša resnična pokritost.
4. Nalaganja nosijo order_id, čas konverzije po kliku, vrednost, valuto in heširane podatke o kupcu, normalizirane po Googlovo.
5. Pogoji za podatke o strankah so sprejeti v nastavitvah konverzij; brez njih so izboljšani podatki zavrnjeni.
6. Natanko ena akcija za nakup je primarna; nalaganje začne kot sekundarno, kadar spletna značka že licitira.
7. Signali soglasja odražajo odgovor na pasici po naročilu; na opt-in trgih ni nič privzeto označeno kot odobreno.
8. Vračila in preklici gredo nazaj kot popravki, orodje, ki ga uporabljate, pa je imenovalo datum svoje selitve na Data Manager.

Pogosta vprašanja

Ali obstaja Google CAPI, podoben Meta CAPI?

Ne. Google Ads nima produkta z imenom Conversions API. Ustreznica je nalaganje konverzij v Google Ads (ID klika, vrednost, ID naročila in heširani podatki o kupcu, poslani z vašega strežnika), izboljšane konverzije za heširane podatke in od leta 2026 Data Manager API kot enotni vhod. Orodja, ki oglašujejo "Google CAPI", opisujejo svoj konektor do enega od teh.

Kaj je CAPI v marketingu?

CAPI pomeni Conversions API, Metin način poročanja dogodkov, kot so nakupi in povpraševanja, oglasom na Facebooku in Instagramu neposredno s strežnika na strežnik, brez zanašanja na brskalniški piksel. V marketingu je beseda postala okrajšava za vsako strežniško pošiljanje konverzij, vključno z ustreznicami v Google Ads iz tega vodiča, zato se "Google CAPI" išče, čeprav produkt ne obstaja.

Ali lahko nakupe v Google Ads pošiljam iz CRM-ja?

Da, dokler zapis v CRM-ju hrani Googlov ID klika, zajet ob prihodu povpraševanja, ali kupčev e-naslov za izboljšane konverzije za leade. Nalaganje nosi ID klika ali heširan e-naslov, čas in vrednost konverzije ter pristane v 90 dneh po kliku. Enalitica to za storitvena podjetja naredi samodejno: povpraševanje z ID-jem klika se naloži v namensko konverzijsko akcijo z vrednostjo, ki ste jo določili tej vrsti dogodka.

Ali še potrebujem Google Ads značko, če konverzije nalagam?

Obdržite jo. Značka daje brskalniško konverzijo, ki licitira od prvega dne, hrani sezname za remarketing in pokrije naročila, pri katerih je bil ID klika izgubljen, značka pa se je vseeno sprožila. Nalaganje doda naročila, ki jih značka nikoli ni videla. Poganjajte oboje, natanko eno imejte primarno in njuni štetji primerjajte v stolpcu Vse konverzije, preden odločite, katero licitira.

Ali strežniško pošiljanje obide soglasje za piškotke?

Ne, in orodje, ki trdi, da ga, daje pravno trditev, ne tehnične. ID klika se bere z obiskovalčeve naprave, kar na opt-in trgih zahteva soglasje, nalaganje pa nosi signale Consent Mode, po katerih Google pri uporabnikih iz EGP ravna. Strežniško pošiljanje spremeni, od kod podatki odidejo, ne pa, ali ste jih smeli zbrati.

Uvoz konverzij zunaj spleta ali izboljšane konverzije za leade?

Uvoz konverzij zunaj spleta ujema po ID-ju klika, ki ste ga shranili k povpraševanju; izboljšane konverzije za leade ujemajo po heširanem e-naslovu ali telefonski številki, ki jo je stranka vpisala v obrazec, zato delujejo tudi, ko ID klika ni bil zajet, in obnovijo tudi konverzije med napravami in po angažiranem ogledu. Google za nove postavitve povpraševanj priporoča drugo, prva ostaja na voljo. Izboljšane konverzije za leade ne delujejo z gbraid ali wbraid, samo z gclid ali s podatki o stranki.

Kdaj se naložena konverzija pojavi v Google Ads?

Običajno v enem dnevu za konverzije z gclid in do 72 ur za gbraid in wbraid. Na novo ustvarjena konverzijska akcija potrebuje več ur, preden Google sprejme prva nalaganja, popravek pa je mogoče uveljaviti šele, ko je izvirna konverzija obdelana, zato nalaganje s takojšnjim umikom pade in ga je treba naslednji dan poskusiti znova.

Ali Data Manager API potrebujem že zdaj?

Če gradite novo integracijo, da: od 15. junija 2026 storitev za nalaganje v Google Ads API zavrača razvijalske žetone brez predhodnih nalaganj konverzij. Če uporabljate obstoječe orodje, ga vprašajte, kateri vhod uporablja in kdaj se seli. V tem, kar mora konverzija vsebovati, se ne spremeni nič; ID klika, ID naročila, heširani podatki o kupcu in signali soglasja so na obeh vhodih isti.