.svg)
يتم إرسال إشعارات الدفع المحفزة في Braze عند إكمال المستخدم لحدث معين، وليس في تاريخ محدد على التقويم. أنت من يختار المحفز، وفترة التأخير، وأي أحداث استثنائية، والإطار الزمني، وقاعدة إعادة الأهلية. غالباً ما تكمن المشكلات في كيفية تفاعل هذه الخيارات مع بعضها البعض، لذا يوضح هذا الدليل كيفية إعدادها بالتسلسل ويبين الأسباب التي قد تؤدي إلى عدم إرسال الرسائل.
أبرز النقاط
- يتم إرسال إشعار الدفع المحفز بعد إكمال المستخدم لحدث معين، وليس في تاريخ محدد على التقويم.
- تعمل الجمهور المستهدف كغرفة انتظار: يجب أن يستوفي المستخدمون المعايير المطلوبة مسبقاً قبل تفعيل المحفز.
- المستخدمون الذين أكملوا حدث التحفيز قبل إطلاق الحملة لا يعتبرون مؤهلين.
- لا ينطبق حدث الاستثناء إلا عند إرسال الرسالة بعد فترة تأخير زمنية.
- قد يؤدي اختيار إطار زمني أو تأخير طويل إلى إلغاء الإرسال افتراضياً، ما لم تختر خيار الوقت المتاح التالي.
- قم بإجراء اختبار عن طريق تفعيل الحدث بعد الإطلاق، ثم تأكد من أن Braze قد استلمه.
ما هي إشعارات الدفع المحفزة في Braze؟
إشعار الدفع المحفز هو حملة تنتظر إجراءً من المستخدم. توضح وثائق Braze ذلك كالتالي: "بدلاً من إرسال حملتك في أيام معينة، يمكنك تحفيزها ليتم إرسالها بعد أن يكمل المستخدم حدثاً معيناً".
توفر Braze ثلاثة مسارات لتسليم إشعارات الدفع. يمكن إرسال الرسائل وفقاً لجدول زمني، أو بعد إجراء معين، أو من خلال محفز عبر واجهة برمجة التطبيقات (API)، وكل مسار يناسب غرضاً مختلفاً.
مسار التسليمما الذي يطلق عملية الإرسالاختره عندماجدول زمنيالتاريخ والوقت الذي تحددهأنت الرسالة عبارة عن بث مخطط لهقائم على الإجراءحدث يقوم به المستخدم، مثل عملية شراء أو حدث مخصصالرسالة تستجيب لسلوك المستخدممحفز عبر APIطلب من خوادمك الخاصةنظامك الخلفي يحتفظ بالإشارة أولاً
كيف يمكنك إعداد إشعارات الدفع المحفزة في Braze؟
اتبع خطوات البناء بهذا الترتيب. التسلسل مهم لأن الإعدادات اللاحقة تعتمد على الإعدادات السابقة.
- أنشئ حملة أو Canvas واختر منصات الدفع.
- اكتب العنوان، ونص الرسالة، والسلوك عند النقر، ثم قم بإجراء الاختبار.
- في خطوة التسليم، اختر "قائم على الإجراء" (Action-based) وحدد حدث التحفيز.
- حدد فترة التأخير، ثم أي أحداث استثنائية.
- حدد مدة الحملة والإطار الزمني.
- حدد قواعد إعادة الأهلية ووضع سقف لتكرار الرسائل.
- اختر الجمهور المستهدف وأحداث التحويل، ثم راجع الحملة وأطلقها.
نوصي ببناء الجمهور في المرحلة الأخيرة. فما تتعلمه في الخطوات السابقة غالباً ما يغير من يجب أن يكون ضمن هذا الجمهور، كما أن الجمهور يعمل كبوابة دخول وليس كمجرد أداة تصفية.
لماذا لا يتلقى المستخدم الموجود ضمن الجمهور إشعار الدفع (Push)؟
تعمل الشريحة المستهدفة كغرفة انتظار. تنص الوثائق على أن "رسالتك لن تُرسل إلا للمستخدمين الذين يستوفون بالفعل الشروط التي حددتها في خطوة الشريحة المستهدفة. وبعد ذلك، لا يزال يتعين عليهم استيفاء شرط التفعيل الذي تحدده في خطوة جدولة التسليم".
يخلق التوقيت الفخ الثاني. فالمستخدمون الذين أكملوا حدث التفعيل قبل الإطلاق لا يتأهلون، لذا فإن الاختبار الذي أطلق الحدث بالأمس لا يثبت شيئاً.
يمكن أن تؤدي عملية التقسيم بناءً على بيانات المستخدم المسجلة في وقت الحدث إلى حدوث حالة سباق (race condition). عندما لا تصل السمة إلى Braze قبل الحدث، يكون الحل المذكور في الوثائق هو إرفاق القيم ذات الصلة كخصائص مخصصة للحدث والتصفية بناءً على خاصية الحدث بدلاً من استخدام مرشح التقسيم.
كيف يجب عليك ضبط التأخير وأحداث الاستثناء؟
التأخير هو وعد بأن المستخدم لا يزال بحاجة إلى الرسالة عند وصولها. أما حدث الاستثناء فهو الطريقة التي تفي بها بهذا الوعد. يتيح لك Braze اختيار حدث استثناء يستبعد المستخدمين من الحملة، ولكن فقط إذا تم إرسال الرسالة بعد فترة تأخير.
يظل المستخدمون الذين تم حظرهم بواسطة حدث استثناء مؤهلين في المرة التالية التي يكملون فيها حدث التفعيل، حتى لو لم تقم بتمكين إعادة التأهيل. تعتمد التأخيرات أيضاً على الطابع الزمني للحدث؛ فإذا وصل طابع زمني مؤرخ بتاريخ سابق، فقد يتعامل Braze مع التأخير على أنه قد انقضى بالفعل ويرسل الرسالة في وقت أبكر مما تتوقع.
عندما تحتوي الحملة على تأخير، يمكنك أيضاً تحديد خيار "إعادة تقييم عضوية الشريحة عند وقت الإرسال" (Re-evaluate segment membership at send-time). وهذا يمنع المستخدمين الذين غادروا الجمهور أثناء فترة الانتظار من تلقي الرسالة.
كيف تؤثر الأطر الزمنية وساعات الهدوء على التسليم؟
يمكن للإطار الزمني أن يلغي عمليات إرسال كنت تعتقد أنها آمنة. فإذا أكمل المستخدم حدث التفعيل خارج الإطار الزمني، أو إذا أدى التأخير إلى تجاوز ذلك الوقت، فلن يتلقى الرسالة بشكل افتراضي.
يمكنك إنقاذ هؤلاء المستخدمين باستخدام مربع الاختيار الذي يرسل الرسالة في الوقت المتاح التالي. بالنسبة للتسليم القائم على الإجراء، يمكنك أيضاً ضبط المدة وساعات الهدوء في نفس الخطوة.
نوصي باتخاذ قرار بشأن مربع الاختيار هذا بعناية لكل حملة. فالتذكير بسلة التسوق الذي يصل في صباح اليوم التالي قد يظل مفيداً، بينما تنبيه يوم التوصيل الذي يصل متأخراً يوماً كاملاً يفقد قيمته كونه تنبيهاً.
ما الذي يجب أن تقرره بشأن إعادة التأهيل؟
تحدد إعادة التأهيل ما إذا كان بإمكان المستخدم نفسه تلقي الحملة مرة أخرى. إذا سمحت بذلك، يمكنك ضبط فترة تأخير قبل أن يتمكن المستخدم من تلقي الحملة مجدداً.
اقرن ذلك بوضع حد أقصى للتكرار من نفس خطوة التسليم. بالنسبة للحملات التي يتم تفعيلها عبر واجهة برمجة التطبيقات (API)، تنطبق نفس الفكرة، بحيث يتلقى المستخدم الحملة مرة واحدة أو مرة واحدة خلال فترة زمنية محددة، بغض النظر عن عدد المرات التي يطلق فيها نظامك حدث التفعيل.
متى تكون الحملة التي يتم تفعيلها عبر واجهة برمجة التطبيقات (API) هي الخيار الأفضل؟
اختر مسار واجهة برمجة التطبيقات عندما يكون حدث التفعيل موجوداً على خوادمك بدلاً من التطبيق. تصف الوثائق الحملات التي يتم تفعيلها عبر واجهة برمجة التطبيقات بأنها مثالية لحالات الاستخدام المعاملاتي الأكثر تقدماً، وتأكيد الدفع من قبل نظامك الخلفي هو أحد الأمثلة على ذلك. تظل قواعد النصوص، والاختبار متعدد المتغيرات، وقواعد إعادة التأهيل في لوحة تحكم Braze، بينما يقوم نظامك بإرسال الإشارة.
هناك بعض التفاصيل الموثقة التي توفر عليك جلسة تصحيح أخطاء. بشكل افتراضي، send_to_existing_only تكون صحيحة في /campaigns/trigger/send، لذا لن يؤدي الاستدعاء إلى إنشاء ملفات تعريف جديدة.
استخدم قوسين متعرجين بالضبط لكل وسم Liquid في trigger_properties وفي نص الرسالة. بالنسبة للإرسالات المتعلقة بالمعاملات، اضبط التأخير على صفر دقيقة حتى يتلقى المستخدم الحملة في كل مرة.
إذا كانت خوادمك الخاصة هي التي سترسل تلك الإشارة، فإن خدمة هندسة المنتجات لدينا من CustomerIK تغطي البرمجيات الوسيطة المخصصة التي تربط أنظمتك بالأدوات المحيطة بها.
كيف تبدو عملية تذكير سلة التسوق من البداية إلى النهاية؟
لنفترض وجود بائع تجزئة يرغب في إرسال إشعار دفع بعد أن يضيف شخص ما عناصر إلى سلة التسوق ثم يغادر. المحفز هنا هو تحديث سلة التسوق، والذي يقبل فلاتر الخصائص بحيث يتم الإرسال فقط لسلال التسوق التي تريد استهدافها.
يُعد التأخير أول قرار حقيقي يجب اتخاذه. فالانتظار لفترة قصيرة يبدو كتذكير لطيف، بينما قد يؤدي الانتظار لفترة طويلة إلى قيام المستخدم بالشراء من مكان آخر. حدث الاستثناء هو عملية الشراء، لذا فإن أي شخص يكمل طلبًا خلال فترة الانتظار لن يرى التذكير أبدًا.
بعد ذلك، تحقق من أوضاع الفشل بالترتيب. تأكد من أن الحدث تضمن تفاصيل سلة التسوق كخصائص، وأن الإطار الزمني يسمح بالإرسال عند انتهاء التأخير. اجعل فترة إعادة الأهلية قصيرة بما يكفي ليتمكن النظام من إرسال تذكير آخر لسلة تسوق جديدة غدًا، وطويلة بما يكفي لضمان عدم إزعاج المستخدم بتذكيرين في جلسة واحدة.
هذا توضيح للمنطق وليس توصية بأوقات انتظار محددة. يعتمد التأخير المناسب على نمط التسوق، ويجب عليك اختباره مقابل بيانات التحويل الخاصة بك.
كيف يمكنك اختبار وتصحيح أخطاء إشعار الدفع المحفز؟
اختبر الحدث بعد إطلاقه، وليس قبل ذلك أبدًا. ثم تابع التحقق من الخطوات الموثقة بالترتيب. أولاً، تأكد من تمرير الحدث المخصص إلى Braze.
إذا تم ذلك، قارن الطابع الزمني للحدث بالوقت الذي أصبحت فيه الحملة مباشرة. بعد ذلك، انظر إلى عضوية الشريحة، وتعيين مجموعة التحكم، وأي تأخير.
سلوك الجهاز مهم أيضًا. يتلقى المستخدم الذي لديه عدة أجهزة إشعار الدفع على جميع الأجهزة التي تحتوي على رمز دفع صالح بشكل افتراضي. التبديل إلى جهاز واحد يتبع أحدث رمز دفع، وليس أحدث جلسة.
على نظام Android، يتم إرسال الرسالة التي تحتوي على مسافة واحدة فقط كإشعار دفع صامت.
كيف يرتبط هذا ببقية البرنامج؟
نادرًا ما يعمل إشعار الدفع المحفز بمفرده. دليلنا حول محفزات التفاعل في Braze يغطي تصميم الحدث الأوسع وراءه، و تساعد تجزئة الإشعارات الفورية يوضح كيفية تحديد من هم المؤهلون.
التوقيت والمحتوى يأتيان في المرتبة التالية. اقرأ تحسين توقيت إشعارات الدفع قبل تحديد فترات التأخير، و تخصيص إشعارات الدفع للنص. للاطلاع على رحلات محددة، راجع إشعار دفع لإكمال عملية الإعدادوتوقيت رسائل الاحتفاظ بالمستخدمين.
تصل الأحداث إلى Braze من خلال تكامل SDK وAPI الخاص بك. للاطلاع على مثال لشريك يوجه فريقاً داخلياً صغيراً خلال هذا العمل، اقرأ دراسة الحالة الخاصة بنا حول التنفيذ الموجه والمواءمة بين الوكالات.
بصفتها شريكاً في تنفيذ Braze، توصي CustomerIK بإنشاء إشعار دفع واحد في كل مرة، والتحقق من مشغله وتأخيره وحدث الاستثناء الخاص به في مساحة عمل تجريبية قبل إضافة التالي. فكل مشغل إضافي يضاعف التفاعلات التي يتعين عليك التحقق منها.
الأسئلة الشائعة
1. ما الفرق بين إشعارات الدفع القائمة على الإجراء وتلك التي يتم تشغيلها عبر API في Braze؟
يتم إطلاق الحملات القائمة على الإجراء عندما يكمل المستخدم حدثاً يسجله Braze بالفعل. أما الحملات التي يتم تشغيلها عبر API، فيتم إطلاقها عندما يقوم نظامك الخاص باستدعاء Braze.
2. هل يمكن للمستخدم تلقي إشعار دفع مشغل إذا قام بالحدث قبل الإطلاق؟
المستخدمون الذين أكملوا حدث التشغيل قبل إطلاق الحملة لا يتأهلون، لذا يجب تنفيذ الحدث مرة أخرى بعد الإطلاق.
3. لماذا لم يتم إرسال إشعار الدفع المؤجل الخاص بي؟
تشمل الأسباب الشائعة حدث استثناء، أو تجاوز الإطار الزمني، أو انتهاء مدة الحملة. تحقق من كل منها بهذا الترتيب.
4. هل تعمل أحداث الاستثناء بدون تأخير؟
لا ينطبق حدث الاستثناء إلا إذا تم إرسال الرسالة المشغلة بعد تأخير زمني.
5. هل تصل إشعارات الدفع المشغلة إلى كل جهاز يملكه المستخدم؟
افتراضياً، نعم، تصل إلى جميع الأجهزة التي تمتلك رمز دفع صالحاً. يمكنك قصر التسليم على جهاز واحد فقط.
المصادر
- Braze،التسليم القائم على الإجراء. تم الاسترجاع في 30 أكتوبر 2026.
- Braze،إنشاء رسالة دفع. تم الاسترجاع في 30 أكتوبر 2026.
- Braze،التسليم عبر واجهة برمجة التطبيقات (API). تم الاسترجاع في 30 أكتوبر 2026.
- بقلم CustomerIK، شريك تنفيذ معتمد لـ Braze.
CustomerIK هي شريك تنفيذ لـ Braze، وتعمل في مجالات الإعداد، والتكامل التقني، وعمليات التسويق، وإدارة بيانات العملاء.
إذا كنت ترغب في الحصول على رأي إضافي حول إعداد إشعارات الدفع المشغلة لديك، فلنتحدث.
.svg)
