สรุปสั้น ๆ (TL;DR)
- บันทึกการเปิดตัว Tag Manager ของ Google วันที่ 8 ตุลาคม 2569 ระบุว่าคอนเทนเนอร์ gtm.js จะเริ่มทำงานเมื่อคอนเทนเนอร์โหลด โดยไม่ขึ้นกับคำสั่ง gtag('config') ใดๆ
- คำสั่ง config จะปรากฏใน dataLayer เป็นอีเวนต์ gtag.config แท็กที่ผูกกับทริกเกอร์ custom event แบบไวลด์การ์ด .* จึงอาจยิงเพิ่มหนึ่งครั้ง
- Google ถือว่าการโหลด ID แบบ G-, AW- หรือ DC- ผ่าน gtm.js หรือการใช้สนิปเป็ต GTM คู่กับบรรทัด gtag('config') ที่อยู่แยกโดยไม่มีตัวโหลด gtag.js เป็นรูปแบบที่ไม่รองรับ และส่งอีเมลถึงเจ้าของคอนเทนเนอร์โดยไม่บอกจำนวน
- ทางแก้ของ Google คือย้ายไปใช้สนิปเป็ต gtag.js หรือเก็บ GTM ไว้โดยใช้ ID แบบ GTM- และตั้ง Google tag ภายในคอนเทนเนอร์ แล้วตรวจด้วย Tag Assistant
บันทึกการเปิดตัว Tag Manager ของ Google วันที่ 8 ตุลาคม 2569 ระบุว่าสนิปเป็ตคอนเทนเนอร์ gtm.js ทั้งหมดจะเริ่มทำงานเมื่อคอนเทนเนอร์โหลด "โดยไม่ขึ้นกับคำสั่ง gtag('config') ใดๆ" และคำสั่ง config จะปรากฏใน dataLayer เป็นอีเวนต์ gtag.config ที่มองเห็นได้ มีสองกลุ่มที่ต้องลงมือ คือเว็บที่โหลดแท็ก ID แบบ G-, AW- หรือ DC- ผ่านพาธสนิปเป็ต gtm.js หรือใช้สนิปเป็ต GTM คู่กับบรรทัด gtag('config') ที่อยู่แยกโดยไม่มีตัวโหลด gtag.js และคอนเทนเนอร์ใดก็ตามที่ยิงแท็กด้วยทริกเกอร์ custom event แบบไวลด์การ์ด .*
Google ประกาศอะไรเมื่อวันที่ 8 ตุลาคม 2569
รายการในบันทึกการเปิดตัว Google Tag Manager ใช้ชื่อว่า "Standardizing gtag('config') command behavior for Google Tag Manager" มีความยาวเพียงสามย่อหน้าสั้นๆ Google ระบุว่ากำลังปรับพฤติกรรมของสนิปเป็ตแท็กให้เป็นมาตรฐานเดียวกัน "เพื่อให้มีความสม่ำเสมอ ความน่าเชื่อถือ และประสิทธิภาพสูงในทุกเว็บไซต์ที่ใช้ Google tag"
บันทึกนี้มีสาระสามข้อ ข้อแรก สนิปเป็ตคอนเทนเนอร์ Tag Manager (gtm.js) ทั้งหมดจะเริ่มทำงานเมื่อคอนเทนเนอร์โหลด โดยไม่ขึ้นกับคำสั่ง gtag('config') ใดๆ ข้อสอง คำสั่ง config จะปรากฏใน dataLayer เป็นอีเวนต์ gtag.config ที่มองเห็นได้ และ Google เตือนว่าคอนเทนเนอร์ที่ใช้ทริกเกอร์ custom event แบบไวลด์การ์ดอาจยิงแท็กเหล่านั้นบนอีเวนต์นี้ ข้อสาม เว็บที่ต้องการใช้โค้ดกำหนดค่า gtag ต่อไป ต้องให้ทุกหน้ารันสนิปเป็ต Google tag (gtag.js)
บันทึกการเปิดตัวนี้ลิงก์ไปยังหน้าช่วยเหลือของ Google ชื่อ "Set up your Google tag installation correctly for gtag.js" ซึ่งมีรายละเอียดเชิงปฏิบัติ ได้แก่ รูปแบบการติดตั้งที่ Google รองรับ ขั้นตอนย้ายระบบสี่ขั้น และวิธีตรวจสอบผลสองวิธี
สนิปเป็ตสองแบบ ID สองประเภท
Google มีตัวโหลดสองตัวที่หน้าตาคล้ายกันในซอร์สโค้ดของหน้าเว็บ และการเปลี่ยนแปลงครั้งนี้จะเข้าใจได้ก็ต่อเมื่อแยกสองตัวนี้ออกจากกัน สนิปเป็ตคอนเทนเนอร์ Tag Manager โหลดไฟล์ชื่อ gtm.js และระบุด้วย ID ที่ขึ้นต้นด้วย GTM- ส่วนสนิปเป็ต Google tag โหลด gtag.js จาก googletagmanager.com/gtag/js และใช้ ID ของแต่ละผลิตภัณฑ์ ได้แก่ G- สำหรับ Google Analytics 4, AW- สำหรับ Google Ads และ DC- สำหรับ Floodlight
สนิปเป็ต gtag.js จะสร้างฟังก์ชันเล็กๆ ชื่อ gtag() แล้วเรียก gtag('js', new Date()) และ gtag('config', 'TAG_ID') ฟังก์ชันนี้ทำงานเพียงอย่างเดียว คือส่งอาร์กิวเมนต์ของตัวเองเข้าไปในอาร์เรย์ dataLayer ซึ่งเป็นอาร์เรย์เดียวกับที่ Tag Manager อ่าน คำสั่ง config จึงลงไปอยู่ในอาร์เรย์นั้นมาตลอด ตามบันทึกการเปิดตัววันที่ 8 ตุลาคม คอนเทนเนอร์ gtm.js จะเริ่มทำงานโดยไม่ขึ้นกับคำสั่งนั้น และ Tag Manager จะแสดงคำสั่งนั้นเป็นอีเวนต์ gtag.config ที่มีชื่อซึ่งทริกเกอร์มองเห็นได้
ใครได้รับผลกระทบจากอีเวนต์ gtag.config
กลุ่มที่ 1: การติดตั้งแบบผสมที่ Google ไม่รองรับ
หน้าช่วยเหลือของ Google อธิบายการติดตั้งที่ไม่รองรับไว้สองแบบ แบบแรกคือการใช้แท็ก ID ที่ไม่ใช่ GTM เช่น ID ที่ขึ้นต้นด้วย G-, AW- หรือ DC แล้วติดตั้งผ่านพาธสนิปเป็ตของ Tag Manager (gtm.js) ส่วนตัวอย่าง "การติดตั้งที่ไม่ถูกต้อง" ของ Google คือสนิปเป็ตคอนเทนเนอร์ GTM มาตรฐานที่โหลดด้วย ID แบบ GTM-XXXXXX ตามด้วยบล็อกสคริปต์แยกที่มีเพียง gtag('config', 'TAG_ID') โดยไม่มีตัวโหลด gtag.js อยู่บนหน้าเลย คำเตือนในหน้าช่วยเหลือครอบคลุมทุกหน้าที่ใช้สนิปเป็ต GTM แต่พึ่งพา gtag('config') ในการส่งพารามิเตอร์หรือกำหนดค่าแท็ก Google ระบุว่าเว็บที่ใช้รูปแบบนี้ "อาจพบการเปลี่ยนแปลงที่ไม่คาดคิดในพฤติกรรมของแท็ก"
Google ยังระบุว่าผู้ใช้คอนเทนเนอร์ที่ติดตั้งแบบไม่รองรับได้รับอีเมลแจ้งเตือนแล้ว แต่ไม่ได้บอกว่าครอบคลุมกี่คอนเทนเนอร์ หากอีเมลผู้ดูแลคอนเทนเนอร์เป็นของพนักงานที่ลาออกไปแล้วหรือของนักพัฒนาเว็บรายเก่า คำเตือนนั้นอาจไม่เคยไปถึงคนที่ดูแลเว็บอยู่ในตอนนี้ การตรวจสอบด้วยตัวเองจึงปลอดภัยกว่าการรออีเมล
PPC Land ซึ่งวิเคราะห์การเปลี่ยนแปลงนี้เมื่อวันที่ 9 ตุลาคม อธิบายความเสี่ยงของผู้ลงโฆษณาไว้ตรงๆ ว่า แท็ก Conversion ของ Google Ads หรือการตั้งค่า Analytics ที่พึ่งพาบรรทัด config ที่ลอยอยู่นั้น อาจไม่รับพารามิเตอร์ที่บรรทัดนั้นเคยส่งให้อีกต่อไป
กลุ่มที่ 2: คอนเทนเนอร์ที่มีทริกเกอร์ custom event แบบ .*
กลุ่มที่สองกว้างกว่าและสังเกตได้ยากกว่า เอกสารทริกเกอร์ custom event ของ Google เตือนไว้ก่อนแล้วว่า "regex .* หมายความว่าทริกเกอร์จะทำงานกับทุกอีเวนต์ที่ตรวจพบ รวมถึงอีเวนต์ที่ Google Tag Manager และ Google tag ส่งออกมาโดยอัตโนมัติ" และแนะนำให้ใช้ regex ที่จำกัดกว่านี้ อีเวนต์ gtag.config ตัวใหม่ก็เป็นหนึ่งในอีเวนต์ที่ถูกส่งออกมาโดยอัตโนมัตินั้น
PPC Land ชี้ว่าการเปลี่ยนแปลงครึ่งนี้อาจกระทบแม้แต่การติดตั้งที่ Google ถือว่าถูกต้อง เพราะสนิปเป็ต gtag.js ที่รองรับเองก็มีคำสั่ง config อยู่ข้างใน บนหน้าที่รัน gtag.js คู่กับคอนเทนเนอร์ GTM แท็กที่ผูกกับทริกเกอร์ .* จะมีอีเวนต์ให้ยิงเพิ่มขึ้นอีกหนึ่งครั้ง ผลกระทบมากหรือน้อยขึ้นกับตัวแท็ก แท็กสำหรับดีบักจะได้บันทึกเพิ่มหนึ่งแถว แต่แท็ก Conversion แท็กรีมาร์เก็ตติ้ง หรือแท็ก Custom HTML ที่ส่งทุกอีเวนต์ใน dataLayer ต่อไปยังแพลตฟอร์มอื่น อาจส่งข้อมูลซ้ำเพิ่มหนึ่งครั้ง
ใครที่ไม่ได้รับผลกระทบ
เว็บที่รันเฉพาะสนิปเป็ต gtag.js มาตรฐานและไม่มีทริกเกอร์ไวลด์การ์ด หรือเว็บที่ใช้เฉพาะคอนเทนเนอร์ GTM- โดยตั้งค่า Google tag ไว้ภายใน Tag Manager และไม่มีทริกเกอร์ .* ถือว่าตรงกับรูปแบบที่ Google ระบุว่าถูกต้องอยู่แล้ว หน้าช่วยเหลือไม่ได้ขอให้เว็บกลุ่มนี้เปลี่ยนแปลงอะไร
สรุปรูปแบบการติดตั้งที่รองรับและไม่รองรับ
บันทึกการเปิดตัวและหน้าช่วยเหลือของ Google อธิบายรูปแบบการติดตั้งไว้สี่แบบ ตารางนี้สรุปสิ่งที่ Google ระบุไว้สำหรับแต่ละแบบ
| รูปแบบการติดตั้ง | สิ่งที่ Google ระบุ |
|---|---|
| สนิปเป็ต gtag.js พร้อม gtag('config') ในทุกหน้า | รองรับ เป็นเทมเพลตของ Google สำหรับการใช้คำสั่ง config |
| สนิปเป็ต gtm.js ที่ใช้ ID แบบ GTM- และตั้งค่า Google tag ภายใน Tag Manager | รองรับ Google แนะนำแบบนี้เมื่อใช้ Tag Manager รันแท็กของบุคคลที่สามด้วย |
| สนิปเป็ต gtm.js (ID ใดก็ได้) พร้อมบรรทัด gtag('config') แยกโดยไม่มีตัวโหลด gtag.js หรือ ID แบบ G-, AW- หรือ DC- ที่โหลดผ่าน gtm.js | ไม่รองรับ พฤติกรรมของแท็กอาจเปลี่ยนแบบไม่คาดคิด |
| คอนเทนเนอร์ใดก็ตามที่มีทริกเกอร์ custom event แบบไวลด์การ์ด .* | แท็กเหล่านั้นอาจยิงบนอีเวนต์ gtag.config |
วิธีย้ายออกจากรูปแบบที่ไม่รองรับ
หน้าช่วยเหลือของ Google วางขั้นตอนไว้สี่ขั้น สำหรับย้ายการติดตั้งแบบผสมไปใช้สนิปเป็ต gtag.js ที่รองรับ
- คัดลอก Google tag ID ใน Google Ads ให้เปิด Data manager จากเมนู Tools หา Google tag ใต้หัวข้อ "Google tag" คลิก Manage เลือก Google tag ทางซ้ายของแผนภาพ แล้วคัดลอก ID ใต้ "Tag details" ส่วนใน Google Analytics ให้ไปที่ Admin แล้วเลือก "Data collection and modification" จากนั้น Data streams เลือกสตรีม คลิก "Configure tag settings" เลือก Google tag แล้วคัดลอก ID ใต้ "Tag details"
- ใส่ ID ลงในเทมเพลต gtag.js ของ Google แทนที่คำว่า TAG_ID
- ลบสนิปเป็ต gtm.js และคำสั่ง gtag('config') ที่อยู่แยกและเกี่ยวข้องกับสนิปเป็ตนั้นออกจากหน้าเว็บ
- วางสนิปเป็ต gtag.js ไว้ถัดจากแท็กเปิด head ทันที ในทุกหน้าของเว็บไซต์
การถอด Tag Manager ออกไม่ใช่ทางเดียว และสำหรับเว็บการตลาดจำนวนมากก็ไม่ใช่ทางที่เหมาะ Google ระบุว่าหากคุณใช้ Tag Manager จัดการแท็กของบุคคลที่สามหรือการตั้งค่าแบบกำหนดเองอื่นๆ ควรเก็บสนิปเป็ตหลักของ Tag Manager ไว้ แล้วเปลี่ยน ID แบบ G-, AW- หรือ DC- ในสนิปเป็ต gtm.js เป็น ID แบบ GTM-XXXXXX ของคุณ ติดตั้ง Google tag ไว้ภายในคอนเทนเนอร์ และตั้งค่าที่จำเป็นผ่านหน้าจอของ Tag Manager เว็บที่รันแท็กของ Meta, TikTok หรือ LINE ผ่าน Tag Manager โดยทั่วไปจะเลือกทางนี้
ก่อนลบอะไรออก ให้จดไว้ก่อนว่าบรรทัด config เดิมทำหน้าที่อะไร หน้าช่วยเหลือของ Google อธิบายปัญหาว่าเป็นหน้าที่ "พึ่งพา gtag('config') ในการส่งพารามิเตอร์หรือกำหนดค่าแท็ก" การตั้งค่าใดที่บรรทัดนั้นเคยส่ง ต้องยังมีอยู่หลังย้ายระบบ ไม่ว่าจะอยู่ในสนิปเป็ต gtag.js ใหม่ หรืออยู่ในการตั้งค่า Google tag ภายใน Tag Manager ถ้าลบบรรทัดนั้นทิ้งโดยไม่ย้ายการตั้งค่าไปด้วย ก็เท่ากับเปลี่ยนช่องโหว่การวัดผลจุดหนึ่งไปเป็นอีกจุดหนึ่ง
วิธีจัดการกับทริกเกอร์ .*
คำแนะนำทั่วไปของ Google คือให้ใช้ regex ที่จำกัดกว่าเดิม ในทางปฏิบัติหมายถึงการระบุชื่ออีเวนต์ที่แท็กควรตอบสนองให้ชัด แทนที่จะจับคู่กับทุกอีเวนต์ หากแท็กใดจำเป็นต้องเห็นอีเวนต์เกือบทั้งหมดจริงๆ ให้เพิ่มเงื่อนไขให้แท็กนั้นข้ามอีเวนต์ gtag.config หรือทำให้แน่ใจว่าบันทึกและรายงานของคุณนับรวมการยิงที่เพิ่มขึ้นนี้แล้ว
การตรวจคอนเทนเนอร์สำหรับเรื่องนี้ทำได้เป็นสี่รอบ
- เปิดทริกเกอร์ custom event ทีละตัว แล้วดูว่ามีการเปิด "Use regex matching" คู่กับ .* หรือรูปแบบอื่นที่กว้างพอจะจับ gtag.config ได้หรือไม่
- จดรายการแท็กที่ทริกเกอร์แต่ละตัวยิง
- แท็กสำหรับบันทึกหรือดีบักล้วนๆ ปล่อยไว้ได้ ถ้าบันทึกเพิ่มหนึ่งแถวไม่สร้างปัญหา
- สำหรับแท็กที่ส่ง Conversion กลุ่มรีมาร์เก็ตติ้ง หรืออีเวนต์ไปยังแพลตฟอร์มภายนอก ให้จำกัดทริกเกอร์ให้แคบลง หรือเพิ่มเงื่อนไขยกเว้นตามชื่ออีเวนต์
วิธีตรวจสอบว่าแก้ไขสำเร็จ
หน้าช่วยเหลือของ Google ระบุวิธีตรวจสอบไว้สองวิธี
- Tag Assistant: ไปที่ Google Tag Assistant คลิก Add domain ใส่ URL ของเว็บแล้วคลิก Connect จากนั้นดูใต้หัวข้อ "Google tags found" ว่า ID แท็กของคุณแสดงพร้อมไอคอนสถานะสีเขียวหรือสีน้ำเงินหรือไม่
- Chrome Developer Tools: เปิดเว็บใน Chrome เปิด Developer Tools จากเมนู View แล้ว Developer แล้ว Developer Tools ไปที่แท็บ Network แล้วรีเฟรชหน้า คำขอควรวิ่งไปที่ googletagmanager.com/gtag/js แทน /gtm.js ทราฟฟิกของ Google Ads จะเห็นเป็นคำขอไปยัง googleadservices.com และทราฟฟิกของ Google Analytics จะเห็นเป็นคำขอไปยัง analytics.google.com
ข้อควรทราบหนึ่งข้อ การตรวจ /gtag/js เขียนไว้สำหรับเว็บที่ย้ายไปใช้สนิปเป็ต gtag.js หากคุณเก็บ Tag Manager ไว้และเปลี่ยนสนิปเป็ตเป็น ID แบบ GTM- คำขอ gtm.js ที่มี ID แบบ GTM- นั้นคือผลลัพธ์ที่ถูกต้อง สำหรับฝั่งทริกเกอร์ ให้เปิดโหมดพรีวิวของ Tag Manager บนหน้าที่รันคำสั่ง config หา gtag.config ในรายการอีเวนต์ แล้วดูว่ามีแท็กใดยิงบนอีเวนต์นั้นบ้าง
สิ่งที่ Google ยังไม่ได้บอก
หลังรายการวันที่ 8 ตุลาคม ยังมีคำถามที่เปิดค้างอยู่หลายข้อ ซึ่งควรรู้ไว้ก่อนวางแผนงานรอบการเปลี่ยนแปลงนี้
- Google ไม่ได้บอกว่ามีคอนเทนเนอร์ที่ใช้รูปแบบไม่รองรับกี่คอนเทนเนอร์ หรือมีเจ้าของกี่รายที่ได้รับอีเมล
- PPC Land ตั้งข้อสังเกตว่าหน้าช่วยเหลือระบุว่าสนิปเป็ต gtm.js "จะถูกอัปเดตเร็วๆ นี้" ส่วนบันทึกการเปิดตัวลงวันที่ 8 ตุลาคม แต่ก็ใช้คำว่า "จะ" เช่นกัน จึงไม่มีเอกสารใดยืนยันวันเปิดใช้จริง
- ไม่มีเอกสารใดบอกว่าระบบวินิจฉัยของ Tag Manager จะแจ้งเตือนรูปแบบการติดตั้งแบบผสม หรือทริกเกอร์ไวลด์การ์ดที่จับอีเวนต์ใหม่นี้หรือไม่
- Google ไม่ได้ประเมินว่าตัวเลขการวัดผลของเว็บที่ได้รับผลกระทบอาจเปลี่ยนไปมากแค่ไหน
การเปลี่ยนแปลงนี้อยู่ตรงไหนในภาพรวมการปรับแท็กของ Google
บันทึกการเปิดตัวแสดงให้เห็นว่า Google ค่อยๆ เข้มงวดขึ้นเรื่อยๆ ว่าโค้ดแท็กของตนติดตั้งได้แบบใดบ้าง เมื่อวันที่ 9 กรกฎาคม 2569 Google เปลี่ยนวิธีที่ Tag Manager จัดการคอนเทนเนอร์ที่โหลดผ่านพาธที่ไม่รองรับ เช่น /gtag/js หรือ /gtag/destination นับจากนั้น ID ที่ใช้โหลดคอนเทนเนอร์เป็นตัวกำหนดว่าอะไรรันได้ ไม่ใช่พาธ คอนเทนเนอร์ที่โหลดด้วย ID แบบ GTM- จะไม่ถูกจำกัด ส่วน ID ของผลิตภัณฑ์อย่าง G- หรือ AW- จะอนุญาตเฉพาะแท็กและตัวแปรที่ Google จัดให้ การเปลี่ยนแปลงเมื่อ 8 ตุลาคมจัดการกรณีกลับด้าน คือคำสั่ง config ของ gtag ที่วางไว้ข้างตัวโหลด GTM
PPC Land เชื่อมการเปลี่ยนแปลงทั้งสองครั้งเข้ากับแผนของ Google ในเดือนพฤษภาคม 2569 ที่จะรวม Tag Manager และ Google tag เข้าด้วยกัน และอ้างคำพูดของ Google ว่าสนิปเป็ตสำหรับติดตั้งรุ่นใหม่ "จะไม่มีคำสั่ง gtag config" Relevant Audience เคยรายงานเรื่องการรวมระบบนี้เมื่อวันที่ 25 สิงหาคม 2569 และเรื่องการตั้งค่าติดตามการซื้อของ Google Ads แบบมีขั้นตอนนำทางใน Tag Manager เมื่อวันที่ 21 กรกฎาคม 2569 เมื่ออ่านรวมกัน ทิศทางคือหนึ่ง ID มีกฎการโหลดเพียงแบบเดียว และการกำหนดค่าจะอยู่ภายในแท็กหรือคอนเทนเนอร์ ไม่ใช่โค้ดที่ลอยอยู่บนหน้าเว็บ
เรื่องนี้มีความหมายอย่างไรกับนักการตลาดไทย
หากโค้ดติดตามของคุณถูกเพิ่มเข้ามาเป็นชั้นๆ (สนิปเป็ต Google Ads จากหน้าตั้งค่าหนึ่ง สนิปเป็ต GA4 จากอีกหน้า แล้วค่อยเพิ่มคอนเทนเนอร์ Tag Manager ทีหลัง) การติดตั้งแบบผสมก็อาจเกิดขึ้นได้โดยที่ไม่มีใครตั้งใจเลือก
การตรวจสองอย่างครอบคลุมความเสี่ยงได้เกือบทั้งหมด อย่างแรก เปิดดูซอร์สของหน้าเว็บ แล้วหาสนิปเป็ต gtm.js ที่ ID ขึ้นต้นด้วย G- หรือ AW- หรือบรรทัด gtag('config') ที่ไม่มีตัวโหลด gtag/js อยู่ด้านบน อย่างที่สอง เปิดคอนเทนเนอร์แล้วตรวจแท็กทุกตัวที่ผูกกับทริกเกอร์ .* โดยเฉพาะ LINE Tag, TikTok pixel และ Meta pixel เพราะการยิงเพิ่มหนึ่งครั้งต่อหน้าอาจทำให้ตัวเลขอีเวนต์ที่แพลตฟอร์มเหล่านั้นรายงานสูงเกินจริง หากการติดตั้ง GA4 หรือการติดตาม Conversion ของ Google Ads ของคุณพึ่งพารูปแบบใดรูปแบบหนึ่งนี้ ควรแก้ไขก่อนที่ตัวเลขจะคลาดเคลื่อนไปถึงรายงานเดือนหน้า
คำถามที่พบบ่อยเกี่ยวกับ gtag.config และ Google Tag Manager
ถ้าเว็บใช้เฉพาะคอนเทนเนอร์ GTM- ต้องเปลี่ยนอะไรไหม
ไม่ต้องเปลี่ยนในส่วนการโหลด ตราบใดที่ไม่มีบรรทัด gtag('config') ที่อยู่แยกวางไว้ข้างสนิปเป็ต GTM โดยไม่มีตัวโหลด gtag.js ตัวอย่างการติดตั้งที่ไม่รองรับของ Google เองคือสนิปเป็ต GTM- คู่กับบรรทัด config ที่ลอยอยู่ อีเวนต์ gtag.config ยังคงปรากฏบนทุกหน้าที่รันคำสั่ง config จึงควรตรวจทริกเกอร์ไวลด์การ์ดไม่ว่ากรณีใด
อีเวนต์ gtag.config คืออะไร
อีเวนต์ gtag.config คืออีเวนต์ใน dataLayer ที่จะปรากฏทุกครั้งที่คำสั่ง gtag('config') ทำงาน ตามบันทึกการเปิดตัวของ Google วันที่ 8 ตุลาคม 2569 คำสั่ง config ถูกส่งเข้า dataLayer มาตลอด แต่จะถูกแสดงเป็นอีเวนต์ที่มีชื่อและมองเห็นได้ ซึ่งทริกเกอร์สามารถจับคู่ได้
จะรู้ได้อย่างไรว่าเว็บของเราใช้การติดตั้งแบบไม่รองรับ
เว็บของคุณใช้รูปแบบนี้ ถ้ามี ID แบบ G-, AW- หรือ DC- ที่โหลดผ่านสนิปเป็ต gtm.js หรือมีสนิปเป็ต GTM วางคู่กับบรรทัด gtag('config') ที่อยู่แยกโดยไม่มีตัวโหลด gtag.js Google ระบุว่าได้ส่งอีเมลถึงผู้ใช้คอนเทนเนอร์ที่ใช้รูปแบบนี้แล้ว แต่การเปิดดูซอร์สของหน้าเว็บโดยตรงเชื่อถือได้มากกว่าการรออีเมล
การเปลี่ยนแปลงนี้มีผลในประเทศไทยแล้วหรือยัง
บันทึกการเปิดตัวของ Google ไม่ได้กล่าวถึงข้อจำกัดด้านประเทศหรือภูมิภาคใดๆ สิ่งที่ Google ยังไม่ได้ระบุคือการเปิดใช้มีผลกับทุกคอนเทนเนอร์ทันที หรือทยอยเปิดเป็นระยะ
การเปลี่ยนแปลงนี้จะทำให้การติดตาม Conversion ของ Google Ads พังไหม
อาจพังได้ หากการตั้งค่า Conversion ของคุณพึ่งพาการติดตั้งแบบผสม หรือหากแท็ก Conversion ยิงด้วยทริกเกอร์ .* Google ไม่ได้ระบุขนาดของผลกระทบ ทางที่ปลอดภัยคือตรวจทั้งสองรูปแบบ แล้วยืนยันผลด้วย Tag Assistant และแท็บ Network
การเปลี่ยนแปลงเมื่อ 8 ตุลาคมเป็นเรื่องเล็กในแง่โค้ด แต่พลาดได้ง่ายในทางปฏิบัติ เพราะไม่มีอะไรพังให้เห็นบนหน้าเว็บ หากคุณไม่แน่ใจว่าเว็บของคุณใช้รูปแบบใด Relevant Audience ช่วยตรวจคอนเทนเนอร์ Tag Manager และการติดตั้ง Google tag ของคุณ แล้วบอกได้ชัดเจนว่าส่วนไหนต้องย้ายหรือแก้ไข
