สร้างลำดับอีเมลเปลี่ยนผู้ทดลองใช้เป็นลูกค้าจากสิ่งที่ผู้ใช้ทำในผลิตภัณฑ์ ทั้งเหตุการณ์เริ่มใช้งานจริง อีเมลละหนึ่งหน้าที่ การตรวจเกณฑ์ และการทดสอบเงื่อนไขการออก
อีเมลที่ช่วยเปลี่ยนผู้ทดลองใช้เป็นลูกค้าควรตอบสนองต่อสิ่งที่ผู้ใช้ทำไปแล้ว คนที่ยังไม่ได้สร้างโปรเจกต์ต้องการความช่วยเหลือเรื่องการตั้งค่า ส่วนคนที่ใช้ผลิตภัณฑ์ทุกวันต้องการคำอธิบายที่ชัดเจนเรื่องแพ็กเกจแบบชำระเงิน การส่งอีเมลนับถอยหลังแบบเดียวกันให้ทั้งสองคนจึงมองข้ามความแตกต่างนี้ไป
คู่มือนี้แยกการออกแบบลำดับอีเมลออกจากตรรกะของแอปพลิเคชันที่ตัดสินว่าใครควรได้รับอีเมลแต่ละฉบับ
เลือกการกระทำ 1 อย่างที่แสดงว่าผู้ใช้ได้ผลลัพธ์ที่มีประโยชน์ครั้งแรกจากผลิตภัณฑ์แล้ว และให้เจาะจงพอที่แบ็กเอนด์ของคุณจะบันทึกได้ เช่น สร้างโปรเจกต์แล้ว นำเข้าข้อมูลเสร็จแล้ว หรือเชิญเพื่อนร่วมทีมแล้ว การเปิดดูหน้าเว็บเพียงอย่างเดียวแทบไม่เคยพอ
บันทึกเวลาที่สมัครใช้งาน วันสิ้นสุดช่วงทดลองใช้ การเริ่มใช้งานจริง และสถานะการชำระเงินไว้ในระบบที่เป็นเจ้าของข้อเท็จจริงเหล่านั้น และให้มองฟิลด์ผู้ติดต่อในแพลตฟอร์มอีเมลเป็นข้อมูลที่ซิงค์มา ไม่ใช่หลักฐานว่าโฟลว์ที่เริ่มไปก่อนหน้ากำลังอ่านสถานะล่าสุดอยู่
| อีเมล | ใช้เมื่อไร | เกณฑ์ที่ตรวจเมื่อถึงเวลาส่ง |
|---|---|---|
| ต้อนรับ | หลังสมัครใช้งานหรือยืนยันอีเมล | มีบัญชีอยู่ และรับอีเมลนี้ได้ |
| ช่วยตั้งค่า | ราว 2 วันหลังจากนั้น ปรับตามผลิตภัณฑ์ของคุณ | ยังไม่เริ่มใช้งานจริง |
| การกระทำที่มีประโยชน์ขั้นต่อไป | หลังเริ่มใช้งานจริง | เริ่มใช้งานจริงแล้ว และยังไม่ได้ทำการกระทำนั้น |
| ช่วงทดลองใช้ใกล้สิ้นสุด | ก่อนวันสิ้นสุดช่วงทดลองใช้จริง | ช่วงทดลองใช้ยังไม่หมด และบัญชียังไม่ได้ชำระเงิน |
| ถามไถ่ครั้งสุดท้าย | หลังช่วงทดลองใช้สิ้นสุด หากเหมาะสม | ยังไม่ชำระเงิน ยังเข้าเกณฑ์ และได้รับอนุญาตให้รับอีเมลการตลาด |
จังหวะเวลาเหล่านี้เป็นจุดเริ่มต้นสำหรับการทดสอบ ไม่ใช่ช่วงเวลาที่วัดแล้วว่าได้ผลดีที่สุด ให้ระบุวันสิ้นสุดช่วงทดลองใช้จริงและสิ่งที่จะเกิดขึ้นต่อไป อย่าสร้างความขาดแคลนขึ้นมาเอง หรือทำให้เข้าใจว่าจะมีการเรียกเก็บเงินทั้งที่ยังไม่มีวิธีการชำระเงินอยู่ในระบบ
ในโฟลว์ของ Brew ที่เริ่มจากเหตุการณ์ ค่า payload.activated จะอ่านจากเหตุการณ์ต้นทาง ขณะที่ contact.activated จะอ่านฟิลด์ผู้ติดต่อปัจจุบันของผู้รับใน Brew ตอนที่โหนดตัวกรองหรือโหนดแยกเส้นทางตามเงื่อนไขทำงาน หากต้องการข้ามอีเมลเตือนเรื่องการตั้งค่าหลังผู้ใช้เริ่มใช้งานจริงแล้ว ให้ประกาศฟิลด์ประเภทใช่/ไม่ใช่ (boolean) นั้น ซิงค์ค่าจากผลิตภัณฑ์ของคุณอยู่เสมอ และตรวจ contact.activated equals false หลังขั้นตอน “รอ” แต่ละขั้นที่เกี่ยวข้อง ค่าที่ขาดหายไม่เท่ากับ false จึงต้องทดสอบแยกต่างหาก
การอ่านค่าเหล่านี้ใช้ข้อมูลผู้ติดต่อที่ Brew เก็บไว้ ไม่ใช่ฐานข้อมูลของแอปพลิเคชันคุณหรือคำขอไปยัง Stripe แบบเรียลไทม์ การได้รับเหตุการณ์เริ่มใช้งานจริงหรือเหตุการณ์ชำระเงินไม่ได้ยกเลิกรอบการทำงานที่เริ่มไปก่อนหน้าโดยอัตโนมัติ กราฟระบบอัตโนมัติจึงต้องมีเงื่อนไขก่อนการส่งทุกครั้งที่ขึ้นอยู่กับสถานะ
สำหรับข้อเท็จจริงที่อยู่นอก Brew ให้แอปพลิเคชันของคุณตั้งเวลางานไว้ เมื่อถึงเวลา ให้อ่านข้อมูลบัญชีหรือใบแจ้งหนี้ปัจจุบัน แล้วส่งเหตุการณ์ที่กำหนดเองของ Brew แยกอีกรายการหนึ่งเฉพาะเมื่อผู้รับยังเข้าเกณฑ์อยู่ และใส่ข้อมูลปัจจุบันที่ต้องใช้ในการปรับเนื้อหาเฉพาะบุคคลไว้ในเหตุการณ์ใหม่นั้นด้วย
ตัวอย่างเช่น อีเมลเตือนที่แอปพลิเคชันตั้งเวลาไว้จะทำงานแบบนี้:
Signup committed → fire welcome event
Reminder job becomes due → read current account
Already activated or paid → finish without firing an email event
Still eligible → fire setup-reminder event with current dataใช้ ID ทริกเกอร์จริงที่ Brew ส่งกลับมา และสคีมาที่ประกาศไว้ของทริกเกอร์นั้น ทำตามคู่มือการตั้งค่าระบบอัตโนมัติและสคีมาเพย์โหลดแบบมีไทป์ และสำหรับการส่งเหตุการณ์ซ้ำเมื่อมีการลองใหม่ ให้ใช้กลไก idempotency ตามที่เอกสารระบุไว้
หาก Stripe เป็นผู้ดูแลช่วงทดลองใช้ เหตุการณ์การสมัครสมาชิกของ Stripe จะให้บริบทด้านการเรียกเก็บเงิน การเชื่อมต่อ Stripe มีทริกเกอร์จากเหตุการณ์ที่รองรับ รวมถึง customer.subscription.trial_will_end ส่วนการเริ่มใช้งานจริงในผลิตภัณฑ์ยังเป็นข้อมูลของแอปพลิเคชันคุณ เว้นแต่คุณจะส่งข้อมูลนั้นแยกเข้ามา
สำหรับอีเมลเตือนเรื่องการชำระเงินในภายหลัง ให้ตรวจข้อมูลปัจจุบันใน Stripe การอัปเดตบัตรสำเร็จไม่ได้พิสูจน์ว่าใบแจ้งหนี้ได้รับการชำระแล้ว และควรประสานกับอีเมลที่ Stripe ส่งเอง เพื่อให้ลูกค้าได้รับการแจ้งเตือนเพียงฉบับเดียวต่อหนึ่งวัตถุประสงค์
เริ่มจากสถานการณ์จริงของผู้รับ อธิบายการกระทำที่มีประโยชน์ 1 อย่าง และลิงก์ไปยังสิ่งนั้นโดยตรง อีเมลเรื่องการตั้งค่าอาจมีตัวอย่างสั้น ๆ และที่อยู่สำหรับตอบกลับ ส่วนอีเมลเรื่องแพ็กเกจแบบชำระเงินควรอธิบายขีดจำกัดหรือฟีเจอร์ที่เกี่ยวข้องและราคาจริง พร้อมลิงก์ไปยังหน้าราคาปัจจุบัน
ทำให้ความยินยอมรับอีเมลการตลาด การทำงานของการยกเลิกการรับข่าวสาร และวัตถุประสงค์ของโดเมนสอดคล้องกับเนื้อหาอีเมล การสมัครทดลองใช้ไม่ได้เป็นเหตุผลให้ส่งอีเมลโปรโมชันที่ไม่เกี่ยวข้อง
ทดสอบว่าจะเกิดอะไรขึ้นเมื่อผู้ติดต่อเริ่มใช้งานจริงหรือชำระเงินก่อนถึงการตรวจเกณฑ์แต่ละจุด หากใช้เงื่อนไขของผู้ติดต่อ ให้อัปเดตฟิลด์ที่เกี่ยวข้องใน Brew ระหว่างช่วงรอ แล้วยืนยันว่าอีเมลเตือนถูกข้าม หากใช้การตรวจที่แอปพลิเคชันตั้งเวลาไว้ ให้ยืนยันว่าบัญชีที่ไม่เข้าเกณฑ์ไม่ทำให้เกิดเหตุการณ์เตือน และทดสอบการลองใหม่ การขยายช่วงทดลองใช้ การลบบัญชี การยกเลิกการรับข่าวสาร และฟิลด์ที่ไม่มีค่าด้วย ตรวจทั้งบันทึกของแอปพลิเคชันและประวัติการทำงานใน Brew
วัดการเริ่มใช้งานจริงและการเปลี่ยนเป็นลูกค้าแบบชำระเงินด้วยข้อมูลผลิตภัณฑ์ของคุณ และวัดความล้มเหลวในการนำส่งด้วยแพลตฟอร์มอีเมล อัตราการเปิดเพียงอย่างเดียวไม่ได้บอกว่าลำดับอีเมลช่วยผู้ทดลองใช้ได้หรือไม่ ดูตัวอย่างได้ที่การออกแบบลำดับอีเมลต้อนรับ และดูการแบ่งงานในการนำไปใช้ได้ที่ MCP กับ REST
