เก็บ LINE User ID ไว้เต็มฐานข้อมูลแล้วผสมเข้า Ads โดยไม่รู้ตัว แก้อย่างไร
สรุปสั้น ๆ
PDPA เก็บ LINE user id ต้องพิจารณาว่า User ID อาจใช้ระบุตัวตนได้ในทางอ้อมเมื่อผูกกับข้อมูลอื่น จึงต้องมีฐานทางกฎหมายหรือความยินยอมรองรับ จำกัดการเข้าถึง กำหนด Retention และไม่ส่งค่าดิบไปยังแพลตฟอร์มโฆษณาที่ไม่รองรับ
ทีมพัฒนาระบบทีมหนึ่งเก็บ LINE User ID ของทุกคนที่เคยทักเข้ามาไว้ในฐานข้อมูลกลาง เพราะคิดว่าเป็นแค่รหัสตัวอักษรสุ่ม ๆ ไม่มีความหมายอะไร จนกระทั่งมีคนถามว่าถ้าเอา User ID นี้ไปผูกกับเบอร์โทรและประวัติการซื้อในตารางเดียวกัน มันจะกลายเป็นข้อมูลที่ระบุตัวตนได้หรือไม่ คำตอบคือได้ และนั่นคือจุดเริ่มต้นที่ทีมต้องกลับมาทบทวนวิธีเก็บข้อมูลใหม่ทั้งหมด
ความเข้าใจผิดที่พบบ่อยคือคิดว่า LINE User ID ไม่ใช่ข้อมูลส่วนบุคคลเพราะไม่ใช่ชื่อหรือเบอร์โทรตรง ๆ แต่ในทางปฏิบัติ ถ้า User ID นี้ถูกผูกกับข้อมูลอื่นจนสามารถย้อนกลับไประบุตัวบุคคลได้ ก็ควรถูกพิจารณาในกรอบเดียวกับข้อมูลส่วนบุคคลอื่น ยิ่งถ้านำไปผสมกับข้อมูลที่ส่งต่อให้แพลตฟอร์มโฆษณาภายนอก ความเสี่ยงยิ่งสูงขึ้นไปอีก
บทความนี้จะพาไปดูว่าควรเก็บ LINE User ID แบบไหนให้ปลอดภัยขึ้น ต้องจำกัดการเข้าถึงตรงไหนบ้าง และมีข้อควรระวังอะไรเมื่อต้องส่งข้อมูลที่เกี่ยวข้องไปยังระบบวัดผลโฆษณา (เนื้อหานี้เป็นกรอบวิเคราะห์ทั่วไป ไม่ใช่คำแนะนำทางกฎหมายที่รับรองแทนผู้เชี่ยวชาญได้)
ทำไม LINE User ID ถึงอาจถือเป็นข้อมูลที่ระบุตัวตนได้ทั้งที่ดูเหมือนรหัสสุ่ม
LINE User ID เป็นรหัสเฉพาะที่ผูกกับบัญชี LINE ของผู้ใช้แต่ละคนแบบไม่ซ้ำกัน แม้ตัวรหัสเองจะดูเหมือนตัวอักษรสุ่มที่อ่านไม่ออกความหมาย แต่จุดสำคัญคือมันคงที่และไม่เปลี่ยนแปลงสำหรับผู้ใช้คนเดิม ทำให้สามารถใช้เป็นตัวเชื่อมย้อนกลับไปหาประวัติการสนทนา ประวัติการซื้อ หรือข้อมูลอื่นของคนคนนั้นได้ตลอดเวลา
เมื่อ User ID ถูกผูกกับข้อมูลอื่นในระบบ เช่น ชื่อ เบอร์โทร หรือประวัติการสั่งซื้อที่เชื่อมกับ First Party Data ของธุรกิจ ชุดข้อมูลทั้งหมดนี้ก็มีศักยภาพที่จะระบุตัวบุคคลได้ ต่อให้ตัว User ID เพียงอย่างเดียวจะดูไม่มีความหมาย จึงควรพิจารณาความเสี่ยงจากมุมของ 'ชุดข้อมูลที่ผูกกันอยู่' มากกว่าดูแค่ตัว Identifier เดี่ยว ๆ
จัดเก็บ LINE User ID ภายในระบบให้ปลอดภัยขึ้นอย่างไร
หลักการพื้นฐานคือจำกัดจำนวนคนและระบบที่เข้าถึง User ID ได้ให้น้อยที่สุดเท่าที่จำเป็น ไม่ใช่เปิดให้ทุกทีมในบริษัทดึงข้อมูลนี้ได้อย่างอิสระ ทีมที่ดูแลระบบควรกำหนด Role และ Permission แยกตามหน้าที่ เช่น แอดมินที่ตอบแชทเห็นได้เฉพาะ Lead ที่ตัวเองดูแล ไม่ใช่เห็นฐานข้อมูลทั้งหมด
อีกแนวทางที่ช่วยลดความเสี่ยงคือกำหนด Retention หรือระยะเวลาที่จะเก็บข้อมูลไว้ ไม่ใช่เก็บถาวรโดยไม่มีกำหนด ถ้าลูกค้ารายหนึ่งไม่มีการติดต่อกลับมานานเกินระยะเวลาที่กำหนด ควรมีกระบวนการทบทวนว่าจะยังเก็บข้อมูลไว้ต่อหรือควรลบทิ้งตามนโยบายที่ประกาศไว้
ส่งข้อมูลที่เกี่ยวข้องกับ LINE User ID ไปยังแพลตฟอร์มโฆษณา ต้องระวังอะไรบ้าง
ก่อนส่งข้อมูลใด ๆ ที่เกี่ยวข้องกับ User ID ไปยังระบบภายนอก ควรตรวจสอบให้ครบตามตารางนี้ก่อนทุกครั้ง:
| สิ่งที่ต้องตรวจ | เหตุผล |
|---|---|
| ฟิลด์นั้นจำเป็นต่อการวัดผลจริงหรือไม่ | ยิ่งส่งฟิลด์น้อย ความเสี่ยงยิ่งลดลง |
| แพลตฟอร์มปลายทางรองรับการรับค่านี้หรือไม่ | การส่งค่าที่ไม่ตรง Format อาจถูกปฏิเสธหรือใช้งานไม่ได้ |
| มีการ Hash ตามมาตรฐานที่แพลตฟอร์มกำหนดหรือไม่ | ลดความเสี่ยงด้านเทคนิค แต่ไม่ใช่ทางออกทางกฎหมายทั้งหมด |
| มีฐานทางกฎหมายหรือความยินยอมรองรับหรือไม่ | เป็นเงื่อนไขที่ต้องมีก่อนส่งข้อมูลใด ๆ ออกนอกระบบ |
แจ้งวัตถุประสงค์และขอความยินยอมให้ผู้ใช้เข้าใจได้จริง
การมี Privacy Notice ไม่ได้แปลว่าเขียนข้อความยาว ๆ แปะไว้ที่ไหนสักที่แล้วจบ แต่ควรอธิบายให้ผู้ใช้เข้าใจได้จริงว่าข้อมูลของเขาจะถูกเก็บไปทำอะไร ใครเข้าถึงได้ และมีสิทธิ์อะไรบ้างเกี่ยวกับข้อมูลของตัวเอง ยิ่งถ้าธุรกิจนำข้อมูลไปใช้เพื่อการตลาดหรือส่งต่อให้แพลตฟอร์มโฆษณา ยิ่งต้องอธิบายให้ชัดเจนกว่าการเก็บข้อมูลเพื่อให้บริการพื้นฐานเพียงอย่างเดียว
ธุรกิจควรทบทวนว่าขั้นตอนตอนนี้เพียงพอหรือไม่ ไม่ใช่แค่มีเอกสารไว้เฉย ๆ แต่ต้องดูว่าผู้ใช้จริงมีโอกาสได้อ่านและเข้าใจก่อนที่จะเริ่มทักเข้ามา หรือมีช่องทางให้สอบถามเพิ่มเติมได้ถ้าสงสัย
เมื่อลูกค้าขอให้ลบหรือขอดูข้อมูลของตัวเอง ต้องทำอย่างไร
ธุรกิจควรมีกระบวนการรองรับคำขอจากเจ้าของข้อมูล เช่น การขอดูว่าเก็บข้อมูลอะไรไว้บ้าง หรือขอให้ลบข้อมูลออกจากระบบ กระบวนการนี้ต้องครอบคลุมทุกที่ที่ User ID และข้อมูลที่เกี่ยวข้องถูกเก็บไว้ ไม่ใช่แค่ลบในระบบหลักแล้วลืมว่ายังมีสำเนาอยู่ในระบบสำรองหรือระบบวิเคราะห์ข้อมูลอื่น
บางกรณีมีข้อจำกัดทางเทคนิคที่ทำให้ลบข้อมูลบางส่วนไม่ได้ทันที เช่น ข้อมูลที่ถูกส่งไปยังแพลตฟอร์มโฆษณาแล้วก่อนหน้านี้ ซึ่งอาจอยู่นอกเหนือการควบคุมโดยตรงของธุรกิจ ในกรณีแบบนี้ควรตรวจสอบนโยบายของแพลตฟอร์มปลายทางและแจ้งข้อจำกัดนี้ให้ผู้ใช้ทราบตามความเหมาะสม
แนวทางที่ทีมพัฒนาและทีมการตลาดควรทำร่วมกัน
ทีมพัฒนาระบบควรออกแบบฐานข้อมูลให้แยกชั้นการเข้าถึงตั้งแต่ต้น ไม่ใช่ให้ทุกตารางเชื่อมกันจนใครก็ดึงข้อมูลอะไรก็ได้ ส่วนทีมการตลาดควรเข้าใจว่าข้อมูลที่ขอให้ทีมพัฒนาส่งออกไปยังแพลตฟอร์มโฆษณานั้น มีความเสี่ยงด้านความเป็นส่วนตัวแนบมาด้วยเสมอ ไม่ใช่แค่ขอข้อมูลเพื่อ Optimize แคมเปญอย่างเดียว
การประชุมร่วมกันระหว่างสองทีมนี้เป็นระยะ ช่วยให้ทั้งสองฝ่ายเข้าใจข้อจำกัดของกันและกัน ทีมพัฒนาจะรู้ว่าการตลาดต้องการข้อมูลแบบไหนไปใช้งานจริง ส่วนทีมการตลาดจะรู้ว่าข้อมูลไหนส่งออกไปได้และข้อมูลไหนต้องเก็บไว้ภายในเท่านั้น
เมื่อใช้ระบบภายนอกช่วยจัดเก็บ User ID ใครเป็นผู้ควบคุมข้อมูล ใครเป็นผู้ประมวลผลแทน
เมื่อธุรกิจใช้ระบบกลางอย่าง CRM หรือเครื่องมือเชื่อมข้อมูลจาก LINE OA มาช่วยจัดเก็บและประมวลผล User ID ควรทำความเข้าใจบทบาทที่ต่างกันระหว่างผู้ที่เป็นเจ้าของและตัดสินใจเกี่ยวกับข้อมูล กับผู้ที่เพียงประมวลผลข้อมูลตามคำสั่งของธุรกิจเท่านั้น การเข้าใจบทบาทนี้ช่วยให้รู้ว่าใครต้องรับผิดชอบส่วนไหนเมื่อเกิดปัญหาเกี่ยวกับข้อมูล
ในทางปฏิบัติ ธุรกิจควรตรวจสอบว่าเครื่องมือหรือระบบที่นำมาใช้มีนโยบายจัดการข้อมูลอย่างไร เก็บข้อมูลไว้ที่ไหน และมีมาตรการความปลอดภัยระดับใด ไม่ใช่เลือกใช้เพียงเพราะสะดวกหรือราคาถูก โดยไม่เคยตรวจสอบรายละเอียดเรื่องการจัดการข้อมูลเลย เพราะสุดท้ายแล้วธุรกิจในฐานะเจ้าของข้อมูลยังต้องรับผิดชอบต่อผู้ใช้อยู่ดี แม้จะมอบหมายงานประมวลผลบางส่วนให้ระบบภายนอกทำแทนก็ตาม
ข้อตกลงระหว่างธุรกิจกับผู้ให้บริการระบบภายนอกจึงควรระบุให้ชัดเจนว่าใครทำหน้าที่อะไร เช่น ผู้ให้บริการจะเก็บข้อมูลไว้ในรูปแบบไหน มีสิทธิ์นำข้อมูลไปใช้เพื่อวัตถุประสงค์อื่นนอกเหนือจากที่ธุรกิจร้องขอหรือไม่ และจะลบข้อมูลอย่างไรเมื่อยกเลิกการใช้บริการ คำถามเหล่านี้ควรได้รับคำตอบชัดเจนก่อนเริ่มใช้งานระบบใด ๆ ไม่ใช่ค่อยไปถามทีหลังเมื่อเกิดปัญหาขึ้นแล้ว
ระบบกลางอย่าง linli ช่วยตรงไหน และอะไรที่ธุรกิจยังต้องรับผิดชอบเอง
ระบบที่ทำหน้าที่เป็นชั้นกลางเชื่อมข้อมูลจาก LINE OA ไปสู่ระบบวัดผล อย่าง linli ช่วยจัดระเบียบว่าข้อมูลไหนควรถูกส่งต่อไปยังแพลตฟอร์มโฆษณาตาม Integration ที่เปิดใช้งาน สอดคล้องกับหลักการที่กล่าวถึงใน PDPA Conversion Tracking LINE แต่ไม่ได้ทำให้ธุรกิจผ่าน PDPA โดยอัตโนมัติ ธุรกิจยังคงเป็นเจ้าของข้อมูลลูกค้าและต้องรับผิดชอบให้การเก็บและใช้ข้อมูลเป็นไปตามกฎหมายอยู่ดี
สิ่งที่ธุรกิจยังต้องทำเองคือการตัดสินใจว่าจะขอความยินยอมแบบไหน จะเก็บข้อมูลไว้นานแค่ไหน และจะตอบคำขอของเจ้าของข้อมูลอย่างไรเมื่อมีการร้องขอเข้ามา ระบบเป็นเพียงเครื่องมือที่ช่วยให้ Journey จากโฆษณาไปถึงยอดขายเชื่อมกันได้ ไม่ใช่ผู้รับผิดชอบด้านกฎหมายแทนธุรกิจ
สรุป
LINE User ID อาจดูเหมือนรหัสสุ่มที่ไม่มีความหมาย แต่เมื่อผูกกับข้อมูลอื่นในระบบ มันมีศักยภาพที่จะระบุตัวบุคคลได้ ธุรกิจจึงควรพิจารณาความเสี่ยงจากมุมของชุดข้อมูลทั้งหมดที่เชื่อมโยงกัน ไม่ใช่ดูแค่ตัว Identifier เดี่ยว ๆ
สิ่งที่ควรทำต่อจากนี้คือสำรวจว่าตอนนี้เก็บ User ID ไว้ที่ไหนบ้าง ใครเข้าถึงได้ และมีการส่งข้อมูลที่เกี่ยวข้องไปยังระบบภายนอกหรือไม่ แล้วจำกัดการเข้าถึงและทบทวน Retention ให้เหมาะสมก่อนขยายการใช้งานเพิ่มเติม
- LINE User ID อาจถือเป็นข้อมูลที่ระบุตัวตนได้ทางอ้อม เมื่อผูกกับข้อมูลอื่นในระบบ
- จำกัดการเข้าถึงตาม Role และกำหนด Retention ไม่เก็บข้อมูลไว้ถาวรโดยไม่มีกำหนด
- ก่อนส่งข้อมูลไปแพลตฟอร์มโฆษณา ต้องตรวจว่าจำเป็นจริง รองรับ Format และมีฐานทางกฎหมายรองรับ
- เมื่อใช้ระบบภายนอกช่วยจัดเก็บ ควรตกลงบทบาทระหว่างผู้ควบคุมและผู้ประมวลผลข้อมูลให้ชัดเจนก่อนเริ่มใช้งาน
- linli ช่วยจัดระเบียบข้อมูลที่ส่งต่อ แต่ไม่ได้ทำให้ธุรกิจผ่าน PDPA โดยอัตโนมัติ
คำถามที่พบบ่อย
LINE User ID ต่างจาก LINE Display Name หรือรูปโปรไฟล์อย่างไร
LINE Display Name และรูปโปรไฟล์เป็นข้อมูลที่ผู้ใช้ตั้งเองและอาจเปลี่ยนได้ตลอดเวลา ส่วน User ID เป็นรหัสคงที่ที่ไม่เปลี่ยนแปลง ทำให้ User ID มีความเสี่ยงด้านการใช้ติดตามระยะยาวมากกว่า แม้จะดูเหมือนไม่มีความหมายในตัวเองก็ตาม
ถ้าลบ User ID ออกจากฐานข้อมูลหลักแล้ว ถือว่าปลอดภัยหรือยัง
ยังไม่แน่นอน เพราะอาจมีสำเนาอยู่ในระบบสำรอง Log ไฟล์ หรือระบบวิเคราะห์อื่นที่แยกจากฐานข้อมูลหลัก ควรตรวจสอบทุกจุดที่ข้อมูลอาจถูกคัดลอกไปเก็บไว้ ไม่ใช่ดูแค่ตารางหลักที่ใช้งานประจำ
ทีมเล็กที่ไม่มีฝ่ายกฎหมายควรเริ่มจากตรงไหนก่อน
ควรเริ่มจากสำรวจว่าตอนนี้เก็บ User ID ไว้ที่ไหนบ้างและใครเข้าถึงได้ แล้วจำกัดการเข้าถึงให้แคบลงก่อนเป็นอันดับแรก ส่วนเรื่องเอกสารและฐานทางกฎหมายที่ซับซ้อนกว่านั้น ควรปรึกษาผู้เชี่ยวชาญด้านกฎหมายเพื่อความเหมาะสมกับบริบทของธุรกิจตัวเอง
ส่งเฉพาะ User ID ที่ Hash แล้วไปแพลตฟอร์มโฆษณา ปลอดภัยพอหรือยัง
การ Hash ช่วยลดความเสี่ยงด้านเทคนิคได้ระดับหนึ่ง แต่ไม่ได้ทำให้ข้อมูลพ้นจากสถานะข้อมูลส่วนบุคคลตามกฎหมายโดยอัตโนมัติ ธุรกิจยังต้องมีฐานทางกฎหมายหรือความยินยอมรองรับวัตถุประสงค์การส่งข้อมูลนั้นอยู่ดี
พนักงานที่ลาออกไปแล้วยังเข้าถึง User ID เดิมได้อยู่ไหม
ไม่ควรเข้าถึงได้อีก ธุรกิจควรมีกระบวนการเพิกถอนสิทธิ์การเข้าถึงทันทีที่พนักงานพ้นสภาพ รวมถึงทบทวน Access Log เป็นระยะเพื่อตรวจสอบว่าไม่มีบัญชีเก่าที่ยังเข้าถึงข้อมูลอยู่
ต้องแจ้งลูกค้าทุกครั้งไหมถ้ามีการเปลี่ยนแปลงวิธีใช้ข้อมูล
ควรพิจารณาแจ้งเมื่อมีการเปลี่ยนแปลงวัตถุประสงค์การใช้ข้อมูลอย่างมีนัยสำคัญ เพื่อให้ผู้ใช้รับทราบและตัดสินใจได้ว่ายังยินยอมให้ใช้ข้อมูลในลักษณะใหม่นั้นหรือไม่ การไม่แจ้งเลยอาจทำให้ความยินยอมเดิมที่เคยได้รับไม่ครอบคลุมวัตถุประสงค์ใหม่ และอาจต้องขอความยินยอมใหม่อีกรอบก่อนเริ่มใช้งานจริง
อ่านต่อแบบเจาะลึก
วัด Conversion LINE ทุกแบรนด์ รวมศูนย์ที่เดียว
องค์กรที่มีหลายแบรนด์ หลายสาขา หลาย LINE OA — linli รวม Tracking และส่ง Conversion กลับทุกแพลตฟอร์ม พร้อม Custom Limit เริ่มฟรี 14 วัน
ติดต่อทีม Salesบทความที่เกี่ยวข้อง
ใครก็ยิง POST มาที่ Endpoint รับ Webhook ได้ ถ้าไม่ตรวจลายเซ็นก่อน Conversion ปลอมก็เข้า CAPI ได้เหมือนของจริง
ออเดอร์เดียวต้องส่งเข้า Meta, Google และ TikTok พร้อมกัน แต่ event_id เดียวใช้ซ้ำสามที่ไม่ได้ ออกแบบ Fan-out Pipeline ให้ไม่ชนกันเอง
