Email API: คู่มือฉบับสมบูรณ์สำหรับการส่งอีเมลด้วยโค้ด (2026)

Email API ช่วยให้แอปพลิเคชันของคุณส่งอีเมลผ่านคำขอ HTTP ได้

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

หน้าเวอร์ชันเดิมมีโครงสร้างที่ถูกต้องแต่ลงลึกไม่พอ มันเปรียบเทียบ API แสดงตัวอย่าง Brevo สั้น ๆ และอธิบายว่าควรใช้ API หรือ SMTP เมื่อใด การปรับปรุงครั้งนี้คงโครงสร้างเดิมไว้และขยายให้เป็นคู่มือการนำไปใช้ที่ครบถ้วนและมีการค้นคว้ารองรับ โดยอ้างอิงหน้าเว็บของผู้ให้บริการ เอกสารทางเทคนิค และหน้าราคาปัจจุบันของ Brevo SendGrid Mailgun Amazon SES Postmark รวมถึงเอกสาร messaging API ของ Tajo เอง

คำตอบอย่างรวดเร็ว

ใช้ Email API เมื่อคุณต้องการอีเมลที่ถูกกระตุ้นโดยแอปพลิเคชัน

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

ใช้ SMTP เมื่อระบบที่ส่งรองรับเพียงข้อมูลรับรอง SMTP หรือเมื่อคุณต้องการชั้นการรับส่งอีเมลมาตรฐานสำหรับแอปเดิม ปลั๊กอิน เซิร์ฟเวอร์ หรือเครื่องมือภายใน

ตัวเลือก Email API ที่ดีที่สุดขึ้นอยู่กับระบบที่คุณใช้

อย่าเลือกจากราคาที่แสดงหน้าเว็บอย่างเดียว ต้นทุนของ Email API ยังรวมถึงเวลาของทีมวิศวกรรม งานด้านความสามารถในการส่งถึง การออกแบบโครงสร้างข้อมูล การเฝ้าติดตาม การสนับสนุน และความเสี่ยงในการย้ายระบบในอนาคต

Email API เทียบกับ SMTP

ทั้ง API และ SMTP ส่งอีเมลได้ ความต่างอยู่ที่วิธีที่แอปพลิเคชันส่งมอบข้อความให้แพลตฟอร์มผู้ส่ง

SMTP เป็นโปรโตคอลรับส่งอีเมลที่ใช้กันมานาน ทำงานร่วมกับเครื่องมือได้หลากหลาย และยังมีประโยชน์เมื่อผลิตภัณฑ์ต้องการการตั้งค่าโฮสต์ พอร์ต ชื่อผู้ใช้ และรหัสผ่าน

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

กฎเชิงปฏิบัติคือ หากคุณเป็นเจ้าของโค้ดแอปพลิเคชัน ให้เริ่มจาก API หากคุณกำลังตั้งค่าเครื่องมือของบุคคลที่สามที่รองรับเพียง SMTP ให้ใช้ SMTP

Email API ทำงานอย่างไร

โฟลว์การส่งพื้นฐานมี 7 ขั้นตอน

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

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

เริ่มต้นอย่างรวดเร็ว ส่งอีเมลด้วย Brevo API

Email API แจ้งธุรกรรมของ Brevo ใช้คำขอที่ยืนยันตัวตนแล้วไปยังปลายทาง /v3/smtp/email ชื่อฟิลด์และ SDK อาจเปลี่ยนแปลงได้ จึงควรยึดเอกสารอ้างอิง API ของผู้ให้บริการเป็นแหล่งความจริงเมื่อลงมือพัฒนา

ตัวอย่างคำขอ

curl --request POST \
  --url https://api.brevo.com/v3/smtp/email \
  --header 'api-key: YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --data '{
    "sender": {
      "name": "Your App",
      "email": "[email protected]"
    },
    "to": [
      {
        "email": "[email protected]",
        "name": "Customer"
      }
    ],
    "subject": "Welcome to your account",
    "htmlContent": "<h1>Welcome</h1><p>Your account is ready.</p>"
  }'

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

สถาปัตยกรรม Email API สำหรับการใช้งานจริง

การเชื่อมต่อ Email API สำหรับการใช้งานจริงไม่ควรส่งอีเมลตรงจากทุกคอนโทรลเลอร์หรือทุกเส้นทางของแอป

ให้ใช้ชั้นจัดการข้อความเล็ก ๆ

1. เกิดอีเวนต์ในผลิตภัณฑ์
2. แอปพลิเคชันเขียนอีเวนต์ลงคิว งานเบื้องหลัง หรือบัสอีเวนต์
3. บริการอีเมลจับคู่อีเวนต์เข้ากับเทมเพลต
4. บริการอีเมลตรวจสอบความยินยอมของผู้รับและกฎการระงับการส่ง
5. บริการอีเมลเรียกใช้ API ของผู้ให้บริการ
6. บริการอีเมลบันทึกรหัสข้อความของผู้ให้บริการ
7. Webhook อัปเดตสถานะของข้อความในภายหลัง

วิธีนี้ช่วยให้โค้ดของผลิตภัณฑ์สะอาด และแยกแยะปัญหาการส่งอีเมลได้ง่ายขึ้น

ฟิลด์ภายในที่แนะนำ

• event_id
• message_type
• recipient_id
• recipient_email
• template_id
• locale
• provider
• provider_message_id
• idempotency_key
• status
• error_code
• created_at
• sent_at
• delivered_at

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

เปรียบเทียบ Email API ที่ดีที่สุด

Brevo

Brevo มีประโยชน์เมื่ออีเมลแจ้งธุรกรรมเป็นส่วนหนึ่งของระบบสื่อสารกับลูกค้าที่กว้างกว่า

เลือก Brevo เมื่อ

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

ควรระวัง

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

เอกสารของ Brevo ครอบคลุมการส่งอีเมลแจ้งธุรกรรม การส่งเป็นชุด โหมดแซนด์บ็อกซ์ SMTP relay Webhook SDK และหน้าอ้างอิง API ให้ใช้เอกสารเหล่านั้นสำหรับรายละเอียดการพัฒนา

SendGrid

SendGrid เป็นตัวเลือกที่พบบ่อยสำหรับทีมที่ต้องการ Email API สำหรับนักพัฒนาที่สมบูรณ์ และรองรับภาษากับแพลตฟอร์มได้กว้าง

เลือก SendGrid เมื่อ

• นักพัฒนาต้องการ Email API และระบบนิเวศ SDK ที่คุ้นเคย
• คุณต้องการทั้งอีเมลแจ้งธุรกรรมและอีเมลการตลาดจากผู้ให้บริการรายเดียว
• คุณมีโครงสร้างพื้นฐาน Twilio อยู่แล้ว
• คุณต้องการ Webhook แจ้งอีเวนต์และการควบคุมการส่งอย่างละเอียด

ควรระวัง

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

Mailgun

Mailgun ออกแบบมารอบการส่งที่นำโดยนักพัฒนาและเวิร์กโฟลว์ที่ยึด API เป็นหลัก

เลือก Mailgun เมื่อ

• ทีมวิศวกรรมเป็นเจ้าของโครงสร้างพื้นฐานด้านอีเมล
• คุณต้องการการส่งผ่าน HTTP การใช้ SMTP สำรอง บันทึกการทำงาน เส้นทางอีเมลขาเข้า และเครื่องมือตรวจสอบที่อยู่
• คุณต้องการผู้ให้บริการที่ชัดเจนเรื่องงานปฏิบัติการด้านความสามารถในการส่งถึง

ควรระวัง

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

Amazon SES

Amazon SES มีลักษณะเป็นโครงสร้างพื้นฐาน

เลือก Amazon SES เมื่อ

• แอปพลิเคชันของคุณทำงานบน AWS เป็นหลักอยู่แล้ว
• คุณมีทรัพยากรด้านวิศวกรรมที่จะดูแลการตั้งค่าเองมากขึ้น
• คุณต้องการการส่งปริมาณสูงแบบจ่ายตามการใช้งาน
• คุณต้องการเชื่อมต่ออย่างแนบแน่นกับ IAM CloudWatch SNS Lambda หรือบริการอื่นของ AWS

ควรระวัง

• การออกจากโหมดแซนด์บ็อกซ์และการขอสิทธิ์ใช้งานจริง
• การตั้งค่าตัวตนของโดเมน
• การจัดการอีเมลตีกลับและการร้องเรียน
• การตัดสินใจเรื่อง IP เฉพาะ
• การเฝ้าติดตามและการแจ้งเตือน
• ต้นทุนด้านวิศวกรรมในการสร้างฟีเจอร์ที่ผู้ให้บริการรายอื่นมีมาให้ในหน้าจอผลิตภัณฑ์อยู่แล้ว

SES ทำงานได้ยอดเยี่ยมเมื่อปริมาณสูง แต่ไม่ใช่ตัวเลือกที่ใช้แรงน้อยที่สุดสำหรับทุกทีม

Postmark

Postmark มุ่งเน้นที่อีเมลแจ้งธุรกรรม

เลือก Postmark เมื่อ

• ความน่าเชื่อถือและความชัดเจนของอีเมลแจ้งธุรกรรมสำคัญกว่าความครอบคลุมด้านการตลาดแบบครบวงจร
• คุณต้องการสตรีมข้อความที่แยกประเภทอีเมลออกจากกัน
• คุณต้องการเทมเพลต อีเมลขาเข้า และอีเวนต์การส่งถึง ในผลิตภัณฑ์ที่ตรงไปตรงมา

ควรระวัง

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

Tajo

Tajo เกี่ยวข้องเมื่อการส่งอีเมลผูกกับอีคอมเมิร์ซ อีเวนต์ของลูกค้า และระบบอัตโนมัติที่เชื่อมกับ Brevo

ใช้ Tajo เมื่อ

• อีเวนต์ของผลิตภัณฑ์และอีคอมเมิร์ซต้องไหลเข้าสู่ Brevo
• ข้อมูลจาก Shopify หรือระบบการค้าอื่นควรกระตุ้นข้อความเรื่องตะกร้าที่ถูกละทิ้ง คำสั่งซื้อ หรือวงจรชีวิต
• คุณต้องการชั้นการเชื่อมต่อเดียวสำหรับข้อมูลลูกค้า คำสั่งซื้อ สินค้า และอีเวนต์
• คุณต้องการเส้นทางการส่งข้อความแจ้งธุรกรรมที่มีเอกสารกำกับ และเชื่อมกับแบบจำลองข้อมูลลูกค้าที่กว้างกว่า

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

ควรใช้ Email API เมื่อใด

อีเมลแจ้งธุรกรรม

อีเมลแจ้งธุรกรรมถูกกระตุ้นด้วยการกระทำของผู้ใช้หรืออีเวนต์ของระบบ

ตัวอย่าง

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

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

ดูเพิ่มเติมที่ อีเมลยืนยันคำสั่งซื้อ และ ตัวอย่างอีเมลแจ้งธุรกรรม

อีเมลตามวงจรชีวิตของผลิตภัณฑ์

อีเมลตามวงจรชีวิตอยู่ตรงกลางระหว่างอีเมลแจ้งธุรกรรมกับอีเมลการตลาด

ตัวอย่าง

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

อีเมลเหล่านี้ได้ผลดีที่สุดเมื่อถูกกระตุ้นด้วยข้อมูลการใช้งานผลิตภัณฑ์ ไม่ใช่ปฏิทินแบบทั่วไป

อีเมลสำหรับอีคอมเมิร์ซ

ทีมอีคอมเมิร์ซมักต้องใช้ทั้งอีเมลแจ้งธุรกรรมและอีเมลการตลาดที่ถูกกระตุ้นด้วยเหตุการณ์

• ข้อเสนอต้อนรับ
• ตะกร้าสินค้าที่ถูกละทิ้ง
• การละทิ้งการเรียกดูสินค้า
• สินค้ากลับมามีสต็อก
• ราคาลดลง
• คำแนะนำสินค้า
• การเตือนให้ซื้อสินค้าเติม
• การอัปเดตสิทธิประโยชน์สะสม
• การขอรีวิว
• สิทธิ์เข้าถึงก่อนสำหรับ VIP

สำหรับทีมที่ใช้ Shopify และ Brevo Tajo ช่วยเชื่อมข้อมูลคำสั่งซื้อ ลูกค้า ความยินยอม สินค้า และตะกร้า เพื่อให้ข้อความเหล่านั้นถูกกระตุ้นด้วยพฤติกรรมการค้าที่เกิดขึ้นจริง

อีเมลการตลาดผ่าน API

อย่ามองอีเมลการตลาดเป็นเพียงงานส่งจดหมายข่าวเป็นชุด

การตลาดที่กระตุ้นผ่าน API รองรับ

• การแบ่งกลุ่มตามอีเวนต์
• แคมเปญเฉพาะบุคคล
• ชุดอีเมลแบบทยอยส่ง ที่ถูกกระตุ้นตามเงื่อนไข
• การเริ่มต้นใช้งานที่นำโดยตัวผลิตภัณฑ์
• เส้นทางวงจรชีวิตแบบอิงบัญชีลูกค้า
• อีเมลอัตโนมัติ ที่ผูกกับพฤติกรรมลูกค้า

มาตรฐานด้านการปฏิบัติตามกฎยังคงใช้เช่นเดิม ข้อความการตลาดต้องมีความยินยอมที่เหมาะสม การจัดการคำขอถอนความยินยอม และกฎการระงับการส่ง

ฟีเจอร์สำคัญของ API ที่ควรมองหา

การยืนยันตัวตนและการจัดการคีย์

Email API ที่จริงจังควรรองรับคีย์ API ที่ปลอดภัยและมีเอกสารการยืนยันตัวตนที่ชัดเจน

ข้อกำหนดด้านการปฏิบัติงาน

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

เทมเพลต

เทมเพลตช่วยให้อีเมลแจ้งธุรกรรมมีความสม่ำเสมอ

มองหา

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

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

Webhook

Webhook เปลี่ยนการส่งอีเมลให้เป็นวงจรป้อนกลับ

ติดตาม

• ประมวลผลแล้ว
• เลื่อนการส่ง
• ส่งถึงแล้ว
• เปิดแล้ว โดยตีความอย่างระมัดระวัง
• คลิกแล้ว โดยตีความอย่างระมัดระวัง
• ตีกลับ
• ถูกยกเลิกการส่ง
• ถูกร้องเรียน
• ยกเลิกติดตาม

เก็บรหัสข้อความของผู้ให้บริการไว้ เพื่อให้จับคู่อีเวนต์จาก Webhook กับผู้ใช้และอีเวนต์ภายในระบบได้

การจัดการการระงับการส่ง

การจัดการการระงับการส่งช่วยปกป้องความสามารถในการส่งถึงและการปฏิบัติตามกฎ

ระบบควรจัดการ

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

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

ขีดจำกัดอัตราและปริมาณการส่ง

ตรวจสอบว่าผู้ให้บริการจัดการเรื่องเหล่านี้อย่างไร

• ขีดจำกัดจำนวนคำขอ API
• ปริมาณข้อความที่ส่งได้
• ปลายทางสำหรับการส่งเป็นชุด
• ขีดจำกัดการส่งพุ่งในช่วงสั้น
• ขีดจำกัดรายวันหรือรายเดือนตามแพ็กเกจ
• การอุ่นเครื่องบัญชีใหม่
• การอุ่นเครื่อง IP เฉพาะ

วางแผนรับช่วงพีค การเปิดตัวผลิตภัณฑ์ เหตุการณ์ที่ทุกคนต้องรีเซ็ตรหัสผ่าน การลดราคาช่วง Black Friday หรือการแจ้งเตือนด้านความปลอดภัย อาจสร้างปริมาณการส่งที่สูงกว่าค่าเฉลี่ยรายวันมาก

การวิเคราะห์และการส่งออกข้อมูล

รายงานขั้นต่ำที่ควรมี

• ส่งแล้ว
• ส่งถึงแล้ว
• ตีกลับ
• เลื่อนการส่ง
• การร้องเรียน
• การยกเลิกติดตาม
• ประสิทธิภาพของเทมเพลต
• ข้อผิดพลาดที่ผู้ให้บริการตอบกลับ
• อีเวนต์รายได้หรือการแปลงในกรณีที่เกี่ยวข้อง

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

การรับอีเมลขาเข้า

อีเมลขาเข้าสำคัญเมื่อผู้ใช้ตอบกลับหรือส่งเนื้อหาเข้ามาในผลิตภัณฑ์

กรณีการใช้งาน

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

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

ความสามารถในการส่งถึงเมื่อใช้ Email API

API ไม่ได้แก้ปัญหาความสามารถในการส่งถึงโดยอัตโนมัติ

คุณยังต้องมี

• SPF
• DKIM
• DMARC
• โดเมนผู้ส่งที่ยืนยันแล้ว
• ตัวตนของผู้ส่งที่สม่ำเสมอ
• รายชื่อที่สะอาด
• การจัดการอีเมลตีกลับ
• การจัดการการร้องเรียน
• ลิงก์ยกเลิกติดตามที่ชัดเจนสำหรับข้อความการตลาด
• เนื้อหาที่ตรงประเด็น
• ความถี่ในการส่งที่เหมาะสม
• การเฝ้าติดตาม

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

แยกประเภทข้อความเมื่อทำได้

• การยืนยันตัวตนและความปลอดภัย
• ใบเสร็จและการอัปเดตคำสั่งซื้อ
• วงจรชีวิตของผลิตภัณฑ์
• การตลาด
• โปรโมชันจำนวนมาก

อย่าปล่อยให้แคมเปญโปรโมชันที่ส่งหนักไปทำลายการส่งถึงของอีเมลรีเซ็ตรหัสผ่านหรือใบเสร็จ

การจัดการข้อผิดพลาดและการส่งซ้ำ

ควรจำแนกประเภทของความล้มเหลวในการเรียกใช้ Email API

ควรลองใหม่

• หมดเวลาการเชื่อมต่อ
• ข้อผิดพลาดชั่วคราวของผู้ให้บริการ
• การเกินขีดจำกัดอัตรา โดยรอสักครู่ก่อนลองใหม่
• ความล้มเหลวของเครือข่าย
• ปัญหาคิวชั่วคราว

ไม่ควรลองใหม่ไม่รู้จบ

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

ใช้การหน่วงเวลาแบบเพิ่มขึ้นเรื่อย ๆ และคิวสำหรับข้อความที่ส่งไม่สำเร็จ สำหรับข้อความที่ยังล้มเหลวหลังลองใหม่แล้ว

อีเมลสำคัญทุกฉบับควรมีเส้นทางเชิงปฏิบัติการ

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

รายการตรวจสอบการนำ Email API ไปใช้

ใช้รายการนี้ก่อนเปิดใช้งานจริง

1. เลือกประเภทข้อความและผู้รับผิดชอบ
2. เลือกผู้ให้บริการ API และแนวทางสำรอง
3. ยืนยันโดเมนผู้ส่ง
4. ตั้งค่า SPF DKIM และ DMARC
5. สร้างคีย์ API สำหรับระบบทดสอบและระบบใช้งานจริง
6. เก็บความลับอย่างปลอดภัย
7. สร้างบริการหรือตัวเชื่อมสำหรับส่งข้อความ
8. เพิ่มคีย์ป้องกันการส่งซ้ำ
9. เพิ่มบันทึกล็อกที่มีโครงสร้าง
10. สร้างพฤติกรรมการลองใหม่และคิวสำหรับข้อความที่ส่งไม่สำเร็จ
11. สร้างเทมเพลต
12. ตรวจสอบการปรับให้เป็นส่วนตัวและค่าสำรอง
13. ตั้งค่า Webhook
14. เก็บรหัสข้อความของผู้ให้บริการ
15. จัดการอีเมลตีกลับ การร้องเรียน และการยกเลิกติดตาม
16. สร้างเครื่องมือให้ฝ่ายบริการส่งซ้ำและตรวจสอบสถานะได้
17. เฝ้าติดตามอัตราข้อผิดพลาดและอัตราการส่งถึง
18. จัดทำเอกสารเรื่องขีดจำกัดอัตราและคู่มือรับมือเหตุขัดข้อง

ตารางให้คะแนนการเลือกผู้ให้บริการ

ให้คะแนนผู้ให้บริการแต่ละรายตั้งแต่ 1 ถึง 5

สำหรับหลายทีม คำตอบที่ถูกต้องไม่ใช่ Email API ที่ถูกที่สุด แต่คือผู้ให้บริการที่ลดความเสี่ยงเชิงปฏิบัติการของอีเมลประเภทที่ลูกค้าพึ่งพา

ข้อผิดพลาดที่พบบ่อย

หลีกเลี่ยง

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

เริ่มต้นใช้งาน

สำหรับการพัฒนาใหม่ ให้เลือกเส้นทางที่สั้นและปลอดภัยที่สุด

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

หากทีมของคุณใช้ Brevo สำหรับงานการตลาดและ CRM อยู่แล้ว ให้เริ่มจาก API แจ้งธุรกรรมของ Brevo และจับคู่ข้อมูลอีเวนต์ที่คุณต้องการ หากผลิตภัณฑ์ของคุณต้องนำข้อมูลอีคอมเมิร์ซเข้าสู่ Brevo ให้ใช้ Tajo เชื่อมอีเวนต์ของลูกค้า ความยินยอม สินค้า ตะกร้า และคำสั่งซื้อ ก่อนจะสร้างข้อความตามวงจรชีวิตเพิ่มเติม

หากต้องการตั้งค่า SMTP แทน ดูที่ คู่มือ SMTP ฉบับสมบูรณ์ และ คู่มือเซิร์ฟเวอร์ SMTP ฟรี

คู่มือที่เกี่ยวข้อง

• คู่มือบริการอีเมลแจ้งธุรกรรม
• ตัวอย่างอีเมลแจ้งธุรกรรม
• คู่มือ SMTP ฉบับสมบูรณ์
• SPF DKIM และ DMARC
• คู่มือระบบอัตโนมัติทางอีเมล
• การเชื่อมต่อ Brevo กับ Shopify