trusty — Website Trust Platform
Business, Industry & SEO

วิธีวางระบบ PDPA สำหรับ Agency สำหรับร้านค้าออนไลน์และ E-commerceแบบเป็นขั้นตอน

เอเจนซีที่ดูแล Pixel โฆษณาและอีเมลให้ร้านค้าออนไลน์ อยู่ในสถานะผู้ประมวลผลข้อมูลลูกค้าของร้าน คู่มือนี้วางระบบ DPA เปิดเผย Sub-processor และจัดการ Audience เมื่อเลิกจ้างแบบเป็นขั้นตอน

📅 เผยแพร่ 26 กรกฎาคม 2569อัปเดตล่าสุด 26 กรกฎาคม 2569✍️ เขียนโดย trusty Editorial Team⏱ อ่าน 9 นาที
Two young adults packing clothing items in an office for their online store startup.
ภาพโดย Kampus Production จาก Pexels

💬 สรุปสั้น ๆ

เอเจนซีที่ดูแลโฆษณา อีเมลมาร์เก็ตติ้ง หรือ CRM ให้ร้านค้าออนไลน์ อยู่ในสถานะผู้ประมวลผลข้อมูล (Data Processor) ให้ร้านค้าซึ่งเป็นผู้ควบคุมข้อมูลลูกค้าปลายทาง ระบบที่ต้องวางคือสัญญาประมวลผลข้อมูล (DPA) ที่ระบุขอบเขตการเข้าถึงฐานลูกค้าและ Custom Audience ชัดเจน รายชื่อ Sub-processor อย่างแพลตฟอร์มโฆษณาและเครื่องมืออีเมลที่เปิดเผยต่อร้านค้า ขั้นตอนลบหรือคืน Audience และฐานข้อมูลเมื่อเลิกจ้างพร้อมหลักฐาน และเส้นแบ่งความรับผิดเมื่อร้านค้าสั่งให้ทำสิ่งที่มีความเสี่ยง การมีระบบนี้ช่วยลดความเสี่ยงเมื่อเกิดเหตุ แต่ไม่มีขั้นตอนใดที่ทำให้ธุรกิจปลอดภัยจากทุกกรณีโดยอัตโนมัติ

สารบัญ

เอเจนซีที่ดูแลโฆษณา อีเมลมาร์เก็ตติ้ง หรือ CRM ให้ร้านค้าออนไลน์ อยู่ในสถานะผู้ประมวลผลข้อมูล (Data Processor) ให้ร้านค้าซึ่งเป็นผู้ควบคุมข้อมูลลูกค้าปลายทาง ระบบที่ต้องวางคือสัญญาประมวลผลข้อมูล (DPA) ที่ระบุขอบเขตการเข้าถึงฐานลูกค้าและ Custom Audience ชัดเจน รายชื่อ Sub-processor อย่างแพลตฟอร์มโฆษณาและเครื่องมืออีเมลที่เปิดเผยต่อร้านค้า ขั้นตอนลบหรือคืน Audience และฐานข้อมูลเมื่อเลิกจ้างพร้อมหลักฐาน และเส้นแบ่งความรับผิดเมื่อร้านค้าสั่งให้ทำสิ่งที่มีความเสี่ยง การมีระบบนี้ช่วยลดความเสี่ยงเมื่อเกิดเหตุ แต่ไม่มีขั้นตอนใดที่ทำให้ธุรกิจปลอดภัยจากทุกกรณีโดยอัตโนมัติ

ทีม Media Buying ของเอเจนซีที่ดูแลโฆษณาให้ร้านค้าออนไลน์หลายเจ้าพร้อมกัน มักถามคำถามเดียวกันในกลุ่มแชทภายในว่า ถ้าเราอัปโหลดเบอร์โทรและอีเมลลูกค้าของร้านค้าเข้าไปสร้าง Custom Audience ใน Ads Manager แบบนี้ ใครต้องรับผิดชอบถ้าข้อมูลนั้นรั่วไหลหรือถูกใช้ผิดวัตถุประสงค์ คำตอบสั้น ๆ คือความรับผิดชอบไม่ได้ตกอยู่ที่ฝ่ายเดียว เพราะร้านค้าคือเจ้าของข้อมูลลูกค้าปลายทางที่ตัดสินใจว่าจะเก็บและใช้ข้อมูลอะไร ส่วนเอเจนซีที่นำข้อมูลนั้นไปประมวลผลต่อในระบบโฆษณาหรืออีเมล คือผู้ทำตามคำสั่งของร้านค้าอีกทอดหนึ่ง เมื่อความสัมพันธ์เป็นแบบนี้ สิ่งที่เอเจนซีต้องวางระบบจึงต่างจากสิ่งที่ร้านค้าต้องทำเองในหลายจุด และหลายเอเจนซีที่รับงานด้าน Performance Marketing ให้ร้านค้าออนไลน์ยังไม่เคยเขียนเรื่องนี้เป็นลายลักษณ์อักษรเลยแม้แต่ครั้งเดียว

ทำไมเอเจนซีที่ดูแลร้านค้าออนไลน์จึงเป็นผู้ประมวลผลข้อมูล ไม่ใช่เจ้าของข้อมูลลูกค้า

งานที่เอเจนซีรับทำให้ร้านค้าออนไลน์ ไม่ว่าจะเป็นการยิงโฆษณา Retargeting การส่งอีเมลเตือนตะกร้าสินค้าที่ถูกทิ้งไว้ หรือการเชื่อมระบบ CRM เพื่อวิเคราะห์พฤติกรรมลูกค้าประจำ ล้วนต้องใช้ข้อมูลส่วนบุคคลของลูกค้าปลายทางของร้านค้า เช่น ชื่อ เบอร์โทร อีเมล ประวัติการสั่งซื้อ หรือพฤติกรรมเข้าเว็บผ่าน Pixel ในความสัมพันธ์นี้ ร้านค้าซึ่งเป็นเจ้าของธุรกิจคือผู้ควบคุมข้อมูล (Data Controller) เพราะเป็นผู้กำหนดว่าจะเก็บข้อมูลอะไร นานแค่ไหน และนำไปใช้เพื่อวัตถุประสงค์ใด ส่วนเอเจนซีที่นำข้อมูลนั้นไปประมวลผลตามคำสั่งของร้านค้า เช่น อัปโหลดเข้าแพลตฟอร์มโฆษณาหรือส่งอีเมลผ่านระบบภายนอก คือผู้ประมวลผลข้อมูล (Data Processor) ความแตกต่างนี้มีผลจริงในทางปฏิบัติ เพราะผู้ควบคุมข้อมูลต้องรับผิดชอบเรื่องฐานทางกฎหมายในการเก็บข้อมูลและการตอบสนองคำขอใช้สิทธิของลูกค้าปลายทาง ส่วนผู้ประมวลผลอย่างเอเจนซีมีหน้าที่หลักคือทำตามขอบเขตที่ตกลงไว้เท่านั้น ห้ามนำฐานข้อมูลลูกค้าของร้านหนึ่งไปใช้กับร้านอื่น และต้องมีมาตรการป้องกันข้อมูลที่เหมาะสมกับปริมาณและความอ่อนไหวของข้อมูลที่ตนถืออยู่

ขั้นตอนที่ 1: ทำสัญญาประมวลผลข้อมูล (DPA) ที่ครอบคลุมฐานลูกค้าและระบบโฆษณา

ก่อนเริ่มรับฐานข้อมูลลูกค้าหรือเชื่อมต่อ Pixel ให้ร้านค้าใหม่ทุกครั้ง ควรมีเอกสารสัญญาประมวลผลข้อมูลที่ระบุอย่างน้อยสี่เรื่อง เรื่องแรกคือขอบเขตข้อมูลที่เอเจนซีจะเข้าถึงได้ เช่น เฉพาะอีเมลและเบอร์โทรสำหรับสร้าง Audience หรือรวมถึงประวัติการสั่งซื้อทั้งหมดในระบบ CRM ด้วย เรื่องที่สองคือวัตถุประสงค์ที่จำกัดเฉพาะแคมเปญของร้านนั้น ห้ามนำฐานลูกค้าของร้านหนึ่งไปสร้าง Lookalike Audience ให้ลูกค้าอีกรายที่ขายสินค้าคล้ายกัน แม้จะดูเหมือนช่วยประหยัดเวลาก็ตาม เรื่องที่สามคือมาตรการความปลอดภัยขั้นต่ำ เช่น การจำกัดสิทธิ์เข้าถึงบัญชี Ads Manager เฉพาะทีมที่ดูแลแคมเปญนั้นจริง และการแจ้งร้านค้าทันทีหากพบความผิดปกติ เช่น บัญชีโฆษณาถูกเข้าถึงโดยไม่ได้รับอนุญาต เรื่องที่สี่คือระยะเวลาการเข้าถึงที่ผูกกับสัญญาว่าจ้าง ไม่ใช่ปล่อยให้ทีมเก่าคงสิทธิ์เข้าถึงไว้หลังพ้นสัญญาไปแล้ว เอกสารนี้ทำเป็นภาคผนวกสั้น ๆ แนบท้ายใบเสนอราคาก็เพียงพอ แต่ต้องมีการยืนยันเป็นลายลักษณ์อักษรจากทั้งสองฝ่ายเสมอ

ขั้นตอนที่ 2: เปิดเผย Sub-processor ที่เกี่ยวข้องกับแพลตฟอร์มโฆษณา อีเมล และ CRM

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

ขั้นตอนที่ 3: วางระบบลบหรือคืน Audience และฐานข้อมูลลูกค้าเมื่อเลิกจ้าง

จุดที่หลายเอเจนซีลืมวางระบบมากที่สุดคือช่วงเลิกจ้าง โดยเฉพาะเมื่อร้านค้าเปลี่ยนไปใช้เอเจนซีเจ้าอื่นหรือทำการตลาดเองภายใน สิ่งที่ต้องจัดการเมื่อความสัมพันธ์จบลงมีมากกว่าการปิดบัญชี Ads Manager เพราะ Custom Audience ที่เคยสร้างไว้ในแพลตฟอร์มโฆษณา ฐานข้อมูลลูกค้าที่ Export มาวิเคราะห์ หรือรายชื่ออีเมลที่นำเข้าระบบส่งข่าวสาร ล้วนเป็นสำเนาข้อมูลที่ต้องถูกลบหรือส่งคืนให้ร้านค้าอย่างชัดเจน แนวทางที่ทำได้จริงคือกำหนดไว้ในสัญญาตั้งแต่ต้นว่าเมื่อเลิกจ้าง เอเจนซีต้องลบ Custom Audience ในแพลตฟอร์มโฆษณาที่ตนสร้างไว้ ลบไฟล์ฐานข้อมูลที่ดาวน์โหลดมาเก็บไว้ในเครื่องหรือระบบคลาวด์ของทีม และปิดสิทธิ์เข้าถึงระบบอีเมลหรือ CRM ของร้านค้าภายในระยะเวลาที่ตกลงกัน เช่น สิบห้าวันหลังสัญญาสิ้นสุด พร้อมส่งภาพหน้าจอหรือรายงานยืนยันการลบให้ร้านค้าเก็บไว้เป็นหลักฐาน ขั้นตอนนี้สำคัญเพราะ Custom Audience ที่ค้างอยู่ในบัญชีโฆษณาเก่าเป็นสิ่งที่ร้านค้ามักไม่รู้ตัวว่ายังมีอยู่ จนกว่าจะมีคนตรวจสอบจริงจัง

พร้อมตรวจสอบความน่าเชื่อถือของเว็บไซต์คุณหรือยัง?

ทดลองใช้งาน trusty ฟรี ไม่ต้องใช้บัตรเครดิต เริ่มสแกนได้ทันที

ทดลองใช้งานระบบฟรี

ขั้นตอนที่ 4: กำหนดเส้นแบ่งความรับผิดเมื่อร้านค้าสั่งให้ทำสิ่งที่มีความเสี่ยง

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

ขั้นตอนที่ 5: ทำเช็คลิสต์ภายในทีมสำหรับลูกค้า E-commerce ทุกราย

เมื่อวางสี่ขั้นตอนข้างต้นเรียบร้อยแล้ว สิ่งที่ทำให้ระบบนี้ใช้งานได้จริงในระยะยาวคือแปลงมันเป็นเช็คลิสต์สั้น ๆ ที่ทีม Media Buying ทุกคนเปิดดูก่อนรับลูกค้าใหม่ทุกครั้ง เพราะเอเจนซีขนาดกลางมักมีปัญหาว่าคนที่เข้าใจเรื่องนี้ดีที่สุดคือหัวหน้าทีมเพียงคนเดียว พอมอบหมายให้ทีมจูเนียร์ดูแลบัญชีโฆษณาต่อ ความรู้เรื่องขอบเขตข้อมูลและ Sub-processor ก็ไม่ได้ถูกส่งต่อไปด้วย โดยเฉพาะขั้นตอนลบ Audience หลังเลิกจ้าง ซึ่งมักถูกลืมเพราะทีมมัวยุ่งกับลูกค้าใหม่ที่เข้ามาจนไม่มีใครย้อนกลับไปปิดงานเก่าให้เรียบร้อย สำหรับทีมที่ต้องการตรวจสอบระบบที่มีอยู่แล้วว่าครบถ้วนหรือไม่ อ่านต่อได้ที่ แนวทางตรวจสอบ PDPA สำหรับเอเจนซีที่ดูแลร้านค้าออนไลน์ และ เช็กลิสต์ก่อนเปิดใช้งานระบบ เมื่อทำเช็คลิสต์เสร็จแล้ว ควรกำหนดวันทบทวนซ้ำทุกหกเดือนหรือทุกครั้งที่มีการเปลี่ยนเครื่องมือโฆษณาหลัก เพราะแพลตฟอร์มโฆษณาแต่ละเจ้ามักปรับนโยบายการใช้ข้อมูลผู้ใช้อยู่เรื่อย ๆ สิ่งที่เคยทำถูกต้องเมื่อปีก่อนอาจไม่สอดคล้องกับเงื่อนไขใหม่ของแพลตฟอร์มแล้วก็ได้ ทีมที่รับผิดชอบควรมีปฏิทินเตือนสำหรับตรวจสอบเรื่องนี้แยกจากปฏิทินแคมเปญโฆษณาปกติ เพื่อไม่ให้ถูกกลืนไปกับงานประจำวันจนลืมตรวจสอบไปหลายเดือน

ข้อผิดพลาดที่พบบ่อยของเอเจนซีที่ดูแลร้านค้าออนไลน์

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

สรุประบบ PDPA สำหรับเอเจนซีที่ดูแลร้านค้าออนไลน์

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

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

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

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

เอเจนซีที่ดูแลโฆษณาให้ร้านค้าออนไลน์ ต้องทำสัญญาประมวลผลข้อมูลกับทุกร้านหรือไม่

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

ถ้าเปลี่ยนแพลตฟอร์มโฆษณาหรือระบบอีเมลระหว่างแคมเปญ ต้องแจ้งร้านค้าใหม่หรือไม่

ควรแจ้ง เพราะเครื่องมือใหม่ถือเป็น Sub-processor ที่เข้าถึงข้อมูลลูกค้าปลายทางผ่านทางเอเจนซีอีกทอดหนึ่ง การแจ้งล่วงหน้าช่วยให้ร้านค้ามีโอกาสตรวจสอบหรือทักท้วงก่อนเริ่มใช้งานจริง

เมื่อเลิกจ้างแล้ว ต้องลบ Custom Audience ในแพลตฟอร์มโฆษณาด้วยหรือไม่

ควรลบ เพราะ Audience ที่สร้างจากฐานลูกค้าของร้านนั้นถือเป็นข้อมูลของร้านค้า ไม่ใช่ทรัพยากรของเอเจนซี การปล่อยให้ค้างอยู่หลังเลิกจ้างเป็นความเสี่ยงที่ร้านค้ามักไม่รู้ตัว

ถ้าร้านค้าขอให้อัปโหลดฐานลูกค้าที่ไม่เคยยินยอมรับข่าวสารการตลาด เอเจนซีต้องรับผิดชอบเองหรือไม่

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

เอเจนซีขนาดเล็กที่ดูแลร้านค้าออนไลน์ไม่กี่รายจำเป็นต้องวางระบบนี้เหมือนเอเจนซีใหญ่หรือไม่

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

อ่านต่อในหัวข้อเดียวกัน

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

พร้อมตรวจสอบความน่าเชื่อถือของเว็บไซต์คุณหรือยัง?

ทดลองใช้งาน trusty ฟรี ไม่ต้องใช้บัตรเครดิต เริ่มสแกนได้ทันที