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

Joel Margolis นักวิจัยด้านความปลอดภัยกล่าวกับ Wired ว่า “คนในทีมการตลาดอยากสร้างเว็บไซต์ เขาไม่ใช่วิศวกร และน่าจะมีพื้นฐานหรือความรู้ด้านความปลอดภัยน้อยมากหรือไม่มีเลย” รายงาน Wired เดียวกันระบุว่าบริษัทความปลอดภัย RedAccess พบแอปที่สร้างด้วยไวบ์โค้ดดิ้งมากกว่า 5,000 แอป ซึ่งแทบไม่มีการรักษาความปลอดภัยหรือการยืนยันตัวตน และประมาณ 40 เปอร์เซ็นต์เปิดเผยข้อมูลอ่อนไหว Wired ไม่สามารถยืนยันได้ว่าข้อมูลส่วนบุคคลหรือข้อมูลบริษัทที่ตรวจดูเป็นข้อมูลจริงหรือไม่

แอปที่สร้างด้วย AI สำหรับทีมการตลาดมีปัญหานี้ในรูปแบบเฉพาะ เครื่องมือที่คุ้มค่าต่อการสร้าง เช่น เครื่องมือสร้างกลุ่มย่อย แดชบอร์ดแคมเปญ เครื่องมือวิเคราะห์ A/B และเครื่องมือซิงก์กลุ่มเป้าหมาย ล้วนเชื่อมต่อกับรายชื่อผู้สมัครรับข่าวสาร และมักเชื่อมกับบัญชีโฆษณาด้วย

สรุปประเด็นสำคัญ

• ให้คีย์ API ของแพลตฟอร์มอีเมลและโทเคนบัญชีโฆษณาแต่ละรายการมีสิทธิ์แคบที่สุดเท่าที่เครื่องมือใช้ และเก็บไว้ในโค้ดฝั่งเซิร์ฟเวอร์ Marketing API ของ Mailchimp ไม่มีคีย์แบบจำกัดสิทธิ์กว่านี้ ดังนั้นงาน Mailchimp แบบอ่านอย่างเดียวควรใช้ไฟล์ส่งออกที่จำกัดเฉพาะข้อมูลจำเป็นแทนคีย์
• แพลตฟอร์มอีเมลยังคงเป็นแหล่งข้อมูลอ้างอิงหลักของสถานะการสมัคร เครื่องมือจะไม่สมัครให้ผู้ที่ปฏิเสธกลับเข้ามาอีก ต้องส่งต่อคำขอยกเลิกไปยังแพลตฟอร์ม และใส่ลิงก์ยกเลิกที่ใช้งานได้ในอีเมลการตลาดทุกฉบับที่ส่งเอง
• ข้อมูลอัปโหลดกลุ่มเป้าหมายแบบกำหนดเองที่แฮชแล้วก็ยังเป็นข้อมูลส่วนบุคคล ต้องตัดสินใจก่อนส่งว่าจะให้ข้อมูลใดแก่แพลตฟอร์มโฆษณาและบริการ AI และทำให้การยกเลิกทุกรายการส่งผลถึงกลุ่มเป้าหมายโฆษณา
• GDPR กำกับการเก็บและใช้รายชื่อ เช่น การแจ้งเหตุละเมิดและสิทธิคัดค้านการตลาดโดยไม่มีเงื่อนไข ส่วน ePrivacy/PECR, CAN-SPAM หรือ CASL กำกับการส่งอีเมล แม้ส่งจากเครื่องมือภายในก็ตาม

ความผิดพลาดในการติดตั้งใช้งานที่ทำให้ข้อมูลผู้สมัครรั่วไหลหรือผิดเงื่อนไขความยินยอม

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

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

เปลี่ยนคีย์แพลตฟอร์มอีเมลแบบเต็มสิทธิ์เป็นคีย์ที่จำกัดที่สุด

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

แต่ละแถวอ้างอิงเอกสารของแพลตฟอร์มเอง ได้แก่ หน้าช่วยเหลือคีย์ API ของ Mailchimp, สิทธิ์คีย์ API ของ SendGrid, คู่มือยืนยันตัวตนของ Klaviyo และ เอกสารคีย์ API ของ Mailgun ส่วนสิทธิ์ Listmonk อยู่ในหัวข้อ Listmonk ด้านล่าง

เครื่องมือได้รับคีย์ที่แคบที่สุดตามงาน หรือไม่ได้รับคีย์เลย สำหรับ Mailchimp งานอ่านอย่างเดียว เช่น รายงานหรือจำนวนกลุ่มย่อย ควรใช้รายงานของแพลตฟอร์มหรือให้เจ้าของบัญชีส่งออกแบบจำกัดเฉพาะฟิลด์ที่งานต้องใช้ ข้อแลกเปลี่ยนคือใช้เวลาคนและข้อมูลใหม่ได้เพียง ณ เวลาส่งออก งานเปลี่ยนแปลงและส่งให้ไอทีทำหรือคงไว้ใน Mailchimp ส่วนแพลตฟอร์มอื่น เช่น ActiveCampaign หรือ Brevo ให้หาตัวเลือกคีย์จำกัดสิทธิ์ก่อน

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

ค้นหาคีย์ API โทเคนเข้าถึง รหัสผ่าน หรือความลับทั้งหมดในโครงการนี้สำหรับแพลตฟอร์มอีเมลของเรา เช่น Mailchimp, Klaviyo, SendGrid, Mailgun, Listmonk หรืออื่น ๆ และแพลตฟอร์มโฆษณา เช่น Meta, Google Ads, LinkedIn หรืออื่น ๆ ใช้ตัวสแกนความลับในเครื่องหรือวิธีที่ไอทีอนุมัติเพื่อตรวจโค้ด ไฟล์สภาพแวดล้อม และประวัติคลังโค้ด ห้ามส่งค่าความลับดิบ เนื้อหาไฟล์สภาพแวดล้อม หรือประวัติที่มีข้อมูลรับรองไปยังบริการ AI ภายนอก ให้ AI เฉพาะผลที่ปกปิดข้อมูลแล้ว พร้อมตำแหน่งไฟล์และชนิดข้อมูลรับรองที่พบ แต่ละรายการให้บอก:

- ไฟล์และบรรทัด

- ค่าเขียนตรงในโค้ดหรืออ่านจากตัวแปรสภาพแวดล้อม

- โค้ดที่ใช้ค่านั้นทำงานบนเซิร์ฟเวอร์หรือเบราว์เซอร์

แสดงเพียงสี่อักขระแรกของทุกค่า ห้ามพิมพ์คีย์หรือโทเคนเต็ม

ทำเครื่องหมายข้อมูลรับรองที่ส่งอีเมล เปลี่ยนผู้สมัคร หรือจัดการบัญชีโฆษณาได้เป็นความสำคัญสูงสุด

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

หมายเหตุ: การลบคีย์ที่วางในแชตหรือโค้ดไม่ได้ทำให้การเปิดเผยถูกยกเลิก ต้องเพิกถอนคีย์โดยปิดใช้งานในการตั้งค่าแพลตฟอร์มให้หยุดทำงาน แล้วสร้างใหม่

ตรวจสอบ: เปิดเครื่องมือ กด F12 เลือกแท็บ Network แล้วใช้งานแบบที่ทีมจะใช้ พร้อมอ่านโดเมนของแต่ละคำขอ คำขอเบราว์เซอร์ที่เรียก API ส่วนตัวของแพลตฟอร์มอีเมลโดยตรงเป็นสัญญาณเตือน แต่ปลายทางอย่างเดียวไม่พิสูจน์ว่าความลับเปิดเผย ตรวจส่วนหัวคำขอและโค้ดเพื่อหาข้อมูลรับรองส่วนตัว โดยไม่คัดลอกค่าไปยังแชต AI คำขอ SDK สาธารณะฝั่งไคลเอนต์ต่างออกไป เพราะอาจใช้ตัวระบุสาธารณะอย่างถูกต้องแทนคีย์ลับ ใน Klaviyo คำขอไปยัง a.klaviyo.com/client/ ใช้คีย์สาธารณะและควรอยู่ในเบราว์เซอร์ แต่คำขอเบราว์เซอร์ไปยัง a.klaviyo.com/api/ ต้องตรวจสอบ เพราะปกติเอนด์พอยต์นี้ต้องยืนยันด้วยคีย์ส่วนตัว ยืนยันว่ามีการส่งข้อมูลรับรองส่วนตัวจริงหรือไม่

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

ให้โทเคนบัญชีโฆษณาเฉพาะสิทธิ์ที่เครื่องมือใช้

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

สิ่งที่โทเคนนี้ไม่ส่งกลับคือรายชื่อผู้สมัครที่อัปโหลดไปยังกลุ่มเป้าหมายแบบกำหนดเอง คู่มือ Custom Audiences ของ Meta ใช้ค่าแฮช SHA-256 ทั้งเพิ่มและลบคน โดยเป็นการแปลงแต่ละที่อยู่แบบทางเดียวให้แพลตฟอร์มเทียบกับบันทึกของตน และไม่มีเอนด์พอยต์ที่ระบุในเอกสารใดส่งคืนรายชื่อที่อ่านได้จากกลุ่มเป้าหมายเดิม

เอกสารอ้างอิงสิทธิ์ของ Meta อธิบายแต่ละสิทธิ์และให้ผู้พัฒนาเลือกเฉพาะที่แอปต้องใช้ แต่ละเครื่องมือมีโทเคนของตัวเองจากผู้ใช้ระบบ ซึ่ง Meta ใช้เรียกบัญชีใน Business Manager ที่ซอฟต์แวร์ใช้ โดยให้เข้าถึงเฉพาะบัญชีโฆษณาที่เครื่องมือนั้นทำงานด้วย อย่าใส่โทเคนล็อกอินส่วนตัวของผู้สร้างในเครื่องมือ และเก็บโทเคนผู้ใช้ระบบบนเซิร์ฟเวอร์เหมือนคีย์อีเมล ต้องทำบัญชีรายการแบบเดียวกันกับสิทธิ์ Google Ads หรือ LinkedIn ด้วย

แสดงทุกรายการที่เครื่องมือนี้เรียก Marketing API ของ Meta, Google Ads หรือแพลตฟอร์มโฆษณาอื่น รวมการเรียกผ่านไลบรารีช่วยเหลือหรือ SDK แต่ละรายการให้ระบุ:

- ไฟล์และบรรทัด

- เอนด์พอยต์หรือเมธอด SDK

- ป้ายกำกับ REPORT อ่านตัวชี้วัดหรือการใช้จ่าย, MANAGE สร้างหรือเปลี่ยนแคมเปญ โฆษณา งบ หรือกลุ่มเป้าหมาย หรือ LEADS อ่านการส่งแบบฟอร์มลูกค้าเป้าหมาย

- สิทธิ์บนแพลตฟอร์มที่ป้ายกำกับนั้นต้องใช้

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

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

ปิดที่อยู่สาธารณะและแสดงแถวผู้สมัครเฉพาะผู้ดูแลรายชื่อ

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

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

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

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

จากนั้นเพิ่มสองบทบาท โดยดึงจากบัญชีที่ลงชื่อเข้าใช้และตรวจบนเซิร์ฟเวอร์สำหรับทุกหน้า การส่งออก และเส้นทาง API:

- ผู้ดูแลรายชื่อ: เห็นแถวผู้สมัครและสั่งส่งออกได้

- นักการตลาด: เห็นเฉพาะตัวเลขระดับแคมเปญ จำนวนกลุ่มย่อย และผล A/B ไม่มีแถวรายบุคคลและส่งออกไม่ได้

ปฏิเสธอย่างอื่นด้วยคำตอบ “ปฏิเสธการเข้าถึง” (403) รายงานว่าการตรวจใดป้องกันแต่ละหน้าและเส้นทาง

ข้อมูลที่เก็บเข้ารหัสบนดิสก์หรือไม่เป็นเรื่องที่ต้องถามไอที เครื่องมือ AI ยืนยันจากการอ่านโค้ดไม่ได้

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

ให้แพลตฟอร์มอีเมลดูแลการยกเลิกและบันทึกความยินยอม

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

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

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

- เปลี่ยนสถานะสมัครของผู้สมัครเดิม

- เขียนทับบันทึกผู้สมัครเดิม

- รวมผู้ติดต่อที่ยกเลิกหรือถูกระงับการส่ง

สำหรับทุกเส้นทางที่ส่งอีเมลหรือส่งออกรายชื่อเพื่อส่ง ให้บอกว่าอ่านสถานะสมัครจากที่ไหน ระหว่างแพลตฟอร์มอีเมล ณ ขณะนั้นกับสำเนาของเครื่องมือ

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

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

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

ส่งผ่านแพลตฟอร์มอีเมล หรือสร้างเส้นทางยกเลิกก่อน

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

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

ผู้ส่งปริมาณสูงอาจใช้เพียงลิงก์ส่วนท้ายไม่พอ Gmail กำหนดให้ผู้ส่งที่ส่งอย่างน้อย 5,000 ข้อความต่อวันไปยังบัญชี Gmail ส่วนบุคคล รองรับยกเลิกคลิกเดียวตาม RFC 8058 สำหรับข้อความการตลาดและข้อความที่สมัครรับ ต้องเพิ่มส่วนหัวอีเมล List-Unsubscribe และ List-Unsubscribe-Post พร้อมลิงก์ยกเลิกที่มองเห็น เอนด์พอยต์คลิกเดียวต้องประมวลผล POST การเปิด URL ด้วย GET อย่างเดียวต้องไม่ยกเลิกใคร ขอให้ไอทีตรวจข้อกำหนดก่อนส่งระดับนั้น

เพิ่มลิงก์ยกเลิกในทุกข้อความการตลาดที่เครื่องมือนี้ส่ง พร้อมเอนด์พอยต์ยกเลิกเบื้องหลัง
หากเครื่องมืออยู่ภายใต้ข้อกำหนดผู้ส่งจำนวนมากของ Gmail ให้เพิ่มส่วนหัวคลิกเดียวตาม RFC 8058 ที่ครอบคลุมด้วยลายเซ็น DKIM ที่ถูกต้อง และเอนด์พอยต์แบบ POST ห้ามยกเลิกเพียงเพราะมีการเปิด URL ระบุความไม่แน่ใจให้ไอทีตรวจ
เมื่อเอนด์พอยต์ยกเลิกได้รับคำขอที่ถูกต้องจากการคลิกลิงก์ ส่งแบบฟอร์ม หรือเรียก API:

- เพิ่มที่อยู่เข้ารายชื่อระงับการส่งที่เก็บแยกจากตารางผู้สมัครทันที

- บันทึกวันเวลาและช่องทางที่คำขอเข้ามา

- หากแพลตฟอร์มอีเมลของเราเก็บรายชื่อ ให้แจ้งแพลตฟอร์มยกเลิกที่อยู่นั้นด้วย

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

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

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

ตัดสินใจว่าข้อมูลใดไปแพลตฟอร์มโฆษณาและ AI ก่อนส่งออก

โค้ดสองเส้นทางส่งข้อมูลผู้สมัครออกตามค่าเริ่มต้น ได้แก่ การซิงก์ที่อัปโหลดกลุ่มย่อยไป Meta หรือ Google custom audience และการเรียกที่ส่งฟิลด์ผู้สมัครให้ AI API เพื่อเขียนหัวเรื่องหรือให้คะแนนลูกค้าเป้าหมาย หรือให้สคริปต์วิเคราะห์และเว็บฮุก

Meta และ Google จับคู่กลุ่มเป้าหมายลูกค้าด้วยตัวระบุผู้ติดต่อที่แฮช SHA-256 ได้ Data Manager API ของ Google กำหนดให้ปรับรูปแบบอีเมลและโทรศัพท์ให้เป็นมาตรฐานและแฮชก่อนส่ง ส่วนการอัปโหลดผ่านหน้าจอ Google Ads บางแบบแฮชระหว่างอัปโหลดได้ แฮชคือวิธีจับคู่ที่อยู่กับโปรไฟล์ ไม่ได้ทำให้บุคคลไม่ระบุตัวตน ดูคำถามที่พบบ่อย

สำหรับการเชื่อมต่อ Google Customer Match ใหม่ ตรวจว่า API อัปโหลดใดรองรับก่อนสร้างซิงก์ ตั้งแต่ 1 เมษายน 2026 Google จำกัดวิธีอัปโหลด Customer Match เก่าสำหรับผู้เริ่มใช้ใหม่ และให้การเชื่อมต่อเหล่านั้นใช้ Data Manager API

ข้อกำหนดกลุ่มเป้าหมายจากรายชื่อลูกค้าของ Meta ให้ผู้โฆษณารับรองว่ามีสิทธิ อนุญาต และฐานกฎหมายที่จำเป็นต่อการแชร์ข้อมูล นโยบาย Customer Match ของ Google กำหนดให้เปิดเผยการแชร์ในนโยบายความเป็นส่วนตัวและขอความยินยอมเมื่อกฎหมายกำหนด

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

ดังนั้นเส้นทางอัปโหลดควรรับเฉพาะกลุ่มย่อยที่บริษัทอนุมัติใช้จับคู่โฆษณา บริษัทต้องกำหนดฐานกฎหมายที่เหมาะสมโดยรับคำแนะนำจากผู้รับผิดชอบความเป็นส่วนตัวหรือเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) หากแต่งตั้งไว้ ผู้ยกเลิกและถูกระงับต้องไม่อยู่ในการอัปโหลดใด และการยกเลิกต้องสั่งลบด้วยค่าแฮชจากทุกกลุ่มเป้าหมาย หัวข้อ GDPR ด้านล่างอธิบายเหตุผล

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

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

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

สำหรับทุกเส้นทางในเครื่องมือนี้ที่อัปโหลดผู้ติดต่อไป Meta, Google Ads หรือแพลตฟอร์มโฆษณาอื่น:

- แฮชอีเมลและโทรศัพท์ด้วย SHA-256 บนเซิร์ฟเวอร์ก่อนอัปโหลด โดยทำตามกฎปรับรูปแบบมาตรฐานของแต่ละแพลตฟอร์ม

- อัปโหลดเฉพาะผู้ติดต่อใน [กลุ่มย่อยที่บริษัทอนุมัติสำหรับจับคู่โฆษณา]

- ตัดผู้ยกเลิกและถูกระงับออก ณ เวลาอัปโหลด

- เมื่อผู้ติดต่อยกเลิก ให้ส่งคำขอลบค่าแฮชไปยังทุกกลุ่มเป้าหมายที่เคยอัปโหลด

- บันทึกทุกการอัปโหลดและลบ พร้อมวันเวลา กลุ่มเป้าหมาย จำนวนผู้ติดต่อ และผู้ใช้หรืองานที่สั่งทำ

รายงานสิ่งที่เปลี่ยนและทำเครื่องหมายสิ่งที่ไม่แน่ใจ

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

สิ่งที่เครื่องมือทำกับรายชื่อเป็นตัวกำหนดที่รัน

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

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

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

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

ฝั่งเซิร์ฟเวอร์เป็นส่วนที่ให้ไอทีช่วย โดยระบุเจ้าของรับผิดชอบเซิร์ฟเวอร์และคีย์หนึ่งคน เครื่องมือรันบน VPS คือเซิร์ฟเวอร์เช่าที่ทีมควบคุมเต็มที่ ภายใต้เครื่องมือติดตั้ง เช่น Coolify หรือ Dokploy ที่รันแอปจากโค้ดและเก็บตัวแปรสภาพแวดล้อมรวมคีย์แพลตฟอร์ม

ฝ่าย IT ควรจำกัดแอปให้เข้าถึงผ่านเครือข่ายส่วนตัวที่ได้รับอนุมัติหรือเกตเวย์ที่มีการยืนยันตัวตน และบล็อกการเข้าถึงสาธารณะโดยตรง การลงชื่อเข้าใช้บริษัทแบบ single sign-on ด้วยบัญชีบริษัทใช้ Authentik หรือ Keycloak และรีเวิร์สพร็อกซี เช่น Caddy หรือ Nginx Proxy Manager เพิ่ม HTTPS ในส่วนที่เครื่องมือเปิดสู่เว็บ

ย้ายระบบส่งอีเมลไป Listmonk

อีกทางแทนจำกัดคีย์แพลตฟอร์มปัจจุบันคือย้ายรายชื่อและการส่งไปตัวจัดการรายชื่อที่โฮสต์เอง เพื่อไม่ต้องมีคีย์แพลตฟอร์มเชิงพาณิชย์ Listmonk ตั้งแต่ v4.0.0 ให้แต่ละเครื่องมือมีผู้ใช้ API ของตัวเอง พร้อมบทบาทรายชื่อจำกัดเฉพาะที่เครื่องมือนั้นแตะ

เครื่องมืออ่านอย่างเดียวได้สิทธิ์ดูรายชื่อของตนโดยไม่มีสิทธิ์ส่ง ส่วน campaigns:send และ tx:send สำหรับข้อความธุรกรรมให้เฉพาะเครื่องมือส่ง ห้ามใส่สามสิทธิ์อันตรายเป็นพิเศษในบทบาทเครื่องมือที่ต้องจำกัด ได้แก่ lists:get_all และ lists:manage_all ซึ่งข้ามบทบาทรายรายชื่อ และ subscribers:sql_query ซึ่งเอกสารบทบาทและสิทธิ์ของ Listmonk เตือนว่าทำให้ “คิวรีรายชื่อและผู้สมัครทั้งหมดตรงจากฐานข้อมูลโดยข้ามสิทธิ์รายชื่อและผู้สมัครรายตัว” ตรวจสิทธิ์กว้าง เช่น subscribers:get_all, campaigns:get_all และ campaigns:manage_all ก่อนเรียกเครื่องมือว่าจำกัดตามรายชื่อ ให้ผู้ใช้ API แต่ละคนเฉพาะสิทธิ์จำเป็น Listmonk ออกแบบเพื่อแคมเปญ ไม่ใช่อัตโนมัติหลายขั้น ดูเมื่อใด Listmonk ไม่ใช่เครื่องมือที่เหมาะ ส่วน Mautic ทำระบบอัตโนมัตินั้นบนเซิร์ฟเวอร์แบบเดียวกันได้

ข้อแลกเปลี่ยนคืองานต่อเนื่อง ทีมรับผิดชอบการยืนยันโดเมนส่งด้วย SPF, DKIM และ DMARC รวม SMTP relay เพื่อส่งเมล แพตช์ สำรองข้อมูล และการส่งถึงปลายทาง หากรายชื่อเล็ก ไม่มีคนดูแลเซิร์ฟเวอร์ หรือชื่อเสียงการส่งและระบบอัตโนมัติของแพลตฟอร์มเดิมช่วยงานที่ทีมพึ่งพา การอยู่บนแพลตฟอร์มพร้อมคีย์จำกัดเหมาะกว่า

สถานที่มีแฟรงก์เฟิร์ตและอัมสเตอร์ดัมใน EU ลอนดอนในสหราชอาณาจักร และหลายเมืองสหรัฐฯ ที่ที่เลือกกำหนดตำแหน่งเครื่องมือและสำเนารายชื่อ และรวมรายชื่อจริงเมื่อใช้ Listmonk สถานที่เป็นข้อมูลประกอบการคุยกับ DPO ไม่ใช่สิ่งแทนการคุย และไม่ทำให้เครื่องมือเป็นไปตามกฎด้วยตัวมันเอง

ความยินยอมและกฎต่อต้านสแปมสำหรับอีเมลการตลาด

GDPR สำหรับรายชื่อผู้สมัคร

GDPR ไม่ได้กำหนดว่าการประมวลผลเพื่อการตลาดทางตรงต้องใช้ความยินยอมเป็นฐานเสมอ บทนำข้อ 47 ระบุว่าอาจถือว่าการประมวลผลนั้น “ทำเพื่อประโยชน์โดยชอบด้วยกฎหมาย” หากใช้ความยินยอมแทน มาตรา 7 กำหนดให้บริษัท “สามารถแสดงหลักฐาน” ว่าแต่ละคนยินยอม และถอนความยินยอมได้ง่ายพอกับให้ นี่คือหน้าที่ของแหล่งที่มาและวันเวลาความยินยอมในแพลตฟอร์มอีเมล

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

รายชื่อรั่วหรือถูกเปลี่ยนผิดอาจเป็นเหตุละเมิดข้อมูลส่วนบุคคล มาตรา 33 กำหนดให้แจ้งหน่วยงานกำกับ คือผู้กำกับคุ้มครองข้อมูลระดับประเทศ โดยไม่ชักช้าเกินควร และหากทำได้ภายใน 72 ชั่วโมงหลังทราบ เว้นแต่เหตุนั้นไม่น่าจะก่อความเสี่ยงต่อบุคคล ในสหราชอาณาจักร กฎหมายเทียบเท่าคือ UK GDPR ซึ่ง ICO บังคับใช้

กฎหมายการส่ง: ePrivacy และ PECR, CAN-SPAM และ CASL

กฎ ePrivacy ของ EU และ PECR ของสหราชอาณาจักรกำหนดความยินยอมก่อนส่งอีเมลการตลาดถึงบุคคล โดยมีข้อยกเว้น “soft opt-in” ที่แคบสำหรับลูกค้าเดิม สหราชอาณาจักรยังมี soft opt-in แยกสำหรับการกุศลภายใต้เงื่อนไขเฉพาะ บทความนี้เน้นการตลาดเชิงพาณิชย์ CASL ของแคนาดาต้องมีความยินยอมชัดแจ้งหรือโดยนัย CAN-SPAM ของสหรัฐฯ ไม่กำหนดความยินยอมให้ส่ง แต่กำหนดกลไกปฏิเสธที่ใช้งานและทำตามภายใน 10 วันทำการ พร้อมข้อมูลผู้ส่งถูกต้องและที่อยู่ไปรษณีย์ในทุกข้อความ

soft opt-in ในมาตรา 13 ของคำสั่ง ePrivacy ครอบคลุมข้อมูลติดต่อที่ได้รับระหว่างการขาย ใช้กับสินค้าคล้ายกันของตน โดยให้โอกาสปฏิเสธฟรีเมื่อเก็บและในทุกข้อความ ฉบับสหราชอาณาจักรคือ ข้อบังคับ PECR ข้อ 22 ซึ่งอธิบายในแนวทางอีเมลการตลาดของ ICO มาตรา 13 ยังห้ามอีเมลการตลาดที่อำพรางผู้ส่งหรือไม่มีที่อยู่รับคำขอปฏิเสธที่ใช้ได้ และข้อบังคับ PECR ข้อ 23 ทำเช่นเดียวกันในสหราชอาณาจักร

ตัวเลข CAN-SPAM มาจากคู่มือ CAN-SPAM ของ FTC ซึ่งเพิ่มว่าห้ามขายหรือโอนที่อยู่ที่ปฏิเสธรับ ยกเว้นให้บริษัทที่จ้างมาช่วยปฏิบัติตาม CAN-SPAM กฎ CASL อยู่ในมาตรา 6 ของ CASL และมาตรา 11 ส่วนโทษอยู่ในภาพรวม CASL ของ ISED

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

GDPR ใช้กับเครื่องมือจดหมายข่าวที่สร้างเองหรือไม่?

คำตอบขึ้นอยู่กับบริษัทดำเนินงานที่ไหนและเครื่องมือเก็บข้อมูลของใคร ไม่ใช่วิธีสร้าง ตามมาตรา 3 GDPR ใช้กับบริษัทที่ตั้งใน EU และบริษัทภายนอกที่เสนอสินค้าหรือบริการแก่คนใน EU หรือติดตามพฤติกรรมของพวกเขาที่นั่น บริษัทใดอยู่ในขอบเขตต้องถาม DPO ของบริษัท

จะเกิดอะไรขึ้นหากคีย์ API ของ Klaviyo รั่ว?

ผู้ถือคีย์ Full Access เปลี่ยนรายชื่อได้ ส่วน Read-Only ให้ดูเท่านั้น สร้างคีย์ทดแทนที่มีเฉพาะขอบเขตที่เครื่องมือใช้ เพราะ Klaviyo เพิ่มขอบเขตให้คีย์เดิมภายหลังไม่ได้ จึงต้องเลือกตอนนี้ เพิกถอนคีย์รั่วทันที เปลี่ยนเครื่องมือไปใช้คีย์ทดแทน และตรวจการส่งออกหรือเปลี่ยนรายชื่อที่ไม่มีใครทำ หากรายชื่ออาจถูกอ่าน ให้ถือเป็นเหตุละเมิด GDPR ที่เป็นไปได้

รายชื่ออีเมลที่แฮชแล้วยังเป็นข้อมูลส่วนบุคคลหรือไม่?

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

อีเมลการตลาด B2B ต้องตามกฎเดียวกันหรือไม่?

ไม่ใช่ทุกแห่ง FTC ระบุว่า CAN-SPAM ไม่มีข้อยกเว้นให้อีเมลระหว่างธุรกิจ กฎอีเมลของ PECR ครอบคลุมบุคคล และ ICO ยืนยันว่าส่งอีเมลการตลาดถึงบริษัทได้ สำหรับประเทศใน EU และแคนาดาให้ถามที่ปรึกษากฎหมาย