ข้อมูลส่วนบุคคลบนเว็บไซต์ คืออะไร? คู่มือสำหรับร้านค้าออนไลน์และ E-commerce

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

บทความนี้จึงไม่ได้ไล่นิยามข้อมูลส่วนบุคคลทีละประเภทตามตำรา แต่จะพาเจ้าของร้านและทีม Performance Marketing เดินตามเส้นทางจริงของลูกค้าหนึ่งคน เพื่อดูว่าข้อมูลอะไรเกิดขึ้นที่จุดไหน จุดไหนเสี่ยงที่สุด และควรวางมาตรการป้องกันอย่างไรให้เหมาะกับร้านค้าออนไลน์โดยเฉพาะ

บทความนี้อธิบายแนวทางเชิงปฏิบัติสำหรับร้านค้าออนไลน์และ E-commerce เท่านั้น ไม่ใช่คำแนะนำทางกฎหมายเฉพาะกรณี ควรปรึกษาที่ปรึกษากฎหมายของธุรกิจตนเองประกอบการตัดสินใจ

เส้นทางข้อมูลลูกค้า ตั้งแต่คลิกเข้าร้านจนถึงพัสดุถึงมือ

ลองไล่เส้นทางของลูกค้าคนหนึ่งที่คลิกโฆษณา Facebook เข้ามาดูสินค้า แล้วตัดสินใจซื้อ: pixel การตลาดบันทึก Cookie ID และพฤติกรรมการเข้าชมทันทีที่หน้าเว็บโหลด ก่อนที่ลูกค้าจะกรอกข้อมูลใด ๆ ด้วยซ้ำ เมื่อลูกค้าเพิ่มสินค้าลงตะกร้าและกรอกอีเมลเพื่อรับส่วนลด ระบบ Email Marketing ก็เริ่มมีข้อมูลระบุตัวตนโดยตรงเก็บไว้ในฐานข้อมูลของแอปการตลาดที่ร้านติดตั้งเพิ่ม เมื่อกดสั่งซื้อ ระบบตะกร้าจะส่งชื่อ ที่อยู่จัดส่ง และเบอร์โทรไปยังผู้ให้บริการขนส่ง พร้อมส่งข้อมูลบัตรหรือช่องทางชำระเงินไปยัง Payment Gateway แยกต่างหาก และสุดท้ายเมื่อพัสดุถูกจัดส่ง ข้อมูลสถานะการจัดส่งจะถูกส่งกลับมาแสดงในระบบติดตามพัสดุที่ลูกค้าเข้าดูได้เอง

จะเห็นว่าในเส้นทางเดียวนี้ ข้อมูลลูกค้าไหลผ่านอย่างน้อยสี่ระบบที่แยกจากกัน คือ เครื่องมือโฆษณา/pixel ระบบอีเมลการตลาด ระบบตะกร้าสินค้าของร้าน และผู้ให้บริการขนส่ง/ชำระเงิน แต่ละระบบมีเจ้าของและมาตรฐานความปลอดภัยของตัวเอง ทีม E-commerce จึงไม่สามารถ "ป้องกันข้อมูลลูกค้า" ด้วยมาตรการเดียวได้ ต้องแยกพิจารณาความเสี่ยงตามระบบที่ข้อมูลไหลผ่านจริง

จุดที่ข้อมูลการชำระเงินเสี่ยงหลุดมากที่สุด

ข้อมูลบัตรเครดิตหรือบัญชีธนาคารเป็นข้อมูลที่ร้านค้าออนไลน์ควรหลีกเลี่ยงการเก็บไว้ในระบบของตัวเองมากที่สุด เพราะการเก็บเลขบัตรเต็มรูปแบบต้องผ่านมาตรฐาน PCI-DSS ซึ่งมีค่าใช้จ่ายและภาระการตรวจสอบสูงเกินความจำเป็นสำหรับร้านค้าส่วนใหญ่ แนวทางที่ปลอดภัยกว่าคือใช้ Payment Gateway ที่ได้มาตรฐาน (เช่น Omise, 2C2P, GB Prompt Pay หรือผู้ให้บริการที่ร้านใช้อยู่) เป็นผู้เก็บข้อมูลบัตรจริง แล้วร้านเก็บเพียง token หรือหมายเลขอ้างอิงธุรกรรมไว้ในระบบของตัวเอง

จุดเสี่ยงที่พบบ่อยในทางปฏิบัติคือทีมพัฒนาเว็บไซต์เก็บ log คำขอ (request log) ของหน้าชำระเงินไว้เพื่อ debug โดยลืมกรองข้อมูลบัตรหรือ CVV ออกก่อน ทำให้ข้อมูลอ่อนไหวเหล่านี้หลุดไปอยู่ใน log ไฟล์ที่ไม่มีการเข้ารหัสหรือจำกัดสิทธิ์การเข้าถึง ควรตรวจสอบเป็นระยะว่าระบบ logging ของร้านกรองข้อมูลการชำระเงินออกก่อนบันทึกจริง

ข้อมูลพฤติกรรมที่ Retargeting และอีเมลการตลาดดึงไปใช้ต่อ

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

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

เปรียบเทียบความเสี่ยงของข้อมูลตามจุดสัมผัสในร้านค้าออนไลน์

ระบบและผู้ให้บริการที่เกี่ยวข้องกับข้อมูลลูกค้าร้านค้าออนไลน์

ร้านค้าออนไลน์ทั่วไปมักไม่ได้เก็บข้อมูลลูกค้าไว้ในระบบเดียว แต่กระจายอยู่ในแพลตฟอร์ม E-commerce หลัก (เช่น Shopify, WooCommerce) แอปเสริมด้านการตลาดและรีวิว ระบบตะกร้าสินค้า เครื่องมือ Retargeting และระบบจัดส่งของผู้ให้บริการขนส่ง การจัดทำรายการว่าระบบใดเก็บข้อมูลอะไรบ้าง และใครมีสิทธิ์เข้าถึงระบบไหน เป็นจุดเริ่มต้นที่จำเป็นก่อนวางมาตรการป้องกัน เพราะถ้าไม่รู้ว่าข้อมูลอยู่ที่ไหนบ้าง ก็ไม่สามารถป้องกันได้ครบถ้วน

ขั้นตอนจัดการข้อมูลตามเส้นทางลูกค้า

1. ไล่ทำแผนที่เส้นทางลูกค้า (customer journey map) พร้อมระบุว่าแต่ละจุดสัมผัสเก็บข้อมูลอะไร ส่งต่อไปยังระบบใด
2. ตรวจสอบว่าร้านเก็บข้อมูลบัตรหรือข้อมูลการชำระเงินไว้เองหรือไม่ หากเก็บ ให้ย้ายไปใช้ tokenization ผ่าน Payment Gateway แทน
3. ตรวจสอบ pixel และเครื่องมือ Retargeting ทุกตัวว่าทำงานหลังได้รับความยินยอมเท่านั้น ไม่ใช่ยิงทันทีที่หน้าโหลด
4. จำกัดสิทธิ์การเข้าถึงข้อมูลลูกค้าในแพลตฟอร์ม E-commerce ให้เฉพาะทีมที่ต้องใช้งานจริง โดยเฉพาะข้อมูลที่อยู่จัดส่งและประวัติการสั่งซื้อ
5. ตรวจสอบ log ของหน้าชำระเงินว่าไม่มีข้อมูลบัตรหรือ CVV หลุดเข้าไปในไฟล์ log
6. กำหนดระยะเวลาการเก็บรักษาข้อมูลตะกร้าที่ถูกทิ้ง (abandoned cart) และข้อมูลลูกค้าที่ไม่มีการสั่งซื้อซ้ำเป็นเวลานาน ไม่ให้เก็บไว้นานเกินจำเป็น

กรณีตัวอย่าง: เปิดแคมเปญลดราคาใหญ่ปลายปี

ช่วงแคมเปญลดราคาใหญ่ เช่น 11.11 หรือ 12.12 เป็นช่วงที่ร้านค้าออนไลน์เพิ่มปริมาณโฆษณาและติดตั้งเครื่องมือ Retargeting ใหม่อย่างเร่งด่วน ทีม Performance Marketing มักเพิ่ม pixel หรือแอปติดตามผลใหม่ในช่วงนี้เพื่อวัดผลแคมเปญให้แม่นยำขึ้น แต่ความเร่งรีบมักทำให้ข้ามขั้นตอนตรวจสอบว่า pixel ใหม่ผูกกับความยินยอมถูกต้องหรือไม่ หากพบปัญหาหลังแคมเปญเริ่มไปแล้ว การแก้ไขจะยากกว่าการตรวจสอบให้ครบก่อนเปิดแคมเปญ

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

การตรวจสอบและเก็บหลักฐานเมื่อเกิดข้อพิพาทการสั่งซื้อ

ร้านค้าออนไลน์มักต้องเผชิญข้อพิพาทที่เกี่ยวข้องกับข้อมูลส่วนบุคคลโดยตรง เช่น ลูกค้าปฏิเสธว่าไม่ได้เป็นผู้สั่งซื้อ (chargeback) หรือลูกค้าขอให้ลบข้อมูลบัญชีของตนเองหลังยกเลิกใช้งาน กรณีแรกทีมงานต้องมีหลักฐานว่าข้อมูลที่อยู่จัดส่งและช่องทางชำระเงินที่ใช้ในการสั่งซื้อนั้นมาจากคำสั่งซื้อจริง ซึ่งควรเก็บ log การทำธุรกรรมไว้กับ Payment Gateway ไม่ใช่ก็อปปี้ข้อมูลบัตรมาเก็บเองเพื่อความสะดวก ส่วนกรณีที่สองทีมงานต้องตรวจสอบว่าระบบใดบ้างที่ยังมีข้อมูลของลูกค้ารายนั้นค้างอยู่ เพราะข้อมูลอาจกระจายอยู่ทั้งในแพลตฟอร์ม E-commerce หลัก ระบบอีเมลการตลาด และเครื่องมือ Retargeting ที่เคยซิงก์ข้อมูลไปแล้ว การลบเฉพาะบัญชีหลักโดยไม่ตรวจสอบระบบรอบข้างจึงไม่เพียงพอ

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

ดูภาพรวมเพิ่มเติมได้ในหมวด Privacy Fundamentals และหัวข้อที่เกี่ยวข้องได้ที่ Data Governance ส่วนแนวทางของกลุ่มธุรกิจอื่นในชุดคู่มือเดียวกันดูได้ที่ คู่มือสำหรับ SME และ คู่มือสำหรับธุรกิจสุขภาพ

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

• ทำแผนที่เส้นทางลูกค้าพร้อมระบุว่าแต่ละจุดสัมผัสเก็บข้อมูลอะไร
• ย้ายการเก็บข้อมูลบัตร/การชำระเงินไปใช้ tokenization ผ่าน Payment Gateway แทนการเก็บเอง
• ตรวจสอบว่า pixel และเครื่องมือ Retargeting ทำงานหลังได้รับความยินยอมเท่านั้น
• จำกัดสิทธิ์การเข้าถึงข้อมูลที่อยู่จัดส่งและประวัติคำสั่งซื้อเฉพาะทีมที่จำเป็น
• ตรวจสอบ log หน้าชำระเงินว่าไม่มีข้อมูลบัตรหรือ CVV หลุดเข้าไปบันทึก
• กำหนดระยะเวลาเก็บรักษาข้อมูลตะกร้าที่ถูกทิ้งและบัญชีที่ไม่มีการใช้งานนาน

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

เก็บเลขบัตรเครดิตหรือ CVV ไว้ในฐานข้อมูลของร้านเองแทนที่จะให้ Payment Gateway เป็นผู้เก็บ

เปิด pixel หรือแอป Retargeting ใหม่ช่วงแคมเปญใหญ่โดยไม่ตรวจสอบว่าผูกกับความยินยอมถูกต้อง

ติดตั้งแอปรีวิวหรือแอปแชทใหม่โดยไม่ตรวจสอบขอบเขตข้อมูลที่แอปขอเข้าถึง

log คำขอของหน้าชำระเงินโดยไม่กรองข้อมูลบัตรหรือข้อมูลอ่อนไหวออกก่อนบันทึก

เก็บข้อมูลตะกร้าที่ถูกทิ้งไว้ไม่มีกำหนดระยะเวลา ทำให้สะสมข้อมูลเกินความจำเป็น

สรุป

ข้อมูลส่วนบุคคลบนเว็บไซต์ของร้านค้าออนไลน์และ E-commerce ไม่ได้อยู่นิ่งในที่เดียว แต่ไหลผ่านหลายระบบตลอดเส้นทางลูกค้า ตั้งแต่ pixel โฆษณา ระบบตะกร้าสินค้า ไปจนถึง Payment Gateway และผู้ให้บริการขนส่ง การมองข้อมูลตามจุดสัมผัสในเส้นทางจริงแทนที่จะมองเป็นก้อนเดียว ช่วยให้เจ้าของร้านและทีม Performance Marketing จัดลำดับความสำคัญของมาตรการป้องกันได้ตรงจุดกว่า โดยเฉพาะจุดเสี่ยงสูงอย่างข้อมูลการชำระเงินและการตั้งค่า pixel ที่ต้องตรวจสอบก่อนเปิดแคมเปญทุกครั้ง

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

• สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC)