ข้ามไปเนื้อหาหลัก

Server-Side Tracking คือ​อะไร ย้าย​แท็ก​แล้ว​ยัง​ต้อง​ขอ​ความ​ยินยอม

อัปเดตล่าสุด 28 กันยายน 2569
เวลาอ่านประมาณ 11 นาที
Server-Side Tracking คือ​อะไร ย้าย​แท็ก​แล้ว​ยัง​ต้อง​ขอ​ความ​ยินยอม

KEY TAKEAWAYS

3 ประเด็น

Server-side tagging ของ Google Tag Manager ย้าย​การ​ประมวล​ผล​แท็ก​จาก​เบราว์เซอร์​ของ​ผู้​ใช้​ไป​ไว้​บน​เซิร์ฟเวอร์​ที่​ธุรกิจ​ควบคุม

ข้อมูล​จาก​หน้า​เว็บ​ส่ง​เข้า​เซิร์ฟเวอร์​ก่อน แล้ว​เซิร์ฟเวอร์​จึง​ส่ง​ต่อ​ไป​ยัง​เครื่อง​มือ​แต่ละ​ตัว

คู่มือ​ของ Google ประเมิน​ค่า​เซิร์ฟเวอร์​บน Cloud Run ไว้​ราว 45 ดอลลาร์​ต่อ​เครื่อง​ต่อ​เดือน และ​แนะนำ​ให้​รัน​อย่าง​น้อย 2 เครื่อง

ค่า log อาจ​เพิ่ม​ขึ้น​มาก​เมื่อ​มี​คำขอ​เกิน​หนึ่ง​ล้าน​ครั้ง​ต่อ​เดือน

ความ​ยินยอม​ต้อง​ตั้ง​ที่ web container บน​หน้า​เว็บ แล้ว​ส่ง​ไป​กับ​คำขอ​ถึง​เซิร์ฟเวอร์

เมื่อ​ผู้​ใช้​ปฏิเสธ analytics_storage ระบบ​จะ​ไม่​เขียน​หรือ​อ่าน​คุกกี้​ของ Analytics ไม่​ว่า​ใน​เครื่อง​ของ​ผู้​ใช้​หรือ​บน​เซิร์ฟเวอร์​ของ​ธุรกิจ

Server-Side Tracking ย้าย​ตัว​รับ​ข้อมูล​ไป​ไว้​บน​เซิร์ฟเวอร์​ของ​ธุรกิจ Google ประเมิน​ค่า​เครื่อง​ราว 45 ดอลลาร์​ต่อ​เดือน และ​ความ​ยินยอม​ยัง​ต้อง​ส่ง​มา​จาก​หน้า​เว็บ

ข้อ​เสนอ​ให้​ย้าย​แท็ก​ไป​ฝั่ง​เซิร์ฟเวอร์​ที่​ส่ง​ถึง​เจ้าของ​ธุรกิจ​มัก​มา​พร้อม​คำ​อธิบาย​ว่า​จะ​ได้​ข้อมูล​ที่​ตัว​บล็อก​โฆษณา​บัง​ไว้​กลับ​คืน​มา และ​ตัวเลข​โฆษณา​จะ​ดี​ขึ้น​ทันที ข้อ​เสนอ​แบบ​นี้​มัก​ไม่​บอก​ค่า​เซิร์ฟเวอร์​ราย​เดือน และ​ไม่​พูด​ถึง​คน​ที่​กด​ปฏิเสธ​คุกกี้​บน​หน้า​เว็บ บท​นี้​ตอบ​ว่า server-side tagging ทำงาน​อย่างไร ต้อง​จ่าย​อะไร​ทุก​เดือน ความ​ยินยอม​ของ​ผู้​ใช้​ยัง​มี​ผล​ตรง​ไหน และ​ธุรกิจ​ควร​ถาม​อะไร​ก่อน​ตกลง

ต้นทุน​และ​ขั้น​ตอน​มา​จาก​คู่มือ server-side tagging ของ Google สาม​หน้า คือหน้า​แนะนำ server-side tagging คู่มือ​ติด​ตั้ง​บน Cloud Run และหน้า​วิธี​ใช้ Consent Mode กับ server-side Tag Manager หน้า​ทั้ง​สาม​มี​วัน​ปรับปรุง​เป็น 30 กรกฎาคม 2569 ส่วน​การ​กัน​นับ​ซ้ำ​มา​จากเอกสาร​ของ Meta เรื่อง​การ​ลบ​ข้อมูล​ซ้ำ​ระหว่าง​พิกเซล​กับ Conversions API

ข้อมูล​เดิน​ทาง​อย่างไร​เมื่อ​ย้าย​แท็ก​ไป​ฝั่ง​เซิร์ฟเวอร์

ใน​การ​ตั้ง​ค่า​แบบ​เดิม ซึ่ง​เรียก​กัน​ว่า client-side ตัว container ของ Tag Manager ทำงาน​อยู่​ใน​เบราว์เซอร์​ของ​ผู้​ใช้ แล้ว​แต่ละ​แท็ก​ส่ง​ข้อมูล​ตรง​ไป​ยัง​เซิร์ฟเวอร์​ของ​เครื่อง​มือ​แต่ละ​ตัว เช่น Google Analytics และ​แพลตฟอร์ม​โฆษณา เว็บ​ที่​ติด​ห้า​เครื่อง​มือ​จึง​ให้​เบราว์เซอร์​ของ​ผู้​ใช้​ส่ง​ข้อมูล​ออก​ไป​ห้า​ทาง

เมื่อ​ใช้ server-side tagging หน้า​คู่มือ​ของ Google อธิบาย​ว่า server container ไม่​ได้​ทำงาน​ใน​เบราว์เซอร์​หรือ​ใน​โทรศัพท์​ของ​ผู้​ใช้ แต่​ทำงาน​บน​เซิร์ฟเวอร์​ที่​ธุรกิจ​ควบคุม เช่น ใน​โปร​เจ​กต์ Google Cloud ของ​ธุรกิจ​เอง ข้อมูล​จาก​หน้า​เว็บ​ส่ง​เข้า​เซิร์ฟเวอร์​นี้​ก่อน และ​มี​เพียง​ธุรกิจ​ที่​เข้า​ถึง​ข้อมูล​ได้​จนกว่า​จะ​เลือก​ส่ง​ต่อ ภายใน​เซิร์ฟเวอร์​ใช้ tag trigger และ variable แบบ​เดียว​กับ​ที่​ทีม​คุ้น​เคย เพิ่ม​ส่วน​ใหม่​ที่​เรียก​ว่า client

client ทำ​หน้าที่​เป็น​ตัว​แปลง รับคำ​ขอ​ที่​เข้า​มา แปลง​เป็น​เหตุการณ์ ส่ง​ให้​แท็ก​ใน​เซิร์ฟเวอร์​ประมวล​ผล แล้ว​ตอบ​กลับ​ไป​ยัง​ผู้​ส่ง server container มี client ติด​มา​ให้​สอง​ตัว คือ Google Analytics และ Measurement Protocol หน้า​เว็บ​จะ​ส่ง​ข้อมูล​เข้า​มา​ได้​ด้วย​การ​ตั้ง​ค่า server_container_url ใน​แท็ก​ของ Google ให้​ชี้​ไป​ที่ URL ของ​เซิร์ฟเวอร์

ทำไม Google แนะนำ​ให้​ใช้​โดเมน​ของ​ตัว​เอง

คู่มือ​ของ Google แนะนำ​อย่าง​หนัก​แน่น​ให้​ติด​ตั้ง​เซิร์ฟเวอร์​บน​โดเมน​ของ​ธุรกิจ​เอง เช่น ซับ​โดเมน​ของ​เว็บ​หลัก และ​เปลี่ยน​เป็น​โหมด production ก่อน​ส่ง​การ​เข้า​ชม​จริง ด้วย​เหตุผล​เรื่อง​ประสิทธิภาพ​และ​ความ​ปลอดภัย ผล​อีก​ข้อ​คือ​คุกกี้​ที่​เซิร์ฟเวอร์​ตั้ง​ผ่าน​การ​ตอบ​กลับ​อยู่​ใน​ฐานะ​คุกกี้​ของ​โดเมน​เจ้าของ​เว็บ ซึ่ง​เบราว์เซอร์​บาง​ตัว​จำกัด​น้อย​กว่า​คุกกี้​ที่​สคริปต์​สร้าง ราย​ละเอียด​ข้อ​จำกัด​ของ Safari อยู่​ในFirst-Party Data คุกกี้​ของ​เว็บ​เอง​ก็​หมด​อายุ​ใน 7 วัน​ได้ ข้อ​นี้​เปลี่ยน​อายุ​ของ​คุกกี้ แต่​ไม่​ได้​เปลี่ยน​หน้าที่​ของ​ธุรกิจ​ใน​การ​ขอ​ความ​ยินยอม

ต้นทุน​ที่​ต้อง​จ่าย​ทุก​เดือน

คู่มือ​ติด​ตั้ง​บน Cloud Run ให้​ตัวเลข​ไว้​ดังนี้

รายการ ตาม​คู่มือ​ของ Google
ค่า​เซิร์ฟเวอร์ ราว 45 ดอลลาร์​ต่อ​เครื่อง​ต่อ​เดือน สำหรับ Cloud Run 1 vCPU หน่วย​ความ​จำ 0.5GB แบบ​จัดสรร CPU ตลอด​เวลา
จำนวน​เครื่อง​ที่​แนะนำ อย่าง​น้อย 2 เครื่อง เพื่อ​ลด​ความ​เสี่ยง​ข้อมูล​หาย​เมื่อ​เครื่อง​หนึ่ง​ล่ม
ความ​สามารถ​รับ​โหลด ขยาย​อัตโนมัติ 2 ถึง 10 เครื่อง รับ​ได้​ราว 35 ถึง 350 คำขอ​ต่อ​วินาที ขึ้น​กับ​จำนวน​และ​การ​ทำงาน​ของ​แท็ก
ค่า log บันทึก​ทุก​คำขอ​เป็น​ค่า​เริ่ม​ต้น ถ้า​เกิน​หนึ่ง​ล้าน​คำขอ​ต่อ​เดือน​อาจ​มี​ค่า​บันทึก​สูง คู่มือ​แนะนำ​ให้​ปิด​การ​บันทึก​คำขอ
สิ่ง​ที่​ต้อง​มี​ก่อน บัญชี​เรียก​เก็บ​เงิน​ของ Google Cloud

ค่า​ตั้ง​ต้น​ตาม​คู่มือ​จึง​อยู่​ที่​ราว 90 ดอลลาร์​ต่อ​เดือน​สำหรับ​สอง​เครื่อง ก่อน​นับ​ค่า log ค่า​โดเมน และ​ค่า​คน​ดูแล คู่มือ​ยัง​แนะนำ​ให้​ตั้ง​การ​แจ้ง​เตือน​ค่า​ใช้​จ่าย​ไว้ เพราะ Cloud Run เพิ่ม​เครื่อง​เอง​ตาม​ปริมาณ​คำขอ และ​ค่า max-instances คือ​กรณี​ที่​ต้อง​จ่าย​สูงสุด

ธุรกิจ​เล็ก​คำนวณ​ความ​คุ้ม​ค่า​อย่างไร

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

ความ​ยินยอม​ยัง​ต้อง​มา​จาก​หน้า​เว็บ

หน้า​วิธี​ใช้ Consent Mode กับ server-side Tag Manager อธิบาย​ลำดับ​ไว้​สาม​ขั้น ป้าย​ขอ​ความ​ยินยอม​บน​หน้า​เว็บ​รับคำ​ตอบ​ของ​ผู้​ใช้​แล้ว​ส่ง​ให้​แท็ก​ของ Google แท็ก​ของ Google เพิ่ม​พารามิเตอร์​ความ​ยินยอม​ลง​ใน​คำขอ​ที่​ส่ง​ไป​ยัง server container แล้ว​แท็ก​ผลิตภัณฑ์​ของ Google ใน​เซิร์ฟเวอร์​ปรับ​ปริมาณ​และ​ชนิด​ข้อมูล​ที่​ส่ง​ต่อตาม​คำ​ตอบ​นั้น คู่มือ​จึง​บอก​ว่าการ​ตั้ง Consent Mode ทำ​ที่ web container บน​หน้า​เว็บ​เพียง​ที่​เดียว

พฤติกรรม​ของ​แท็ก​ของ Google ใน​เซิร์ฟเวอร์​เมื่อ​ผู้​ใช้​ปฏิเสธ​เป็น​ดังนี้

  1. Google Analytics เมื่อ analytics_storage เป็น​ปฏิเสธ ไม่มี​การ​เขียน เข้า​ถึง หรือ​อ่าน​คุกกี้​ของ Analytics เลย ข้อ​นี้​ใช้​กับ​ทั้ง​หน้า​เว็บ​และ server container
  2. Google Ads Conversion เมื่อ ad_storage เป็น​ปฏิเสธ ไม่​เขียน​และ​ไม่​อ่าน​คุกกี้​ของ Google Ads และ​ต้อง​ติด​ตั้ง​แท็ก Conversion Linker ใน​เซิร์ฟเวอร์​ก่อน​จึง​จะ​ทำงาน
  3. Google Ads Remarketing เมื่อ ad_storage เป็น​ปฏิเสธ บล็อก​ทั้ง​คำขอ HTTP และ​การ​ใช้​คุกกี้

หน้า​นี้​อธิบาย​เฉพาะ​แท็ก​ของ Google แท็ก​ของ​แพลตฟอร์ม​อื่น​ที่​วาง​ไว้​ใน​เซิร์ฟเวอร์​เดียวกัน​จึง​ต้อง​ตั้ง​ให้​อ่าน​สถานะ​ความ​ยินยอม​แยก​เอง ถ้า​ไม่​ตั้ง ข้อมูล​ของ​คน​ที่​ปฏิเสธ​อาจ​ถูก​ส่ง​ออก​ไป​ทั้ง​ที่​หน้า​เว็บ​บอก​ว่า​ไม่​ส่ง วิธี​เลือก​แบบ​ของ Consent Mode อยู่​ในConsent Mode v2 คือ​อะไร โมเดล​เติม​ข้อมูล​ได้​เฉพาะ​เว็บ​คน​เข้า​มาก

ใช้ server-side เพื่อ​หลบ​ตัว​บล็อก​โฆษณา​ได้​หรือ​ไม่

ใน​ทาง​เทคนิค คำขอ​ที่​ส่ง​ไป​โดเมน​ของ​เว็บ​เอง​อาจ​ไม่​ถูก​ตัว​บล็อก​บาง​ตัว​จับ แต่​ใน​ทาง​กฎหมาย​และ​ความ​ไว้ใจ คำถาม​ที่​ต้อง​ตอบ​คือ​ผู้​ใช้​ยินยอม​หรือ​ไม่ กฎหมาย​ข้อมูล​ส่วน​บุคคล​ไทย​มาตรา 19 วาง​หลัก​ว่า​ธุรกิจ​นำ​ข้อมูล​ของ​บุคคล​ไป​เก็บ​รวบรวม ใช้ หรือ​ส่ง​ต่อ​ได้​เมื่อ​เจ้าของ​ข้อมูล​ยินยอม​ไว้​ก่อน​หรือ​ใน​ขณะ​นั้น เว้น​แต่​มี​กฎหมาย​ให้​ทำได้ และ​การ​ถอน​คำ​ยินยอม​ต้อง​ทำได้​ง่าย​ไม่​ต่าง​จาก​ตอน​ที่​ให้ ผู้​ใช้​ที่​ติด​ตั้ง​ตัว​บล็อก​กำลัง​บอก​ความ​ต้องการ​ของ​ตัว​เอง​อยู่​แล้ว การ​ออกแบบ​ระบบ​เพื่อ​อ้อม​ความ​ต้องการ​นั้น​เสี่ยง​ทั้ง​ข้อ​กฎหมาย​และ​ชื่อ​เสียง​ของ​แบรนด์ ถ้า​ผู้​ใช้​รู้​ภาย​หลัง ตัว​บท​ฉบับ​เต็ม​อยู่​ในไฟล์​กฎหมาย​ที่​เผย​แพร่​บน​เว็บ​ของ​สำนักงาน​คณะ​กรรมการ​คุ้มครอง​ข้อมูล​ส่วน​บุคคล

ส่ง​ซ้ำ​สอง​ทาง​ต้อง​กัน​การ​นับ​ซ้ำ

ธุรกิจ​ที่​ย้าย​ไป​ฝั่ง​เซิร์ฟเวอร์​มัก​ส่ง​เหตุการณ์​ให้ Meta สอง​ทาง ทาง​หนึ่ง​จาก​พิกเซล​บน​หน้า​เว็บ อีก​ทาง​จาก Conversions API บน​เซิร์ฟเวอร์ ถ้า​ไม่​ตั้ง​อะไร​เพิ่ม การ​ซื้อ​หนึ่ง​ครั้ง​อาจ​ถูก​นับ​สอง​ครั้ง เอกสาร​ของ Meta ให้​สอง​วิธี​กัน​การ​นับ​ซ้ำ

  1. ใช้​รหัส​เหตุการณ์ ส่ง eventID จาก​พิกเซล​ให้​ตรง​กับ event_id ของ Conversions API และ​ให้​ชื่อ​เหตุการณ์​ของ​พิกเซล​ตรง​กับ event_name ของ​เซิร์ฟเวอร์ ถ้า Meta ได้​รับ​คู่​ที่​ตรง​กัน​ไป​ยัง​พิกเซล​เดียวกัน​ภายใน 48 ชั่วโมง จะ​ทิ้ง​เหตุการณ์​ที่มา​ทีหลัง
  2. ใช้​ข้อมูล​ระบุ​ผู้​ใช้ ส่ง event_name คู่​กับ fbp หรือ external_id ให้​ตรง​กัน​ทั้ง​สอง​ทาง แล้ว Meta จะ​เทียบ​กันเอง

เอกสาร​ย้ำ​ว่า Meta จะ​ตัด​เหตุการณ์​ที่​มี​รหัส​ซ้ำ​ออก​ได้​ก็​ต่อ​เมื่อ​เหตุการณ์​ที่​สอง​มา​ถึง​ไม่​เกิน 48 ชั่วโมง​หลัง​เหตุการณ์​แรก​ที่​ใช้​รหัส​เดียวกัน ระบบ​ที่​ส่ง​ข้อมูล​จาก​เซิร์ฟเวอร์​ช้า​เป็น​วัน เช่น ส่ง​เป็น​ชุด​ทุก​คืน จึง​ควร​ตรวจ​เวลา​ส่ง​ด้วย โครงสร้าง​บัญชี​โฆษณา​ของ Meta ที่​ต้อง​เข้าใจ​ก่อน​ตั้ง​ค่า​นี้​อยู่​ในMeta Ads พอร์ต​โฟ​ลิ​โอ​ธุรกิจ บัญชี​โฆษณา และ​แคมเปญ​สาม​ชั้น

ค่า​เซิร์ฟเวอร์​ใน​คู่มือ​เป็น​ราคา​ประมาณ

ข้อมูล​ใน​บท​นี้​มี​ขอบเขต​ห้า​ข้อ

  1. 45 ดอลลาร์​เป็น​ตัวเลข​ประมาณ​ของ Google ราคา Cloud Run จริง​ขึ้น​กับ​ภูมิภาค​ที่​เลือก​และ​ปริมาณ​คำขอ คู่มือ​ให้​ใช้​เครื่อง​คำนวณ​ราคา​ของ Google Cloud ประเมิน​เอง
  2. บท​นี้​ไม่​ได้​ตรวจ​ผู้​ให้​บริการ​โฮสต์ server container ราย​อื่น ผู้​ให้​บริการ​แต่ละ​ราย​มี​ราคา​และ​เงื่อนไข​การ​เก็บ​ข้อมูล​ต่าง​กัน
  3. ไม่มี​ตัวเลข​ว่า​ย้าย​แล้ว​ได้​ข้อมูล​เพิ่ม​กี่​เปอร์เซ็นต์ ผล​ขึ้น​กับ​สัดส่วน​ผู้​ใช้​ที่​ใช้​ตัว​บล็อก สัดส่วน​ที่​กด​ปฏิเสธ และ​แท็ก​ที่​เว็บ​ใช้
  4. เอกสาร​ของ Meta ที่​อ้าง​เป็น​ฉบับ​ที่​เปิด​อ่าน​ใน​เดือน​กันยายน 2569 Meta ปรับ​เอกสาร​สำหรับ​นัก​พัฒนา​เป็น​ระยะ ก่อน​ตั้ง​ค่า​จริง​ควร​เปิด​หน้า​ล่าสุด​อีก​ครั้ง
  5. บท​นี้​ไม่ใช่​คำ​แนะนำ​ทาง​กฎหมาย มาตรา 19 ยก​มา​เพื่อ​ให้​เห็น​หลัก​เรื่อง​ความ​ยินยอม การ​ประเมิน​ว่า​ข้อมูล​แต่ละ​ชนิด​ใช้​ฐาน​ทาง​กฎหมาย​ใด​ควร​ให้​ที่​ปรึกษา​กฎหมาย​ตรวจ

ธุรกิจ​ที่​อยาก​รู้ตัว​เลข​ของ​ตัว​เอง​ควร​เก็บ​สัดส่วน​คน​ที่​กด​ยอมรับ​และ​ปฏิเสธ​บน​ป้าย​ขอ​ความ​ยินยอม​ไว้​สัก​หนึ่ง​เดือน​ก่อน​คุย​เรื่อง​ย้าย​ระบบ

ห้า​คำถาม​ก่อน​ตอบ​รับ​ข้อ​เสนอ

  1. ค่า​เซิร์ฟเวอร์​ราย​เดือน​เท่าไร ใคร​จ่าย และ​บัญชี Google Cloud เป็น​ชื่อ​ของ​ใคร บัญชี​ควร​เป็น​ของ​ธุรกิจ ไม่ใช่​ของ​ผู้​ติด​ตั้ง
  2. เซิร์ฟเวอร์​รัน​กี่​เครื่อง และ​ปิด​การ​บันทึก​คำขอ​หรือ​ยัง ถ้า​รัน​เครื่อง​เดียว ต้อง​รู้​ว่า​จะ​เกิด​อะไร​เมื่อ​เครื่อง​ล่ม
  3. แท็ก​ที่​ไม่ใช่​ของ Google ใน​เซิร์ฟเวอร์​อ่าน​สถานะ​ความ​ยินยอม​หรือ​ไม่ ขอ​ให้​สาธิต​ด้วย​การ​กด​ปฏิเสธ​บน​ป้าย แล้ว​ดู​ว่า​มี​ข้อมูล​ส่ง​ออก​ไป​หรือ​ไม่
  4. ส่ง​เหตุการณ์​ให้ Meta สอง​ทาง​หรือ​ไม่ และ​กัน​นับ​ซ้ำ​ด้วย​วิธี​ไหน ถ้า​ใช้​รหัส​เหตุการณ์ ต้อง​ตรวจ​ว่า​รหัส​ตรง​กัน​ทั้ง​สอง​ทาง
  5. วัดผล​อย่างไร​ว่า​ย้าย​แล้ว​ดี​ขึ้น ควร​ตกลง​ตัวเลข​ที่​ใช้​เทียบ​ก่อน​เริ่ม เช่น จำนวน​การ​แปลง​ที่​ระบบ​โฆษณา​เห็น​เทียบ​กับ​ยอด​ขาย​ใน​ระบบ​หลัง​บ้าน​ช่วง​เดียวกัน

หน้า​บริการ​ที่​เกี่ยว​กับ​การ​ตรวจ​ระบบ​วัดผล​ก่อน​ลงทุน​คือบริการ​ที่​ปรึกษา​การ​ตลาด

ใช้​แพลตฟอร์ม​ร้าน​ค้า​แบบ​เช่า​ใช้​อยู่ ควร​เริ่ม​ตรง​ไหน

เริ่ม​จาก​ดู​ว่า​แพลตฟอร์ม​มี​ตัว​เชื่อม​กับ Google และ Meta ที่​ส่ง​ข้อมูล​จาก​ฝั่ง​เซิร์ฟเวอร์​ให้​แล้ว​หรือ​ไม่ แพลตฟอร์ม​ร้าน​ค้า​หลาย​ราย​มี​ตัว​เชื่อม​เหล่า​นี้​ใน​หน้า​ตั้ง​ค่า ซึ่ง​ทำงาน​บน​เซิร์ฟเวอร์​ของ​แพลตฟอร์ม​เอง ร้าน​ไม่​ต้อง​จ่าย​ค่า Cloud Run และ​ไม่​ต้อง​ดูแล​เซิร์ฟเวอร์ สิ่ง​ที่​ร้าน​ยัง​ต้อง​ตรวจ​คือ​ตัว​เชื่อม​นั้น​อ่าน​สถานะ​ความ​ยินยอม​จาก​ป้าย​บน​หน้า​ร้าน​หรือ​ไม่ และ​กัน​การ​นับ​ซ้ำ​กับ​พิกเซล​บน​หน้า​เว็บ​อย่างไร ถ้า​เอกสาร​ของ​แพลตฟอร์ม​ไม่​ตอบ​สอง​เรื่อง​นี้ ให้​ถาม​ฝ่าย​ช่วย​เหลือ​ของ​แพลตฟอร์ม​เป็น​ลาย​ลักษณ์​อักษร

สรุป

Server-side tagging ของ Google Tag Manager ย้าย​การ​ประมวล​ผล​แท็ก​ไป​ไว้​บน​เซิร์ฟเวอร์​ที่​ธุรกิจ​ควบคุม ข้อมูล​จาก​หน้า​เว็บ​ผ่าน​เซิร์ฟเวอร์​ก่อน​ส่ง​ต่อ คู่มือ​ของ Google ประเมิน​ค่า​เซิร์ฟเวอร์​ราว 45 ดอลลาร์​ต่อ​เครื่อง​ต่อ​เดือน​และ​แนะนำ​อย่าง​น้อย 2 เครื่อง บวก​ค่า log เมื่อ​คำขอ​เกิน​หนึ่ง​ล้าน​ครั้ง​ต่อ​เดือน ความ​ยินยอม​ต้อง​ตั้ง​ที่​หน้า​เว็บ​แล้ว​ส่ง​ไป​กับ​คำขอ แท็ก​ของ Google ใน​เซิร์ฟเวอร์​ปรับ​ตาม​สถานะ​นั้น ส่วน​แท็ก​ของ​แพลตฟอร์ม​อื่น​ต้อง​ตั้ง​เอง ธุรกิจ​ที่​ส่ง​ข้อมูล​ให้ Meta ทั้ง​จาก​พิกเซล​และ Conversions API ต้อง​ใช้​รหัส​เหตุการณ์​ที่​ตรง​กัน​ภายใน 48 ชั่วโมง​เพื่อ​กัน​นับ​ซ้ำ การ​ย้าย​ระบบ​จึง​คุ้ม​เมื่อ​งบ​โฆษณา​สูง​พอ และ​ไม่​ควร​ใช้​เป็น​ทาง​อ้อม​ความ​ต้องการ​ของ​ผู้​ใช้​ที่​ปฏิเสธ​การ​เก็บ​ข้อมูล

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

client-side ให้​เบราว์เซอร์​ของ​ผู้​ใช้​ส่ง​ข้อมูล​ตรง​ไป​ยัง​เครื่อง​มือ​แต่ละ​ตัว server-side ให้​เบราว์เซอร์​ส่ง​ข้อมูล​มา​ที่​เซิร์ฟเวอร์​ของ​ธุรกิจ​ก่อน แล้ว​เซิร์ฟเวอร์​เป็น​ผู้​ส่ง​ต่อ ธุรกิจ​จึง​เลือก​ได้​ว่า​จะ​ตัด​หรือ​ส่ง​ข้อมูล​ใด​ต่อ​ไป​ยัง​เครื่อง​มือ​ใด

ไม่​ต้อง​เลิก​ทั้งหมด หน้า​เว็บ​ยัง​ต้อง​มี​แท็ก​ของ Google ที่​ส่ง​ข้อมูล​เข้า​เซิร์ฟเวอร์ และ​ยัง​ต้อง​มี​ป้าย​ขอ​ความ​ยินยอม ส่วน​แท็ก​ของ​เครื่อง​มือ​อื่น​ย้าย​ไป​อยู่​ใน​เซิร์ฟเวอร์​ได้ที​ละ​ตัว

ต้อง​มี​คน​ที่​ตั้ง​ค่า Google Cloud จัดการ​โดเมน และ​ตรวจ log ได้ การ​ติด​ตั้ง​ครั้ง​แรก​อาจ​ทำ​ตาม​คู่มือ​ได้ แต่​ระบบ​นี้​ต้อง​ดูแล​ต่อ เช่น อัปเดต​เซิร์ฟเวอร์​ตาม​รุ่น​ใหม่ และ​ตรวจ​ค่า​ใช้​จ่าย​ทุก​เดือน

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

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

PHYGITAL INSIGHT

ฟิจิ⁠ทัล​เทียบ​ค่า​เซิร์ฟเวอร์​และ​ค่า​ดูแล​ทั้ง​ปี​กับ​งบ​โฆษณา​ของ​ลูกค้า​ก่อน​แนะนำ​ให้​ย้าย​แท็ก หลาย​ครั้ง​คำ​ตอบ​คือ​ยัง​ไม่​ต้อง​ย้าย เพราะ​ปัญหา​จริง​อยู่​ที่​แท็ก​บน​หน้า​เว็บ​ยัง​นับ​การ​ติดต่อ​ไม่​ครบ ซึ่ง​แก้​ได้​โดย​ไม่​ต้อง​มี​เซิร์ฟเวอร์​ใหม่ บริการ​ที่​ปรึกษา​ของ​ฟิจิ⁠ทัล​ตรวจ​ทั้ง​ข้อ​เสนอ​และ​ระบบ​เดิม แล้ว​บอก​ลูกค้า​ตรง ๆ ว่า​ควร​ย้าย​ตอน​นี้ รอ​ก่อน หรือ​แก้​จุด​อื่น​แทน

ให้ PHYGITAL AGENCY ช่วยต่อยอดเรื่องนี้สู่ผลลัพธ์จริง

การ​ย้าย​แท็ก​ไป​ฝั่ง​เซิร์ฟเวอร์​มี​ค่า​ใช้​จ่าย​ทุก​เดือน และ​ไม่​ได้​ลบ​หน้าที่​เรื่อง​ความ​ยินยอม​ของ​ผู้​ใช้

ส่ง​ใบ​เสนอ​ราคา​เรื่อง server-side tracking ที่​ได้​รับ​มา​ให้ PHYGITAL AGENCY อ่าน แล้ว​เรา​จะ​ไล่​ห้า​คำถาม​นี้​ให้​ก่อน​คุณ​ตัดสิน​ใจ

PARANATH PANARATANA

WRITTEN BY

PARANATH PANARATANA

CHAIRMAN OF PHYGITAL AGENCY

ประธานกรรมการบริษัท ฟิจิทัล เอเจนซี จำกัด มีประสบการณ์ดูแลการตลาดที่ผสานโลกจริงและโลกออนไลน์เข้าด้วยกัน ตลอดจนเป็นที่ปรึกษาในการวินิจฉัยธุรกิจ อีกทั้งยังเคยทำงานในสายวิดีโอโปรดักชั่นและภาพยนตร์ไทยอีกด้วย