Trigger-based Entry: เริ่ม Journey ทันทีที่มี Event
เริ่ม journey ทันทีที่ผู้ใช้ทำสิ่งสำคัญ ไม่ว่าจะเพิ่มสินค้าลงตะกร้า ชำระเงินไม่สำเร็จ หรือสั่งซื้อสำเร็จ ไม่ต้องรอรอบดึงข้อมูล segment ครั้งถัดไปครับ
เริ่มทันทีที่มันเกิดขึ้น
คุณอยากให้ journey เริ่มทันทีที่มีอะไรเกิดขึ้น ไม่ใช่รอให้ segment รอบถัดไปมาถึง เรื่องนี้พูดง่ายแต่รักษาไว้ยากเมื่อมี automation รันพร้อมกันหลายตัว: แคมเปญกู้คืนตะกร้าสินค้าเรียงอยู่กับ automation อีกสิบตัว แต่ละตัวก็ดูสมเหตุสมผลในตัวเอง ข้อความ “ลืมของไว้ในตะกร้าหรือเปล่าคะ” ที่ batch งานตอนกลางคืนส่งออกไปอีกชั่วโมงถัดมา ให้ความรู้สึกต่างจากข้อความที่ทำงานอยู่แล้วก่อนคนคนนั้นจะวางมือถือลง โดยเฉพาะช่วง flash sale สงกรานต์หรือ 11.11 ที่ทราฟฟิกตะกร้าสินค้าพุ่งพร้อมกันเป็นพัน ๆ ราย Trigger-based entry คือตัวที่ปิดช่องว่างนี้
Trigger-based Entry ทำอะไรได้บ้าง
เลือก event หนึ่งตัว แล้วใครก็ตามที่ยิง event นั้นจะเข้า journey ทันที แทนที่จะรอรอบสแกน segment ที่บันทึกไว้ครั้งถัดไป
ตอบสนองแบบเรียลไทม์
เข้า journey ทันทีที่ event ยิง ไม่ใช่รอรอบสแกนตามกำหนดเวลา
กรองจาก payload ของ event
ตั้งเงื่อนไขเสริมบน attribute ของ event เองเพื่อคัดกรองการเข้า journey นอกเหนือจากแค่ชื่อ event
รันหลาย session พร้อมกัน
Concurrency ที่ผูกกับ order_id หรือ product_id ทำให้ผู้ใช้หนึ่งคนถือหลาย session ขนานกันได้
ควบคุม re-entry
บล็อก event ซ้ำ หรือให้มันเริ่ม session ใหม่ ตั้งได้ต่อองค์ประกอบ
| การตั้งค่า | ตัวเลือก |
|---|---|
| แหล่งที่มา Event | SDK postEvent, REST API, PW_* event ที่มีให้ตามค่าเริ่มต้น, custom event, การเข้าหรือออกจาก geozone |
| เงื่อนไขการเข้า | เสริม: กรองจาก attribute ของ event เอง (attribute, operator, value) |
| ใครเข้า journey | ผู้ใช้ที่ยิง event เอง หรือผู้ใช้ที่ระบุชื่อไว้ใน payload ของ event |
| Re-entry | ไม่อนุญาต (ค่าเริ่มต้น) หรืออนุญาตและให้เริ่ม session ใหม่ |
| Concurrency | หนึ่ง session ที่ทำงานต่อผู้ใช้หนึ่งคน หรือหลาย session ที่ผูกกับ session attribute เช่น order_id หรือ product_id |
Audience-based entry ตรวจ segment ซ้ำตามรอบเวลาที่ตั้งไว้ ส่วนองค์ประกอบนี้ตอบสนองภายในช่วงเวลาเดียวกับที่ event ยิง และการรันหลาย session ต่อผู้ใช้พร้อมกันหมายความว่า 3 ออเดอร์ที่เปิดอยู่พร้อมกันจะมี journey ติดตามสถานะของตัวเองแยกกัน แทนที่จะชนกันเป็น session เดียว การส่ง event ที่มาทีหลังกลับไปยัง session ที่ถูกต้องคือสิ่งที่ session-scoped matching ของ Wait for Trigger จัดการต่อในแคนวาสถัดไป องค์ประกอบทั้งหมดนี้ รวมเงื่อนไขและการควบคุม re-entry มีให้ในแพ็กเกจฟรีครับ
ทำไมสิ่งนี้ถึงสำคัญกับ journey builder
Journey builder จะดีได้ก็ต่อเมื่อจุดเริ่มต้นของมันดีพอ Audience-based entry ครอบคลุมรอบเวลาตามกำหนด อย่างจดหมายข่าวหรือแคมเปญดึงผู้ใช้เก่ากลับมา สิ่งที่ builder ต้องมีเพิ่มเติมคือวิธีตอบสนองในจังหวะที่การชำระเงินล้มเหลวหรือมีคนทิ้งตะกร้าสินค้าไว้ และนั่นคือสิ่งที่ trigger-based entry มอบให้ Customer Journey Builder มันอ่านจาก event catalog ชุดเดียวกับที่ส่วนอื่นบนแคนวาสใช้สำหรับ segmentation และการแยกสาขาอยู่แล้ว สัญญาณที่เปิดประตูจึงเป็นสัญญาณเดียวกับที่ขับเคลื่อน flow หลังจากนั้น
สิ่งที่มันส่งต่อไปยังขั้นตอนถัดไป
event add_to_cart ยิงขึ้น แล้ว journey กู้คืนตะกร้าสินค้าก็เริ่มทำงาน องค์ประกอบ Wait for Trigger ให้เวลาผู้ซื้อสูงสุด 90 วันในการซื้อให้เสร็จ ก่อนแยกไปเส้นทางดึงกลับ ทั้งสององค์ประกอบไม่ส่งอะไรด้วยตัวเอง ทั้งคู่ส่งต่อให้บล็อกช่องทาง ไม่ว่าจะเป็น push, ข้อความในแอป, อีเมล หรือ LINE สำหรับผู้ใช้ที่ปิดการแจ้งเตือนแอปไว้ ส่วนองค์ประกอบเข้า journey เป็นตัวตัดสินว่าใครอยู่ใน flow ตั้งแต่ต้น
event ที่เริ่ม session ยังพก key ที่ขั้นตอนถัดไปต้องใช้แยกออเดอร์หนึ่งจากอีกออเดอร์หนึ่งได้ ทั้งหมดนี้อยู่บนแคนวาส Customer Journey Builder เดียวกัน
Event และ Journey อยู่บนโครงสร้างพื้นฐานที่คุณระบุตัวตนได้
Event ทุกตัวที่องค์ประกอบ Trigger-based entry อ่าน วิ่งผ่านโครงสร้างพื้นฐานเดียวกับที่แพลตฟอร์มทั้งหมดใช้ Pushwoosh ได้รับการรับรอง ISO 27001:2022 และ SOC 2 Type I สอดคล้องกับ GDPR ทำงานบนฮาร์ดแวร์ของเราเองในสหรัฐอเมริกาและเยอรมนี ภายใต้ BDSG รายละเอียดทั้งหมดอยู่ที่หน้าความปลอดภัยของข้อมูล
วิธีการทำงาน
-
เพิ่มองค์ประกอบเข้า journey
บนแคนวาส เพิ่มองค์ประกอบ Trigger-based entry แล้วเลือก event: จะเป็น PW_* event ที่มีให้ตามค่าเริ่มต้น หรือ custom event ที่ส่งผ่าน SDK postEvent หรือเรียกจาก server ก็ได้
-
ตั้งเงื่อนไขและเป้าหมายการเข้า
เพิ่มเงื่อนไขบน attribute ของ event เพื่อคัดกรองการเข้า เช่น add_to_cart ที่ cart_value เกิน 50 และเลือกว่าให้คนที่ยิง event เองเข้า หรือให้ผู้ใช้ที่ระบุชื่อไว้ใน payload เข้าแทน
-
ตั้งค่า re-entry และ concurrency
ตัดสินใจว่าคนที่อยู่ใน journey อยู่แล้วยิง event ซ้ำได้อีกไหม และผู้ใช้หนึ่งคนถือหลาย session พร้อมกันได้หรือไม่ ผูกกับ attribute อย่าง order_id
เปลี่ยน event หนึ่งตัวให้กลายเป็น journey ที่ทำงานจริง
สำรวจผลิตภัณฑ์ที่เกี่ยวข้อง
วางแผนและปรับปรุงแคมเปญของคุณด้วยเครื่องมือภาพเดียว สื่อสาร ดึงดูด รักษา และแปลงกลุ่มเป้าหมาย รวมถึงการแบ่งส่วนและทดลองใช้กับ Pushwoosh Customer Journey Builder
เปิดใช้งาน campaign อัตโนมัติเมื่อผู้ใช้มีการกระทำ behavioral trigger ให้ผล conversion สูงกว่า scheduled campaign ถึง 3-5 เท่า
หยุดผู้ใช้ไว้สูงสุด 90 วัน แยกได้ถึง 3 สาขา สาขาละ 4 event ด้วย AND/OR มีสาขา Not triggered เสมอ พร้อม session-scoped matching สำหรับ order_id และ ride_id
หยุดพัก journey ด้วยระยะเวลาคงที่ เวลานาฬิกา วันที่ครั้งเดียว ช่วงเวลารายสัปดาห์ หรือระยะห่างที่นับจากวันที่ซึ่งบันทึกไว้ในโปรไฟล์ผู้ใช้อยู่แล้ว
เปลี่ยนตะกร้าสินค้าที่ถูกทิ้งให้เป็นรายได้ด้วยระบบอัตโนมัติในการกู้คืนตะกร้า ส่งการแจ้งเตือนทันท่วงที ข้อเสนอส่วนบุคคล และสิ่งจูงใจที่ช่วยเพิ่มอัตราการแปลง
ตรวจสอบว่า push, อีเมล, SMS, WhatsApp หรือ LINE เข้าถึงลูกค้าได้หรือไม่ ก่อนสลับไปช่องทางอื่นอัตโนมัติเมื่อช่องทางหลักปิดครับ