ข้อดีและข้อเสียบางประการของการติดตามฝั่งเซิร์ฟเวอร์

ในโพสต์ก่อนหน้าของเราเกี่ยวกับ คอนเทนเนอร์ฝั่งเซิร์ฟเวอร์ (SSC) ของ Google Tag Manager เราได้เริ่มดูว่ามันทำงานอย่างไร ในบทความนี้ เราจะมาดูข้อดีหลักๆ บางประการที่ระบบฝั่งเซิร์ฟเวอร์จะมอบให้คุณ รวมถึงข้อเสียที่อาจเกิดขึ้น

ข้อดี

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

1) การปฏิบัติตามข้อกำหนด

ด้วยการสกัดกั้นข้อมูล Server-Side Container สามารถแก้ไขข้อมูลก่อนที่จะถูกส่งไปยังปลายทางสุดท้าย สิ่งนี้มีประโยชน์อย่างมากสำหรับการ ปฏิบัติตาม GDPR และการปกป้องความเป็นส่วนตัวที่คล้ายคลึงกัน เนื่องจากคุณสามารถลบข้อมูลใดๆ ที่อาจใช้สำหรับการทำโปรไฟล์และการพิมพ์ลายนิ้วมือก่อนที่จะไปถึงปลายทาง

เซิร์ฟเวอร์ที่คอนเทนเนอร์ฝั่งเซิร์ฟเวอร์ทำงานอยู่สามารถระบุตำแหน่งได้ ดังนั้น ข้อมูลที่ระบุได้นี้จึงไม่จำเป็นต้องออกจากอาณาเขตที่รวบรวมไว้ (สหภาพยุโรปที่สำคัญที่สุดสำหรับ GDPR) ก่อนที่จะถูกลบ

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

2) คุกกี้บุคคลที่หนึ่ง

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

3) รวบรวมข้อมูลสำหรับเครื่องมือเดียวและเขียนถึงผู้อื่น

เมื่อข้อมูลถูกส่งจากเว็บไซต์ อาจมีไว้สำหรับเครื่องมือหนึ่ง แต่สามารถแยกวิเคราะห์และส่งไปยังผู้อื่นได้ สิ่งนี้อาจมีประโยชน์อย่างเหลือเชื่อในหลายกรณี ตัวอย่างอาจเป็นการนำ Hit ขาเข้าจากคำขอ Universal Analytics แยกวิเคราะห์ข้อมูล และส่งไปยังตาราง Google BigQuery ฟังก์ชันนี้ใช้ได้กับ Universal Analytics ในผลิตภัณฑ์ Universal Analytics 360 ระดับพรีเมียมเท่านั้น

4) การลดโหลดฝั่งไคลเอ็นต์

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

5) การซ่อนคีย์ API และข้อมูลลับไคลเอ็นต์

เนื่องจากข้อมูลจะถูกส่งไปยังเครื่องมือสุดท้ายจากคอนเทนเนอร์ฝั่งเซิร์ฟเวอร์เท่านั้น คีย์ API และความลับของไคลเอ็นต์ทั้งหมดจึงสามารถเก็บไว้ในคอนเทนเนอร์ฝั่งเซิร์ฟเวอร์ได้ เพื่อหลีกเลี่ยงโอกาสที่สิ่งเหล่านี้จะถูกเปิดเผยในฝั่งไคลเอ็นต์ ตัวอย่างนี้คือ Google Analytics UA-ID บุคคลที่สามสามารถไปที่ไซต์ใดๆ ก็ตามที่ใช้ Google Analytics และเพียงแค่นำ UA-ID ออกจากไซต์และวางไว้บนไซต์อื่นและสแปมบัญชี Google Analytics เราได้เห็นสิ่งนี้เกิดขึ้นบ่อยครั้งในช่วงหลายปีที่ผ่านมา การติดตามฝั่งเซิร์ฟเวอร์จะไม่สามารถทำได้ เนื่องจากคุณสามารถเพิ่ม UA-ID ได้ทางฝั่งเซิร์ฟเวอร์เท่านั้น และจะไม่ปรากฏให้เห็นเลยเมื่อเว็บไซต์โหลด

6) โหลดสคริปต์ติดตามจากโดเมนของคุณเอง

ซึ่งสามารถเห็นได้ทั้งข้อดีและข้อเสียของการติดตามฝั่งเซิร์ฟเวอร์ เนื่องจากคอนเทนเนอร์ฝั่งเซิร์ฟเวอร์สามารถเรียกใช้เครื่องมือที่เป็นปัญหาได้โดยตรง จึงสามารถใช้คอนเทนเนอร์ฝั่งเซิร์ฟเวอร์เพื่อดึงไฟล์ JavaScript ที่เครื่องมือส่วนใหญ่ (GA, Facebook, LinkedIn ฯลฯ…) ดึงเข้ามาในไซต์ได้ เมื่อดึงแล้วสามารถส่งไฟล์ไปยังไซต์ได้ ซึ่งหมายความว่าคุณสามารถหลีกเลี่ยงการเรียกไปยังไซต์ของบุคคลที่สามได้โดยตรงจากเบราว์เซอร์ของผู้ใช้ และสามารถช่วยให้คุณหยุดการดึงสคริปต์ที่ไม่ต้องการใดๆ เข้ามา เนื่องจากไฟล์นี้จะถูกส่งจากโดเมนของตัวเอง (หาก SCC ถูกตั้งค่าด้วยวิธีนี้) บริการที่บล็อกตัวติดตามที่รู้จักโดยอัตโนมัติ (เช่น เบราว์เซอร์เช่น Firefox, Safari และ Brave) จะไม่รู้จักไฟล์นั้นเป็นสคริปต์ติดตาม การดำเนินการนี้ไม่รับประกันเสมอไป เนื่องจากบริการเหล่านี้อาจระบุโดเมนของเว็บไซต์ของคุณว่าเป็นตัวติดตามในที่สุด สิ่งสำคัญคือต้องจำไว้ว่าโปรแกรมวิเคราะห์ของคุณควรเคารพตัวเลือกความเป็นส่วนตัวของผู้ใช้เสมอ

ข้อเสีย

มีข้อเสียและสถานการณ์บางอย่างในการติดตามฝั่งเซิร์ฟเวอร์ที่คุณควรระวัง ประเด็นเหล่านี้เกี่ยวกับการยกระดับเพิ่มเติมที่ใช้ในการเรียกใช้การติดตามฝั่งเซิร์ฟเวอร์รวมถึงข้อผิดพลาดบางประการในการรับผิดชอบต่อความถูกต้องของข้อมูลและความเป็นส่วนตัวของผู้ใช้ของคุณมากขึ้น

1) ความเชี่ยวชาญทางเทคนิค

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

2) ความถูกต้องของข้อมูลขึ้นอยู่กับคุณ

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

3) ค่าใช้จ่าย

การติดตามฝั่งเซิร์ฟเวอร์ต่างจากคอนเทนเนอร์เว็บของ Google Tag Manager ในการเรียกใช้คอนเทนเนอร์ฝั่งเซิร์ฟเวอร์ จะต้องสร้างคอนเทนเนอร์บนโครงสร้างพื้นฐานของ Google Cloud โดยใช้คุณลักษณะ App Engine นอกจากนี้ คุณจะต้องให้คอนเทนเนอร์ทำงานบนอินสแตนซ์เซิร์ฟเวอร์สองสามตัวเพื่อพิจารณาความซ้ำซ้อนและความจุ คุณจะต้องจ่ายเงินสำหรับกรณีเหล่านี้ แน่นอน ยิ่งคุณรันเซิร์ฟเวอร์มากเท่าไหร่ และข้อมูลยิ่งส่งมากเท่าไหร่ ต้นทุนก็ยิ่งสูงขึ้นเท่านั้น

4) ความกังวลเรื่องความเป็นส่วนตัว

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

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