การใช้การแจ้งเตือนแบบพุชของ Braze เพื่อให้ผู้ใช้เริ่มต้นใช้งานจนสำเร็จ

Hand with a pen pointing at a printed wireframe of a permission pop-up with two buttons, one green, beside sticky notes and a plant, showing how a push primer is designed.

การแจ้งเตือนแบบ Push ของ Braze จะช่วยเรื่องการเริ่มต้นใช้งาน (Onboarding) ได้ก็ต่อเมื่อมีการออกแบบคำขออนุญาต ตัวกระตุ้น และแผนสำรองไปพร้อมๆ กัน โดยให้ขออนุญาตหลังจากผู้ใช้ทำกิจกรรมที่มีคุณค่าครั้งแรก ใช้ตัวช่วยแนะนำการแจ้งเตือน (Push Primer) แบบไม่ต้องเขียนโค้ด แยกเส้นทางสำหรับผู้ที่ปฏิเสธ และให้ผู้ใช้ออกจากขั้นตอนทันทีที่ทำภารกิจสำเร็จ

‍

ประเด็นสำคัญ

ขออนุญาตส่งการแจ้งเตือนแบบ Push ในช่วงเวลาที่ผู้ใช้ได้รับคุณค่าจากแอปจริงๆ โดยให้ทำภายในขั้นตอนการใช้งาน ไม่ใช่หลังจากจบขั้นตอนนั้นแล้ว
สร้างตัวช่วยแนะนำ (Primer) ด้วยปุ่ม "Request Push Permission" เพื่อให้ SDK ตรวจสอบสถานะของแต่ละอุปกรณ์
วางแผนรับมือกรณีที่ผู้ใช้ปฏิเสธ: iOS จะแสดงคำขอเพียงครั้งเดียวต่อการติดตั้งหนึ่งครั้ง ส่วน Android 13 ขึ้นไปจะบล็อกการแสดงคำขอหลังจากถูกปฏิเสธสองครั้ง
ให้ผู้ใช้ออกจากขั้นตอนเมื่อทำกิจกรรมสำเร็จ และวางการแจ้งเตือนแบบสะกิด (Nudge) ไว้หลังขั้นตอนการหน่วงเวลา (Delay)
ส่งการแจ้งเตือนแบบสะกิด (Nudge) ไปยังผู้ใช้ที่ไม่สามารถรับการแจ้งเตือนแบบ Push ได้ ผ่านทางข้อความในแอป (In-app message) หรืออีเมลแทน
เปรียบเทียบสิ่งที่เหมือนกัน: ผู้ใช้ที่ยอมรับตัวช่วยแนะนำ (Primer) มักจะมีแนวโน้มที่จะทำขั้นตอนจนจบอยู่แล้ว

‍

การแจ้งเตือนแบบ Push ของ Braze มีบทบาทอย่างไรในการเริ่มต้นใช้งาน (Onboarding)?

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

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

‍

คุณควรขออนุญาตส่งการแจ้งเตือนแบบ Push ตอนไหนระหว่างการเริ่มต้นใช้งาน?

Braze แนะนำให้รอจนกว่าผู้ใช้จะทำกิจกรรมที่มีคุณค่าบางอย่างสำเร็จ ซึ่งเป็นสัญญาณว่าพวกเขาเริ่มเห็นประโยชน์ของแอปคุณแล้ว เอกสารสำหรับนักพัฒนาของ Android ก็แนะนำเช่นเดียวกันว่า ควรให้ผู้ใช้ทำความคุ้นเคยกับแอปก่อนที่จะขออนุญาตใดๆ

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

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

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

‍

คุณจะสร้างตัวช่วยแนะนำการแจ้งเตือน (Push Primer) ใน Braze ได้อย่างไร?

Push Primer คือข้อความในแอปที่อธิบายว่าผู้ใช้จะได้รับอะไรบ้าง โดยจะปรากฏขึ้นก่อนที่ระบบปฏิบัติการจะแสดงคำขอของตัวเอง คุณสามารถสร้างได้โดยไม่ต้องเขียนโค้ด เพียงใช้พฤติกรรมการคลิกปุ่ม "Request Push Permission" ในข้อความในแอปสำหรับ iOS, Android หรือเว็บ

ขั้นตอนด้านล่างนี้เป็นไปตามเอกสารของ Braze

สร้างข้อความในแอปแบบเต็มหน้าจอหรือแบบ Modal เพื่อให้มีพื้นที่เพียงพอสำหรับเนื้อหาและปุ่มทั้งสองปุ่ม
เขียนเนื้อหาให้ชัดเจนว่าคุณจะส่งการแจ้งเตือนประเภทใด และการแจ้งเตือนเหล่านั้นมีประโยชน์อย่างไรต่อผู้ใช้
เพิ่มปุ่มสองปุ่ม โดย Braze แนะนำให้ใช้ "อนุญาตการแจ้งเตือน" และ "ไว้คราวหน้า" เป็นค่าเริ่มต้น ตั้งค่าปุ่มแรกเป็น "ขอสิทธิ์การแจ้งเตือนแบบพุช" และปุ่มที่สองเป็น "ปิดข้อความ"
กำหนดเวลาส่งข้อความแบบอิงตามการกระทำ (action-based) โดยใช้ Perform Custom Event เป็นตัวกระตุ้น และให้ส่งเหตุการณ์นั้นในช่วงเวลาที่ผู้ใช้ได้รับคุณค่าจากแอปเป็นครั้งแรก
ขอให้ทีมพัฒนาของคุณลบโค้ดเดิมที่ใช้ขอสิทธิ์การแจ้งเตือนแบบพุชออก เพื่อให้ข้อความแนะนำ (primer) เป็นหน้าต่างแรกที่ผู้ใช้เห็น

‍

พฤติกรรมของปุ่มจำเป็นต้องใช้ SDK เวอร์ชันขั้นต่ำในแต่ละแพลตฟอร์ม

แพลตฟอร์มเวอร์ชัน SDK ขั้นต่ำสำหรับพฤติกรรมของปุ่มSwift5.4.0Web4.0.3Android21.0.0

‍

การกำหนดกลุ่มเป้าหมายเป็นจุดที่ครัวเรือนที่ใช้หลายอุปกรณ์อาจก่อให้เกิดปัญหาได้ เนื่องจาก Braze เก็บข้อมูลในระดับโปรไฟล์ไม่ใช่ระดับอุปกรณ์ ตัวกรองอย่าง Push Subscription Status ที่ไม่ใช่ Opted In จะกีดกันผู้ใช้ที่เลือกรับการแจ้งเตือนบนอุปกรณ์อื่นออกไป ทำให้โทรศัพท์เครื่องใหม่ของพวกเขาไม่ได้รับข้อความแนะนำเลย

วิธีแก้ไขที่แนะนำคือการใช้ข้อความแนะนำแบบไม่ต้องเขียนโค้ด (no-code primer) โดยไม่ต้องใส่ตัวกรองสถานะการแจ้งเตือนเพิ่มเติม เพราะ SDK จะตรวจสอบที่อุปกรณ์นั้นโดยเฉพาะ หากคุณสร้างตรรกะหรือ Deep Link ขึ้นมาเอง SDK จะไม่สามารถจดจำข้อความแนะนำได้และจะแสดงข้อความนั้นกับทุกอุปกรณ์ ในกรณีนี้ ให้ใช้ตัวกรอง Foreground Push Enabled For App เป็น false แทน

หากบันทึกของอุปกรณ์และโปรไฟล์ไม่ตรงกันในระบบโดยรวมของคุณ หน้า การจัดการข้อมูลลูกค้า ของเราจะครอบคลุมเรื่องการจับคู่อุปกรณ์และการลบข้อมูลซ้ำ

‍

จะเกิดอะไรขึ้นในแต่ละแพลตฟอร์มเมื่อมีคนปฏิเสธ?

วางแผนสำหรับกรณีที่ผู้ใช้ปฏิเสธก่อนที่คุณจะออกแบบกรณีที่ผู้ใช้ตอบรับ ระบบปฏิบัติการจะเป็นผู้บังคับใช้หน้าต่างแจ้งเตือน ดังนั้นกฎจึงแตกต่างกันไปตามแพลตฟอร์ม เส้นทางประสบการณ์ผู้ใช้ (journey) ของคุณต้องรองรับทุกกรณีเหล่านี้

แพลตฟอร์มและสถานะข้อความแนะนำแสดงหรือไม่?สิ่งที่เส้นทางประสบการณ์ผู้ใช้ควรทำiOS, ผู้ใช้ยังไม่ได้ตอบสนองใช่แสดงข้อความแนะนำในช่วงเวลาที่ผู้ใช้ได้รับคุณค่าครั้งแรกiOS, ผู้ใช้ปฏิเสธไม่ iOS อนุญาตให้แสดงหน้าต่างแจ้งเตือนของระบบได้เพียงครั้งเดียวให้เปลี่ยนไปใช้ข้อความในแอปหรืออีเมล และเสนอช่องทางไปสู่การตั้งค่าอุปกรณ์Android 13 ขึ้นไป, ปฏิเสธสองครั้งไม่ Android จะบล็อกการแจ้งเตือนเพิ่มเติมเหมือนกับกรณี iOS ปฏิเสธAndroid 12 และก่อนหน้าไม่แนะนำ เนื่องจากระบบจะเลือกรับการแจ้งเตือนโดยอัตโนมัติให้ข้ามข้อความแนะนำและส่งการแจ้งเตือนแบบพุชโดยตรงWeb, ปฏิเสธสิทธิ์ไม่ ไม่สามารถกู้คืนสถานะนี้ได้ในเบราว์เซอร์ให้ใช้อีเมลหรือข้อความในแอปเท่านั้น

‍

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

บน iOS อุปกรณ์ที่ได้รับสิทธิ์แบบชั่วคราว (provisional authorisation) ยังคงมีสิทธิ์ได้รับข้อความแนะนำและได้รับโทเค็นการแจ้งเตือนแบบพุชในเบื้องหน้า หากคุณใช้สิทธิ์แบบชั่วคราวร่วมกับข้อความแนะนำ Braze แนะนำให้ติดต่อตัวแทนของ Braze เพื่อขอคำแนะนำเพิ่มเติม

หากการตั้งค่าการแจ้งเตือนของแอปถูกปิด Braze ระบุว่าคุณต้องนำผู้ใช้ไปยังการตั้งค่าการแจ้งเตือนในตัวเครื่อง การใช้ข้อความแจ้งเตือนแบบนุ่มนวล (soft prompt) บนเว็บมีความสำคัญด้วยเหตุผลเดียวกัน เนื่องจากเบราว์เซอร์จะจำกัดความถี่ในการแสดงหน้าต่างแจ้งเตือน และการปฏิเสธสิทธิ์ไม่สามารถแก้ไขได้จากฝั่งของคุณ

‍

Canvas สำหรับการต้อนรับผู้ใช้ใหม่ (onboarding) ควรจัดการกับผู้ใช้ที่รับการแจ้งเตือนและผู้ใช้อื่นๆ อย่างไร?

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

จากนั้นกำหนดเกณฑ์การออกจากเส้นทาง (exit criteria) ให้เป็นเหตุการณ์ที่ทำสำเร็จ เมื่อผู้ใช้ทำเหตุการณ์นั้น Braze จะทำเครื่องหมายให้พวกเขาออกจากเส้นทางทันที และพวกเขาจะไม่ไปยังขั้นตอนถัดไป การหน่วงเวลา (delay) มีข้อควรระวังคือ ผู้ใช้ที่อยู่ในขั้นตอนการหน่วงเวลาจะยังคงอยู่ที่นั่นจนกว่าเวลาจะสิ้นสุดลง

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

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

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

‍

การแจ้งเตือนแบบพุชในช่วงเริ่มต้นใช้งาน (onboarding) ควรมีเนื้อหาอย่างไร?

Braze แนะนำให้รักษาความยาวของหัวข้อและเนื้อหาแต่ละบรรทัดไว้ที่ประมาณ 30-40 ตัวอักษร และแนะนำให้ทำให้การแจ้งเตือนแบบพุชนั้นสามารถดำเนินการต่อได้และมีประโยชน์โดยใช้ตัวอักษรไม่เกิน 40 ตัว ควรทดสอบบนอุปกรณ์จริงก่อนส่งเสมอ เนื่องจากการแสดงผลสุดท้ายของการปรับแต่งด้วย Liquid จะแตกต่างกันไปในผู้ใช้แต่ละราย

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

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

มีประเด็นด้านนโยบายสองประการที่ต้องพิจารณาควบคู่กัน หน้าแนวปฏิบัติที่ดีที่สุดสำหรับการแจ้งเตือนแบบพุชของ Braze ได้อ้างถึงนโยบาย App Store ของ Apple ซึ่งระบุว่าแอปไม่ควรบังคับให้ต้องเปิดการแจ้งเตือนแบบพุชเพื่อให้แอปทำงานได้ นอกจากนี้ หน้าดังกล่าวยังอ้างถึงกฎที่ห้ามใช้การแจ้งเตือนแบบพุชเพื่อการส่งเสริมการขายหรือการตลาดทางตรงโดยไม่ได้รับความยินยอมอย่างชัดเจนจากผู้ใช้ภายในแอปของคุณ

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

‍

สิ่งนี้จะมีหน้าตาเป็นอย่างไรสำหรับแอปสมมติ?

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

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

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

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

‍

อะไรที่อาจผิดพลาด และคุณจะตรวจพบได้อย่างไร?

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

ความล้มเหลวลักษณะที่ปรากฏวิธีแก้ไขการแจ้งเตือนซ้ำซ้อน (Double prompt)ข้อความแจ้งเตือนของระบบปรากฏขึ้นก่อนข้อความแจ้งเตือนเบื้องต้นของคุณ ทำให้ข้อความแจ้งเตือนเบื้องต้นไม่มีอะไรให้ถามอีกต่อไปลบโค้ดการขออนุญาตแบบเก่าออกเพื่อให้ข้อความแจ้งเตือนเบื้องต้นแสดงเป็นอันดับแรกข้อความแจ้งเตือนเบื้องต้นแบบลิงก์กำหนดเอง (Custom-link)มีการใช้ Deep link หรือตรรกะกำหนดเองแทนปุ่ม ทำให้ข้อความแสดงบนทุกอุปกรณ์ใช้การกระทำของปุ่ม "Request Push Permission"ตัวกรองระดับผู้ใช้ผู้ใช้ที่มีอุปกรณ์เครื่องที่สองจะไม่เห็นข้อความแจ้งเตือนเบื้องต้นบนอุปกรณ์เครื่องใหม่ยกเลิกตัวกรองสถานะการแจ้งเตือนแบบพุช หรือใช้ตัวกรองระดับอุปกรณ์แทนการอ่านสถานะการสมัครรับข้อมูลว่าเป็นความสามารถในการเข้าถึงจำนวนกลุ่มเป้าหมายดูปกติแต่การแจ้งเตือนแบบพุชเข้าถึงผู้คนน้อยลงตรวจสอบการเปิดใช้งานการแจ้งเตือนแบบพุชในเบื้องหน้า ไม่ใช่แค่สถานะการสมัครรับข้อมูลเพียงอย่างเดียวหน้าต่างการแปลงผล (Conversion window) สั้นเกินไปการทำรายการเสร็จสิ้นที่ล่าช้าจะอยู่นอกหน้าต่างเวลาและไม่ถูกนับรวมใน CanvasBraze แนะนำให้ตั้งค่าหน้าต่างการแปลงผลให้ครอบคลุมอย่างน้อยเท่ากับเส้นทางที่ยาวที่สุดใน Canvas

‍

ผู้ใช้ที่ปฏิเสธการแจ้งเตือนที่ระดับระบบปฏิบัติการจะยังคงมีสถานะสมัครรับข้อมูล (Subscribed) อยู่ แต่ในโปรไฟล์จะไม่มีโทเค็นการแจ้งเตือนแบบพุชในเบื้องหน้า Braze จะไม่เปลี่ยนสถานะการสมัครรับข้อมูลแบบพุชของผู้ใช้เป็นยกเลิกการสมัคร (Unsubscribed) โดยอัตโนมัติเมื่อพวกเขาปฏิเสธที่ระดับระบบปฏิบัติการ ดังนั้นโปรไฟล์อาจแสดงว่าสมัครรับข้อมูลอยู่ ในขณะที่อุปกรณ์ระบุว่าไม่ได้รับ

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

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

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

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

‍

สิ่งนี้เชื่อมโยงกับส่วนที่เหลือของโปรแกรมอย่างไร?

การแจ้งเตือนแบบ Push เป็นเพียงช่องทางหนึ่งในการสร้างกระบวนการต้อนรับผู้ใช้งาน (Onboarding) ภาพรวมของเราเกี่ยวกับ แคมเปญต้อนรับผู้ใช้งานที่ผ่านการพิสูจน์แล้ว 10 รูปแบบ จะแสดงให้เห็นว่าการกระตุ้น (Nudge) มีบทบาทอย่างไรท่ามกลางข้อความอื่นๆ ส่วนคำแนะนำเกี่ยวกับ การทำระบบต้อนรับผู้ใช้งานอัตโนมัติด้วย Canvas จะครอบคลุมรายละเอียดเกี่ยวกับการตั้งค่าจุดเริ่มต้นและจุดสิ้นสุดของเส้นทางผู้ใช้งาน

ทั้งเหตุการณ์ที่แสดงถึงความสำเร็จ (Completing event) และเหตุการณ์ที่แสดงถึงคุณค่าแรกที่ได้รับ (First-value event) ต่างก็ขึ้นอยู่กับ การติดตามเหตุการณ์ของผู้ใช้งาน อย่างถูกต้อง ตัวข้อความแนะนำเบื้องต้น (Primer) เองก็เป็นข้อความในแอป ดังนั้นคู่มือของเราเกี่ยวกับ ตัวกระตุ้นข้อความในแอป จึงสามารถนำไปปรับใช้ได้โดยตรง

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

ในฐานะพันธมิตรด้านการติดตั้งใช้งาน Braze ทาง CustomerIK แนะนำให้มองว่าการขออนุญาตส่ง Push เป็นช่วงเวลาสำคัญของผลิตภัณฑ์ ไม่ใช่แค่การตั้งค่าทางเทคนิค คุณควรตกลงเรื่องเหตุการณ์ที่แสดงถึงคุณค่าแรกที่ได้รับกับทีมผลิตภัณฑ์ สร้างข้อความแนะนำเบื้องต้นแบบไม่ต้องเขียนโค้ด (No-code) บนเหตุการณ์นั้น และมอบการกระตุ้นในรูปแบบที่เทียบเท่ากันผ่านช่องทางอื่นให้กับผู้ใช้งานทุกคนที่ไม่สามารถรับการแจ้งเตือนแบบ Push ได้

‍

คำถามที่พบบ่อย
‍

1. ฉันควรขออนุญาตส่ง Push ตั้งแต่การเปิดใช้งานครั้งแรกเลยหรือไม่?

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

2. ฉันสามารถแสดงข้อความแนะนำเบื้องต้นอีกครั้งได้หรือไม่ หากผู้ใช้งานปฏิเสธบน iOS?

ไม่สามารถทำได้ผ่านข้อความแนะนำเบื้องต้น เอกสารของ Braze ระบุว่า iOS จะไม่แสดงหน้าต่างแจ้งเตือนแบบเนทีฟซ้ำสำหรับการติดตั้งแอปนั้นๆ SDK จะระงับการแสดงข้อความแนะนำเบื้องต้นสำหรับอุปกรณ์ที่ปฏิเสธไปแล้ว ดังนั้นวิธีเดียวที่จะกลับไปเปิดใช้งานได้คือการตั้งค่าในตัวเครื่องเท่านั้น

3. จำเป็นต้องใช้การแจ้งเตือนแบบ Primer สำหรับ Android 12 และเวอร์ชันก่อนหน้าหรือไม่?

Braze ไม่แนะนำให้ใช้ เนื่องจากระบบจะเปิดรับการแจ้งเตือนแบบ Push ไว้เป็นค่าเริ่มต้นในเวอร์ชันดังกล่าวอยู่แล้ว แต่สำหรับ Android 13 ขึ้นไป จำเป็นต้องได้รับอนุญาตก่อนจึงจะแสดงการแจ้งเตือนได้

4. สถานะการสมัครรับการแจ้งเตือนแบบ Push เหมือนกับการที่ผู้ใช้สามารถรับการแจ้งเตือนได้จริงหรือไม่?

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

5. การแจ้งเตือนแบบ Push เพื่อแนะนำการใช้งาน (Onboarding) ควรมีความยาวเท่าใด?

Braze แนะนำให้ใช้ความยาวประมาณ 30-40 ตัวอักษรต่อบรรทัดสำหรับหัวข้อและเนื้อหา และแนะนำให้ข้อความที่ต้องการให้ผู้ใช้กดดำเนินการมีความยาวไม่เกิน 40 ตัวอักษร

‍

แหล่งข้อมูล

Braze,ข้อความในแอปสำหรับแจ้งเตือนแบบ Push Primerสืบค้นเมื่อ 14 ต.ค. 2026
Braze,การแจ้งเตือนแบบ Soft Push สำหรับเว็บสืบค้นเมื่อ 14 ต.ค. 2026
Braze,แนวปฏิบัติที่ดีที่สุดสำหรับการแจ้งเตือนแบบ Pushสืบค้นเมื่อ 14 ต.ค. 2026
Braze,การเปิดใช้งานการแจ้งเตือนแบบพุชและการสมัครรับข้อมูลสืบค้นเมื่อ 14 ต.ค. 2026
Braze,เกณฑ์การออกจากระบบสืบค้นเมื่อ 14 ต.ค. 2026
Braze,การจับคู่เกณฑ์การออกจาก Canvas กับเหตุการณ์เริ่มต้น (Entry events)สืบค้นเมื่อ 14 ต.ค. 2026
Braze,ประเภทการส่งและการเข้าถึงสืบค้นเมื่อ 14 ต.ค. 2026
นักพัฒนา Android, การอนุญาตให้แจ้งเตือนขณะใช้งานแอป (Runtime permission)สืบค้นเมื่อ 14 ต.ค. 2026
เขียนโดย CustomerIK พันธมิตรด้านการติดตั้งใช้งาน Braze

‍

CustomerIK คือพันธมิตรด้านการติดตั้งใช้งาน Braze ที่เชี่ยวชาญทั้งในด้านการเริ่มต้นใช้งาน การเชื่อมต่อทางเทคนิค การดำเนินงานด้านการตลาด และการจัดการข้อมูลลูกค้า

หากขั้นตอนการเริ่มต้นใช้งาน (onboarding) ของคุณยังมีช่วงเวลาที่ต้องขออนุญาตผู้ใช้ซึ่งคุณยังไม่ได้ออกแบบไว้ มาคุยกับเราสิ

‍