ทำความเข้าใจอีเมลการตลาดและอีเมลธุรกรรมที่ส่งตามเหตุการณ์ พร้อมโมเดลที่ใช้ได้จริงสำหรับเพย์โหลดของทริกเกอร์ การเผยแพร่ และการตรวจเกณฑ์ที่เกิดขึ้นภายหลัง
อีเมลที่ส่งตามทริกเกอร์เริ่มจากสิ่งที่เกิดขึ้นแล้ว เช่น การสมัครใช้งาน ใบแจ้งหนี้ที่ชำระไม่สำเร็จ การส่งออกข้อมูลที่เสร็จสิ้น หรือเหตุการณ์อื่นที่ระบบของคุณอธิบายได้ เหตุการณ์นั้นคือบริบทของข้อความ
ทริกเกอร์ไม่ได้เป็นตัวตัดสินว่าข้อความเป็นอีเมลการตลาดหรืออีเมลธุรกรรม สิ่งที่ตัดสินคือวัตถุประสงค์ของข้อความและความสัมพันธ์กับผู้รับ ใบเสร็จกับข้อเสนอให้อัปเกรดอาจมาจากผลิตภัณฑ์เดียวกัน แต่ยังต้องใช้กฎการส่งที่ต่างกัน
ตั้งชื่อที่อธิบายการกระทำหรือเงื่อนไขที่ยืนยันแล้ว ประกาศฟิลด์ที่อีเมลต้องใช้ และทดสอบด้วยเพย์โหลดที่เป็นตัวแทนของกรณีจริง หลีกเลี่ยงเหตุการณ์ที่มีความหมายต่างกันไปตามบริการที่ส่งเหตุการณ์นั้นมา
ตัวอย่างเช่น เหตุการณ์คำสั่งซื้อที่เสร็จสมบูรณ์อาจมีที่อยู่อีเมลของผู้รับ เลขอ้างอิงคำสั่งซื้อ และลิงก์ไปยังคำสั่งซื้อ อย่าใส่ข้อมูลที่อ่อนไหวหรือไม่จำเป็นไว้ในเพย์โหลด ส่วนรูปแบบคำขอที่รองรับดูได้ในเอกสารอ้างอิง API
โมเดลระบบอัตโนมัติของ Brew เชื่อมทริกเกอร์เข้ากับขั้นตอนต่าง ๆ เช่น การส่งอีเมล ให้สร้างและตรวจทานฉบับร่าง แล้วเผยแพร่ระบบอัตโนมัติก่อนจะคาดหวังให้เหตุการณ์จากระบบที่ใช้งานจริงสั่งให้ระบบอัตโนมัตินั้นทำงาน ส่วนโฟลว์ตามวงจรชีวิตลูกค้าที่ควรสร้างก่อน ตั้งแต่การสมัครใช้งานไปจนถึงการกระตุ้นให้กลับมาใช้งาน ดูได้ในบทความอีเมลอัตโนมัติด้วย AI
ลำดับอีเมลต้อนรับที่โปรโมตผลิตภัณฑ์ถือเป็นอีเมลการตลาด ส่วนใบเสร็จคำสั่งซื้อหรือข้อความด้านความปลอดภัยของบัญชีที่ผู้ใช้ร้องขออาจเป็นอีเมลธุรกรรม ข้อความแบบผสมต้องประเมินวัตถุประสงค์หลัก และการเพิ่มโปรโมชันเล็กน้อยไม่ได้ตอบคำถามทางกฎหมายให้โดยอัตโนมัติ ไม่ว่าจะไปทางใด
ทำให้ข้อมูลบัญชีที่สำคัญหาได้ง่าย ใช้วัตถุประสงค์ของโดเมนผู้ส่งที่เหมาะสม และทดสอบการทำงานของสถานะการรับข่าวสาร อ่านคู่มืออีเมลธุรกรรมเพื่อดูความแตกต่าง และข้อกำหนดของผู้ให้บริการอีเมลที่ลิงก์ไว้
สำหรับอีเมลการตลาด ให้ตรวจสอบความยินยอม และดำเนินการตามสถานะการยกเลิกการรับข่าวสารและการระงับการส่ง เหตุการณ์ที่ตรงเงื่อนไขไม่ใช่ใบอนุญาตให้ส่งอีเมลถึงทุกคนที่บังเอิญมีที่อยู่อยู่ในเพย์โหลด
สมมติว่าคุณต้องการเตือนผู้ทดลองใช้ที่ยังตั้งค่าไม่เสร็จหลังผ่านไป 6 วัน เหตุการณ์การสมัครใช้งานรู้แค่สิ่งที่เป็นจริงตอนสมัคร และคาดเดาไม่ได้ว่าผู้ใช้จะตั้งค่าเสร็จในวันพรุ่งนี้หรือไม่
สำหรับการตรวจในวันที่หกใน Brew นั้น โหนดตัวกรองหรือโหนดแยกเส้นทางตามเงื่อนไขอ่านฟิลด์ผู้ติดต่อปัจจุบันใน Brew ได้ผ่าน contact.<name> ให้กำหนดและซิงค์ฟิลด์ที่บอกสถานะการเริ่มใช้งานจริงและสถานะการรับข่าวสาร แล้วตรวจฟิลด์เหล่านั้นหลังช่วงรอ ส่วนฟิลด์ของเหตุการณ์อย่าง payload.activated ยังเก็บค่าเดิมจากเหตุการณ์ต้นทาง หากสถานะที่ต้องใช้อยู่นอก Brew ให้แอปพลิเคชันของคุณตรวจในวันที่หก แล้วส่งเหตุการณ์เตือนใหม่เฉพาะเมื่อผู้ใช้ยังเข้าเกณฑ์อยู่
กฎเดียวกันนี้ใช้กับเงื่อนไขอย่าง “ยังไม่ได้ซื้อ” หรือ “ยังใช้แพ็กเกจฟรีอยู่” ด้วย ส่วนรูปแบบที่ให้แอปพลิเคชันเป็นผู้ตรวจ อธิบายไว้ในบทความเรื่องลำดับอีเมลช่วงทดลองใช้
ทดสอบคำขอที่ส่งเหตุการณ์ รอบการทำงานของระบบอัตโนมัติ และอีเมลที่ได้รับ โดยครอบคลุมกรณีฟิลด์ขาดหาย การลองใหม่ ผู้รับทดสอบแบบส่วนตัว และการเปลี่ยนสถานะที่ควรหยุดการส่งในภายหลัง
สำหรับผู้ให้บริการที่เชื่อมต่อไว้ ให้ใช้ชื่อเหตุการณ์จริงของผู้ให้บริการนั้น หน้า Stripe แสดงรายการเหตุการณ์ที่ Brew รองรับ และอธิบายว่าทำไมการตั้งค่า “ซิงค์ชื่อ-นามสกุล” จึงไม่เกี่ยวกับการเผยแพร่ระบบอัตโนมัติ
เมื่อเส้นทางทำงานได้แล้ว ให้รักษาลำดับอีเมลให้เข้าใจง่าย เหตุการณ์ที่กำหนดไว้อย่างชัดเจนไม่กี่รายการกับข้อความที่ผ่านการตรวจทานแล้วดูแลง่ายกว่าระบบอัตโนมัติยาวเหยียดตัวเดียวที่ไม่มีใครอธิบายเงื่อนไขได้
