ย้ายสคริปต์ Google Tag มาเสิร์ฟจากโดเมนตัวเอง กู้สัญญาณที่หายไปได้จริงแค่ไหน

สมมติร้านของคุณจ่าย Google Ads เดือนละ 60,000 บาท แล้ววันหนึ่งลองเปิดสองรายงานเทียบกัน Google Ads บอกว่ามี 1,000 คลิก แต่ GA4 นับ session ที่มาจาก google / cpc ได้ 780 ตัวเลข 780 เป็นตัวอย่างสมมตินะครับ ไม่ใช่ค่ากลางของวงการ แต่ช่องว่างหน้าตาแบบนี้คือสิ่งที่เจ้าของเว็บส่วนใหญ่เจอเมื่อลองเทียบ

ส่วนต่าง 220 คลิกไม่ได้หายไปไหน คนกลุ่มนั้นเข้าเว็บจริง แต่สคริปต์วัดผลไม่ได้ทำงานตั้งแต่ต้น สาเหตุหนึ่งคือตัวบล็อกโฆษณาและโหมดป้องกันการติดตามของบางเบราว์เซอร์ตัดคำขอที่วิ่งไปหาโดเมนของ Google ก่อนมันจะออกจากเครื่องผู้ใช้ Google tag gateway ถูกออกแบบมาแก้ข้อนี้โดยเฉพาะ

คำถามที่ควรถามก่อนลงมือจึงเป็นว่ามันกู้ได้เท่าไหร่ และกู้ตรงจุดที่คุณสนใจหรือเปล่า ถ้ายอดขายของคุณปิดในแชท LINE ส่วนที่ gateway แตะถึงกับส่วนที่ทำให้ยอดหายอาจเป็นคนละส่วนกัน

สิ่งที่เปลี่ยนจริงเมื่อเปิด tag gateway

ปกติเมื่อหน้าเว็บมี Google tag เบราว์เซอร์จะดึงสคริปต์จาก googletagmanager.com แล้วส่งคำขอวัดผลไปยังโดเมนของ Google อีกหลายโดเมน รายการกรองของตัวบล็อกโฆษณาจับคู่กับชื่อโดเมนเหล่านี้ได้ง่ายมาก เพราะชื่อเหล่านี้ไม่เคยเปลี่ยนจากเว็บหนึ่งไปอีกเว็บหนึ่ง

เมื่อเปิด tag gateway คุณวางกฎ reverse proxy ไว้ที่ CDN หรือ load balancer หน้าเว็บ เช่น ให้ทุกคำขอที่ขึ้นต้นด้วย /metrics ถูกส่งต่อไปยังเซิร์ฟเวอร์ของ Google เบราว์เซอร์จะเห็นแค่ร้านของคุณ.com/metrics เท่านั้น สคริปต์เดิม แท็กเดิม ข้อมูลที่ส่งก็เดิม เปลี่ยนแค่เส้นทางที่มันเดิน และเพราะเป็นการส่งต่อ Google ยังได้รับ IP กับ user agent ของผู้ใช้ตามปกติ

มันจึงไม่ใช่ server container คุณไม่ได้ประมวลผลหรือกรองข้อมูลก่อนส่งต่อ ไม่มีเซิร์ฟเวอร์ GTM ให้เช่า ไม่มีบิล Cloud Run ท้ายเดือน ผมเลยมองว่านี่คือการแก้ที่ถูก เร็ว และสลับกลับได้ในไม่กี่นาที

เทียบสามแบบที่คนมักปนกัน

ตารางนี้เทียบการติดแท็กปกติ tag gateway และ Server-side GTM โดยดูที่สิ่งที่เบราว์เซอร์เห็นกับสิ่งที่คุณต้องดูแล จุดที่อยากให้สังเกตคือแถวสุดท้ายแก้ปัญหาการถูกบล็อกตามโดเมนได้เหมือนแถวกลาง ต่างกันที่ server-side ทำเรื่องอื่นได้อีก

สี่เรื่องที่ gateway ช่วยไม่ได้

ถ้าคุณคาดหวังให้มันกู้ทุกอย่างที่หายไป คุณจะผิดหวัง สี่เรื่องนี้อยู่นอกขอบเขตของมัน:

• เพดาน 7 วันของคุกกี้บน Safari สคริปต์ยังรันในเบราว์เซอร์และเขียนคุกกี้ด้วย JavaScript เหมือนเดิม ผมจึงไม่เห็นเหตุผลทางกลไกที่ ITP จะปล่อยให้นานขึ้น และยังไม่เห็นเอกสารที่รับรองว่ามันยืดอายุ ให้ทดสอบเองตามขั้นตอนด้านล่างแทนที่จะเชื่อผม
• คนที่ปฏิเสธคุกกี้ gateway ไม่เปลี่ยนว่าผู้ใช้ยินยอมหรือไม่ และไม่ควรถูกใช้เป็นทางลัดหลบแบนเนอร์ ถ้าผู้ใช้ปฏิเสธ แท็กต้องเคารพสถานะนั้น ดูวิธีตั้งในการตั้งค่า Consent Mode ให้ยิงแอดเข้า LINE
• ตัวบล็อกที่จับด้วยรูปแบบ URL บางรายการกรองตามชื่อไฟล์หรือเส้นทางที่รู้จักอยู่แล้ว ถ้าเส้นทางหลังโดเมนของคุณหน้าตาเหมือนตัวอย่างในเอกสาร ก็ยังโดนบล็อกได้ ควรเลือกชื่อเส้นทางที่ไม่ซ้ำกับตัวอย่างสาธารณะ
• ยอดขายที่เกิดนอกเว็บ คนที่คลิกแอด เข้าเว็บ แล้วกดไป LINE จะไม่มีเหตุการณ์ซื้อให้แท็กเห็นเลย เพราะการต่อรองและโอนเงินเกิดในแชท gateway ทำให้นับ ‘คลิกปุ่ม LINE’ ได้ครบขึ้น แต่ไม่ได้ทำให้ยอดขายจริงกลับไปหา Google ต้องมีgclid ที่เก็บไว้ตั้งแต่ก่อนเข้า LINE แยกต่างหาก

ทดสอบเองให้จบในครึ่งวัน ก่อนเชื่อตัวเลขของใคร

1. จดตัวเลขตั้งต้นย้อนหลัง 14 วัน คือคลิกใน Google Ads เทียบกับ session จาก google / cpc ใน GA4 รายสัปดาห์ สองค่านี้ไม่มีวันเท่ากันเป๊ะเพราะนิยามต่างกัน ใช้ดูแนวโน้มของอัตราส่วนเท่านั้น และดูด้วยว่าอัตราส่วนแกว่งแค่ไหนในสัปดาห์ปกติ
2. ตั้ง gateway แล้วเปิดหน้าเว็บด้วย DevTools แท็บ Network กรองด้วยชื่อเส้นทางที่เลือก คำขอต้องวิ่งไปโดเมนคุณและตอบ 200 ให้จดไว้ด้วยว่ายังมีคำขอไหนที่วิ่งไปโดเมนของ Google อยู่
3. เปิดโปรไฟล์เบราว์เซอร์ใหม่ที่ติดตัวบล็อกโฆษณายอดนิยมสักตัว โหลดหน้าเดียวกันก่อนและหลังเปิด gateway แล้วดูว่ามีคำขอวัดผลออกไปถึงหรือไม่
4. ทดสอบ Safari บน iPhone โดยเปิดลิงก์ที่ต่อท้ายด้วย ?gclid=TEST123 แล้วดูคุกกี้ _gcl_aw ผ่าน Web Inspector ที่ต่อกับ Mac เทียบวันหมดอายุที่เห็นกับวันหมดอายุที่ Google tag ตั้งไว้ ถ้า Safari ลดเหลือ 7 วันหรือน้อยกว่า แปลว่า gateway ไม่ได้แก้เรื่องนี้
5. รอ 14 วันแล้วคำนวณอัตราส่วนใหม่ เก็บ gateway ไว้ก็ต่อเมื่ออัตราส่วนขยับเกินความแกว่งปกติที่วัดได้ในข้อแรก และ Preview ใน GTM ไม่ขึ้นข้อผิดพลาด ถ้าอยากตรวจ container ทั้งใบพร้อมกัน ใช้ เช็กลิสต์ตรวจสุขภาพ GTM container

ตั้งค่าตรงไหน และจุดที่มักพลาด

การตั้งค่าอยู่ในส่วนจัดการ Google tag ถ้าเว็บอยู่หลัง Cloudflare อยู่แล้วจะมีขั้นตอนนำทางที่เกือบเสร็จในไม่กี่คลิก CDN เจ้าอื่นต้องวางกฎส่งต่อเอง ชื่อเมนูและปุ่มเปลี่ยนบ่อย ให้ยึดเอกสารของ Google ฉบับล่าสุดมากกว่าภาพหน้าจอในบทความไหนก็ตาม รวมถึงบทความนี้

ที่เจอพลาดบ่อยมีสองอย่าง อย่างแรกคือเส้นทางที่เลือกชนกับหน้าจริงของเว็บ เช่นเว็บมีหน้า /metrics อยู่แล้ว ทำให้ทั้งสองฝั่งพังพร้อมกัน อย่างที่สองคือกฎแคชของ CDN ไปแคชคำขอวัดผล ทำให้ข้อมูลค้างหรือซ้ำ ให้ตั้งไม่แคชสำหรับเส้นทางนี้ และเตรียมวิธีปิดสวิตช์ไว้ก่อนเปิด เผื่อยอดวัดหายกลางแคมเปญ

ถ้าเว็บอยู่บน shared hosting ที่ไม่มี CDN หน้าบ้าน การเปิดฟีเจอร์นี้อาจหมายถึงการย้าย nameserver ทั้งโดเมนไปที่ CDN ผมไม่แนะนำให้ทำเรื่องใหญ่ขนาดนั้นเพื่อฟีเจอร์เดียว โดยเฉพาะถ้าเว็บของคุณเป็นแค่หน้า landing ที่ส่งคนต่อไป LINE

เปิดเมื่อไหร่ ข้ามเมื่อไหร่

ผมเปิดทันทีถ้าเว็บอยู่หลัง Cloudflare อยู่แล้ว เพราะใช้เวลาไม่ถึงชั่วโมงและกลับคืนได้ ตรงข้ามกัน ถ้าต้องย้ายระบบ DNS ทั้งโดเมนเพียงเพื่อเปิดมัน ผมจะรอจนกว่าเรื่องเก็บ click id จะเรียบร้อยก่อน

ลำดับที่ผมเรียงให้ร้านที่ปิดการขายในแชทคือ เก็บ gclid และ fbclid ผูกกับ LINE user ID ก่อน ส่งยอดขายจริงจาก LINE กลับ Google Ads ก่อน แล้วค่อยมาปรับชั้นการเสิร์ฟสคริปต์ เพราะขั้นหลังเพิ่มจำนวนคลิกที่นับได้ ส่วนขั้นแรกเพิ่มยอดขายที่ระบบมองเห็น ซึ่งส่งผลต่อ Smart Bidding มากกว่าหลายเท่า ถ้ากำลังชั่งใจเรื่อง server-side เต็มชุด อ่านServer-Side GTM กับ funnel ที่ปิดใน LINE ประกอบ

สรุป

ผลที่ได้คือการจัดลำดับงาน ไม่ใช่การเลือกข้างระหว่างเครื่องมือ gateway เป็นงานครึ่งวันที่กันการบล็อกตามชื่อโดเมนได้ส่วนหนึ่ง แต่ยอดที่หายจากคุกกี้หมดอายุและยอดที่ไปจบในแชทยังอยู่ที่เดิม

ตั้งเกณฑ์ผ่านไว้ล่วงหน้าก่อนเปิด เช่นอัตราส่วนคลิกต่อ session ต้องขยับขึ้นหลัง 14 วัน ถ้าไม่ขยับ ให้ปิดแล้วย้ายเวลาไปแก้การเก็บ click id ที่ให้ผลต่อการประมูลมากกว่า

• Gateway กู้ได้เฉพาะคำขอที่ถูกบล็อกตามชื่อโดเมน ไม่ยืดอายุคุกกี้ Safari และไม่เห็นยอดที่ปิดในแชท
• ทดสอบด้วยอัตราส่วนคลิกต่อ session 14 วัน เก็บไว้เมื่อขยับเกินความแกว่งปกติเท่านั้น

คำถามที่พบบ่อย