การติดแท็กฝั่งเซิร์ฟเวอร์
ย้ายแท็กไปยังเซิร์ฟเวอร์
การติดแท็กฝั่งเซิร์ฟเวอร์ เป็นบทเรียน Digital Marketing Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Digital Marketing Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Digital Marketing Academy มีบทเรียนทั้งหมด 4 บทเรียน
การติดแท็กฝั่งเซิร์ฟเวอร์คืออะไร
การติดแท็กฝั่งเซิร์ฟเวอร์ย้ายการประมวลผลแท็กออกจากเบราว์เซอร์ของผู้ใช้มาไว้ในเซิร์ฟเวอร์ที่คุณควบคุม แทนที่หน้าเว็บจะส่งพิกเซลโดยตรงไปยัง Google และ Meta หน้าเว็บจะส่งคำขอหนึ่งรายการไปยังจุดปลายทางการติดแท็กของคุณเอง
จากนั้นเซิร์ฟเวอร์จะตัดสินใจว่าจะส่งข้อมูลใดต่อ ส่งให้ใคร และจัดรูปแบบอย่างไร เบราว์เซอร์จะติดต่อกับโดเมนบุคคลที่หนึ่งของคุณเท่านั้น
ลำดับการทำงานฝั่งไคลเอนต์เทียบกับฝั่งเซิร์ฟเวอร์
ในรูปแบบดั้งเดิม พิกเซลของผู้ให้บริการแต่ละรายทำงานในเบราว์เซอร์ และแต่ละตัวส่งคำขอไปยังบุคคลที่สามของตนเอง ส่วนการทำงานฝั่งเซิร์ฟเวอร์ เบราว์เซอร์จะส่งเหตุการณ์หนึ่งรายการไปยังเซิร์ฟเวอร์การติดแท็ก แล้วเซิร์ฟเวอร์จะกระจายเหตุการณ์นั้นต่อไป
วิธีนี้ทำให้คุณควบคุมข้อมูลได้ ลดคำขอที่ถูกบล็อก และลดขนาดโค้ดฝั่งไคลเอนต์ที่ทำให้หน้าเว็บช้าลง
CLIENT-SIDE (old)
Browser --> google-analytics.com
Browser --> facebook.com/tr
Browser --> tiktok.com/pixel
(each blockable, leaks data)
SERVER-SIDE (new)
Browser --> sgtm.yoursite.com (1 request)
|
+----------+----------+
v v v
GA4 Meta CAPI TikTok
(server-to-server, controlled)เซิร์ฟเวอร์การติดแท็ก (sGTM)
Server-Side Google Tag Manager (sGTM) ของ Google เป็นการนำไปใช้ที่พบได้ทั่วไปที่สุด โดยเป็นคอนเทนเนอร์ที่ทำงานบน Cloud Run, App Engine หรือโฮสต์ใด ๆ รับคำขอและประมวลผลผ่านไคลเอนต์และแท็ก
ไคลเอนต์จะวิเคราะห์คำขอขาเข้าให้เป็นเหตุการณ์ จากนั้นแท็กจะส่งเหตุการณ์เหล่านั้นต่อไปยังปลายทางต่าง ๆ นี่คือ GTM แต่ทำงานบนเซิร์ฟเวอร์แทนที่จะทำงานบนหน้าเว็บ
โดเมนย่อยบุคคลที่หนึ่ง
ประโยชน์ด้านความน่าเชื่อถือที่สำคัญเกิดจากการกำหนดเซิร์ฟเวอร์การติดแท็กให้ใช้โดเมนย่อยของเว็บไซต์คุณเอง เช่น sgtm.example.com ผ่านระเบียน DNS A หรือ CNAME
เนื่องจากคำขอไปยังโดเมนของคุณแล้ว คุกกี้ที่ตั้งค่าในคำตอบจึงเป็นคุกกี้บุคคลที่หนึ่งและเป็น HttpOnly คุกกี้เหล่านี้หลุดพ้นจากข้อจำกัด ITP ที่เข้มงวดที่สุด และมีโอกาสถูกตัวบล็อกโฆษณาบล็อกน้อยกว่ามาก
DNS + cookie setup
--------------------------------------
sgtm.example.com -> Cloud Run host
Response header from server:
Set-Cookie: FPID=abc123; Domain=.example.com;
HttpOnly; Secure; SameSite=Lax;
Max-Age=63072000
=> first-party, server-set, long-lived
=> survives ITP better than JS cookiesเหตุการณ์เดินทางอย่างไร
มีการซื้อเกิดขึ้นบนหน้าเว็บ คอนเทนเนอร์เว็บ (หรือ gtag) ส่งเหตุการณ์ไปยัง sgtm.example.com ไคลเอนต์ GA4 ที่นั่นจะสร้างข้อมูลการเข้าชมขึ้นใหม่ เติมข้อมูลให้ครบถ้วน แล้วแท็ก GA4 จะส่งต่อไปยังจุดปลายทางการรวบรวมข้อมูลของ Google
เหตุการณ์เดียวกันนี้สามารถเรียกใช้แท็ก Meta Conversions API, คอนเวอร์ชัน Google Ads ฝั่งเซิร์ฟเวอร์ และรายการอื่น ๆ ได้พร้อมกัน ทั้งหมดมาจากคำขอขาเข้ารายการเดียว
Event payload sketch (purchase)
--------------------------------------
{
"event_name": "purchase",
"client_id": "FPID.abc123",
"value": 89.90,
"currency": "EUR",
"transaction_id": "T-10482",
"items": [{"id":"SKU1","qty":2}],
"consent": {"ad_user_data":"granted"},
"user_data": {"em_hashed":"<sha256>"}
}Conversions API (CAPI)
Conversions API ของ Meta, Enhanced Conversions ของ Google และ Events API ของ TikTok ล้วนเป็นจุดปลายทางระหว่างเซิร์ฟเวอร์กับเซิร์ฟเวอร์ โดยรับเหตุการณ์โดยตรงจากเซิร์ฟเวอร์ของคุณและข้ามพิกเซลของเบราว์เซอร์ไปทั้งหมด
วิธีนี้ช่วยกู้คืนคอนเวอร์ชันที่สูญหายจากตัวบล็อกโฆษณาและ ITP และทำให้คุณส่งตัวระบุบุคคลที่หนึ่งที่ผ่านการแฮช เช่น อีเมลหรือหมายเลขโทรศัพท์ เพื่อจับคู่ได้ดีขึ้น โดยต้องมีความยินยอม
การเพิ่มข้อมูลและการควบคุม
เนื่องจากเซิร์ฟเวอร์มองเห็นเหตุการณ์ดิบ คุณจึงสามารถเพิ่มข้อมูลให้เหตุการณ์ได้ เช่น เติมมูลค่าคำสั่งซื้อที่แท้จริงจากฐานข้อมูล ลบ PII ที่ไม่ต้องการแชร์ เพิ่มเวลาประทับฝั่งเซิร์ฟเวอร์ หรือขจัดเหตุการณ์ซ้ำเมื่อเทียบกับเหตุการณ์จากไคลเอนต์
คุณจะกลายเป็นผู้กลั่นกรองข้อมูลของตนเอง โดยส่งให้แต่ละแพลตฟอร์มเฉพาะช่องข้อมูลขั้นต่ำที่จำเป็น นี่คือการลดทอนข้อมูลให้เหลือน้อยที่สุดในทางปฏิบัติ ไม่ใช่แค่นโยบาย
Server-side transform rules
--------------------------------------
INCOMING -> TRANSFORM -> OUTBOUND
- hash email (SHA-256) before send
- drop raw IP for non-consented users
- overwrite value w/ DB net revenue
- add event_id for dedup w/ pixel
- block forwarding if consent=deniedการขจัดเหตุการณ์ซ้ำ
หากคุณใช้ทั้งพิกเซลของเบราว์เซอร์และเหตุการณ์จากเซิร์ฟเวอร์สำหรับคอนเวอร์ชันเดียวกัน แพลตฟอร์มจะต้องไม่นับเหตุการณ์นั้นซ้ำ การขจัดเหตุการณ์ซ้ำใช้ตัวระบุร่วมกัน
ส่ง event_id เดียวกัน (และ event_name) จากทั้งพิกเซลของไคลเอนต์และคำขอ CAPI จากเซิร์ฟเวอร์ Meta และแพลตฟอร์มอื่นจะจับคู่ข้อมูลเหล่านี้แล้วเก็บไว้เพียงรายการเดียว ทำให้มีข้อมูลสำรองโดยไม่ทำให้ตัวเลขสูงเกินจริง
Dedup with event_id
--------------------------------------
Browser pixel:
fbq('track','Purchase',{...},
{eventID:'evt_T-10482'})
Server CAPI:
event_id: 'evt_T-10482'
event_name: 'Purchase'
Meta sees same id+name -> counts onceโฮสติ้งและต้นทุน
เซิร์ฟเวอร์การติดแท็กเป็นโครงสร้างพื้นฐานจริง บน Google Cloud Run เซิร์ฟเวอร์จะปรับขนาดอัตโนมัติตามปริมาณการใช้งาน และคุณจะจ่ายค่าการประมวลผลกับการส่งข้อมูลออก เว็บไซต์ขนาดเล็กอาจใช้เพียงสองสามอินสแตนซ์ ส่วนเว็บไซต์ขนาดใหญ่อาจใช้จำนวนมาก
วางแผนสำหรับการตรวจสอบ เซิร์ฟเวอร์ดูตัวอย่างสำหรับการแก้ไขข้อบกพร่อง และความพร้อมใช้งาน เพราะหากเซิร์ฟเวอร์การติดแท็กหยุดทำงาน การวัดผลก็จะหยุดไปด้วย ตอนนี้เซิร์ฟเวอร์นี้เป็นบริการสำหรับระบบจริง ไม่ใช่เพียงโค้ดสั้น ๆ
ข้อจำกัดและความเป็นจริง
การติดแท็กฝั่งเซิร์ฟเวอร์ไม่ใช่ช่องทางหลบเลี่ยงความยินยอม คุณยังคงต้องมีฐานทางกฎหมาย และการส่งข้อมูลโดยไม่ได้รับความยินยอมก็ผิดกฎหมาย ไม่ว่าข้อมูลจะถูกประมวลผลที่ใด
นอกจากนี้ยังไม่สามารถกู้คืนการติดตามข้ามเว็บไซต์แบบระบุผลได้แน่นอนอย่างน่าอัศจรรย์ แต่ช่วยเพิ่มความน่าเชื่อถือและการจับคู่สำหรับข้อมูลบุคคลที่หนึ่งที่ได้รับความยินยอม เป็นชั้นเสริมความทนทาน ไม่ใช่ช่องโหว่
รายการตรวจสอบการนำไปใช้
การนำไปใช้จริงต้องดำเนินตามลำดับดังนี้ ตั้งเซิร์ฟเวอร์ กำหนดโดเมนย่อย เชื่อมคอนเทนเนอร์เว็บเข้ากับเซิร์ฟเวอร์ ตั้งค่าไคลเอนต์และแท็ก แล้วเชื่อมต่อปลายทาง CAPI
ตรวจสอบด้วยมุมมองดูตัวอย่างและแก้ไขข้อบกพร่อง ยืนยันว่าการขจัดเหตุการณ์ซ้ำทำงาน ตรวจสอบการควบคุมตามความยินยอม แล้วจึงเปลี่ยนเส้นทางปริมาณการใช้งาน ปฏิบัติต่อกระบวนการนี้เหมือนการนำบริการหลังบ้านใด ๆ ไปใช้งาน
Rollout checklist
--------------------------------------
[ ] Deploy sGTM (Cloud Run)
[ ] Map sgtm.example.com (CNAME)
[ ] Web container -> send to sGTM
[ ] GA4 client + GA4 tag configured
[ ] Meta CAPI tag + event_id dedup
[ ] Consent checks on every tag
[ ] Preview/debug verified
[ ] Monitoring + alerts on uptimeแบบทดสอบสั้น ๆ
ทดสอบความเข้าใจเกี่ยวกับการติดแท็กฝั่งเซิร์ฟเวอร์
สรุป
การติดแท็กฝั่งเซิร์ฟเวอร์กำหนดเส้นทางเหตุการณ์จากเบราว์เซอร์ไปยังเซิร์ฟเวอร์การติดแท็กบนโดเมนย่อยของคุณเอง เซิร์ฟเวอร์นี้จะตั้งค่าคุกกี้บุคคลที่หนึ่งและส่งข้อมูลที่ได้รับความยินยอมต่อไปยังแพลตฟอร์มผ่าน API ระหว่างเซิร์ฟเวอร์ เช่น Meta CAPI
ประโยชน์ ได้แก่ คำขอที่ถูกบล็อกน้อยลง คุกกี้ที่ทำงานร่วมกับ ITP ได้ดีขึ้น การเพิ่มข้อมูลและการลดทอนข้อมูลให้เหลือน้อยที่สุด และการขจัดเหตุการณ์ซ้ำ นี่คือชั้นด้านความน่าเชื่อถือและการควบคุม เป็นโครงสร้างพื้นฐานจริงที่ต้องดูแล และไม่ใช่สิ่งทดแทนความยินยอม
เรียนรู้ Digital Marketing Academy ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 63
- บทเรียน
- 239
คำถามที่พบบ่อย
บทเรียน “การติดแท็กฝั่งเซิร์ฟเวอร์” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การติดแท็กฝั่งเซิร์ฟเวอร์” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Digital Marketing Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Digital Marketing Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การติดแท็กฝั่งเซิร์ฟเวอร์”
ย้ายแท็กไปยังเซิร์ฟเวอร์ คุณปฏิบัติ Digital Marketing Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Digital Marketing Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Digital Marketing Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “การติดแท็กฝั่งเซิร์ฟเวอร์” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Digital Marketing Academy นี้ได้ไหม
ได้ บทเรียน Digital Marketing Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- เหตุใดการติดตามจึงใช้งานไม่ได้
- การติดแท็กฝั่งเซิร์ฟเวอร์
- โหมดการให้ความยินยอมและ CMP
- กลยุทธ์ข้อมูลจากบุคคลที่หนึ่ง