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

ทำไมคนถึงปิดการแจ้งเตือนแบบพุช

การแจ้งเตือนที่น่ารำคาญเหมือน有人มาตะปบไหล่คุณทั้งวัน แล้วแปลกใจที่คุณเดินจากไป พวกมันขัดจังหวะ เรียกร้องความสนใจ และบ่อยครั้งให้สิ่งตอบแทนน้อย หลังจากไม่กี่วันคนก็มักทำสิ่งที่ง่ายที่สุด: ปิดเสียงคุณ

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

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

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

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

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

ถ้าคุณปฏิบัติต่อพุชเหมือนเป็นสิทธิพิเศษ ผู้ใช้จะมองเป็นประโยชน์ ถ้าคุณปฏิบัติต่อมันเหมือนพื้นที่โฆษณาฟรี ผู้ใช้จะมองเป็นสแปม

อะไรทำให้คนยอมกดอนุญาต

คนกด "Allow" เมื่อพวกเขาเชื่อว่าการแจ้งเตือนจะช่วยพวกเขา ไม่ใช่ช่วยแอป วิธีที่ง่ายที่สุดคือมองการอนุญาตเป็นการแลกเปลี่ยนค่า: คุณสัญญาอะไรที่ชัดเจน แล้วส่งมอบอย่างต่อเนื่อง

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

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

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

ตั้งความคาดหวังตั้งแต่ต้น แม้มันจะดูไม่ชวนขายนัก หากคุณส่งห้าข้อความต่อสัปดาห์ ให้บอก ถ้าเป็นแบบทริกเกอร์เท่านั้น (เช่น อัปเดตการจัดส่ง) ก็บอกด้วย ความประหลาดใจสร้างความไม่ไว้ใจ และความไม่ไว้ใจแปรเป็นการปิด

แสดงตัวอย่างคุณค่าย่อยๆ ก่อนพรอมต์ระบบ หนึ่งตัวอย่างที่สมจริงอาจทำได้มากกว่าหนึ่งย่อหน้าของคำพูด:

"ตัวอย่างการแจ้งเตือน: พัสดุของคุณกำลังส่งออกเพื่อจัดส่ง - คาดว่าจะมาถึงระหว่าง 15:10 ถึง 15:40 น."

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

จังหวะเวลาในการขออนุญาตที่เป็นธรรมชาติ

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

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

รูปแบบที่เชื่อถือได้คือหน้าขอแบบอ่อนก่อนพรอมต์ของระบบ ทำให้สั้นและเจาะจง: จะได้รับอะไร ความถี่ และทำไมมันช่วย แล้วใส่ปุ่มสองปุ่มชัดเจน: "Allow notifications" และ "Not now." แค่แสดงพรอมต์ระบบเมื่อพวกเขาเลือก "Allow" วิธีนี้ลดความประหลาดใจและตั้งความคาดหวังได้

ช่วงเวลาที่เหมาะมักอยู่หลังชัยชนะ (สั่งซื้อเสร็จ บรรลุเป้า) หลังจากติดตามหรือสมัคร หลังจากบันทึกหรือบุ๊กมาร์ก หลังจากตั้งเตือนหรือเริ่มติดตามบางอย่าง หรือหลังจากเปิดฟีเจอร์ที่ต้องการอัปเดต

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

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

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

ออกแบบศูนย์การตั้งค่าการแจ้งเตือน

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

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

ควบคุมที่ควรรวม (และวิธีตั้งชื่อ)

เก็บตัวเลือกให้สั้นและชัด หากคุณเสนอ 20 สวิตช์ ผู้คนจะไม่จัดการ พวกเขาจะปิดคุณ

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

ค่าเริ่มต้นสำคัญ ตั้งให้ช่วยได้แต่ไม่ก้าวร้าว ค่าเริ่มต้นปลอดภัยในหลายผลิตภัณฑ์คือ: แจ้งเตือนสำคัญเปิด (ความปลอดภัยหรือสถานะธุรกรรม), การแจ้งการตลาดปิด, และตั้งความถี่เป็นย่อหน้าเมื่อเหมาะสม ถ้าทุกอย่างเปิดโดยดีฟอลต์ คุณกำลังสร้างความเหนื่อยหน่ายตั้งแต่วันแรก

วางไว้ที่ไหน

อย่าซ่อนการตั้งค่าไว้ในเมนูลึกๆ วางไว้ที่คนมองหาเมื่อต้องการ

หลังการกระทำสำคัญ ให้เสนอพรอมต์เล็กๆ เช่น: "ต้องการอัปเดตเกี่ยวกับสิ่งนี้ไหม?" แล้วพาไปที่การเลือกหัวข้อและความถี่ทันที หลังคนสั่งซื้อ เช่น ให้พวกเขาเปิด "สถานะคำสั่ง" เป็นพุช โดยปล่อย "โปรโมชั่น" ปิด

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

ถ้าคุณสร้างผลิตภัณฑ์ด้วย Koder.ai ให้ถือว่าศูนย์การตั้งค่าเป็นฟีเจอร์ระดับแรก ไม่ใช่เรื่องรอง ถูกเก็บรักษาการอนุญาตย่อมถูกกว่าการพยายามชนะมันกลับ

การออกแบบข้อความที่ผู้ใช้เชื่อใจ

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

เขียนเหมือนคนจริง ใช้คำสั้นๆ ธรรมดา และวางรายละเอียดสำคัญไว้ก่อน "รายงานของคุณพร้อมแล้ว" ดีกว่า "มีการอัปเดตใหม่" เจาะจงดีกว่าฉลาดเกินจำเป็น

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

การปรับแต่งต้องได้มาด้วยความสมควร ตั้งอยู่บนสิ่งที่ผู้ใช้ทำอย่างชัดเจน ไม่ใช่สิ่งที่คุณเดา

ตัวอย่าง: ถ้าคนส่งออกซอร์สโค้ดเมื่อวาน "Export finished. Your ZIP is ready" สมเหตุสมผล แต่ถ้าส่ง "สร้างแอปมือถือวันนี้ไหม?" ให้คนที่ไม่เคยขอเรื่องมือถือ มันจะดูสุ่มและน่ากลัว

ความเร่งด่วนใช้ได้ แต่ความกดดันไม่ควรมี ความเร่งด่วนจริงอธิบายผลที่ตามมาโดยไม่ต้องบิดเบือน:

• ดี: "การชำระเงินล้มเหลว อัปเดตรายการบัตรเพื่อไม่ให้ถูกตัดสิทธิ์พรุ่งนี้"
• แย่: "โอกาสสุดท้าย! รีบทำตอนนี้!"

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

เทมเพลตง่ายๆ ที่ใช้ได้

โครงสร้างสม่ำเสมอช่วยให้ผู้ใช้เรียนรู้ที่จะไว้วางใจสไตล์ของคุณ:

• เกิดอะไรขึ้น (ประโยคสั้น 1 ประโยค)
• ทำไมมันสำคัญ (เลือกได้ 1 วลีสั้น)
• ต้องทำอะไร (การกระทำชัดเจนหนึ่งอย่าง)

ตัวอย่างสำหรับผลิตภัณฑ์เช่น Koder.ai: "Deployment failed. Check logs to retry." ตรงไปตรงมา สอดคล้องกับการกระทำผู้ใช้ และไม่ทำเหมือนทุกอย่างฉุกเฉิน

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

ขั้นตอนทีละข้อ: วางแผนระบบการแจ้งเตือนของคุณ

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

1) ทำบัญชีการแจ้งเตือน

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

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

2) จัดกลุ่มข้อความตามวัตถุประสงค์

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

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

3) ตัดสินทริกเกอร์และขีดจำกัด

สำหรับแต่ละข้อความ กำหนดทริกเกอร์และขีดจำกัด ทริกเกอร์ตอบว่า "เมื่อไหร่ถึงเกี่ยวข้อง?" ขีดจำกัดตอบว่า "เราจะหลีกเลี่ยงสแปมได้อย่างไร?"

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

4) ร่างเทมเพลตและตั้งชื่อเหมือนสินค้า

สร้างเทมเพลตสั้นๆ สำหรับแต่ละการแจ้งเตือน: หัวเรื่อง เนื้อหา และการแตะ ชื่อให้เป็นแบบที่ผู้ใช้จะเรียก ไม่ใช่โค้ดภายใน "อัปเดตการจัดส่ง" ดีกว่า "SHIP_STATUS_CHANGED_V2."

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

5) QA ด้วยสถานการณ์จริง

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

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

ข้อผิดพลาดทั่วไปที่ทำให้ผู้ใช้ปิดการแจ้งเตือน

คนส่วนใหญ่ไม่ได้เกลียดการแจ้งเตือน พวกเขาเกลียดความประหลาดใจ ความรก และข้อความที่ดูเหมือนส่งให้บริษัท ไม่ได้ส่งให้พวกเขา วิธีที่เร็วที่สุดจะเสียความไว้ใจคือมอง opt-in เป็นชัยชนะครั้งเดียว แทนที่จะเป็นความสัมพันธ์ระยะยาว

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

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

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

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

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

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

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

ตรวจสอบด่วนก่อนส่ง

ก่อนกดส่ง หยุด 30 วินาที ข้อความที่ทำให้เกิด opt-out ส่วนใหญ่เกิดจากข้อความที่ทำให้รู้สึกไม่คาดคิด ไม่ชัด หรือส่งบ่อยเกินไป

การทดสอบความเกี่ยวข้องใน 5 วินาที

ถามคำถามเดียว: ผู้ใช้จะคาดหวังสิ่งนี้ในตอนนี้ไหม?

การอัปเดตการจัดส่งตอนของออกนั้นสมเหตุสมผล โปรโมชั่นเช้าวันถัดไปหลังซื้อแล้วไม่สมเหตุผล ใช้เช็คลิสต์เร็วๆ:

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

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

การตรวจเช็คจังหวะเวลาและการควบคุมที่ป้องกันความเหนื่อยหน่าย

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

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

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

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

ตัวอย่างสมจริง: ได้รับสิทธิ์โดยไม่กวน

นึกภาพแอปวางแผนมื้ออาหาร ต้องการ opt-in พุช แต่ก็รู้ว่าความประทับใจแรกแย่ จะทำให้ถูกปิดเร็ว

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

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

หน้าถัดมาเป็นศูนย์การตั้งค่าเรียบง่าย ใช้ภาษาธรรมดาและค่าเริ่มต้นที่สมเหตุสมผล มันเสนอไม่กี่ตัวเลือก: เตือนมื้ออาหาร (ตามแผน สูงสุด 1 ครั้งต่อวัน), สูตรใหม่ (ย่อหน้า weekly), และดีล (ปิดโดยดีฟอลต์) แต่ละตัวเลือกอธิบายความถี่ เช่น "เตือนมื้ออาหาร: สูงสุด 1 ครั้งต่อวันในวันที่คุณวางแผนมื้อ" "สูตรใหม่: สัปดาห์ละครั้ง" ดีลปิดโดยดีฟอลต์

สัปดาห์ต่อมา ผลลัพธ์ต่างจากวิธี "ขอที่เปิดแอป" ทั่วไป ผู้คน opt-in น้อยลง แต่คนที่ยอมรับมีความสุขมากกว่า ส่งน้อยลงเพราะแอปแค่แจ้งคนที่ขอจริงๆ ตามจังหวะที่พวกเขาเลือก ผลคือมีการปิดน้อยลงและน้อยครั้งที่ผู้ใช้เลือก "ปิดทุกอย่าง"

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

วัด ปรับปรุง และตัดสินใจขั้นตอนต่อไป

มองการแจ้งเตือนเป็นฟีเจอร์ของผลิตภัณฑ์: วัดผล เปลี่ยนทีละอย่าง แล้วเรียนรู้เร็ว

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

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

ถัดไป ทบทวนบั๊กที่ทำปัญหามากที่สุด มองหาลวดลาย: หมวดเวลา หรือเทมเพลตซ้ำที่นำไปสู่อัตราปิดสูง แท็กแต่ละการแจ้งเตือนด้วยป้ายเหตุผลง่ายๆ (อัปเดตคำสั่ง, เตือน, โปรโมชั่น) เพื่อให้ตอบได้ว่า: "ข้อความไหนทำให้เกิด opt-out มากที่สุดต่อการส่ง 1,000 ครั้ง?" แก้ที่นั่นก่อน

ทดสอบแบบเล็กๆ แทนการเปลี่ยนใหญ่ เปลี่ยนตัวแปรเดียวทีละอย่าง: ถามทีหลัง (หลังช่วงชนะ), เขียนคำให้ระบุคุณค่าชัดเจน, จำกัดความถี่ต่อหมวด, แยกสิ่งที่ต้องรู้กับสิ่งที่อยากรู้, เริ่มด้วยหมวดที่เปิดน้อยกว่า

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

ถ้าต้องการเดินเร็ว การสร้างและปรับโฟลว์การขออนุญาตและศูนย์การตั้งค่าใน Koder.ai (koder.ai) สามารถช่วยให้คุณปล่อยการเปลี่ยนแปลงเร็ว แล้วส่งออกซอร์สโค้ดเมื่อพร้อมจะนำไปต่อ