.svg)
تُعد قوالب إشعارات الدفع في Braze ممارسة عملية تعتمد على عناصر موثقة: كتل المحتوى (Content Blocks) للنصوص المشتركة، وقوالب Canvas للرحلات، ونسخ المتغيرات (Copy from Variant) للمتغيرات المتشابهة، والقيم الافتراضية للبيانات المفقودة. يوضح هذا الدليل ما يجب تثبيته في القالب، وما يجب تركه مفتوحاً، وكيفية مراجعة النصوص قبل الإطلاق.
أبرز النقاط
- يأتي محتوى إشعارات الدفع القابل لإعادة الاستخدام في Braze من كتل المحتوى، وقوالب Canvas، ونسخ المتغيرات، مع تغطية البيانات المفقودة باستخدام القيم الافتراضية.
- قم بتثبيت التنسيق، والقيم الاحتياطية، والطول، وعنوان الصورة، وترتيب اللغة في القالب، واترك العرض والصياغة النهائية مفتوحة.
- توصي Braze بما يقرب من 30-40 حرفاً لكل سطر في العنوان أو نص الرسالة على نظام iOS، ويقصر نص الرسالة بمقدار 10 أحرف تقريباً لكل سطر عند وجود صورة.
- تُعرض عناوين iOS في سطر واحد، لذا تمرر عناوين Liquid عبر strip_newlines، وتحتاج رسائل Android إلى عنوان.
- تظل كتل المحتوى المدرجة عبر Liquid مرتبطة بالأصل، لذا تحقق من قائمة الإدراج قبل التعديل واختر الأسماء بعناية، لأنه لا يمكن تغييرها لاحقاً.
- أجرِ المراجعة المكونة من ست نقاط نفسها على كل إشعار دفع يتم إنشاؤه من قالب.
ما الذي يُعتبر قالب إشعار دفع في Braze؟
يصف قسم القوالب في وثائق Braze قوالب البريد الإلكتروني، وقوالب الويب هوك، وقوالب الروابط، وكتل المحتوى، وقوالب Canvas. ويذكر أنها موجودة "للحفاظ على الاتساق وتوفير الوقت عبر حملاتك". تستفيد نصوص إشعارات الدفع من المزايا نفسها من خلال الأجزاء التي تناسبها.
تؤدي ثلاث آليات موثقة هذا العمل. تحتفظ كتل المحتوى بمحتوى قابل لإعادة الاستخدام عبر القنوات في موقع مركزي واحد. وتحفظ قوالب Canvas شكل الرحلة، بينما تنقل ميزة "نسخ المتغيرات" النصوص المصاغة إلى متغيرات أخرى للحملة.
تتعامل CustomerIK مع هذه الآليات الثلاث كنظام قالب واحد لإشعارات الدفع، وتعين مالكاً محدداً لكل جزء. وبدون ذلك، ينتهي الأمر بالفريق بامتلاك قطع قابلة لإعادة الاستخدام دون وجود مسؤول عنها.
ما الذي يجب أن يثبته قالب إشعار الدفع، وما الذي يجب أن يتركه مفتوحاً؟
يثبت القالب الجيد الأجزاء التي يجب ألا تتغير، ويترك الأجزاء التي تختلف حسب الحملة مفتوحة. يوضح الجدول أدناه التقسيم الذي نستخدمه عند إعداد برنامج إشعارات الدفع.
جزء من إشعار الدفع | ما يتم تثبيته في القالب | ما يُترك مفتوحاً للحملة | الأساس الموثق التنسيق | نمط العنوان والنص، نص عادي فقط | العرض ودعوة اتخاذ إجراء | إنشاء رسالة دفع البيانات المفقودة | قيمة افتراضية لكل سمة | السمات المراد استخدامها | تعيين قيم افتراضية الطول | ميزانية عدد الأحرف للعنوان والنص | الصياغة النهائية | إنشاء إشعارات دفع غنية لنظام iOS الصور | نمط عنوان آمن للصورة | الأصل نفسه | إنشاء رسالة دفع اللغات | قائمة اللغات، يتم اختيارها قبل النص | النص المترجم | إنشاء رسالة دفع
عمود "ما يتم تثبيته" هو المكان الذي يجب أن تركز فيه مراجعات القوالب. وعمود "ما يُترك مفتوحاً" هو المساحة التي يجب أن يتمتع فيها مديرو الحملات بحرية التصرف.
ما هو الطول المناسب لنص القالب على نظام iOS؟
توصي Braze بالحفاظ على كل سطر من النص لكل من العنوان الاختياري ونص الرسالة عند 30-40 حرفاً تقريباً في إشعارات الدفع على الأجهزة المحمولة. كما توضح وثائق iOS أن العنوان يأخذ سطراً واحداً، بينما يظهر النص في سطرين عند نشاط الجهاز، وما يصل إلى 7 أسطر عند توسيع الإشعار.
هناك تفصيلان موثقان يغيران الميزانية. يقصر نص الرسالة بمقدار 10 أحرف تقريباً لكل سطر عند وجود صورة، وقد تلتف الكلمات الطويلة بشكل مفاجئ أكثر من الكلمات القصيرة. تذكر الصفحة نفسها أنه لا يمكن وضع قاعدة صارمة وثابتة، لذا تعامل مع هذه الأرقام كإرشادات.
نوصي بتعيين ميزانية نص القالب بناءً على متغير الصورة، لأنها الحالة الأكثر ضيقاً. فالقالب الذي يناسب هذه الحالة سيتناسب مع كل الحالات الأخرى دون الحاجة إلى تعديل إضافي.
كيف تحافظ القيم الافتراضية على سلامة قالب إشعار الدفع؟
توثق منصة Braze استخدام فلتر Liquid المسمى default لأي سمة تخصيص. إذا لم يتم توفير قيمة افتراضية وكان الحقل مفقوداً أو غير محدد في ملف تعريف المستخدم، فسيظهر الحقل فارغاً في الرسالة. إن إرسال إشعار دفع يبدأ بتحية متبوعة بفراغ يُعد خطأً غير مهني.
يبدو النمط الموثق كما يلي، بعد تكييفه ليناسب نص إشعار الدفع:
مرحباً {{ ${first_name} | default: 'عميلنا العزيز' }}، لقد تم شحن طلبك.
تضيف الوثائق تفصيلاً يغفل عنه الكثير من الفرق؛ حيث تظهر القيمة الافتراضية للقيم الفارغة تماماً، ولكن ليس للقيم التي تحتوي على مسافات. فالاسم الأول الذي يحتوي على مسافة فقط يُعتبر "فارغاً" من الناحية البرمجية، وبالتالي لن تظهر القيمة الافتراضية.
نحن نقترح جعل تنقية السمات عند نقطة جمع البيانات جزءاً من عملية مراجعة القالب، وليس مشروع بيانات منفصلاً. اسأل مالك البيانات عما إذا كانت السلاسل النصية الفارغة يمكن أن تصل إلى ملف تعريف المستخدم قبل الاعتماد على قيمة افتراضية.
ما الذي قد يسير بشكل خاطئ في عناوين قوالب إشعارات الدفع؟
على نظام iOS، تُعرض عناوين إشعارات الدفع في سطر واحد. إذا كانت مخرجات Liquid تتضمن فواصل أسطر، فقد يرى المستخدمون النص الذي يسبق الفاصل الأول فقط. توثق Braze الحل لذلك: قم بالتقاط المخرجات وتطبيق فلتر strip_newlines.
{% capture title_output %}
YOUR LIQUID HERE
{% endcapture %}
{{ title_output | strip_newlines }}
لنظام Android قواعده الخاصة؛ حيث تنص الوثائق على أنه لا يمكنك إرسال إشعار دفع لنظام Android بدون عنوان، وأن الرسالة التي تحتوي على مسافة واحدة فقط تُرسل كإشعار دفع صامت.
نرى أن أي عنوان يتم إنشاؤه باستخدام منطق Liquid الشرطي يستحق إجراء اختبار تتحول فيه كل حالة إلى "لا شيء". هذا الاختبار وحده سيكشف ما إذا كان القالب قد يقع في حالة الإشعار الصامت عن طريق الخطأ.
متى تكون كتل المحتوى (Content Blocks) مناسبة لنصوص إشعارات الدفع؟
تعد كتل المحتوى مناسبة للعبارات التي تتكرر عبر العديد من إشعارات الدفع، مثل وعود التوصيل أو سطر العروض المشتركة. تصفها الوثائق بأنها محتوى قابل لإعادة الاستخدام عبر القنوات، وتذكر أن كتل المحتوى المدرجة عبر Liquid تظل مرتبطة بالأصل وتعكس أي تغييرات. لذا، فإن تعديلاً واحداً سيقوم بتحديث كل رسالة تستخدم هذه الكتلة.
هذا السلوك مفيد ولكنه يتطلب الحذر. تعرض معاينة مكتبة كتل المحتوى عدد مرات الاستخدام مع قائمة قابلة للنقر بالرسائل التي تستخدم الكتلة، لذا تحقق من تلك القائمة قبل تعديل أي سطر مشترك. كما لا يمكن أرشفة أي كتلة طالما أن هناك رسالة تستخدمها.
تستحق الأسماء اهتماماً أكبر مما تحصل عليه عادةً. تنص الوثائق على أنه لا يمكن تغيير الاسم بعد حفظ الكتلة ولا يمكن إعادة استخدامه حتى لو تمت أرشفته، لذا نوصي بإدراج القناة ورقم الإصدار في الاسم منذ البداية. شيء مثل push_delivery_line_v1 يترك مجالاً لـ v2 دون الحاجة لإعادة التسمية.
يمكن تداخل الكتل، ولكن لمرة واحدة فقط. إذا كنت تبني نص إشعار الدفع من أجزاء، فحافظ على هيكلية بسيطة. عند كتابة كتلة مع فواصل أسطر لسهولة القراءة، تشير Braze إلى أن الفواصل المتبقية قد تضيف مسافات زائدة، لذا استخدم وسم capture الموثق مع فلتر strip.
كيف تساعد قوالب Canvas في رحلات إشعارات الدفع؟
توفر قوالب Canvas إطار عمل متسقاً يمكن تخصيصه ليتناسب مع أهداف محددة عبر مختلف لوحات Canvas. كما تؤكد الوثائق أنه يمكنك حفظ إعدادات منشئ Canvas ضمن قالب، بما في ذلك إعدادات الجمهور. وبذلك، يمكن أن تبدأ رحلة العميل التي تتضمن خطوة إرسال إشعار دفع بهيكلها الجاهز مسبقاً.
نقترح إبقاء النصوص خارج قالب Canvas ووضعها في "كتل المحتوى" (Content Blocks) حيث يمكن للفريق تعديلها. بهذه الطريقة، يحمل القالب الهيكل التنظيمي، بينما تحمل الكتل النصوص. يتيح هذا الفصل لكاتب المحتوى تغيير أي سطر دون المساس بمنطق الرحلة.
ما الذي يجب التحقق منه في مراجعة ما قبل الإطلاق؟
أجرِ نفس المراجعة السريعة على كل إشعار دفع يتم إنشاؤه من قالب. إنها عملية قصيرة بما يكفي لتنفيذها في كل مرة، وهي كفيلة باكتشاف المشكلات التي قد يكون إصلاحها مكلفاً بعد الإطلاق.
- استخدم ميزة "معاينة الرسالة كمستخدم" (Preview message as user) لمستخدم عشوائي ولمستخدم متعدد اللغات، كما هو موضح في الوثائق.
- تأكد من أن كل سمة لها قيمة افتراضية.
- تأكد من أن أي عنوان لنظام iOS تم إنشاؤه باستخدام Liquid يمر عبر دالة strip_newlines.
- تأكد من أن عناوين الصور التي تم إنشاؤها باستخدام Liquid أو المحتوى المتصل (Connected Content) آمنة. تشير الوثائق إلى أن العنوان غير الآمن سيؤدي إلى تعطل تطبيقك.
- تأكد من وجود عناوين لنظام Android وأنها لا تظهر كمسافة فارغة فقط.
- افتح قائمة التضمين (inclusion list) الخاصة بكل "كتلة محتوى" قبل تعديلها.
اقتراحنا هو وضع هذه القائمة في وصف القالب أو في قائمة التحقق الخاصة بفريقك قبل الإطلاق، بدلاً من الاعتماد على الذاكرة. فالمراجعة التي تعتمد على الذاكرة غالباً ما يتم تخطيها في الأسبوع الذي تكون فيه أكثر أهمية.
كيف يبدو المثال العملي؟
هذا المثال افتراضي، ولا يحتوي على بيانات عملاء أو نتائج حقيقية. تخيل بائع تجزئة يرغب في إرسال إشعار دفع عند توفر منتج مجدداً لمستخدمي iOS وAndroid.
يقوم الفريق بتحديد نمط العنوان والمتن، والقيمة الافتراضية للاسم الأول، وكتلة محتوى واحدة تحتوي على سطر التسليم. يتركون اسم المنتج ودعوة اتخاذ الإجراء (CTA) مفتوحين لكل حملة. يقومون بكتابة نص iOS أولاً، ثم تقصير المتن ليتناسب مع متغير الصورة، وبعد ذلك يستخدمون ميزة "نسخ من متغير" (Copy from Variant) لإنشاء نسخة Android.
عند المراجعة، يفتح أحدهم قائمة التضمين الخاصة بسطر التسليم ويرى حملتين أخريين نشطتين تستخدمانه. يقررون أن تغيير الصياغة يجب أن يتم في v2 كتلة جديدة، حتى لا يتم تعديل الحملات النشطة عن طريق الخطأ. هذا القرار، الذي اتُخذ أثناء المراجعة بدلاً من اتخاذه بعد الإطلاق، هو جوهر فائدة القالب.
كيف يرتبط هذا ببقية البرنامج؟
تعتبر القوالب الأساس الذي تُبنى عليه بقية أعمال إشعارات الدفع الخاصة بك. دليل دليل أتمتة التسويق في Braze يغطي إعادة الاستخدام عبر القنوات المختلفة، و تخصيص إشعارات الدفع يغطي ما يتم وضعه في خانات السمات.
يجب أن تكون نصوص القوالب مناسبة أيضاً للجماهير الحقيقية وأوقات الإرسال. اقرأ تساعد تجزئة الإشعارات الفوريةوتحسين توقيت إشعارات الدفع التالي. لمعرفة المزيد حول Liquid، راجع التخصيص باستخدام وسوم Liquid، ولمعرفة المزيد حول سلوك النقر، راجع الروابط العميقة لتفاعل الهاتف المحمول.
بصفتنا شريكاً في تنفيذ Braze، توصي CustomerIK بالبدء بنموذج إشعار دفع واحد، وكتلة محتوى (Content Block) مشتركة واحدة، وقائمة مراجعة واحدة. لا تضف المزيد إلا عندما يحتاج فريق آخر إليها.
الأسئلة الشائعة
1. هل لدى Braze نوع مخصص لنماذج إشعارات الدفع؟
تدرج وثائق Braze نماذج البريد الإلكتروني، وwebhook، والروابط، وكتل المحتوى، ونماذج Canvas. تعتمد فرق إشعارات الدفع على كتل المحتوى ونماذج Canvas وخيار "النسخ من متغير" (Copy from Variant) لإعادة الاستخدام. تتغير الميزات باستمرار، لذا تحقق من الوثائق الحالية قبل التخطيط بناءً على ذلك.
2. هل تؤدي التعديلات على كتلة المحتوى إلى تغيير الرسائل النشطة حالياً؟
كتل المحتوى التي يتم إدراجها عبر Liquid تكون مرتبطة بالأصل وتعكس أي تغييرات تطرأ على النموذج. تحقق من قائمة الإدراج قبل إجراء أي تعديلات.
3. هل يمكنني إعادة تسمية كتلة المحتوى بعد حفظها؟
لا. تنص الوثائق على أنه لا يمكن تغيير الأسماء بعد حفظ الكتلة، كما لا يمكن إعادة استخدام الاسم حتى لو تمت أرشفة الكتلة.
4. ما هو الطول المناسب لعنوان إشعار الدفع على نظام iOS؟
يعرض نظام iOS العنوان في سطر واحد. توصي Braze باستخدام ما يقرب من 30 إلى 40 حرفاً لكل سطر في العنوان أو نص الرسالة، كإرشادات توجيهية وليس كقاعدة ثابتة.
5. ماذا يحدث إذا كان الاسم الأول مفقوداً من الملف الشخصي؟
بدون قيمة افتراضية، سيظهر الحقل فارغاً في الرسالة. أما مع وجود قيمة افتراضية، فسيظهر النص البديل للقيم الفارغة، ولكن ليس للقيم الخالية.
المصادر
- Braze،القوالبتم الاسترجاع في 25 أكتوبر 2026.
- Braze،كتل المحتوىتم الاسترجاع في 25 أكتوبر 2026.
- Braze،إنشاء قالب Canvasتم الاسترجاع في 25 أكتوبر 2026.
- Braze،إنشاء رسالة دفعتم الاسترجاع في 25 أكتوبر 2026.
- Braze،إنشاء إشعارات دفع غنية لنظام iOSتم الاسترجاع في 25 أكتوبر 2026.
- Braze،تعيين القيم الافتراضيةتم الاسترجاع في 25 أكتوبر 2026.
- بقلم CustomerIK، شريك تنفيذ معتمد لـ Braze.
CustomerIK هي شريك تنفيذ لـ Braze، وتعمل في مجالات الإعداد، والتكامل التقني، وعمليات التسويق، وإدارة بيانات العملاء.
إذا كنت ترغب في إعداد نظام قوالب لإشعارات الدفع وقائمة مراجعة للإطلاق في مساحة عمل Braze الخاصة بك، فلنتحدث.
.svg)
