Cookie Policy คืออะไร? คู่มือสำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์

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

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

ปัญหาของ Cookie Policy Template เดียวที่ใช้ซ้ำกับลูกค้าทุกราย

เพื่อประหยัดเวลา เอเจนซีจำนวนมากเขียน Cookie Policy แม่แบบไว้ชุดเดียว แล้วเปลี่ยนแค่ชื่อบริษัทกับโลโก้ก่อนส่งมอบให้ลูกค้าแต่ละราย ปัญหาคือลูกค้าแต่ละรายติดตั้งเครื่องมือไม่เหมือนกัน บางรายใช้ Google Analytics อย่างเดียว บางรายเพิ่ม Facebook Pixel, TikTok Pixel, หรือ heatmap tool อย่าง Hotjar เข้ามาเอง Cookie Policy แม่แบบที่ไม่ได้ปรับตามคุกกี้จริงของแต่ละเว็บจึงมักระบุข้อมูลผิดตั้งแต่วันแรกที่ส่งมอบ

ทางแก้ที่ใช้งานได้จริงคือแยก Cookie Policy เป็นสองชั้น ชั้นแรกคือโครงสร้างและถ้อยคำมาตรฐานที่ใช้ร่วมกันได้ทุกเว็บ ชั้นที่สองคือรายการคุกกี้จริงที่ต้องสแกนแยกเป็นรายเว็บ แล้วประกอบเข้ากับโครงสร้างมาตรฐานโดยอัตโนมัติ ไม่ใช่พิมพ์รายการคุกกี้ด้วยมือทีละเว็บ

ความต่างของการสแกนคุกกี้ในแต่ละแพลตฟอร์ม: WordPress, Webflow, Shopify

แพลตฟอร์ม	จุดที่มักมีคุกกี้แอบติดตั้งเพิ่ม
WordPress	ปลั๊กอินฟอร์ม ปลั๊กอิน SEO และปลั๊กอิน cache ที่ลูกค้าติดตั้งเองโดยไม่แจ้งเอเจนซี
Webflow	Embed code ที่ทีมการตลาดฝั่งลูกค้าวางเองผ่านหน้า custom code โดยตรง
Shopify	แอปจาก App Store ที่ติดตั้งเพิ่มเพื่อ marketing automation หรือ upsell ซึ่งมักมาพร้อมคุกกี้ tracking ของตัวเอง

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

ทำไมคุกกี้ที่สแกนพบบน Staging กับ Production ถึงไม่ตรงกัน

เวลาทำเว็บใหม่ เอเจนซีมักสแกนคุกกี้บนสภาพแวดล้อม staging ก่อนส่งมอบ แต่พอขึ้น production จริงมักมีการเพิ่มเครื่องมือ marketing ที่ทีมลูกค้าติดตั้งเองระหว่างช่วงเตรียมเปิดตัว เช่น pixel โฆษณาที่ทีมสื่อฝั่งลูกค้าใส่เพิ่มก่อนวัน launch เพียงไม่กี่วัน ทำให้ Cookie Policy ที่เขียนจากผลสแกน staging ไม่ตรงกับคุกกี้จริงบน production ตั้งแต่วันแรกที่เว็บเปิดใช้งาน

วิธีป้องกันคือกำหนดให้สแกนคุกกี้อีกครั้งบน production หลัง launch จริงเสมอ ไม่ใช้ผลสแกนจาก staging เป็นเวอร์ชันสุดท้าย และแจ้งลูกค้าให้ชัดว่าเครื่องมือใดก็ตามที่เพิ่มหลังจากนั้นต้องแจ้งเอเจนซีหรือผู้ดูแลเพื่ออัปเดต Cookie Policy ตาม

สัญญาประมวลผลข้อมูล (DPA) กับลูกค้าและขอบเขตความรับผิดชอบ

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

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

กระบวนการส่งมอบงาน (Handoff) ให้ลูกค้าดูแล Cookie Policy ต่อเอง

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

ตัวอย่างสถานการณ์จริง: ลูกค้าเปลี่ยนทีมการตลาดกลางทาง

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

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

การจัดการหลายโดเมนและหลายภาษาในโปรเจกต์เดียว

ลูกค้าเอเจนซีบางรายมีเว็บหลักและเว็บย่อยหลายภาษาสำหรับตลาดต่างประเทศ ซึ่งบางครั้งใช้ analytics คนละบัญชีหรือคนละเครื่องมือในแต่ละภาษา เพราะทีมการตลาดประจำแต่ละประเทศเลือกเครื่องมือของตัวเอง Cookie Policy ที่เขียนจากการสแกนเฉพาะเว็บภาษาไทยจึงอาจไม่ครอบคลุมคุกกี้ที่เว็บภาษาอังกฤษหรือภาษาอื่นใช้งานจริง

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

เครื่องมือภายในสำหรับติดตามสถานะ Cookie Policy ของลูกค้าแต่ละราย

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

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

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

เช็กลิสต์ปฏิบัติ

• แยก Cookie Policy เป็นโครงสร้างมาตรฐานที่ใช้ร่วมกันได้ กับรายการคุกกี้จริงที่สแกนแยกเป็นรายเว็บ
• สแกนคุกกี้ซ้ำบน production หลัง launch จริงเสมอ ไม่ใช้ผลจาก staging เป็นเวอร์ชันสุดท้าย
• ทำรอบสแกนคุกกี้ซ้ำเป็นระยะสำหรับเว็บที่ลูกค้าติดตั้งแอปหรือปลั๊กอินเพิ่มเองได้ (WordPress, Shopify)
• ทำสัญญาประมวลผลข้อมูล (DPA) กับลูกค้าทุกรายก่อนเริ่มเข้าถึงหรือประมวลผลข้อมูลผู้เยี่ยมชมเว็บของลูกค้า
• ระบุในสัญญาว่าเอเจนซียังมีสิทธิ์เข้าถึงบัญชี Analytics ของลูกค้าถึงเมื่อใดหลังโปรเจกต์จบ
• ทำเอกสารส่งมอบที่อธิบายชัดว่า Cookie Policy อ้างอิงคุกกี้ ณ วันส่งมอบ และลูกค้าต้องอัปเดตเองเมื่อเพิ่มเครื่องมือใหม่

ข้อผิดพลาดที่พบบ่อย

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

สรุป

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

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

ดูภาพรวมเรื่องนโยบายและประกาศต่าง ๆ ได้ที่ ศูนย์ความรู้ด้าน Policies & Notices หรือเทียบแนวทางกับธุรกิจ SaaS ที่ดูแลเว็บของตัวเองเว็บเดียวได้ที่ คู่มือ Cookie Policy สำหรับ SaaS และอ่านเรื่องคุกกี้และความยินยอมเพิ่มเติมได้ที่ ศูนย์ความรู้ด้าน Cookies & Consent

แหล่งข้อมูลอ้างอิง

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)
• ศูนย์ความรู้ด้าน Policies & Notices