ทริกเกอร์จากเหตุการณ์การยืนยันตัวตน
เชื่อมต่อ Supabase เพื่อเริ่มส่งอีเมลที่ตรงกับแบรนด์เมื่อมีผู้สมัครใช้งาน ยืนยันอีเมล เปลี่ยนรหัสผ่าน หรือถูกแบน สคริปต์ตั้งค่าจะเพิ่มทริกเกอร์ฐานข้อมูลให้ตาราง auth.users ของคุณ และ Brew จะแปลงการเปลี่ยนแปลงแต่ละครั้งเป็นหนึ่งใน 12 ทริกเกอร์ของระบบอัตโนมัติ
Supabase Auth ยังคงดูแลการเข้าสู่ระบบ, ลิงก์ยืนยัน, Magic Link และการรีเซ็ตรหัสผ่าน ส่วน Brew สร้างและส่งอีเมลที่ตามมาหลังการเปลี่ยนแปลงเหล่านั้น
auth.user.signed_in เกิดขึ้นเมื่อ last_sign_in_at เปลี่ยน การรีเฟรชโทเค็นของ Supabase ก็เปลี่ยนคอลัมน์นี้ด้วย เหตุการณ์นี้จึงอาจเกิดซ้ำหลายครั้งขณะที่ผู้ใช้ยังเข้าสู่ระบบอยู่ และไม่ได้แสดงว่ามีคนกลับมาใช้งานหลังจากหายไปนาน
เหตุการณ์นี้ยังเป็นเหตุการณ์ที่อนุมานได้ซึ่งมีลำดับความสำคัญต่ำที่สุด เมื่อการอัปเดตเดียวกันยืนยันอีเมลหรืออัปเกรดผู้ใช้นิรนาม Brew จะส่งเหตุการณ์นั้นออกมาแทน auth.user.signed_in
หากต้องการส่งอีเมลถามไถ่ผู้ใช้ที่ไม่ได้ใช้งาน ให้แอปพลิเคชันของคุณตัดสินว่าใครไม่ได้ใช้งานจากข้อมูลกิจกรรมของแอปเอง แล้วส่งเหตุการณ์ที่กำหนดเองของ Brew แยกต่างหากเฉพาะสำหรับผู้ใช้ที่เข้าเกณฑ์ และให้ระบบอัตโนมัติที่ “ทำงานอยู่” ส่งอีเมลถามไถ่จากเหตุการณ์นั้น
ทดสอบทั้งสองเส้นทาง: ผู้ใช้ที่ไม่ได้ใช้งานจะได้รับอีเมลถามไถ่ ส่วนผู้ใช้ที่มีการใช้งานก่อนการตรวจสอบจะไม่ได้รับ
auth.user.created, auth.user.updated และ auth.user.deleted มาจากการเพิ่ม การอัปเดต และการลบแถวใน auth.users ส่วนเหตุการณ์อื่น Brew อนุมานจากการอัปเดตโดยเปรียบเทียบแถวเดิมกับแถวใหม่
การอัปเดตหนึ่งครั้งทำให้เกิดเหตุการณ์เดียว เมื่อหลายคอลัมน์เปลี่ยนพร้อมกัน รายการแรกที่ตรงตามลำดับนี้จะถูกใช้: email_confirmed, phone_confirmed, upgraded_from_anonymous, email_changed, password_changed, banned, unbanned, invited, signed_in ส่วนการอัปเดตที่ไม่ตรงกับรายการใดเลยจะมาเป็น auth.user.updated
Brew รองรับประเภทเหตุการณ์ 12 ประเภทต่อไปนี้:
เหตุการณ์ที่ยืนยันแล้วแต่ละรายการซึ่งมีที่อยู่อีเมลจริงจะสร้างหรืออัปเดตผู้ติดต่อใน Brew โดยจับคู่ตามอีเมล ไม่ว่าจะมีระบบอัตโนมัติใช้เหตุการณ์นั้นหรือไม่ก็ตาม หากมีข้อมูล Brew จะบันทึกชื่อ-นามสกุล, supabase_user_id, supabase_phone, supabase_role, supabase_full_name, supabase_avatar_url และ supabase_provider ด้วย
บางเหตุการณ์ยังตั้งค่าฟิลด์เกี่ยวกับวงจรชีวิตของบัญชีด้วย โดย supabase_account_status จะเป็น active, invited, banned หรือ deleted ส่วน supabase_email_verified_at, supabase_phone_verified_at และ supabase_last_sign_in_at มาจากเหตุการณ์การยืนยันและการเข้าสู่ระบบที่ตรงกัน
ใช้สคีมาเพย์โหลดที่ประกาศไว้ของเหตุการณ์ที่เลือกสำหรับแท็กตัวแปร ทุกเหตุการณ์มี email และหากมีข้อมูล จะมี firstName, lastName, fullName, displayName, avatarUrl, phone, role, provider, createdAt, lastSignInAt และ emailConfirmedAt ด้วย ชื่อและรูปโปรไฟล์มาจาก raw_user_meta_data โดยมีค่าสำรองสำหรับผู้ที่สมัครผ่าน OAuth ส่วน timestamp ทั้งสามเป็นเวลาแบบ Unix หน่วยวินาที
เหตุการณ์ที่อนุมานได้จะเพิ่ม previousValue, newValue หรือทั้งสองฟิลด์ ซึ่งเก็บค่าเดิมและค่าใหม่ของคอลัมน์เป็นข้อความ โดย auth.user.password_changed ไม่มีทั้งสองฟิลด์ ส่วน provider เก็บวิธีสมัครใช้งาน เช่น email, google หรือ github คุณจึงแยกโฟลว์ต้อนรับตามวิธีที่ผู้ใช้สมัครได้
ID ผู้ใช้ของ Supabase ไม่ใช่แท็กตัวแปร แต่ Brew จะจัดเก็บไว้ในผู้ติดต่อเป็น supabase_user_id เพื่อใช้กรองและแบ่งเซกเมนต์
การมีบัญชี Supabase ไม่ถือเป็นความยินยอมรับอีเมลการตลาด ให้บันทึกความยินยอมตอนสมัครใช้งาน และตรวจสอบก่อนส่งอีเมลโปรโมชัน
ไม่ส่ง เพราะ Supabase Auth ยังคงส่งลิงก์ยืนยัน, Magic Link, คำเชิญ และอีเมลรีเซ็ตรหัสผ่านผ่านการตั้งค่าอีเมลของตัวเอง เช่น SMTP ที่กำหนดเอง ส่วน Brew จะเริ่มระบบอัตโนมัติหลังการเปลี่ยนแปลงเหล่านั้นไปถึง auth.users แล้ว และ Supabase แนะนำให้แยกโดเมนผู้ส่งสำหรับอีเมลยืนยันตัวตนและอีเมลการตลาด
การได้รับเหตุการณ์กับการส่งอีเมลเป็นคนละขั้นตอนกัน ตรวจสอบว่าระบบอัตโนมัติที่ตรงกันอยู่ในสถานะ “ทำงานอยู่” จากนั้นดูตัวกรอง ประวัติการทำงาน การเข้าเกณฑ์ของผู้รับ และโดเมนผู้ส่ง เหตุการณ์ของผู้ใช้ที่ไม่มีที่อยู่อีเมล เช่น ผู้ใช้นิรนามที่ยังไม่ได้เพิ่มอีเมล จะไม่สร้างผู้ติดต่อและไม่เริ่มระบบอัตโนมัติ
