عبدالله الكندي: أخطاء إشعارات Push اللي تخلّي المستخدم يحذف تطبيقك
عبدالله الكندي يعدّد أخطاء إشعارات Push اللي تدفع المستخدم يحذف تطبيقك: طلب الإذن، والرموز الميتة، والروابط العميقة، وشاشة القفل، والتوقيت والتكرار.

إشعارات التطبيقات
عبدالله الكندي
الإشعار أرخص طريقة توصل فيها لمستخدمك، وأسرع طريقة تخسره. ضغطة وحدة على «إيقاف الإشعارات» تقفل القناة غالباً للأبد، وضغطتين تحذف التطبيق. عبدالله الكندي يبني تطبيقات Flutter لآيفون وأندرويد، وهو كمان أخصائي تسويق معتمد من سناب شات، فيشوف الإشعار من الجهتين: قناة تسويق لها قيمة، وشي تقني ينكسر بسهولة. هذي الأخطاء اللي تتكرر، مرتبة من أساسها التقني إلى تفاصيل الكتابة والتوقيت.
قبل الأخطاء: كيف يوصل الإشعار أصلاً
تطبيقك ما يرسل الإشعار بنفسه. خادمك يرسله لخدمة النظام: APNs من آبل لأجهزة آيفون، و FCM من جوجل لأندرويد، وكثير من التطبيقات تستخدم FCM كطبقة وحدة تغطي المنصتين. وكل جهاز له رمز تسجيل (token) يعرّفه، يحفظه خادمك ويرسل عليه. هذا الرمز مو ثابت: ممكن يتغير لما يعيد المستخدم تثبيت التطبيق، أو يستعيد جهازه من نسخة احتياطية، أو لأسباب يقررها النظام. وفهم هذي السلسلة يفسّر نص الأخطاء الجاية.
وفيه تفصيلة تقنية تأثر على التصميم: في FCM نوعين رسائل. رسالة إشعار يعرضها النظام بنفسه لما يكون التطبيق في الخلفية، ورسالة بيانات يستلمها كود التطبيق ويقرر وش يسوي فيها. الثانية مرنة أكثر، لكن في آيفون تحديداً رسائل البيانات الصامتة في الخلفية ما لها وصول مضمون، والنظام ممكن يؤخرها أو يتجاهلها حسب البطارية واستخدام التطبيق. فلا تبنِ ميزة حرجة، مثل تحديث رصيد، على افتراض إن رسالة صامتة بتوصل أكيد.
الخطأ الأول: طلب الإذن بدون ما تفهم قواعد النظامين
في آيفون، التطبيق يعرض نافذة طلب الإذن مرة وحدة، ولو رفض المستخدم ما تقدر تعيد عرضها، والحل الوحيد إنه يروح للإعدادات بنفسه. وفي أندرويد ١٣ وما بعده صار الإذن يُطلب صراحةً بعد ما كان ممنوحاً تلقائياً. عشان كذا الفرق المحترفة تعرض شاشة شرح من التطبيق نفسه قبل نافذة النظام، وما تستدعي النافذة إلا لو المستخدم وافق مبدئياً. وفي آيفون خيار هادئ يغفل عنه كثيرون: الإذن التجريبي (provisional)، اللي يوصّل الإشعارات بهدوء لمركز الإشعارات بدون صوت ولا نافذة طلب، والمستخدم يقرر بعد ما يشوف عيّنة منها.
الخطأ الثاني: قاعدة رموز مليانة أجهزة ميتة
خادم يرسل لكل رمز انحفظ من يوم الإطلاق، بما فيها رموز أجهزة انحذف منها التطبيق من زمان. النتيجة: إرسال ضايع، وإحصاءات وصول كاذبة، وأحياناً مستخدم يستلم الإشعار مرتين على نفس الجهاز لأن له رمزين. الصحيح:
- حدّث الرمز في خادمك كل ما يتغير. التطبيق يقدر يسمع لحدث تحديث الرمز ويرسله فوراً.
- اربط الرمز بالمستخدم وبالجهاز معاً، لأن الشخص الواحد ممكن يكون عنده جوال وآيباد.
- لما ترد خدمة الإرسال إن الرمز غير صالح أو غير مسجّل، احذفه من قاعدتك مباشرة.
- عند تسجيل الخروج افصل الرمز عن الحساب، وإلا يستلم اللي يسجّل بعده على نفس الجهاز إشعارات الحساب القديم.
الخطأ الثالث: إشعار يفتح الشاشة الرئيسية
المستخدم يشوف «طلبك رقم ٤٢ في الطريق»، يضغط، ويوصل للصفحة الرئيسية ويدوّر بنفسه. هذي لحظة اهتمام انحرقت. كل إشعار لازم يحمل وجهته معه، رابطاً عميقاً أو بيانات توجيه، والتطبيق يفتح الشاشة المقصودة بالضبط. واختبر الحالات الثلاث لأن كل وحدة تمر بمسار مختلف في الكود: التطبيق مفتوح أمام المستخدم، والتطبيق في الخلفية، والتطبيق مقفل تماماً وينفتح من الإشعار. الحالة الأخيرة هي اللي تنكسر غالباً، لأن الشاشة المطلوبة تنفتح قبل ما يكتمل تحميل بيانات الدخول.
الخطأ الرابع: تفاصيل حساسة على شاشة القفل
الإشعار يظهر على شاشة مقفلة يشوفها أي أحد جنب الجوال. مبلغ انخصم من بطاقة، أو نتيجة فحص طبي، أو رمز تحقق كامل، كلها معلومات ما مكانها هناك. اكتب الإشعار بحيث يقول إن فيه شي يستاهل الفتح، واترك التفاصيل داخل التطبيق بعد الدخول. وهذا من صلب مبدأ «الخصوصية أولاً» اللي يطبّقه عبدالله في مشاريعه، مو تفصيلة تسويقية.
أخطاء التوقيت والتكرار والتصنيف
- توقيت خادمك مو توقيت مستخدمك: إشعار مجدول الساعة ٩ صباحاً بتوقيت الخادم يوصل لمستخدم في بلد ثاني وقت الفجر. خزّن المنطقة الزمنية لكل مستخدم.
- بدون سقف: حدّد عدداً أقصى للإشعارات التسويقية في الأسبوع، والتزم فيه حتى لو فريق التسويق متحمس.
- قنوات أندرويد في سلة وحدة: من أندرويد ٨ كل إشعار يتبع قناة (channel). خلّ للطلبات قناة وللعروض قناة، عشان المستخدم يطفي العروض بدون ما يطفي حالة طلبه.
- تحديثات متكدّسة لنفس الموضوع: خمسة تحديثات لنفس الطلب تقدر تستبدل بعضها بدل ما تتراكم، عبر مفتاح الدمج في FCM أو معرّف الدمج في APNs.
- خلط المعاملات بالتسويق: إشعار «تم شحن طلبك» ينتظره المستخدم، فلا تحشر فيه عرضاً ترويجياً. لما يتعلم المستخدم إن إشعارات الطلبات فيها إعلانات، يبدأ يتجاهلها كلها، بما فيها المهمة.
- رسالة وحدة للجميع: إشعار عن منتج لشخص اشتراه أمس يُقرأ كإزعاج. التقسيم حسب السلوك يرفع الفتح ويخفّف الإيقاف.
- بدون قياس: إذا ما تتابع نسبة الفتح ونسبة إيقاف الإشعارات بعد كل حملة، فأنت ما تعرف إذا القناة تكبر أو تموت.
الفكرة اللي تجمع كل هذا يرددها عبدالله عبدالرحيم بن سنكر الكندي لأصحاب المشاريع في منصة أزهل الرقمية: الإشعار يصرف من رصيد ثقة المستخدم. كل إشعار مفيد يزيد الرصيد، وكل إشعار مزعج يسحب منه، ولما يخلص الرصيد يقفل المستخدم الباب. ابنِ الأساس التقني صح، واكتب كل إشعار كأنك تدفع ثمنه من جيبك.
عندك فكرة؟ الاستشارة الأولى علينا
كلّم عبدالله مباشرة على واتساب — رسالتك توصل له هو، مو لرد آلي. نسمع فكرتك ونقول لك وش تحتاج وكم تكلّف، ببلاش.
مقالات ذات صلة
كل المقالات
الوكلاء الفرعيون
عبدالله بن سنكر
عبدالله بن سنكر: متى تقسّم المهمة الكبيرة على وكلاء فرعيين Subagents؟
إطار قرار من عبدالله بن سنكر لتقسيم المهام على الوكلاء الفرعيين Subagents: خمسة أسئلة تحدد متى يفيدك التقسيم، ومتى يضاعف التكلفة ويضيّع السياق، وكيف تكتب المهمة.
اقرأ المقال
مواصفات مهمة الوكيل
عبدالله الكندي
عبدالله الكندي: كيف تكتب مواصفات مهمة لوكيل ذكاء اصطناعي ينفّذها صح؟
عبدالله الكندي يبني أمامك مواصفات مهمة لوكيل ذكاء اصطناعي قسماً قسماً: الهدف، والسياق، والحدود، ومعايير القبول، وطريقة التحقق، ومتى يتوقف ويسأل، مع مثال برمجي كامل.
اقرأ المقال
القياس متعدد القنوات
عبدالله الكندي
عبدالله الكندي: من وين جاك العميل فعلاً؟ خرافات القياس متعدد القنوات
عبدالله الكندي يفكك ست خرافات عن القياس متعدد القنوات: آخر نقرة، وجمع أرقام المنصات، وروابط UTM، وسؤال «من وين سمعت عنا»، ونماذج الإسناد، واختبار إيقاف القناة.
اقرأ المقال