حملات In-app
اعرض رسائل مستهدفة للمستخدمين أثناء استخدامهم النشط لتطبيقك. لا تحتاج رسائل In-app إلى إذن، ويمكن أن تتضمن محتوى غنيًا تفاعليًا، وتوجد بجوار Push وEmail في معالج Campaign الموحد.
نظرة عامة
تتيح لك حملات In-app:
- تهيئة المستخدمين الجدد بنصائح ودروس مفيدة.
- إعلان الميزات وتحديثات المنتج.
- زيادة التفاعل عبر المطالبات وCTAs.
- الترويج للعروض برسائل سياقية.
- إجراء التجارب بنسخ A/B ومجموعات تحكم.
المزايا الأساسية:
- لا تتطلب إذنًا، بخلاف Push.
- محتوى غني وتفاعلي.
- مرتبطة بنشاط المستخدم الحالي.
- معدلات تفاعل أعلى من Push أو Email.
- يُعرض بخطوط التطبيق وألوانه ووضعه الداكن (الرسائل الأصلية).
المتطلبات الأساسية
تأكد أولًا من دمج SDK:
يزامن SDK الحملات المؤهلة ويعرضها عندما يطابق المستخدم شروط المشغّل والاستهداف.
أنواع الرسائل
اختر التخطيط الذي يناسب حالة الاستخدام:
| النوع | التخطيط | الأنسب لـ |
|---|---|---|
| Modal | وسط الشاشة مع خلفية | الإعلانات المهمة وإطلاق الميزات |
| Banner | شريط علوي أو سفلي | نصائح سريعة وعروض حساسة للوقت |
| Slide-up | يظهر من الأسفل | مطالبات خفيفة وفتح الإنجازات |
| Fullscreen | يغطي الشاشة كاملة | التهيئة والتحديثات الكبيرة |
| Custom | عرض يحدده المطور، يُضبط من API | متطلبات UI فريدة |
إنشاء حملة In-app
تستخدم حملات In-app المعالج نفسه ذي الخطوات الست مثل القنوات الأخرى؛ راجع إنشاء الحملات للغلاف المشترك. الخطوتان المختلفتان هما Compose وDelivery.
خطوة Compose
تستخدم خطوة Compose VariantTabs مع منتقي طرق من 3 بطاقات، وهو البوابة نفسها في Email:
- Create with Drag & Drop: محرر مرئي لغير المطورين.
- Create with HTML: عرض مقسم بمحرر كود يسارًا ومعاينة iframe معزولة حية يمينًا.
- Create from Template: اختر من قوالب In-app المحفوظة.
أيًا كانت الطريقة، يُخزن HTML المنشأ في customContent للنسخة. بعد إنشاء النسخة، تُختصر إلى بطاقة AuthoredSummary مع صورة مصغرة 200×220 داخل iframe للرسالة المعروضة؛ انقرها لإعادة فتح المحرر.
رسائل HTML تتطلب موافقة صريحة من التطبيق
تنتج الطرق الثلاث أعلاه HTML يعرضه التطبيق داخل web view. لا تعمل السكربتات المكتوبة داخل الرسالة هناك - فجسر حزمة SDK نفسها يتولى الأزرار والنماذج - لكن web view داخل التطبيق يبقى قرارًا لمطوري التطبيق، لذا لن تعرض حزمة SDK رسالة HTML ما لم يفعّلوا ذلك صراحةً (allowHtmlJsInAppMessages).
التطبيق الذي لم يفعّل ذلك يتجاهل حملات HTML بصمت - ولا يرى المستخدم شيئًا. إن لم تكن متأكدًا، راجع المطورين قبل جدولة حملة HTML، أو استخدم رسالة أصلية بدلًا منها.
أقصى عرض وHTML متجاوب
لرسالة Modal أو Slide-up المبنية بـ Drag & drop أو HTML أو من قالب إعداد أقصى عرض بالبكسل. تجده في بطاقة النسخة بعد كتابة الرسالة، وفي شريط أدوات المحرر بجانب خلفية الرسالة، وفي محرر HTML فوق الكود، وفي خطوة in-app ضمن الرحلة، وفي قالب in-app نفسه. اتركه فارغًا لاستخدام القيمة الافتراضية - 600 px لـ Modal و400 px لـ Slide-up - أو أدخل رقمًا صحيحًا من 240 إلى 1200. يمتد Banner وFullscreen على الشاشة كلها فلا يأخذان أقصى عرض، والرسائل الأصلية ترسم بطاقتها الخاصة.
تحصل الرسالة على عرضها قبل أن يُرتَّب محتواها: الأصغر بين أقصى عرض وعرض الشاشة ناقص هامش صغير (16 px من كل جانب على الويب، وهوامش التطبيق نفسه على iOS وAndroid). ويتبع الارتفاع وحده المحتوى. يظهر تصميم بعرض 680 px بعرض 680 px في متصفح الحاسوب، ويتسع للشاشة على الهاتف.
اكتب HTML متجاوبًا. ترى استعلامات الوسائط (media queries) العرض الحقيقي للرسالة حتى أقصى عرض: يتحقق @media (max-width: 560px) داخل الرسالة عندما يكون عرض الرسالة نفسها 560 px أو أقل، أيًا كان حجم المتصفح. صمّم لأقصى عرض بوصفه الحالة الأعرض، ودع استعلامات الوسائط ترتب الأعمدة فوق بعضها تحته. أعطِ الحاوية الخارجية width: 100% أو max-width بدلًا من عرض ثابت أعرض من هاتف صغير (نحو 320 px).
تستخدم المعاينة في المحررات القاعدة نفسها على سطحي App وWeb، فتعمل نقاط التوقف هناك تمامًا كما تعمل على الجهاز.
متى يسري: على الويب فور تحديث الواجهة الخلفية (backend). وعلى iOS وAndroid مع الإصدار التالي من SDK، وحتى ذلك الحين تحتفظ التطبيقات بتخطيطها الحالي (عرض الشاشة ناقص الهوامش، فيظهر Modal على الجهاز اللوحي بالعرض الكامل). تطبيقات React Native وUnity ترسم الرسائل بنفسها: من ذلك الإصدار تتلقى القيمة باسم maxWidth / MaxWidth لتحدد بها عرض الـ web view.
الرسائل الأصلية
الرسالة الأصلية محتوى منظَّم - عنوان ونص وصورة وحتى ثلاثة أزرار - يرسمه التطبيق بمكوناته الخاصة. لا يوجد web view ولا تجاهل، لذا تُعرض في كل تطبيق بغض النظر عن الإعداد أعلاه، وتطابق خطوط التطبيق وألوانه ووضعه الداكن، وتعمل مع قارئات الشاشة.
المقابل هو التحكم: أنت تختار الكلمات والصورة والأزرار، والتطبيق يقرر شكلها.
| الأصلية | HTML | |
|---|---|---|
| تُعرض دون موافقة التطبيق | نعم | لا |
| تطابق تصميم التطبيق | نعم | فقط إذا أعدت بناءه بـ CSS |
| تحكم كامل في التخطيط | لا | نعم |
| تعمل حيث لا يوجد web view (مثل tvOS) | نعم | لا |
يُكتب المحتوى الأصلي في بطاقة App style ضمن خطوة Compose، إلى جانب Drag & Drop وHTML. وإذا كنت تنشئ الحملات عبر واجهة API فراجع Campaigns API لمرجع الحقول.
الألوان والخط وCSS المخصص
ضمن Style (optional) يمكنك تجاوز خلفية البطاقة ولون النص ولون الزر الرئيسي ونص الزر ونصف قطر الزوايا. اترك الحقل فارغًا فترث الرسالة قيمته من التطبيق - وهذا بالضبط ما يجعل الرسالة الأصلية تبدو جزءًا منه، فلا تغيّر شيئًا إلا حين تحتاج الحملة إلى حضور للعلامة التجارية.
إذا ضبطت لون الزر دون لون النص، يُختار لون النص تلقائيًا - أسود أو أبيض، أيهما يبقى مقروءًا فوق لونك.
خياران يعملان على الويب فقط:
- الخط - لا يستطيع التطبيق عرض سوى الخطوط المرفقة معه، فاسم خط لا يملكه سيؤدي إلى بديل يبدو خاطئًا. تحتفظ الهواتف بخط التطبيق نفسه.
- CSS مخصص، ضمن Advanced - لكل ما لا تعبّر عنه الحقول. تُعاد كتابة كل محدِّد تكتبه ليقع داخل هذه الرسالة قبل تطبيقه، فلا تصل أي قاعدة إلى بقية الصفحة، والقواعد هنا تتجاوز حقول الألوان أعلاه. لا توجد في الهواتف محركات CSS فتتجاهله.
ما يمكن استهدافه: البطاقة نفسها، وh2 (العنوان)، وp (نص الرسالة)، وbutton.primary وbutton.secondary. تُتاح حقول الألوان أيضًا كمتغيرات CSS - --joryio-inapp-bg و--joryio-inapp-fg و--joryio-inapp-primary و--joryio-inapp-primary-fg و--joryio-inapp-radius و--joryio-inapp-font - بحيث يمكنك ضبطها داخل media query.
تعمل تبويبات نسخ A/B نفسها مع In-app، بما فيها مجموعات التحكم.
جعل الأزرار تعمل
تعمل رسالة HTML المخصصة داخل إطار معزول (sandbox) على الويب وداخل web view التطبيق على iOS وAndroid، بمجرد أن يسمح SDK التطبيق برسائل HTML. لا يمكنها الوصول مباشرةً إلى صفحتك أو صفحتنا؛ بدلاً من ذلك توفّر Joryio جسراً صغيراً.
الأنماط: مضمّنة فقط. ضع CSS في كتلة <style> أعلى HTML أو في سمات style. تعرض التطبيقات الرسالة تحت سياسة أمان صارمة تسمح بالأنماط المضمّنة والصور والخطوط والوسائط عبر https ولا شيء غيرها - ورقة الأنماط المجلوبة من CDN عبر <link> لا تُحمَّل على أي جهاز، فانسخ ما تحتاجه إلى كتلة <style>.
ما يعمل على الجهاز. يحتفظ Joryio بترميزك كما كتبته عند حفظ الرسالة (تُزال فقط <base> و<meta http-equiv="refresh"> ويُصلَح الترميز المعطوب)، لكن التطبيقات تشغّله تحت سياسة الأمان هذه: كتل <script> الخاصة بك ومعالجات onclick المضمّنة وتضمينات <iframe> (فيديو YouTube) لا تعمل على الويب أو iOS أو Android. تعمل الأزرار والروابط وسمات data-joryio-action ونماذج data-jry-form عبر جسر Joryio - انظر أدناه - ولا تحتاج إلى برنامج نصي. تُهرَّب قيم التخصيص دائمًا كـ HTML، فلا يصبح حقل في الملف الشخصي كودًا أبدًا (أضف | raw عمدًا عندما تحتاج ترميزًا من حقل). تعرض المعاينة في الحملة التخطيط وتسرد إجراءات الجسر التي تطلقها أزرارك؛ وهي لا تضمن أن البرنامج النصي سيعمل على الجهاز.
data-joryio-action - الطريقة المعتادة
<button data-joryio-action="requestPushPermission">تفعيل الإشعارات</button>
<button data-joryio-action="closeMessage">لا، شكراً</button>
| العملية | ما تفعله |
|---|---|
requestPushPermission | تعرض طلب الإشعارات في المتصفح |
closeMessage | تغلق الرسالة |
logConversion | تسجّل تحويلاً لهذه الحملة |
يمكن تمرير اسم إلى logConversion عبر data-joryio-event؛ وبدونه يُسجَّل التحويل
باسم in_app_conversion.
كل ذلك متاح أيضاً في لوحة الخصائص في المحرر - On click وConversion event (optional) وClick name (reports) - لذا معظم الرسائل لا تحتاج إلى HTML.
النقرات تُسجَّل تلقائياً
كل نقرة على <a> أو <button> يتم الإبلاغ عنها تلقائياً. لتسمية نقرة في التقارير،
أضف data-action:
<a href="/pricing" data-action="pricing_cta">اطّلع على الخطط</a>
روابط http(s) والروابط النسبية للجذر تُفتح من الصفحة المضيفة؛ أما المرساة و
mailto: وtel: فتعمل كالمعتاد.
window.joryioBridge - ما تستدعيه أزرارك
خلف data-joryio-action يقف جسر حزمة SDK، أي window.joryioBridge. سكربت الحزمة هو السكربت الوحيد الذي يعمل في الرسالة، وهو ينفذ هذه الدوال نيابة عنك:
| الدالة | الغرض |
|---|---|
logCustomEvent(name, properties) | تسجيل حدث للمستخدم |
setCustomUserAttribute(key, value) | كتابة سمة في الملف الشخصي |
logConversion(event) | تسجيل تحويل لهذه الحملة |
logClick(action) | تسجيل نقرة بالاسم |
changeUser(userId) | تعريف الزائر |
requestPushPermission() | عرض طلب الإشعارات |
navigate(url, target) | فتح رابط من الصفحة المضيفة |
closeMessage() | إغلاق الرسالة |
يمكن لـ data-joryio-action أن يسمّي أيًّا منها ويمرر وسيطًا واحدًا في data-joryio-event - مثلًا data-joryio-action="logCustomEvent" data-joryio-event="size_selected". أما الدالة التي تحتاج وسيطين، مثل setCustomUserAttribute، فلا يمكن تشغيلها من الترميز. ولا تعمل كتلة <script> أو onclick="joryioBridge.closeMessage()" المضمّن إذا كُتبا داخل الرسالة، لذا لا يمكنهما استدعاء الجسر أيضًا.
الجسر الكامل متاح على الويب وiOS وAndroid (من إصدارات SDK لـ iOS وAndroid التي تتضمنه - logCustomEvent وsetCustomUserAttribute وchangeUser وrequestPushPermission وlogConversion وlogClick وnavigate وcloseMessage وsubmitForm؛ الإصدارات الأصلية الأقدم تعرض فقط closeMessage وnavigate وتسجيل النقرات). تعرض تطبيقات React Native وUnity الرسائل عبر حزم SDK الأصلية لـ iOS وAndroid، لذا ينطبق الجسر نفسه. أما التطبيق الذي يرسم الرسائل في web view خاص به (onInAppMessage في React Native، وSetInAppMessageHandler في Unity) فيقرر بنفسه ما يعمل هناك، ويرسل النماذج عبر submitInAppForm / SubmitInAppForm. تستخدم الرسائل الأصلية أزرار التطبيق نفسه، لذا اربط CTA الخاصة بها عبر إعداد أزرار الحملة لا عبر الترميز.
خطوة Delivery
صُممت خطوة Delivery لحملات In-app خصيصًا: بدل منتقي نوع الإرسال الذي تستخدمه القنوات الأخرى، تحصل على ما يلي.
منتقي مشغّل رئيسي
صف من خمس بطاقات، مع تعليم On Event بـ RECOMMENDED:
| المشغّل | متى تظهر الرسالة |
|---|---|
| Immediate | في جلسة المستخدم المؤهلة التالية. |
| On Event، موصى به | عند إطلاق حدث متتبع للمستخدم. |
| Push Notification Tap | بعد أن تقود نقرة Push المستخدم إلى تطبيقك. |
| Attribute Change | عند تغير قيمة سمة مراقبة. |
| Attribute Threshold | عند عبور سمة رقمية حدًا. |
لكل بطاقة عنوان فرعي من سطر ووصف أطول. يكشف اختيارها إعدادًا خاصًا بالوضع في لوحة رمادية ناعمة أسفلها:
- Immediate: لا إعداد إضافيًا؛ فقط تأخير العرض المشترك أدناه.
- On Event: منتقي حدث قابل للبحث مع بديل
+ Create eventوشروط خصائص اختيارية. - Push Notification Tap: مقتطف للنسخ واللصق يوضح ربط SDK بمعرف الحملة.
- Attribute Change: منتقي سمة وحقلا قيمة من/إلى.
- Attribute Threshold: منتقي سمة وعامل (
>,<,≥,≤,=) وقيمة حد.
تأخير العرض
يتشارك كل وضع مشغّل في حقل Display delay واحد. أدخل المدة بالثواني أو الدقائق أو الساعات عبر منتقي الوحدة؛ تنتظر الرسالة هذه المدة بعد إطلاق المشغّل قبل الظهور.
الجدولة
اختر تاريخي starts at وexpires at بمنطقتين زمنيتين مستقلتين. يثبت منتقي المنطقة workspace default في الأعلى، ثم Recipient local time، ثم قائمة IANA الكاملة، لتظهر الحالات الشائعة أولًا. اكتب في الحقل للبحث بالمدينة أو الدولة أو فرق التوقيت عن UTC؛ تتنقل مفاتيح الأسهم بين النتائج ويختار Enter إحداها.
يُقرأ الوقت الذي تختاره وفق المنطقة التي اخترتها: 09:00 مع America/New_York يبدأ الحملة في الساعة 09:00 بتوقيت نيويورك أينما كنت عند الحفظ، ويعرض المحرر الساعة 09:00 نفسها لمن يفتحه لاحقًا. يقرأ Recipient local time الوقت وفق سمة timezone لكل شخص - تبدأ الحملة في 09:00 لجهة اتصال في طوكيو، وبعد ساعات في 09:00 لجهة اتصال في نيويورك؛ وتستخدم جهة الاتصال التي لا تملك سمة منطقة زمنية المنطقة الزمنية لمساحة العمل. يتبع منتقي الانتهاء منطقة البدء ما لم تمنحه منطقة خاصة به.
حدود التكرار
تحوي بطاقة واحدة عناصر تحكم التكرار:
- Max impressions per user: مثل 3 مرات.
- Time window: 1h / 24h / 7d / 30d / 90d / lifetime، أو نافذة مخصصة.
- Min delay between impressions: أقل فجوة بين مرات الظهور المتتالية.
يُحتسب العرض فقط: انطباع يبلغ عنه الجهاز (تم العرض، أو الإغلاق من عميل يبلغ عن الإغلاق فقط). الصفحة التي حمّلت الرسالة ثم غادرها الزائر قبل ظهورها لا تستهلك حد التكرار. ولكي لا يعرض جهازان في اللحظة نفسها رسالة مخصصة لمرة واحدة، تحجز الرسالة التي سُلّمت إلى جهاز مكانها لمدة دقيقتين حتى يؤكد الجهاز عرضها. لا يبلغ الجهاز عن عرض الرسالة إلا بعد بقائها على الشاشة نحو ثانية، أو عندما ينقر عليها الشخص أو يغلقها قبل ذلك، لذا فالرسالة التي ظهرت لحظيًا أثناء إعادة توجيه أو تغيير شاشة لا تستهلك الحد أيضًا.
أسفلها بطاقة منفصلة Workspace touching rules تقدم مفتاح Ignore Touching Rules. تجاوز قواعد التواصل مناسب للرسائل المعاملية أو الحرجة لكنه لا ينبغي أن يكون افتراضيًا.
- لا تغمر المستخدمين بعدة رسائل In-app في الجلسة نفسها.
- باعد مرات الظهور؛ فجوة 24h+ افتراضية جيدة.
- احجز "Ignore Touching Rules" للرسائل الحرجة فعلًا.
وضع التقييم
منتقي من 3 بطاقات، لا قائمة منسدلة لأن المفاضلات مهمة جدًا لإخفائها:
| الوضع | الكمون | ما تحصل عليه | ما تتخلى عنه |
|---|---|---|---|
| Differential Sync، موصى به | ~80ms | حملات غير محدودة واستهداف كامل بالشرائح/الكيانات/السلوك وبيانات الكيان في القوالب. | رحلة ذهاب وإياب إلى الخادم عند تغير السمات المراقبة. |
| Session start only | <10ms | تقييم مرة عند بداية الجلسة. | لا تظهر التغييرات قبل بدء جلسة جديدة. |
يحتفظ كلا الوضعين بالحملات المتزامنة على الجهاز ويُطلقان المحفزات محليًا، لذا تظهر الرسالة دون طلب شبكة لحظة العرض.
تشرح لوحة نصية تفصيلية أسفل البطاقات الوضع المختار. Differential Sync هو الخيار الصحيح لمعظم حالات الإنتاج.
العرض من الخادم
في وضعي Differential Sync وSession start only، يُعرض محتوى الرسالة على الخادم قبل وصوله إلى الجهاز: تُحل رموز التخصيص وContent Blocks وبيانات الكتالوج من الخادم. وبذلك تملك رسائل In-app قدرة العرض نفسها لـ Email: تعمل بيانات الكيان ومقتطفات blocks.* وعمليات بحث كتالوج المنتجات.
استخدم زر Server render test في منشئ حملة In-app لعرض رسالتك من الخادم لمستخدم تختاره ورؤية ما سيتلقاه SDK بالضبط. تحقق من التخصيص والكتل ومخرجات الكتالوج قبل تفعيل الحملة.
الإعدادات المتقدمة
لوحة مطوية أسفل بطاقة التقييم. عند فتحها:
Watch mode: يتحكم في وقت إعادة SDK تقييم أهلية الحملة بعد تغير السمات:
- Auto، موصى به: يكتشف SDK تلقائيًا السمات التي يعتمد عليها استهداف الحملة وقوالبها ويعيد التقييم عند تغيرها.
- Always: يعيد التقييم مع كل تغير سمة.
- Never: بداية الجلسة فقط.
Priority tiebreaker: يستخدم عندما تشترك حملتان مؤهلتان في الأولوية نفسها:
- Newest، الافتراضي: أظهر أحدث حملة أنشئت أولًا.
- Oldest: أظهر أقدم حملة أولًا، FIFO.
- Random: اختيار عشوائي من الحملات المؤهلة.
اختلافات خطوة Audience
تعمل خطوة Audience مثل القنوات الأخرى: منتقي الوضع نفسه ومنشئ الفلاتر v2 نفسه، مع جزء واحد مخفي:
- تُخفى بطاقة Sending options. لا يوجد مفهوم اشتراك لرسائل In-app؛ يعرضها SDK بصرف النظر عن حالة قبول Email/SMS/Push.
يستخدم تنبيه "Send to everyone" الكهرماني نصًا مختلفًا: مخاطر In-app هي إرهاق modal واستنزاف حدود التكرار لا قابلية التسليم. وتتغير شرائح الفلاتر المثال إلى last_seen within 7 days وplan = free.
العرض في. عندما تحتوي مساحة العمل على أكثر من تطبيق، تسأل خطوة Audience أيضًا عن التطبيق الذي يعرض الرسالة: كل التطبيقات (الافتراضي) أو تطبيق واحد - مثلًا Web App لمتجر Magento فقط، أو تطبيق iOS فقط. لا يتلقاها SDK أي تطبيق آخر. ولخطوة الرسالة داخل التطبيق في الرحلة الإعداد نفسه العرض في.
التخصيص باستخدام Liquid
تدعم قوالب In-app صيغة Liquid كاملة.*`:
Hi {{ user.firstName | default: "there" }},
You've earned {{ user.points }} points!
{% if user.plan == 'free' %}
<p>Upgrade to unlock more rewards.</p>
{% else %}
<p>Thanks for being a {{ user.plan }} member!</p>
{% endif %}
Latest order: #{{ entities.order.id }} ({{ entities.order.total | currency }})
تشمل الفلاتر المتاحة date_format وpluralize وcurrency وtruncate وdefault. راجع قوالب Liquid للمرجع الكامل.
تتبع نقرات الروابط
تُتبع نقرات الروابط داخل رسائل In-app تلقائيًا وتُنسب إلى الحملة؛ لا إعداد إضافيًا ولا إعادة كتابة للوسوم من جانبك. تظهر أعداد النقرات في تحليلات الحملة بجوار مرات الظهور، فتقيس click-through وتستخدم النقرات كإشارات تحويل في اختبارات A/B.
تحمل كل نقرة أيضًا الاسم الذي أعطته لها الرسالة: data-action الخاص بالعنصر، أو استدعاء logClick من الجسر، أو link_click / cta_click من SDK نفسه. افتح إصدارًا من تحليلات الحملة وانتقل إلى خريطة النقرات: يحمل كل زر ورابط في الرسالة عدد الأشخاص الذين نقروا عليه ونسبتهم من كل من شاهدها، وتُرتّب القائمة المجاورة النقرات حسب الزر. الرسالة الأصلية (بدون HTML) تعرض القائمة فقط. تتطلب الأسماء إصدارات SDK من 26-09-2026 فما بعد؛ يبلّغ SDK الأقدم عن كل نقرة كنقرة عادية بلا اسم.
اختبار A/B
يدعم In-app تبويبات نسخ A/B نفسها لكل القنوات، بما فيها مجموعات التحكم. يكون تعيين النسخة حتميًا: في أول تقييم للمستخدم يُجزّأ user id إلى bucket وزن ويحفظ التعيين، لذا يرى المستخدم نفسه النسخة نفسها دائمًا.
لا ترى مجموعات التحكم رسالة؛ تُحجب بالكامل، لتتمكن من قياس الرفع الإضافي للحملة مقارنة بعدم فعل شيء عبر مقارنة معدلات التحويل.
Variant A: 45% - Show campaign
Variant B: 45% - Show alternative
Control: 10% - Show nothing
Variant A conversion: 5%
Control conversion: 2%
Lift: +150%
النماذج داخل الرسائل
يمكن أن تحمل الرسالة داخل التطبيق نموذجًا: في محرر السحب والإفلات، تضم فئة الكتل Form نموذج اشتراك وحقول بريد وهاتف ونص وقائمة منسدلة واختيار وموافقة، وزر إرسال (الكتل نفسها المستخدمة في صفحات الهبوط). أعطِ كل حقل مفتاح حقل (أحرف صغيرة وشرطات سفلية). يعرض عرض النموذج في شريط المحرر ما يعلنه الترميز ويتيح لك تحديد وجهة كل قيمة: السمة التي تُكتب في الملف الشخصي، والقائمة التي يشترك فيها مربع الموافقة، وما يحدث بعد الإرسال (رسالة في مكانها، أو عنوان URL).
عند الإرسال، يرسل SDK القيم مع الهوية التي يحملها: يُحدَّث ملف المستخدم المعروف (البريد أو الهاتف فقط حيث لا يملك الملف أيًا منهما - النموذج لا يستبدلهما أبدًا)، ويصبح الزائر المجهول ملفًا شخصيًا بمجرد أن يسميه النموذج (بريد أو هاتف)، وتُشترك القوائم المحددة، ويُسجَّل In-App Form Submitted مع campaignId وcampaignName وvariantId ومفاتيح الحقول وlistsSubscribed، وemail وphone الخاصين بالنموذج مع phoneUpdated (false عندما احتفظ الملف بهاتف مختلف خاص به)، لتتصرف الرحلات والحملات المحفَّزة والشرائح بناءً عليه. يظهر الإرسال أيضًا كنقرة (form_submit) على الرسالة.
تحتفظ القوالب بنموذجها مع القالب؛ وترثه الحملة التي تستخدم القالب. مدعوم في Web SDK، ومن الإصدارات التي تتضمن الجسر الكامل في SDK لـ iOS وAndroid؛ تطبيق React Native الذي يعرض HTML بنفسه يستدعي submitInAppForm؛ ويعرض Unity الرسائل الأصلية فقط.
المحرر نفسه وعرض النموذج نفسه متاحان أيضًا في خطوة الرسالة داخل التطبيق في الرحلة: النموذج في رسالة تحملها الخطوة بنفسها، أو في القالب الذي تستخدمه، يُرسَل كما في الحملة، ويكون campaignId للإرسال هو معرّف خطوة الرحلة (journey:<معرّف الرحلة>:<معرّف الخطوة>). إزالة النموذج من التصميم تزيل إعدادات حقوله أيضًا؛ والنموذج الذي يُضاف من جديد يبدأ من الإعدادات الافتراضية.
أفضل الممارسات
ابدأ بـ Differential Sync
يجب أن تعمل معظم الحملات في Differential Sync: فهو يقدم أفضل توازن بين الخصائص والأداء.### استخدم Auto Watch mode
دع SDK يكتشف تبعيات السمات. بدّل إلى Always فقط إن احتجت مراقبة سمات لا تُستخدم مباشرة في الاستهداف؛ وبدّل إلى Never فقط لرسائل الترحيب الثابتة.
نفّذ حدود التكرار
افتراضيًا، يرى كل مستخدم الحملة مرة واحدة. التكرار شيء تُفعّله: حدِّد Allow this campaign to show more than once per user ضمن Frequency Capping. إذا تركته معطلًا، تُعرض الرسالة مرة واحدة لكل شخص، إلى الأبد - بلا نافذة زمنية وبلا انتهاء.
عند تفعيله، اترك الحد فارغًا لعدد غير محدود، أو حدِّد رقمًا ونافذة زمنية (دقائق أو ساعات أو أيام أو أسابيع أو أشهر). النافذة تخص العدّ فقط؛ أما Min Delay أسفلها فهي فترة تهدئة منفصلة بين عرضين.
امنع إرهاق الرسائل:
- تفاعل مرتفع: 3 مرات ظهور كل 7 أيام.
- متوسط: مرتان كل 14 يومًا.
- تكرار منخفض: مرة كل 30 يومًا.
اختبر نسخ A/B
ضمّن دائمًا مجموعات تحكم عند قياس أثر التحويل. التقسيم الموصى به: 45% / 45% / 10% تحكم.
استكشاف الأخطاء وإصلاحها
الحملة لا تظهر
تحقق بالترتيب:
- حالة الحملة
activeوليستdraft. - تشمل الجدولة الوقت الحالي، بين
startsAtوexpiresAt. - يطابق المستخدم فلاتر الاستهداف.
- لم يتجاوز حد التكرار لهذا المستخدم.
- لا توجد حملة أعلى أولوية تحجبها.
- ليس المستخدم ضمن مجموعة تحكم.
أخطاء قالب Liquid
- سمات مفقودة: غلفها بـ
| default: "fallback". - صيغة خاطئة: تحقق من
{% endif %}و{% endfor %}المتطابقين.
مشكلات الأداء
- بسّط منطق الاستهداف.
- حسّن قوالب Liquid وتجنب الحلقات الثقيلة.
- استخدم Session-start only للرسائل الثابتة.
In-app مقابل Push
| الميزة | In-app | Push |
|---|---|---|
| الإذن | غير مطلوب | مطلوب |
| وقت الظهور | عندما يكون التطبيق مفتوحًا | في أي وقت |
| المحتوى الغني | نعم | محدود |
| التفاعل | مرتفع | محدود |
| الوصول | المستخدمون النشطون فقط | كل مستخدمي SDK المثبت |
| الأفضل لـ | تفاعل سياقي | إعادة تفاعل |
استخدمهما معًا: Push لدفع فتح التطبيق، وIn-app لتفاعل المستخدمين النشطين.
الخطوات التالية
- إنشاء الحملات: مرجع المعالج المشترك.
- إشعارات Push
- اختبار A/B
- قوالب Liquid