Google Tag Manager gtag config-ის ცვლილება: რა შევამოწმოთ საიტზე

თუ თქვენი საიტი Google Tag Manager-ს იყენებს, Google ცვლის, როგორ ეშვება Tag Manager თქვენს გვერდებზე. 2026 წლის 8 ოქტომბრის გამოშვების ჩანაწერში Google წერს, რომ Tag Manager-ის ყველა კონტეინერი (Tag Manager-ის ის ადგილი, სადაც თქვენი საიტის ტეგები ინახება) ჩატვირთვისთანავე გაეშვება და გვერდზე gtag('config') ბრძანებას აღარ დაელოდება. Google Tag Manager gtag config-ის ეს ცვლილება ყველაზე მეტად ეხება საიტებს, სადაც Tag Manager Google-ის ტეგის ცალკე კოდთან ერთად მუშაობს, და კონტეინერებს წესებით (ტრიგერებით), რომლებიც ტეგებს ნებისმიერ მოვლენაზე უშვებს.

Google-მა წერილები გაუგზავნა იმ კონტეინერების მფლობელებს, რომლებსაც არასწორად დაყენებულად თვლის. რამდენია ასეთი, Google-ს არ გამოუქვეყნებია, მისი ცნობარი კი გასწორების შესახებ ჯერაც ამბობს, რომ განახლება “მალე” გამოვა.

რა შეიცვალა Google Tag Manager-ში 8 ოქტომბერს?

Google-ის თქმით, Tag Manager-ის კონტეინერები აღარ დაელოდება gtag('config') ხაზს, ანუ ბრძანებას, რომელიც Google-ის ტეგს ეუბნება, რომელ ანგარიშზე და რა პარამეტრებით გაგზავნოს მონაცემები. 8 ოქტომბრის გამოშვების ჩანაწერში (ქართული ვერსია არ არსებობს, თარგმანი ჩვენია) წერია: Google Tag Manager-ის (gtm.js) კონტეინერის ყველა ფრაგმენტი კონტეინერის ჩატვირთვისას ინიციალიზდება, gtag(‘config’) ბრძანებების მიუხედავად.

ფრაგმენტი არის კოდის რამდენიმე ხაზი, რომელიც საიტის ყველა გვერდზეა ჩასმული. ტეგი არის კოდის პატარა ნაწილი, რომელიც აღრიცხავს, რა ხდება საიტზე, მაგალითად გვერდის ნახვას ან ფორმის გაგზავნას. ტეგი ამ ინფორმაციას აგზავნის ისეთ ინსტრუმენტში, როგორიცაა Google Analytics ან Google Ads. საიტს Google-ის ტეგების ჩატვირთვა ორიდან ერთი ფრაგმენტით შეუძლია:

ორივე ფრაგმენტი წერს dataLayer-ში, გვერდზე შეტყობინებების რიგში, რომელსაც Tag Manager კითხულობს. აქამდე კონტეინერს შეეძლო გვერდის სხვა ადგილას gtag('config') ხაზი შეენიშნა და დალოდებოდა მას, და ზოგი საიტი ამას ეყრდნობოდა. გამოშვების ჩანაწერი იმასაც ცვლის, რას ხედავს კონტეინერი: config ბრძანებები dataLayer-ში ხილული gtag.config მოვლენების სახით გამოჩნდება.

რომელ საიტებს ეხება Google Tag Manager gtag config-ის ცვლილება?

ცვლილება საიტების ორ ჯგუფს ეხება. Google-ის წერილები პირველმა ჯგუფმა მიიღო, რომელსაც Google-ის სიტყვებით “მხარდაუჭერელი დანერგვა” აქვს. მეორე ჯგუფის დაყენება შეიძლება Google-ის აზრით სწორი იყოს, მაგრამ მას აქვს წესები (ტრიგერები), რომლებიც ტეგებს ნებისმიერ მოვლენაზე უშვებს.

შერეული დაყენება. Google-ის ცნობარი gtag.js-ის დაყენების შესახებ აღწერს საიტებს, რომლებიც G-, AW- ან DC ID-ს Tag Manager-ის ფრაგმენტის გზით ტვირთავს. არასწორი დაყენების მის მაგალითში სტანდარტული GTM- ფრაგმენტია, მის შემდეგ კი ცალკე gtag('config') ხაზი. ასეთ საიტებზე, Google-ის თქმით, ტეგების მუშაობაში “შეიძლება მოულოდნელი ცვლილებები იყოს”, მათმა მფლობელებმა კი “ელფოსტით შეტყობინება მიიღეს” (თარგმანი ჩვენია).

ყველა მოვლენის ტრიგერები. ტრიგერი არის წესი, რომელიც ტეგს ეუბნება, როდის ამოქმედდეს. მომხმარებლის მოვლენის ტრიგერს შეუძლია მოვლენების სახელები .* შაბლონით შეადაროს, რომელიც dataLayer-ის ნებისმიერ მოვლენას ემთხვევა. Google-ის გამოშვების ჩანაწერი აფრთხილებს (თარგმანი ჩვენია): თუ თქვენს Google Tag Manager-ის კონტეინერებში ყველა მოვლენის მომხმარებლის მოვლენის ტრიგერებია, ამ ცვლილებამ შეიძლება ეს ტეგები აამოქმედოს.

Google-ის ცნობარი მომხმარებლის მოვლენის ტრიგერებზე ისედაც უფრო ვიწრო შაბლონს გვირჩევდა, რადგან .* იმ მოვლენებსაც ემთხვევა, რომლებსაც Tag Manager და Google-ის ტეგი ავტომატურად აგზავნის. PPC Land აღნიშნავს, რომ ასეთი ტრიგერების რისკი იმ საიტებსაც ეხება, რომელთა დაყენებაც Google-ის აზრით სწორია, რადგან სტანდარტული gtag.js ფრაგმენტი თავად შეიცავს config ბრძანებას.

როდის გამოაცხადა Google-მა gtag config-ის ცვლილება?

გაფრთხილება გამოშვების ჩანაწერამდე რამდენიმე კვირით ადრე გამოჩნდა. PPC News Feed-მა Google-ის ცნობარში გაფრთხილების შესახებ 2026 წლის 27 აგვისტოს დაწერა. 20 აგვისტოს WordPress.org-ის მხარდაჭერის ფორუმის მომხმარებელმა გამოაქვეყნა წერილი, რომელიც კლიენტმა Google-ისგან მიიღო. წერილში ეწერა (თარგმანი ჩვენია): 2026 წლის 2 ოქტომბრიდან gtm.js-ის ყველა ფრაგმენტი კონტეინერის ჩატვირთვისას ინიციალიზდება.

გამოშვების ჩანაწერი 8 ოქტომბრით არის დათარიღებული. Google-ის ცნობარი გასწორების შესახებ ჯერაც ამბობს, რომ Tag Manager-ის ფრაგმენტები “მალე განახლდება”. როგორც PPC Land და Relevant Audience აღნიშნავენ, Google-ს არ უთქვამს, ცვლილება ყველა კონტეინერს ერთ დღეს შეეხო თუ ეტაპობრივად ინერგება.

რა არ უთქვამს Google-ს

Google-ს საბოლოო ვადა არ დაუსახელებია და არც ის შეუფასებია, მონაცემების რა ნაწილს შეიძლება შეეხოს ცვლილება. Relevant Audience აღნიშნავს, რომ გამოშვების ჩანაწერში ქვეყნების ან რეგიონების შეზღუდვა არ არის ნახსენები, და არც გასწორების ცნობარი ასახელებს მას.

არის პრაქტიკული ხარვეზიც. წერილი იმას მივიდა, ვინც კონტეინერშია მითითებული. Relevant Audience ყურადღებას ამახვილებს: თუ ეს ყოფილი თანამშრომელი ან წინა ვებდეველოპერია, გაფრთხილება შეიძლება ვერასდროს მისულიყო იმამდე, ვინც საიტს დღეს მართავს.

რას ნიშნავს ეს თქვენი ბიზნესისთვის

ჩვენი აზრით, ეს თვალთვალის დაყენების ყურადღებით შემოწმების საბაბია. ამოცანაა, შეამოწმოთ, რას ტვირთავს თქვენი გვერდები, შერეული დაყენების შემთხვევაში აირჩიოთ Google-ის ორი გასწორებიდან ერთი და დარწმუნდეთ, რომ ყოველი მოთხოვნა ერთხელ ითვლება. ჩვენ ამ ნაბიჯებს ამ თანმიმდევრობით გადავდგამდით, სარეკლამო ანგარიშებში რაიმეს შეცვლამდე.

1. გაარკვიეთ, ვის ეკუთვნის კონტეინერი. რაიმეს შესამოწმებლად Tag Manager-ზე წვდომა გჭირდებათ, მფლობელი კი ბიზნესი უნდა იყოს, სააგენტო მომხმარებლად დამატებული. ჩვენს სტატიაში, როგორ შევაფასოთ მარკეტინგული სააგენტო, ვხსნით, რატომ უნდა იყოს ანგარიშები თქვენთან.
2. ნახეთ, რა ფრაგმენტს ტვირთავს გვერდები. გახსენით საიტი, ნახეთ გვერდის საწყისი კოდი და მოძებნეთ “googletagmanager.com”. თუ მისამართში gtm.js-ია GTM-ით დაწყებული ID-ით, თქვენი კონტეინერი მხარდაჭერილი გზით არის დაკავშირებული. თუ gtm.js-ში G-, AW- ან DC ID-ია, ან Tag Manager-ის ფრაგმენტის გვერდით ცალკე gtag('config') ხაზია, თქვენ ის დაყენება გაქვთ, რომლის შესახებაც Google აფრთხილებდა.
3. აირჩიეთ Google-ის ორი გასწორებიდან ერთი. ჩასვით Google-ის ტეგის (gtag.js) ფრაგმენტი ყველა გვერდზე და წაშალეთ gtm.js ფრაგმენტი და ყველა ცალკე config ხაზი. ან, თუ Tag Manager თქვენს სხვა ტეგებს მართავს, დატოვეთ ფრაგმენტი თქვენი GTM- ID-ით და Google-ის ტეგი კონტეინერის შიგნით დააყენეთ. გადაიტანეთ ყველა პარამეტრი, რომელსაც ძველი config ხაზი გადასცემდა, და cookie-ზე თანხმობის დაყენება ხელუხლებლად დატოვეთ, რომ ტეგები კვლავ ითვალისწინებდეს ვიზიტორის არჩევანს cookie-ბანერში.
4. მოძებნეთ კონტეინერში .* ტრიგერები. გახსენით ტრიგერების სია და მოძებნეთ მომხმარებლის მოვლენის ტრიგერები, რომლებიც ყველა მოვლენას ემთხვევა. თითოეული შეზღუდეთ მისთვის საჭირო მოვლენების სახელებამდე, რადგან gtag.config-ზე ამოქმედებულმა ტეგმა შეიძლება იგივე მონაცემები ხელახლა გაგზავნოს და, მაგალითად, ერთი მოთხოვნა ორად დაითვალოს.
5. შეამოწმეთ Tag Assistant-ით და რეალური მოთხოვნით. Tag Assistant არის Google-ის ინსტრუმენტი საიტზე ტეგების შესამოწმებლად, და Google-ის ცნობარის თანახმად, თქვენი ტეგის ID-ს იქ მწვანე ან ლურჯი სტატუსის ხატულა უნდა ჰქონდეს. შემდეგ ტელეფონიდან გაგზავნეთ სატესტო მოთხოვნა და შეამოწმეთ, რომ ის ერთხელ დაითვალა, როგორც ვწერთ სტატიაში იმაზე, რატომ მოაქვს Google Ads-ს კლიკები და არა მოთხოვნები. ჩვენს Google Ads-ის მართვაში თვალთვალს ფსონების ნებისმიერ ცვლილებამდე ვამოწმებთ.
6. შეადარეთ რიცხვები ფოსტას ან CRM-ს. დაალაგეთ ფოსტის ან CRM-ის მოთხოვნები იმ კონვერსიების გვერდით, რომლებსაც Google იმავე დღეებისთვის აჩვენებს, 8 ოქტომბრამდე და მის შემდეგ. იგივე შედარებას ვაკეთებთ CRM-სა და ანალიტიკაზე მუშაობისას, და თუ რიცხვები აღარ ემთხვევა, პირველ რიგში ტეგებს უნდა შეხედოთ.

← ყველა სტატია