กลยุทธ์การแจ้งเตือนแบบ Push เพื่อสร้างการมีส่วนร่วมกับลูกค้าใน Braze

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

‍

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

• การแจ้งเตือนขออนุญาตจากระบบ (Native push prompt) สามารถแสดงได้เพียงครั้งเดียวต่อการติดตั้งหนึ่งครั้ง ดังนั้นข้อความแนะนำ (Primer) จึงมีความสำคัญอย่างยิ่งในการโน้มน้าวให้ผู้ใช้กดตกลง
• ข้อความแนะนำแบบไม่ต้องเขียนโค้ด (No-code primer) จะระงับการแสดงผลด้วยตัวเองตามสถานะของอุปกรณ์ คุณจึงไม่จำเป็นต้องเพิ่มตัวกรองสถานะ Push เพิ่มเติม
• Braze จะตรวจสอบกฎการจำกัดความถี่ก่อนช่วงเวลาห้ามรบกวน และหากผู้ใช้ติดกฎการจำกัดความถี่ ระบบจะข้ามการส่งข้อความนั้นไปเลยแทนที่จะพักไว้
• เหตุการณ์การแปลงค่า (Conversion events) สามารถนับได้สูงสุด 30 วัน และการกำหนดเส้นตายที่ชัดเจนจะช่วยให้ได้ผลลัพธ์ที่เปรียบเทียบกันได้
• นโยบายการคัดกรองผู้ใช้ (Sunset policy) จะหยุดส่งข้อความ Push ไปยังผู้ใช้ที่ไม่มีการเปิดอ่านโดยตรงหรือผ่านการกระตุ้น และเปลี่ยนไปส่งผ่านอีเมลหรือข้อความในแอปแทน
• เราแนะนำให้ตั้งกฎการควบคุมความถี่และกฎการคัดกรองผู้ใช้ก่อนที่จะเริ่มแคมเปญแรก

‍

กลยุทธ์การแจ้งเตือนแบบ Push ของ Braze ควรเริ่มจากอะไรก่อน?

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

ขั้นตอนกลยุทธ์สิ่งที่เอกสารของ Braze ระบุไว้1. การขออนุญาตข้อความแนะนำ (Push primer) ในแอปแจ้งเตือนขออนุญาตจากระบบแสดงได้เพียงครั้งเดียวต่อการติดตั้ง2. การเข้าถึงการควบคุมการสมัครรับข้อมูลในแอปการยกเลิกรับข้อมูลในระดับอุปกรณ์จะลบโทเค็น Push ในเบื้องหน้า3. การควบคุมความถี่กฎจำกัดความถี่และช่วงเวลาห้ามรบกวนสูงสุด 10 กฎต่อหนึ่ง Workspace4. การวัดผลเหตุการณ์การแปลงค่ากรอบเวลาสูงสุด 30 วัน5. การคัดกรองผู้ใช้นโยบาย Sunsetหยุดส่งข้อความถึงผู้ใช้ที่ไม่มีการเปิดอ่านโดยตรงหรือผ่านการกระตุ้น

‍

เราแนะนำให้สร้างขั้นตอนที่ 3 และ 5 ก่อนที่จะเริ่มแคมเปญแรก เพราะการตั้งค่าตั้งแต่เนิ่นๆ จะประหยัดต้นทุนกว่าการต้องมาแก้ไขภายหลังเมื่อโปรแกรมเริ่มใช้งานจริงแล้ว

‍

คุณควรขออนุญาตส่ง Push อย่างไร?

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

ระบบปฏิบัติการเป็นผู้บังคับใช้ขีดจำกัดนี้: หน้าต่างขออนุญาตจากระบบสามารถแสดงได้เพียงครั้งเดียวต่อการติดตั้งหนึ่งครั้ง เอกสารของ Google เกี่ยวกับ Android ระบุว่า Android 13 (API level 33) ขึ้นไปรองรับการขออนุญาตขณะใช้งานสำหรับการส่งการแจ้งเตือนที่ไม่ได้รับการยกเว้นจากแอป Braze ระบุว่าหากมีการปฏิเสธสองครั้งบน Android 13 ขึ้นไป ระบบจะบล็อกการแสดงหน้าต่างขออนุญาตในอนาคต รวมถึงข้อความแนะนำของ Braze ด้วย

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

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

‍

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

ด้วยระบบข้อความแนะนำแบบไม่ต้องเขียนโค้ด (No-code primer) SDK จะตรวจสอบสถานะสิทธิ์ของอุปกรณ์นั้นๆ โดยตรง และจะระงับข้อความไว้ให้โดยอัตโนมัติ คุณจึงไม่จำเป็นต้องเพิ่มตัวกรองสถานะ Push

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

‍

คุณจะรักษาฐานผู้ใช้ที่กดอนุญาตให้รับการแจ้งเตือนไว้ได้อย่างไรหลังจากที่พวกเขาตอบตกลงแล้ว?

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

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

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

‍

ความถี่ในการส่งข้อความระดับไหนที่ถือว่ามากเกินไป?

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

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

แคมเปญผ่าน API สามารถข้ามการจำกัดความถี่ได้โดยการตั้งค่า override_frequency_capping เป็น true โดยค่าเริ่มต้น แคมเปญที่ไม่ปฏิบัติตามกฎการจำกัดความถี่จะไม่ถูกนำไปนับรวมในโควตาการจำกัดความถี่ด้วย

หากคุณใช้การจำกัดอัตราการส่ง (Rate limiting) ร่วมด้วย Braze จะใช้การจำกัดอัตราการส่งก่อน แล้วจึงใช้การจำกัดความถี่ตามมา โดยระบบจะไม่ส่งข้อความย้อนหลังให้ผู้ใช้ที่ถูกคัดออกจากการจำกัดความถี่ ในตัวอย่างที่ระบุไว้ หากมีการจำกัดอัตราการส่งไว้ที่ 500 และมีผู้ใช้ 200 คนที่ถูกจำกัดความถี่ ระบบจะส่งข้อความออกไปทั้งหมด 300 ข้อความ

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

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

‍

การตั้งค่าการส่งแบบใดบ้างที่มีผลต่อวิธีการที่ข้อความ Push ไปถึงอุปกรณ์?

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

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

สำหรับ Android ลำดับความสำคัญในการส่ง (Delivery priority) เป็นตัวเลือกในระดับแคมเปญ โดยระดับ Normal เหมาะสำหรับการซิงค์ข้อมูลเบื้องหลังและอาจมีความล่าช้าเพื่อประหยัดแบตเตอรี่ ในขณะที่ระดับ High เหมาะสำหรับการแจ้งเตือนและการแจ้งเตือนที่เน้นความรวดเร็ว

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

‍

คุณจะวัดผลได้อย่างไรว่ากลยุทธ์ที่ใช้ได้ผลหรือไม่?

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

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

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

เราแนะนำให้กำหนดตัวชี้วัดแยกกันในแต่ละขั้นตอน แทนที่จะใช้อัตราการเปิดข้อความแบบรวม โดยให้ติดตามอัตราการอนุญาต (Grant rate) สำหรับขั้นตอนการแจ้งเตือน (Primer), การสูญเสีย Token สำหรับการควบคุมการเข้าถึง และ Conversion สำหรับกลยุทธ์ข้อความ

‍

เมื่อใดที่คุณควรหยุดส่งข้อความ Push ให้กับใครบางคน?

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

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

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

‍

กลยุทธ์เหล่านี้อาจเกิดข้อผิดพลาดที่จุดไหนได้บ้าง?

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

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

‍

ตัวอย่างการใช้งานจริงเป็นอย่างไร?

ลองจินตนาการถึงร้านค้าปลีกสมมติที่เปิดตัวแอปในตลาดใหม่ โดยมีการตั้งเวลาส่งข้อความแจ้งเตือน (Push primer) เป็นข้อความในแอปแบบอิงตามการกระทำ (Action-based) ซึ่งจะถูกกระตุ้นเมื่อมีการสั่งซื้อครั้งแรกสำเร็จ โดยข้อความแจ้งเตือนนี้จะเสนอการติดตามสถานะการจัดส่งเป็นเหตุผลให้ผู้ใช้ตอบตกลงรับการแจ้งเตือน

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

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

‍

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

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

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

ในฐานะพันธมิตรด้านการติดตั้งใช้งาน Braze ทาง CustomerIK แนะนำให้ตั้งค่ากฎการควบคุมความถี่และกฎการออกจากระบบก่อนที่จะเริ่มแคมเปญแรก โดยควรตรวจสอบกฎเหล่านี้ทุกไตรมาสเทียบกับข้อจำกัดที่ระบุไว้ในเอกสารประกอบของ Braze

‍

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

1. การแจ้งเตือนแบบพุชเบื้องต้น (push primer) จะมาแทนที่การขออนุญาตแบบเนทีฟของระบบหรือไม่?

ไม่แทนที่ โดยข้อความเบื้องต้นจะปรากฏขึ้นก่อน และปุ่ม "ขออนุญาตส่งการแจ้งเตือน" จะเป็นตัวเรียกการขออนุญาตแบบเนทีฟของระบบขึ้นมาอีกครั้ง

2. ข้อความที่ถูกยกเลิก (aborted messages) นับรวมในขีดจำกัดความถี่ (frequency caps) หรือไม่?

ไม่นับรวม Braze ระบุไว้ว่าข้อความที่ถูกยกเลิกจะไม่ถูกนำมานับรวมในขีดจำกัดความถี่

3. Braze จะพักข้อความที่ติดขีดจำกัดไว้จนกว่าจะพ้นช่วงเวลาห้ามรบกวน (quiet hours) หรือไม่?

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

4. ขนาดของ Push Payload ใหญ่ได้แค่ไหน?

Braze ระบุขนาดสูงสุดของ Payload ไว้ที่ 3,807 ไบต์ และแนะนำให้รักษาขนาดไว้ที่หลักร้อยไบต์เท่านั้น เนื่องจาก Liquid จะแสดงผลตามผู้ใช้แต่ละราย คุณจึงควรทดสอบบนอุปกรณ์จริง

5. กฎของ App Store มีผลต่อการส่ง Push เพื่อโปรโมชันหรือไม่?

แนวทางปฏิบัติในการตรวจสอบแอป (App Review Guidelines) ของ Apple ในส่วนที่ 4.5.4 มีข้อจำกัดเกี่ยวกับการใช้ Push เพื่อการส่งเสริมการขายและการตลาดทางตรง ไม่ควรใช้ Push เพื่อวัตถุประสงค์ดังกล่าวเว้นแต่ลูกค้าจะยินยอมอย่างชัดเจนผ่านข้อความขอความยินยอมที่แสดงใน UI ของแอปและสามารถเลือกยกเลิกได้ในแอป บทความนี้ไม่ได้เป็นการยืนยันว่าโปรแกรมของคุณเป็นไปตามกฎดังกล่าวหรือกฎหมายใดๆ

‍

แหล่งข้อมูล

• Braze,แนวปฏิบัติที่ดีที่สุดสำหรับการแจ้งเตือนแบบ Pushสืบค้นเมื่อ 25 ต.ค. 2026
• Braze,ข้อความในแอปสำหรับแจ้งเตือนแบบ Push Primerสืบค้นเมื่อ 25 ต.ค. 2026
• Braze,สร้างข้อความ Pushสืบค้นเมื่อ 25 ต.ค. 2026
• Braze,การจำกัดอัตราและการจำกัดความถี่ (Rate limiting and frequency capping)สืบค้นเมื่อ 25 ต.ค. 2026
• Braze,ช่วงเวลาห้ามรบกวน (Quiet hours)สืบค้นเมื่อ 25 ต.ค. 2026
• Braze,บันทึกประจำรุ่นสืบค้นเมื่อ 25 ต.ค. 2026
• Google, การอนุญาตให้แจ้งเตือนขณะใช้งานแอป (Runtime permission) (2026). สืบค้นเมื่อ 25 ต.ค. 2026
• Apple, แนวทางปฏิบัติในการตรวจสอบแอป (App Review Guidelines)สืบค้นเมื่อ 25 ต.ค. 2026
• บทความนี้อ้างอิงข้อมูลจากเอกสารของ Braze ณ วันที่ 25 ต.ค. 2026 ข้อจำกัด ค่าเริ่มต้น และสถานะการเปิดตัวอาจมีการเปลี่ยนแปลงได้ โปรดตรวจสอบหน้าข้อมูลปัจจุบันก่อนดำเนินการใดๆ
• เขียนโดย CustomerIK พันธมิตรด้านการติดตั้งใช้งาน Braze

‍

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

หากคุณกำลังวางแผนโปรแกรม Push และต้องการจัดลำดับการขออนุญาต การกระตุ้น และกฎการเลิกใช้งานให้ถูกต้อง มาคุยกันได้เลย

‍