# GTM data layer WooCommerce: sujungti su GA4 ir Google Ads

*Paskelbta: 2026-10-14  |  https://www.mycode.lt/gtm-data-layer-woocommerce/*

> GTM data layer WooCommerce: įvykių struktūra, papildinys ar savas kodas, testavimas Preview režimu ir klaidos, gadinančios GA4 bei Google Ads duomenis.

**GTM data layer** yra JavaScript objektas (`window.dataLayer`), į kurį WooCommerce parduotuvė sudeda struktūrizuotus e-komercijos duomenis: peržiūrėtą produktą, krepšelio turinį, užsakymo sumą ir prekių sąrašą. Google Tag Manager tuos duomenis perskaito ir vienu metu perduoda ir GA4, ir Google Ads konversijų žymoms. Tai vienintelis būdas, kad abi sistemos rodytų tą pačią pirkimų sumą, nes duomenys rašomi vieną kartą ir iš vieno šaltinio. Šiame straipsnyje surašiau, kokia turi būti įvykių struktūra, kada užtenka papildinio, o kada reikia savo kodo, kaip viską patikrinti Preview režime ir kokias klaidas randu dažniausiai.

## Kaip veikia GTM data layer e-komercijoje

Grandinė yra trijų dalių. WooCommerce (per papildinį arba jūsų kodą) tam tikru momentu įvykdo `dataLayer.push()` su įvykio pavadinimu ir `ecommerce` objektu. GTM konteineris pagal įvykio pavadinimą paleidžia trigerį, o kintamieji ištraukia reikiamus laukus: sumą, valiutą, užsakymo numerį, prekių masyvą. Tada žymos tuos laukus išsiunčia: GA4 žyma į Analytics, Google Ads žyma į konversijų sekimą ir remarketingo sąrašus.

Svarbiausia idėja: data layer e-komercijoje yra vienas tiesos šaltinis. Jei GA4 papildinys ima duomenis iš vienos vietos, o Google Ads kodas įdėtas tiesiai į temos failą ir skaičiuoja sumą savaip, po mėnesio turėsite dvi skirtingas ataskaitas ir ginčą, kuri teisinga. Kai abi žymos skaito tą patį objektą, skirtumų nelieka. Pagrindus, kaip veikia konteineris, žymos ir trigeriai, aprašiau straipsnyje [Google Tag Manager nuo nulio](https://www.mycode.lt/google-tag-manager-nuo-nulio/), čia į tai nebegrįšiu.

## Kokia turi būti įvykio struktūra

GA4 e-komercija naudoja fiksuotą schemą. Jei laukas pavadintas kitaip, GA4 jo tiesiog nematys, o Google Ads žyma neturės iš kur paimti sumos. Pirkimo įvykis WooCommerce padėkos puslapyje turi atrodyti taip:

- `event: "purchase"` – įvykio pavadinimas, pagal kurį GTM paleidžia trigerį;
- `ecommerce.transaction_id` – WooCommerce užsakymo numeris, pagal jį GA4 ir Ads atmeta pasikartojimus;
- `ecommerce.value` – užsakymo suma skaičiumi (ne tekstu su € ženklu);
- `ecommerce.currency` – `"EUR"`, be jos GA4 pajamų ataskaitos lieka tuščios;
- `ecommerce.tax` ir `ecommerce.shipping` – PVM ir pristatymas atskirai;
- `ecommerce.items` – masyvas, kuriame kiekviena prekė turi `item_id`, `item_name`, `price`, `quantity` ir `item_category`.

Prieš kiekvieną e-komercijos įvykį reikia įvykdyti `dataLayer.push({ ecommerce: null })`. Be šito GTM sujungia seną ir naują `ecommerce` objektą, ir į `add_to_cart` įvykį patenka prekės iš ankstesnio `view_item`. Tai viena iš dažniausių priežasčių, kodėl GA4 rodo daugiau prekių krepšelyje, nei iš tikrųjų buvo.

Toliau lentelėje – kurie laukai kuriam įrankiui būtini. Pilną GA4 įvykių sąrašą nuo `view_item_list` iki `purchase` aprašiau straipsnyje apie [GA4 e-komercijos sekimą WooCommerce](https://www.mycode.lt/ga4-e-komercijos-sekimas-woocommerce/), todėl čia lieka tik tai, kas svarbu sujungimui.

| Įvykis | Laukai, be kurių neveikia | Kas naudoja |
|---|---|---|
| view_item | items[0].item_id, price, currency | GA4 ataskaitos, Ads dinaminis remarketingas |
| add_to_cart | items, value, currency | GA4 piltuvėlis, Ads „krepšelio“ auditorija |
| begin_checkout | items, value, currency | GA4 piltuvėlis, Ads paliktų krepšelių auditorija |
| purchase | transaction_id, value, currency, tax, shipping, items | GA4 pajamos, Ads konversija ir pirkėjų auditorija |

## Ką Google Ads ima iš to paties data layer

Google Ads konversijų žymai GTM konteineryje reikia trijų kintamųjų: konversijos vertės, valiutos ir užsakymo numerio. Visus tris sukuriu kaip „Data Layer Variable“ tipo kintamuosius su keliais `ecommerce.value`, `ecommerce.currency` ir `ecommerce.transaction_id`. Tie patys kintamieji naudojami ir GA4 žymoje, todėl sumos sutampa iki cento.

Užsakymo numeris Ads žymoje yra ne formalumas. Kai pirkėjas po apmokėjimo perkrauna padėkos puslapį arba grįžta į jį iš el. laiško, `purchase` įvykis įvyksta antrą kartą. Google Ads, matydamas tą patį `transaction_id`, antrą konversiją atmeta. Be jo kiekvienas perkrovimas tampa nauja konversija, o kampanijos ROAS atrodo geriau, nei yra.

Dinaminiam remarketingui Ads žymai papildomai reikia prekių masyvo su `id` ir `google_business_vertical: "retail"`. Čia svarbiausia, kad `item_id` data layer sutaptų su prekės ID Merchant Center feede. Jei feedas naudoja SKU, o data layer – WooCommerce produkto ID, Ads nesugebės sujungti peržiūrėtos prekės su skelbimo kortele. Kaip formuojamas feedas ir kurį identifikatorių rinktis, rašiau straipsnyje apie [Merchant Center prekių feedą](https://www.mycode.lt/merchant-center-woocommerce-prekiu-feed/).

## Papildinys ar savas kodas?

Google Tag Manager WooCommerce parduotuvėje galima sujungti dviem būdais. Pirmas – papildinys, kuris pats formuoja data layer pagal WooCommerce puslapius (pvz., GTM4WP). Antras – savo kodas per WooCommerce kablius: `woocommerce_thankyou` pirkimui, `woocommerce_after_single_product` produkto peržiūrai, `wp_footer` krepšeliui ir atsiskaitymui. Rinktis padeda ši lentelė.

| Kriterijus | Papildinys | Savas kodas |
|---|---|---|
| Diegimo laikas | 1–2 val. | 4–8 val. priklausomai nuo įvykių skaičiaus |
| Standartiniai GA4 įvykiai | Yra iš karto | Rašomi rankomis |
| Nestandartinė tema ar krepšelis (AJAX, mini krepšelis, blokinis checkout) | Dalis įvykių gali nesuveikti | Pritaikoma tiksliai |
| Papildomi laukai (marža, prekės ženklas, kliento tipas) | Ribota | Bet kokie laukai |
| Priežiūra atnaujinant WooCommerce | Atnaujina papildinio autorius | Tikrinu pats po didesnių atnaujinimų |
| Kam tinka | Standartinė parduotuvė su įprasta tema | Individualus krepšelis, B2B kainos, kelios valiutos |

Mano praktikoje daugumai parduotuvių pakanka papildinio, bet jį vis tiek reikia sukonfigūruoti: įjungti e-komercijos įvykius, pasirinkti, kurį identifikatorių siųsti kaip `item_id`, ir išjungti dubliuojančius įvykius, jei tema jau turi savo GA4 sekimą. Savo kodo imuosi tada, kai krepšelis perrašytas, naudojamas blokinis checkout su papildomais žingsniais arba reikia laukų, kurių papildinys nemoka suformuoti. Dažniausiai tai būna hibridas: papildinys formuoja standartinius įvykius, o vienas trumpas mano fragmentas prideda trūkstamus laukus prie `purchase`.

## Kaip testuoti Preview režimu

GTM Preview (Tag Assistant) yra pagrindinis įrankis, be kurio data layer diegimo laikau nebaigtu. Eiga, kurią kartoju kiekvieną kartą:

- **Įjungiu Preview** konteineryje ir atidarau parduotuvę per Tag Assistant langą. Kairėje atsiranda visų puslapio įvykių sąrašas.
- **Pereinu visą pirkimo kelią**: kategorija, produktas, įdėjimas į krepšelį, krepšelis, atsiskaitymas, apmokėjimas testiniu būdu. Kiekviename žingsnyje sąraše turi atsirasti atitinkamas įvykis: `view_item_list`, `view_item`, `add_to_cart`, `begin_checkout`, `purchase`.
- **Atidarau „Data Layer“ skirtuką** prie kiekvieno įvykio ir tikrinu laukus: ar `value` yra skaičius, ar `currency` yra EUR, ar `items` ne tuščias, ar variacijos atveju `item_id` rodo variaciją, o ne tėvinį produktą.
- **Tikrinu „Tags“ skirtuką**: prie `purchase` turi suveikti ir GA4 žyma, ir Google Ads konversijų žyma, o „Variables“ skirtuke jų kintamieji turi rodyti tas pačias reikšmes.
- **Perkraunu padėkos puslapį** ir žiūriu, ar `purchase` nesuveikia antrą kartą. Jei suveikia, papildinyje įjungiu apsaugą nuo dubliavimo arba kode tikrinu užsakymo meta lauką.
- **GA4 DebugView** lange patikrinu, kad įvykiai atėjo su parametrais, o Google Ads konversijų skiltyje po kelių valandų – kad konversija užfiksuota su teisinga suma.

Testinį užsakymą po patikros atšaukiu arba trinu, kad nepatektų į WooCommerce ataskaitas. Jei parduotuvė naudoja Consent Mode, visą ciklą kartoju du kartus: sutikęs su slapukais ir atsisakęs. Antru atveju GA4 žyma turi veikti tik ribotu režimu, o Ads konversija – be slapukų, kaip aprašyta straipsnyje apie [slapukų sutikimą pagal BDAR](https://www.mycode.lt/slapuku-sutikimas-bdar-svetainei/).

## Dažnos klaidos, kurias randu audituodamas

- **Trigeris ant puslapio peržiūros, o ne ant įvykio.** GA4 purchase žyma paleidžiama pagal URL `/order-received/`, bet suveikia anksčiau, nei papildinys spėja įvykdyti `push()`. Rezultatas: konversija be sumos. Trigeris turi būti „Custom Event“ su pavadinimu `purchase`.
- **Du sekimo šaltiniai.** Tema ar atskiras GA4 papildinys siunčia savo įvykius, o GTM – savo. GA4 rodo dvigubai daugiau pirkimų. Kaip teisingai sutvarkyti vieną šaltinį, aprašiau straipsnyje apie [GA4 konfigūraciją WordPress svetainėje](https://www.mycode.lt/google-analytics-4-wordpress-konfiguracija/).
- **Suma su PVM vienoje žymoje, be PVM kitoje.** Sutarkite iš anksto: GA4 `value` paprastai yra bendra užsakymo suma, o `tax` ir `shipping` eina atskirai. Ads žymai perduokite tą patį `value`, ne kitą kintamąjį.
- **Nesutampantys prekių ID.** Data layer siunčia WooCommerce ID, Merchant Center – SKU. Dinaminis remarketingas „veikia“, bet rodo ne tas prekes arba nerodo nieko.
- **Kintamasis ne „Version 2“.** Senas Data Layer Variable formatas nemoka skaityti įdėtų objektų, todėl `ecommerce.items` grąžina undefined.
- **Tuščias items masyvas variacijoms.** Dalis papildinių prie variacinio produkto neperduoda pasirinktos variacijos. Tikrinkite Preview lange būtent su variaciniu produktu.
- **Konteineris paskelbtas be versijos aprašymo.** Po pusmečio niekas nebežino, kodėl kuri žyma pridėta. Kiekvienas „Publish“ – su trumpa pastaba, ką keitėte.

Bendra taisyklė: kiekviena iš šių klaidų matoma Preview režime per penkias minutes, bet ataskaitose išlenda tik po kelių savaičių, kai kampanijų biudžetas jau paskirstytas pagal klaidingus skaičius.

## Kaip galiu padėti

GA4 ir Google Tag Manager diegimą WooCommerce parduotuvei darau kaip vieną darbą: konteineris, e-komercijos įvykiai, data layer, Google Ads konversijų žymos ir Consent Mode. Kaina – 140 €, papildomi įvykiai ar nestandartiniai laukai – 30 €/val. Į naujus vidutinio dydžio e-parduotuvės projektus šis sekimas jau įeina. Jei parduotuvė jau turi sekimą, bet GA4 ir Ads skaičiai nesutampa, pirmiausia pereinu Preview ciklą ir surašau, kas konkrečiai neveikia. Daugiau apie paslaugą – [Google Tag Manager diegimas](https://www.mycode.lt/google-tag-manager/).

## Dažniausiai užduodami klausimai

### Kas yra GTM data layer paprastais žodžiais?

Tai JavaScript objektas puslapyje, į kurį svetainė sudeda struktūrizuotus duomenis: kokį produktą lankytojas peržiūrėjo, ką įsidėjo į krepšelį, už kiek nupirko. Google Tag Manager tuos duomenis perskaito ir perduoda GA4, Google Ads ar kitiems įrankiams. Svetainė duomenis rašo vieną kartą, o kas juos naudoja, sprendžiama GTM konteineryje.

### Ar WooCommerce pati siunčia duomenis į data layer?

Ne. WooCommerce be papildinio dataLayer objekto nekuria. Reikia arba GTM papildinio WooCommerce parduotuvei, arba savo kodo, kuris per WooCommerce kablius suformuoja įvykius. Abu variantai veikia, skiriasi tik lankstumas ir kiek reikia prižiūrėti.

### Ar Google Ads konversijoms reikia atskiro data layer?

Nereikia. Google Ads konversijos žyma ima tą patį purchase įvykį: sumą, valiutą ir užsakymo numerį. Svarbu tik, kad GTM kintamieji būtų nukreipti į tuos pačius laukus, kuriuos naudoja GA4, tada abi sistemos rodys tą pačią sumą.

### Kodėl GA4 ir Google Ads rodo skirtingą pirkimų sumą?

Dažniausios priežastys trys: Google Ads žyma siunčia sumą su PVM ir pristatymu, o GA4 be jų; purchase įvykis dubliuojasi perkrovus padėkos puslapį ir tik viena sistema atmeta pasikartojantį užsakymo numerį; arba Consent Mode leidžia vienai žymai veikti be sutikimo, o kitai ne. Visas tris matote Preview režime.

### Kaip patikrinti data layer be tikro pirkimo?

Įjunkite mokėjimo būdą „apmokėjimas gavus“ arba testinį mokėjimų režimą, atlikite užsakymą ir stebėkite GTM Preview langą. Purchase įvykis turi atsirasti vieną kartą padėkos puslapyje su teisinga suma ir prekių sąrašu. Testinį užsakymą po to atšaukite, kad nepatektų į ataskaitas.

### Ar data layer reikia keisti, kai pridedu naują mokėjimo ar pristatymo būdą?

Paprastai ne. Data layer ima sumas iš užsakymo objekto, todėl naujas mokėjimo būdas automatiškai patenka į tuos pačius laukus. Pakeitimo reikia tik tada, kai keičiasi pats padėkos puslapis, pavyzdžiui, mokėjimų tarpininkas nukreipia į kitą URL ir purchase įvykis nebesuveikia.