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

การแยกประเภทขึ้นอยู่กับตัวข้อความ การตั้งให้อีเมลเป็น “ธุรกรรม” ในเครื่องมือส่งอีเมลไม่ได้เป็นตัวกำหนดสถานะทางกฎหมายของอีเมลนั้น

ใช้เกณฑ์วัตถุประสงค์หลัก

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

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

ทำให้ข้อมูลสำคัญเด่นชัด หากโปรโมชันดึงความสนใจไปจากใบเสร็จหรือการแจ้งเตือนด้านความปลอดภัย การแยกเป็นอีเมลการตลาดอีกฉบับมักเป็นทางเลือกที่ชัดเจนกว่า นี่คือแนวทางของสหรัฐฯ ให้ตรวจสอบข้อกำหนดที่ใช้กับผู้รับและธุรกิจของคุณด้วย ตรวจสอบแหล่งที่มาเมื่อ 28 กันยายน 2026

กรณีที่พบบ่อย

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

กฎของผู้ให้บริการอีเมลยังมีผล

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

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

สำหรับอีเมลการตลาด RFC 8058 กำหนดกลไกเฮดเดอร์สำหรับการยกเลิกในคลิกเดียว ลิงก์ในส่วนท้ายกับการยกเลิกการรับข่าวสารผ่านเฮดเดอร์มีบทบาทต่างกัน ให้ทดสอบการทำงานกับข้อความที่ได้รับจริง

ส่งเหตุการณ์ธุรกรรมผ่าน Brew

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

หลังทดสอบและเผยแพร่ระบบอัตโนมัติแล้ว แบ็กเอนด์ของคุณจะเรียกทริกเกอร์ ตัวอย่างนี้สมมติว่าทริกเกอร์ประกาศ order_id และ ship_date ไว้:

curl --fail-with-body \
  "https://brew.new/api/v1/automations/triggers/${BREW_ORDER_TRIGGER_ID}/fire" \
  -H "Authorization: Bearer ${BREW_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-1234-shipped" \
  -d '{"payload":{"email":"ada@example.com","order_id":"1234","ship_date":"Tuesday"}}'

ใช้ตัวระบุทริกเกอร์จริง และคีย์ idempotency ที่คงที่สำหรับเหตุการณ์นั้น อีเมลอ่านฟิลด์เพย์โหลดที่ประกาศไว้ได้ด้วยไวยากรณ์อย่าง {{ trigger.order_id }} ดูเอกสารแท็กตัวแปร และทดสอบกรณีที่ไม่มีค่า

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

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