ส่งข้อมูลกลับแพลตฟอร์มด้วย Hashed Data ให้แม่นและถูก PDPA

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

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

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

Hashing คืออะไร อธิบายแบบเห็นภาพ

Hashing คือการเอาข้อมูลอย่างอีเมลหรือเบอร์โทร มาแปลงเป็นสายอักขระยาว ๆ ที่ดูเหมือนตัวอักษรกับตัวเลขมั่ว ๆ ด้วยสูตรทางคณิตศาสตร์ จุดสำคัญคือมัน "ย้อนกลับไม่ได้" คือจากรหัสที่ได้ คุณแปลงกลับไปเป็นอีเมลเดิมไม่ได้ แต่ถ้าเอาอีเมลเดิมมาแปลงอีกครั้งด้วยสูตรเดิม จะได้รหัสเดิมเป๊ะเสมอ

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

เปรียบเทียบง่าย ๆ เหมือนการปั๊มลายนิ้วมือแทนการส่งบัตรประชาชนตัวจริง ลายนิ้วมือระบุได้ว่าเป็นคนเดิม แต่จากลายนิ้วมือคุณสร้างบัตรประชาชนกลับมาไม่ได้ นี่คือเหตุผลที่แพลตฟอร์มบังคับให้ hash ก่อนส่ง เพราะมันลดความเสี่ยงหากข้อมูลรั่วระหว่างทาง

ทำไม Hash ผิดนิดเดียวก็จับคู่ไม่ได้เลย

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

ตัวอย่างที่เจอจริงคือเรื่องช่องว่างและตัวพิมพ์ ถ้าฝั่งหนึ่งมีอีเมลเป็น somchai@mail.com แต่อีกฝั่งมีเป็น Somchai@mail.com พร้อมช่องว่างข้างหน้า รหัสที่ hash ออกมาจะคนละอันทันที ทั้งที่เป็นคนเดียวกัน ปัญหานี้ทำให้อัตราการจับคู่ต่ำโดยที่ระบบไม่ฟ้อง error อะไรเลย

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

ขั้นตอนทำข้อมูลให้พร้อมก่อน Hash

การเตรียมข้อมูลให้เป็นมาตรฐานก่อน hash ไม่ยาก แต่ต้องทำให้ครบและทำเหมือนกันทุกครั้ง นี่คือลำดับที่ผมใช้:

1. ตัดช่องว่างหน้า-หลังออกให้หมด เพราะช่องว่างที่มองไม่เห็นคือสาเหตุยอดฮิตที่ทำให้จับคู่พลาด
2. แปลงตัวอักษรเป็นพิมพ์เล็กทั้งหมด เพื่อให้ตัวพิมพ์ใหญ่-เล็กไม่ทำให้รหัสเพี้ยน
3. จัดรูปแบบเบอร์โทรให้เป็นมาตรฐานเดียว เช่นตัดเครื่องหมายและเว้นวรรคออก และเติมรหัสประเทศให้ตรงตามที่แพลตฟอร์มกำหนด
4. ตรวจข้อมูลที่ผิดรูปทิ้ง เช่นอีเมลที่ไม่มีเครื่องหมาย at หรือเบอร์ที่หลักไม่ครบ อย่า hash ขยะส่งไปเพราะมันได้แต่รหัสที่จับคู่ไม่ติด
5. แปลงด้วยสูตร hash ตามที่แพลตฟอร์มกำหนด (แต่ละที่ระบุมาตรฐานของตัวเอง) แล้วส่งเฉพาะค่าที่ hash แล้วเท่านั้น ห้ามส่งค่าดิบพ่วงไปด้วย

ด้านกฎหมาย: PDPA ที่ต้องระวังก่อนส่งข้อมูล

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

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

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

สรุปความเสี่ยงและวิธีลดความเสี่ยง

เพื่อให้เห็นภาพว่าอะไรพลาดได้บ้างและกันยังไง ตารางนี้รวมความเสี่ยงที่เจอบ่อยทั้งด้านเทคนิคและด้านกฎหมาย:

สรุป

การส่งข้อมูลกลับแพลตฟอร์มด้วย Hashed Data เป็นเครื่องมือที่มีพลังในยุคที่จับคู่ลูกค้ายากขึ้น แต่มันมีสองด้านที่ต้องทำให้ถูกพร้อมกัน ด้านเทคนิคคือต้องทำข้อมูลให้สะอาดเป็นมาตรฐานก่อน hash ไม่งั้นจับคู่ไม่ติดแบบเงียบ ๆ และด้านกฎหมายคือต้องมีฐานตาม PDPA และแจ้งลูกค้าให้ชัด เพราะข้อมูลส่วนบุคคลไม่ใช่ของที่หยิบไปใช้ได้ตามใจ

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

• Hashing = แปลงข้อมูลเป็นรหัสที่ย้อนกลับไม่ได้ ให้จับคู่ได้โดยไม่เห็นข้อมูลดิบ
• ต้องทำข้อมูลสะอาดเป็นมาตรฐานก่อน hash ไม่งั้นจับคู่ไม่ติดโดยไม่ฟ้อง error
• hash ไม่ได้ทำให้พ้น PDPA — ต้องมีฐานทางกฎหมาย แจ้งลูกค้า และปรึกษาผู้เชี่ยวชาญ

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