ส่งยอดขายกลับ Google/Meta/TikTok ปลอดภัยแค่ไหน เรื่อง Encryption ที่แอดมินมักไม่เคยถาม

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

คำถามนี้สำคัญกว่าที่คิด เพราะข้อมูลที่ส่งไปมักผ่านมือคนกลางหลายต่อ ตั้งแต่ระบบหลังบ้านของร้าน ไปจนถึง server ตัวกลาง (อย่าง GTM server-side) ก่อนจะถึงปลายทาง ถ้าจุดใดจุดหนึ่งระหว่างทางไม่ได้เข้ารหัสให้ดี ข้อมูลก็เสี่ยงถูกดักอ่านได้ในทางทฤษฎี

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

Encryption ตอน 'ส่ง' ต่างจากตอน 'เก็บ' อย่างไร

หลายคนเข้าใจว่า encryption มีแบบเดียว แต่จริง ๆ มีสองจังหวะที่ต้องดูแยกกัน อย่างแรกคือตอนข้อมูล 'พัก' อยู่ในฐานข้อมูล เรียกว่า encryption at rest ส่วนอย่างที่สองคือตอนข้อมูล 'กำลังเดินทาง' จากที่หนึ่งไปอีกที่หนึ่ง เรียกว่า encryption in transit

เวลาส่งยอดขายกลับไปหา ad platform สิ่งที่ต้องสนใจคือช่วง in transit เพราะข้อมูลกำลังวิ่งผ่านอินเทอร์เน็ตจริง ๆ ถ้าช่วงนี้ไม่เข้ารหัส คนที่ดักฟังสัญญาณระหว่างทางในทางทฤษฎีก็อาจอ่านข้อมูลได้ตรง ๆ

เช็กง่าย ๆ ที่แอดมินทำเองได้: HTTPS

สัญญาณพื้นฐานที่สุดที่บอกว่าการเชื่อมต่อเข้ารหัสอยู่หรือไม่ คือดูว่า URL ของระบบที่ใช้ขึ้นต้นด้วย https ไม่ใช่ http ธรรมดา ตัว s ท้าย http บอกว่ามีการเข้ารหัสระหว่างเบราว์เซอร์หรือระบบกับปลายทาง เกือบทุกแพลตฟอร์มใหญ่อย่าง Google, Meta, TikTok บังคับใช้ https อยู่แล้วในฝั่งของเขา

สิ่งที่ร้านต้องเช็กเพิ่มคือ ถ้าใช้ระบบตัวกลางอย่างGTM server-side containerหรือระบบของ agency ที่ช่วยส่งข้อมูลแทน ต้องถามให้ชัดว่าตัวกลางนั้นใช้ https ตลอดทางหรือไม่ ไม่ใช่แค่ปลายทางสุดท้าย เพราะถ้าจุดกลางจุดใดจุดหนึ่งหลุดไปเป็น http ก็ถือว่าช่องโหว่ยังอยู่

อีกชั้นที่ช่วยได้: เข้ารหัสข้อมูลก่อนส่ง ไม่ใช่แค่ระหว่างส่ง

นอกจาก https แล้ว แพลตฟอร์มอย่าง Meta และ Google ยังกำหนดให้ข้อมูลส่วนตัวอย่างอีเมลหรือเบอร์โทร ต้องผ่านการแฮช (hashing) ก่อนส่งเข้า Conversion API เสมอ ซึ่งเป็นคนละเรื่องกับ encryption in transit แต่ทำงานเสริมกัน คือต่อให้มีคนดักข้อมูลระหว่างทางได้จริง สิ่งที่เห็นก็เป็นรหัสที่อ่านไม่ออก ไม่ใช่เบอร์โทรตรง ๆ

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

คำถามที่ควรถามผู้ให้บริการหรือทีมพัฒนาระบบ

• ระบบที่ใช้ส่งข้อมูล conversion ใช้ https ตลอดทางหรือไม่ รวมถึงจุดตัวกลางทุกจุด
• ข้อมูลอ่อนไหวอย่างอีเมล เบอร์โทร มีการแฮชก่อนส่งออกจากระบบร้านหรือไม่
• ถ้าใช้ server-side tracking มี log เก็บข้อมูลดิบไว้นานแค่ไหน และใครเข้าถึง log นั้นได้บ้าง
• มีการตรวจสอบใบรับรอง SSL/TLS ของระบบเป็นระยะหรือไม่ ไม่ใช่ตั้งครั้งเดียวแล้วปล่อยไว้

ร้านเล็กก็ควรสนใจเรื่องนี้ ไม่ใช่แค่บริษัทใหญ่

หลายคนคิดว่าเรื่อง encryption เป็นเรื่องของบริษัทเทคโนโลยีขนาดใหญ่ แต่ความจริงร้านค้าเล็กที่ส่งข้อมูลลูกค้าจำนวนมากผ่าน server-to-server ทุกวันก็มีความเสี่ยงไม่ต่างกัน เพราะข้อมูลที่ส่งคือของลูกค้าจริง ไม่ใช่ข้อมูลทดสอบ การถามคำถามพวกนี้กับผู้ให้บริการที่ใช้อยู่ ไม่ใช่เรื่องเกินตัวเลย แม้จะเป็นร้านที่มีทีมแค่ไม่กี่คน

สรุป

การตั้งค่า Conversion API ให้ยอดขึ้นบน dashboard เป็นแค่ครึ่งเดียวของงาน อีกครึ่งที่มักถูกมองข้ามคือความปลอดภัยของข้อมูลระหว่างทางที่ส่งออกไป ซึ่งเป็นข้อมูลลูกค้าจริงทุกวัน

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

• แยกให้ออกระหว่าง encryption ตอนเก็บข้อมูล กับตอนส่งข้อมูล
• เช็ก https ตลอดทาง ไม่ใช่แค่ปลายทางสุดท้าย
• การแฮชข้อมูลอ่อนไหวก่อนส่งเป็นการป้องกันอีกชั้นที่ควรมีคู่กัน

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