إنه يوم الجمعة الثالث في الربع، وأنت تنظر إلى لوحة معلومات الاحتفاظ الخاصة بك. تسلسل سلة التسوق المهجورة قيد التشغيل. مشغل التخلي عن التصفح قيد التشغيل. طلب مراجعة ما بعد الشراء قيد التشغيل. تنبيه انخفاض السعر قيد التشغيل. تذهب إشعارات الترحيب عند كل تسجيل. ستة إشعارات دفع "آلية". ستة مشغلات موصلة على مدار الثمانية عشر شهرًا الماضية. توقف معدل تكرار الشراء عن الحركة قبل اثني عشر شهرًا.
هذا ما تبدو عليه أتمتة الإشعارات الفورية للتجارة الإلكترونية في معظم أنظمة الاحتفاظ متوسطة السوق: ستة مشغلات منفصلة، كل منها يشحن نسخًا من مالك حملة مختلف، ولا أحد منهم على علم بالآخرين. تستمر سلسلة التخلي عن سلة التسوق في إطلاق إشعارات للمشتركين الذين اشتروا بالفعل. تتداخل حملة استعادة العملاء مع تنبيه انخفاض السعر لنفس العميل. لا يوجد منطق مشترك، ولا معايير خروج مشتركة، ولا هوية مشتركة. مجرد ستة أنابيب منفصلة، كل منها موجه إلى نفس قائمة المشتركين، وكل منها يتظاهر بأن الخمسة الآخرين غير موجودين.
لا ينبغي أن تعمل أتمتة الإشعارات الفورية للتجارة الإلكترونية بهذه الطريقة. يجب أن تعمل كبنية سير عمل واحدة: مجموعة من الرحلات متعددة العقد مع مشغلات مشتركة، ومنطق قرار مشترك، ومعايير خروج مشتركة، تعمل عبر إشعارات الويب، وإشعارات التطبيق، وواتساب، والدردشة الحية من هوية مشترك واحدة. تتناول هذه المقالة ما تبدو عليه بنية سير العمل هذه، وتقدم خمسة مخططات سير عمل كاملة يمكنك استخدامها، وتوضح كيفية قراءة مسار التحويل لكل سير عمل بحيث يمكن الدفاع عن البند المالي أمام قسم المالية.
معظم "الإشعارات الفورية الآلية" ليست آلية في الواقع
كلمة الأتمتة قامت بالكثير من العمل غير المكتسب في دوائر مدونات التجارة الإلكترونية. عندما تقول معظم المقالات "إشعارات فورية آلية"، فإن ما تعنيه هو "إشعارات فورية مشغلة": إشعارات فردية يتم إطلاقها عند وقوع حدث، دون مزيد من الحالة، ولا انتظار، ولا تفرع، ولا شروط خروج. يتخلى المشترك عن سلة التسوق، ويتم إطلاق إشعار التخلي عن سلة التسوق. يعرض المشترك منتجًا، ويتم إطلاق إشعار التصفح. يشتري المشترك، ويتم إطلاق إشعار ما بعد الشراء. كل مشغل هو خط أنابيب خاص به، جاهل بكل مشغل آخر.
سير العمل هو شيء مختلف. سير العمل هو رحلة متعددة الخطوات مع حالة. إنه يعرف مكان دخول المشترك، وأين هو حاليًا، ومتى دخل كل عقدة، وما هي الشروط التي تلغي الرحلة. لا يطلق سير عمل التخلي عن سلة التسوق إشعارًا واحدًا فقط في علامة الساعة الواحدة. يتم إطلاقه في الساعة الواحدة، وينتظر يومًا، ويتحقق مما إذا كانت سلة التسوق لا تزال مهجورة، ويطلق لمسة ثانية بخصم، وينتظر يومين آخرين، ويطلق لمسة نهائية، ويخرج من سير العمل في اللحظة التي يشتري فيها المشترك، بغض النظر عن الخطوة التي كان عليها.
هذا البند الأخير هو الفرق. المشغل ليس لديه ذاكرة. سير العمل لديه. إذا استمرت "أتمتة سلة التسوق المهجورة" في إرسال تذكيرات بعد أن دفع العميل بالفعل، فأنت لا تملك أتمتة. لديك مشغل لم يخبره أحد بالتوقف.
بالنسبة لفريق الاحتفاظ بالعملاء في التجارة الإلكترونية للسوق المتوسط، فإن هذا التمييز هو الفرق بين معدل الشراء المتكرر الذي يتضاعف وتلك التي تتعثر. ستة مشغلات تعمل بالتوازي تنتج ست قنوات من الضوضاء. خمسة مسارات عمل تعمل بالتنسيق تنتج رحلة واحدة لكل مشترك، متفرعة ومحددة. معظم نتائج البحث في الصفحة الأولى لهذه الكلمة المفتاحية تؤطر المشكلة على أنها "ما أنواع الإشعارات التي يجب إرسالها" وتجيب بقائمة من تسعة أو اثني عشر أو خمسة عشر قالبًا. هذا ليس السؤال. السؤال هو كيفية تأليف الرحلة.
تشريح سير عمل إشعارات الدفع
قبل المخططات، المفردات. يتم بناء سير عمل إشعارات الدفع من ستة أنواع من العقد. بمجرد معرفة ما يفعله كل منها، تصبح كل مخططات في هذه المقالة بمثابة رسم بياني، وليس وصفًا.
البداية. نقطة الدخول. تحدد عقدة البداية كيفية تشغيل سير العمل، إما عن طريق حدث مشترك (التخلي عن سلة التسوق، عرض الصفحة، الانضمام إلى شريحة، تتبع هدف الشراء) أو عن طريق مرشح جمهور يحدد المشتركين الذين يطابقون معايير محددة في وقت مجدول. يحتوي سير العمل على بداية واحدة بالضبط.
الانتظار. تأخير. تحتفظ عقدة الانتظار بالمشترك في هذه النقطة لمدة محددة (دقائق، ساعات، أيام) أو حتى وقت تقويمي محدد (الثلاثاء الساعة 10 صباحًا بتوقيت المشترك، 15 ديسمبر الساعة 8 مساءً بتوقيت الموقع). الانتظارات هي كيف يتعلم سير العمل ألا يكون مجرد بث لمرة واحدة.
القرار. فرع ثنائي الاتجاه. تتحقق عقدة القرار من شرط (هل اشترى المشترك، هل ما زالوا في شريحة المتخلين عن سلة التسوق، هل مستوى ولائهم "ذهبي") وتوجههم عبر المسار نعم أو المسار لا. القرارات هي كيف يتوقف سير العمل عن معاملة كل مشترك بنفس الطريقة.
تقسيم المسار. مفترق طرق قائم على النسب المئوية. تقوم عقد تقسيم المسار بتوجيه المشتركين عبر مسارات متعددة بناءً على النسب المئوية المحددة: 50/50 لاختبار A/B، 33/33/34 لاختبار وقت إرسال ثلاثي. بمجرد حصولك على فائز، تقوم بترقية المسار الفائز إلى 100٪ ويستمر سير العمل في العمل على المتغير المثبت.
الإجراء. العمل نفسه. ترسل عقد الإجراء إشعار دفع، أو تضيف المشترك إلى شريحة، أو تحدث سماته، أو تشغل خطاف ويب، أو تبدأ سير عمل آخر، أو توقف واحدًا. تدعم مسارات PushEngage أحد عشر نوعًا من الإجراءات. الأكثر شيوعًا في التجارة الإلكترونية هي SendPushNotification و AddSegment و UpdateAttribute و HttpRequest.
النهاية / الخروج. الطرفية. تحدد عقد النهاية والخروج اكتمال سير العمل وتحديث التحليلات. النهاية هي الاستنتاج الطبيعي. يستخدم الخروج عادةً للإنهاء المبكر: في المسار لا لعقدة القرار عندما لا يتأهل المشترك، أو في فرع تقسيم المسار المصمم كمجموعة تحكم.
كل سير عمل أدناه يتكون من هذه القطع الست. بمجرد مشاركة المفردات، تقرأ المخططات بسرعة.
خمسة مخططات لسير العمل للتجارة الإلكترونية
هذه ليست "أمثلة". إنها مخططات عمل. يسرد كل منها المشغل الخاص به، ونوع التشغيل، وتسلسل العقد، ومعايير الخروج، ومقياس الاحتفاظ المقصود. يمكنك رفع كل منها مباشرة إلى منشئ سير عمل PushEngage وتشغيله في أقل من ساعة.
المخطط 1 - سلسلة الترحيب
- المشغل (البدء): الحدث
PushEngage.Subscriber.Added - نوع التشغيل: فردي (رحلة ترحيب واحدة لكل مشترك، مع فترة تهدئة لمدة 90 يومًا قبل إعادة الدخول)
- التدفق: إشعار ترحيبي (فوري) → انتظر يومين → إشعار تسليط الضوء على الميزات → انتظر 3 أيام → قرار: هل قام المشترك بإجراء عملية شراء؟ → المسار نعم: إرسال إشعار شكر وإضافة إلى شريحة
العملاء→ المسار لا: إرسال خصم أول عملية شراء → إنهاء - معايير الخروج: لا شيء. الرحلة قصيرة بما يكفي بحيث يجب على كل مشترك إكمالها.
- مقياس الاحتفاظ: الوقت حتى أول عملية شراء. المشتركون الجدد الذين يكملون سلسلة الترحيب يشترون بشكل أسرع من أولئك الذين لا يفعلون ذلك، لأن اللمسة الثالثة تحدث في اللحظة التي إما أن يكون فيها قصد الشراء الأول قد تحقق أو تعثر.
المخطط 2 - التخلي عن التصفح
- المشغل (البدء): حدث مخصص
page_viewمفلتر لصفحات تفاصيل المنتج حيث لم يطلق المشترك أيضًاadd_to_cartفي غضون 30 دقيقة - نوع التشغيل: متعدد متوازي (قد يتخلى المشترك عن تصفح منتجات متعددة في جلسة واحدة، وكل منها يحصل على مثيل سير عمل خاص به)
- التدفق: انتظر 30 دقيقة → قرار: هل لا يزال المشترك يتصفح الموقع؟ → المسار نعم: إنهاء (لا تقاطع جلسة نشطة) → المسار لا: إرسال إشعار تذكير بالمنتج الذي شاهده → انتظر 24 ساعة → قرار: هل أضاف إلى عربة التسوق؟ → المسار نعم: إنهاء (سير عمل التخلي عن عربة التسوق يتولى الأمر من هنا) → المسار لا: إرسال لمسة ثانية بتوصية بمنتجات ذات صلة → إنهاء
- معايير الخروج: هدف
add_to_cart(سير عمل عربة التسوق يرث الرحلة) أو هدفpurchase(لا حاجة لمزيد من الرسائل) - مقياس الاحتفاظ: معدل التحويل من التصفح إلى عربة التسوق للمنتجات التي تم تصفحها سابقًا. تغطي مقالة PushEngage حول حملات التخلي عن التصفح عمل التقسيم الذي يرثه هذا المخطط.
المخطط 3 - تصعيد التخلي عن عربة التسوق
- المشغل (البدء): حدث مخصص
cart_abandoned - نوع التشغيل: متعدد متوازي (كل عربة تسوق تم التخلي عنها هي رحلتها الخاصة، لذا فإن المشترك الذي يتخلى عن عربة ثانية بينما لا تزال الأولى نشطة يحصل على مثيل ثانٍ متزامن)
- التدفق: انتظر ساعة واحدة → تذكير #1 (بدون خصم، نبرة ودية) → انتظر 24 ساعة → قرار: هل لا تزال عربة التسوق مهجورة؟ → المسار نعم: تذكير #2 بخصم 10٪ → انتظر 48 ساعة → قرار: هل لا تزال عربة التسوق مهجورة؟ → المسار نعم: تذكير نهائي بخصم 20٪ وتأطير إلحاحي → إنهاء
- معايير الخروج: الهدف
purchaseمطابق لـcart_idمن حدث المشغل. في اللحظة التي يشتري فيها المشترك، يتم إلغاء سير العمل لهذا العربة، بغض النظر عن مكان تواجدهم حاليًا. - مقياس الاحتفاظ: قيمة العربة المستردة لكل عربة مهجورة، لكل قناة. هذا هو سير العمل الأعلى تأثيرًا على الصفحة والأسهل في الدفاع عنه في بيان الربح والخسارة. لتغطية أعمق لتسلسل استعادة العربة المهجورة على وجه التحديد، فإن دليل PushEngage لاستعادة العربة المهجورة يشرح كيف يتم ضبط الإيقاع لسلوك المنصة (تختلف تدفقات الخروج من Shopify Plus عن WooCommerce بطرق تؤثر على الانتظار الأول).
المخطط 4 — طلب مراجعة ما بعد الشراء
- المشغل (البدء): حدث
PushEngage.Goal.Trackedحيثgoal_name = purchase - نوع التشغيل: متسلسل متعدد (رحلة طلب مراجعة نشطة واحدة في كل مرة لكل مشترك، ولكن الشراء التالي يشغل مثيلًا جديدًا)
- التدفق: انتظر 7 أيام (وقت كافٍ لاستلام المنتج وتكوين رأي) → تقسيم المسار 50/50: إرسال صباحي (9 صباحًا بتوقيت المشترك المحلي) مقابل إرسال مسائي (7 مساءً بتوقيت المشترك المحلي) → إشعار طلب المراجعة → الإجراء: طلب HTTP لتسجيل إرسال طلب المراجعة في نظام إدارة علاقات العملاء → النهاية
- ساعات الهدوء: من 10 مساءً إلى 8 صباحًا في منطقة توقيت المشترك، مع خيار
rescheduleكبديل. إشعارات الدفع التي كان من المفترض أن تصل ليلاً تنتظر حتى الساعة 8:01 صباحًا بدلاً من الإرسال. إعدادrescheduleهو الخيار الافتراضي الصحيح لسير العمل هذا لأنskipيتجاهل الإشعارات بصمت ويتركها خارج التحليلات، وهو ما لا تريده معظم فرق الاحتفاظ. - معايير الخروج: الهدف
review_submitted - مقياس الاحتفاظ: معدل تقديم المراجعات حسب متغير وقت الإرسال. يجعل المسار المقسم اختبار A/B جزءًا من سير العمل، وليس فكرة لاحقة ملحقة بتقرير حملة.
المخطط 5 — استعادة العملاء
- المشغل (البدء): مرشح الجمهور
last_active > 30 days - نوع التشغيل: فردي (محاولة استعادة عميل واحدة لكل مشترك كل 90 يومًا)
- التدفق: إشعار "نحن نفتقدك" → انتظر 3 أيام → قرار: هل تفاعل المشترك مع الإشعار أو زار الموقع؟ → المسار نعم: أضف إلى شريحة
re-engaged، أرسل شكرًا وخصمًا، النهاية → المسار لا: أرسل عرضًا أقوى بخصم أعمق → انتظر 5 أيام → قرار: لا يزال غير نشط؟ → المسار نعم: إشعار نهائي "الفرصة الأخيرة" → النهاية - معايير الخروج: مرشح الجمهور
last_active < 7 days. أصبح المشترك نشطًا من تلقاء نفسه وانتهت مهمة سير العمل. - مقياس الاحتفاظ: معدل إعادة التنشيط بعد 60 يومًا من دخول سير العمل.
كلمة عن المشغل. هذا هو المخطط الوحيد في هذه المقالة الذي يستخدم مشغلًا قائمًا على الجمهور بدلاً من مشغل قائم على الحدث. تعمل مشغلات الجمهور في تدفقات عمل PushEngage على معالجة مجموعة المشتركين المطابقين بشكل مجمع في وقت بدء تدفق العمل فقط. المشتركون الذين يصبحون غير نشطين بعد بدء تدفق العمل لا يتم تضمينهم تلقائيًا، وتحرير فلتر الجمهور على تدفق عمل نشط لا يضيف مشتركين جددًا. إذا كنت تريد برنامج إعادة مشاركة متجدد، فقم بتكرار تدفق العمل بجدول زمني متكرر (شهري أو ربع سنوي) بدلاً من توقع أن يقوم تدفق عمل جمهور واحد طويل الأمد باستيعاب مرشحين جدد باستمرار. هذا مصدر حقيقي لتذاكر دعم "لماذا لم يحصل هذا المشترك على استعادة؟" في الفرق التي يساء فهمها لنوع المشغل.
التجزئة، واختبار A/B، ومعايير الخروج تعيش داخل تدفق العمل
النمط السائد عبر نتائج البحث في الصفحة الأولى لهذه الكلمة المفتاحية هو سرد التجزئة، واختبار A/B، وساعات الهدوء كـ "أفضل الممارسات": نقاط عامة في نهاية المقالة، منفصلة عن الحملة التي تستخدمها. هذا هو الإطار الخاطئ. هذه ليست أفضل الممارسات التي تجلس بجوار تدفق العمل. إنها تدفق العمل.
هنا نفس مجموعة المفاهيم، مؤطرة كأفضل الممارسات مقابل مؤطرة كعقد تدفق عمل:
| مفهوم | تأطير أفضل الممارسات (خاطئ) | تأطير عقدة سير العمل (صحيح) |
|---|---|---|
| تجزئة RFM | "قم بتقسيم قائمتك قبل الإرسال" | عقدة قرار تتحقق من الحداثة والتكرار والقيمة النقدية، ثم توجه المشتركين ذوي RFM العالي إلى مسار مختلف عن أولئك ذوي RFM المنخفض. تغطي مشاركة تجزئة PushEngage تعريفات مجموعات RFM التي تغذي هذه العقدة. |
| اختبار A/B | "اختبر دائمًا نصوصك الإعلانية A/B" | عقدة تقسيم المسار بنسبة تخصيص 50/50، ومشتركون متوازنون التحميل لكل مسار، وحقل winner_edge_id الذي يروج للفائز بنسبة 100٪ بمجرد وصول الاختبار إلى الأهمية |
| ساعات الهدوء | "لا ترسل في الساعة 3 صباحًا" | خيار على مستوى تدفق العمل مع start_at، و end_at، و timezone، وإعداد fallback الذي إما يتخطى الإرسال أو يعيد جدولته إلى دقيقة واحدة بعد انتهاء ساعات الهدوء |
| معايير الخروج | "توقف عن الإرسال إلى الأشخاص الذين اشتروا" | قاعدة على مستوى سير العمل تتحقق من المشترك مقابل فلتر جمهور أو هدف مُحفز قبل كل عقدة، وتلغي سير العمل إذا تطابق. |
يحدث الفرق لأن النقاط ذات أفضل الممارسات سهلة الموافقة عليها وصعبة التنفيذ. يتم فرض عقد سير العمل بواسطة المحرك نفسه. عقدة DECISION تعمل في كل مرة. عقدة SPLIT_PATH توازن كل مشترك. آلية السقوط لساعات الهدوء تعمل دون أن يتذكر أحد التحقق من الوقت. قاعدة الخروج تلغي سير العمل سواء كان مالك الحملة منتبهًا أم لا.
بالنسبة لمخطط التخلي عن سلة التسوق أعلاه، هذا يعني في اللحظة التي يشتري فيها المشترك العناصر المهجورة، يتم تشغيل قاعدة الخروج، ويتم إلغاء تدفق العمل لهذا المشترك، ولن يتم إرسال التذكيرات الثانية والثالثة أبدًا. لا توجد تذكرة دعم، ولا بريد إلكتروني من الشؤون المالية، ولا حملة اعتذار. توقف تدفق العمل لأن المحرك كان لديه قاعدة أخبرته بالتوقف.
تنسيق متعدد القنوات: تدفق عمل واحد، أربع قنوات
معظم منصات الإشعارات الفورية هي أدوات ذات قناة واحدة. بعضها ذو قناتين. السؤال الذي لا يمكنهم الإجابة عليه جيدًا هو السؤال الذي يحتاج فريق الاحتفاظ في السوق المتوسطة إلى الإجابة عليه: بالنظر إلى حالة هذا المشترك، أي قناة يجب أن تعمل؟ إشعار ويب إذا وافقوا. بريد إلكتروني إذا ألغوا الاشتراك في إشعار الويب. واتساب إذا كانت قيمة سلة التسوق أكثر من 200 دولار. دردشة مباشرة إذا كان المشترك موجودًا حاليًا على الموقع.
شجرة القرار هذه هي تدفق عمل واحد لأتمتة الإشعارات الفورية متعددة القنوات، وليس أربع حملات في أربع أدوات. مع تدفقات عمل PushEngage، يمكن إنشاء رحلة التخلي عن سلة التسوق على النحو التالي:
- البداية: حدث
cart_abandoned - انتظار: ساعة واحدة
- عقدة القرار 1: هل المشترك مشترك في إشعارات الويب؟
- مسار نعم: إجراء، إرسال تذكير عبر إشعارات الويب
- مسار لا: المتابعة إلى القرار التالي
- انتظار: 30 دقيقة بعد إشعار الويب (أو فورًا، إذا لم يتم إرسال إشعار)
- عقدة القرار 2: هل نقر المشترك على إشعار الويب، أم أنه غير مشترك في إشعارات الويب؟
- إذا تم إرسال إشعار الويب وتم النقر عليه: خروج (دع تدفق سلة التسوق يكتمل)
- إذا تم إرسال إشعار الويب ولم يتم النقر عليه، أو لم يتم إرسال إشعار الويب: المتابعة
- عقدة القرار 3: هل قيمة سلة التسوق أكبر من 200 دولار؟
- مسار نعم: إجراء، إرسال رسالة واتساب عبر إجراء SendPushNotification على قناة واتساب
- مسار لا: إجراء، إرسال بريد إلكتروني عبر طلب HTTP إلى مزود خدمة البريد الإلكتروني الخاص بك
- خروج عند الهدف
purchase
أربع قنوات، تدفق عمل واحد، مجموعة واحدة من معايير الخروج، هوية مشترِك واحدة. نفس مدير الاحتفاظ الذي لم يتمكن سابقًا من تنسيق ذلك بدون ثلاثة تسجيلات دخول للبائعين وتدفق Zapier يمكنه الآن إنشاؤه داخل تدفق عمل واحد يفرضه المحرك.
القيام بنفس الشيء عبر أدوات منفصلة يعني ست عمليات مزامنة بين المنصات، ومحركين للتجزئة يختلفان حول من يُعتبر “مشتركًا مميزًا”، ولا يوجد إسناد إيرادات واحد لأن كل أداة تبلغ عن تحويلاتها الخاصة. القيام بذلك داخل محرك تدفق عمل واحد يعني هوية مشترِك واحدة، ومجموعة واحدة من منطق القرار، وتقرير قمع واحد. لمزيد من المعلومات حول كيفية عمل الإشعارات والبريد الإلكتروني معًا داخل خطة احتفاظ واحدة، راجع تنسيق القنوات المتعددة للإشعارات والبريد الإلكتروني.
هذا هو الفارق الذي لا مثيل له في نتائج الصفحة الأولى المهيمنة. لا يصف أي من أفضل خمسة عشر نتيجة لهذه الكلمة المفتاحية تدفق عمل عبر القنوات ككائن واحد. كلها تعامل الإشعارات كموضوع والبريد الإلكتروني كمقارنة.
رياضيات الاحتفاظ: الإيرادات لكل تدفق عمل، لكل قناة، لكل إشعار
تدفق العمل الذي لا يمكنك الدفاع عنه في مراجعة الأرباح والخسائر التالية هو تدفق عمل يتم إلغاؤه. وظيفة مدير الاحتفاظ هي إظهار، بالدولار، ما أنتجه كل بند. معظم مقالات "إشعارات الدفع الآلية للتجارة الإلكترونية" تتوقف عند معدل النقر. هذا غير كافٍ. المقياس الصحيح هو الإيرادات المستردة لكل مشترك، لكل تدفق عمل، لكل قناة.
يتتبع PushEngage Workflows ثلاثة أرقام عند كل عقدة:
- المستخدمون في الانتظار: المشتركون الذين ينتظرون حاليًا عند هذه العقدة (عادةً انتظار أو إعادة جدولة لساعات هادئة)
- المستخدمون المكتملون: المشتركون الذين مروا عبر هذه العقدة
- المستخدمون الذين خرجوا: المشتركون الذين غادروا تدفق العمل عند هذه العقدة، إما لأن معايير الخروج تطابقت أو لأنهم ألغوا الاشتراك
إليك كيف تبدو تحليلات مستوى العقدة لتدفق عمل نشط للتخلي عن سلة التسوق (أرقام توضيحية، مستمدة من قائمة واقعية تضم 200,000 مشترك):
| عقدة | في الانتظار | مكتمل | خرج | ملاحظات |
|---|---|---|---|---|
| البدء (تم التخلي عن سلة التسوق) | 0 | 12,400 | 320 | تطابق 320 مشتركًا مع معايير الخروج عند بدء تدفق العمل (تم الشراء بين حدث سلة التسوق وفحص تدفق العمل) |
| انتظر ساعة واحدة | 180 | 11,900 | 320 | عمق قائمة الانتظار العادي |
| الإجراء: تذكير #1 | 0 | 11,900 | 0 | تم إرسال الإشعار |
| انتظر 24 ساعة | 240 | 9,800 | 1,860 | عدد خروج مرتفع: اشترى 1,860 مشتركًا بعد التذكير رقم 1 |
| القرار: لا تزال سلة التسوق مهجورة | 0 | 9,800 | 0 | لا يزال لدى جميع المشتركين المتبقين سلة التسوق مفتوحة |
| إجراء: تذكير رقم 2 (خصم 10%) | 0 | 9,800 | 0 | تم إرسال الإشعار مع الخصم |
| انتظر 48 ساعة | 90 | 6,300 | 3,410 | تم تفعيل الخروج لـ 3,410 عمليات شراء أخرى |
| إجراء: تذكير نهائي (خصم 20%) | 0 | 6,300 | 0 | الإشعار النهائي |
| نهاية | غير متاح | 6,300 | غير متاح | 6,300 مشترك لم يشتروا |
In this funnel, 5,270 subscribers (1,860 + 3,410) purchased while inside the workflow, a 42.5% recovered-cart rate. The two waits (24h and 48h) are the highest-exit nodes in the funnel, which is the expected pattern: time-to-purchase decisions happen in the wait windows, not in the action windows. If your workflow shows the inverse pattern, with high exits at action nodes and low exits at wait nodes, your timing is wrong and the waits should be shortened.
The retention math also has to address cost. Push notifications cost nothing per send once the subscriber has opted in. Email costs depend on your ESP, but at a 200,000-subscriber list with a typical Klaviyo or Bloomreach setup, a single cart-abandonment send costs several hundred dollars in metered usage (your contract terms apply).
A push-first abandoned cart push notification automation that recovers carts at 42% can reach the same recovered-revenue number as a push-and-email workflow at 38%, at materially lower cost. Run the math on your own list size and ESP contract. The point is that push, app push, and WhatsApp do not incur the per-send cost that email does, and the workflow’s job is to use the cheapest channel first whenever the subscriber’s state allows.
When the line item is defensible (this workflow recovered $X in carts at a $Y all-in cost), the budget conversation is short.
ابنِها في مسارات PushEngage
Every blueprint in this article maps directly to PushEngage Workflows components. Here is the mapping for the five blueprints above:
| Blueprint | أنواع العقد المستخدمة | أنواع الإجراءات المستخدمة | خيار سير العمل |
|---|---|---|---|
| Welcome series | بداية، انتظار، قرار، إجراء، نهاية | إرسال إشعار دفع، إضافة شريحة | نوع التشغيل: فردي |
| تخلي عن التصفح | START, WAIT, DECISION, ACTION, EXIT | SendPushNotification | Run type: Multiple Parallel |
| Cart abandonment escalation | بداية، انتظار، قرار، إجراء، نهاية | SendPushNotification | Run type: Multiple Parallel; exit on goal purchase |
| Post-purchase review request | START, WAIT, SPLIT_PATH, ACTION, END | SendPushNotification, HttpRequest | Run type: Multiple Sequential; quiet hours 10 PM – 8 AM, reschedule fallback |
| Win-back | START, ACTION, WAIT, DECISION, END | إرسال إشعار دفع، إضافة شريحة | Run type: Single; audience-based trigger |
The Workflows engine ships with 60+ shipped templates covering each of these flows. Each template is a starting point. Every blueprint above can be installed in under five minutes on Shopify, Shopify Plus, WooCommerce, BigCommerce, or Magento inside the PushEngage push notification workflow builder.
The Workflows feature also covers the decision logic and personalization steps that make the multi-channel routing in the previous section possible, and supports the eleven action types that let you do more than just send a notification: update subscriber attributes, fire webhooks to your CRM, start downstream workflows, or stop conflicting ones.
For a broader view of how these workflows fit into a complete eCommerce retention program, the ecommerce push notifications hub post covers the campaign types these blueprints implement.
The free plan gives you 200 subscribers, all four channels (web push, app push, WhatsApp, and live chat), and the full Workflows engine on day one. That is enough to prove the channel before you put it on a budget line.
ما يغيره هذا
إذا كان هناك شيء واحد ستأخذه من هذه المقالة، فليكن هذا: أتمتة إشعارات الدفع للتجارة الإلكترونية هي بنية سير عمل، وليست مجرد مجموعة من الحملات المُحفزة. رحلة التخلي عن سلة التسوق التي تنتهي بالشراء، وسلسلة الترحيب التي تتفرع بناءً على سلوك الشراء الأول، والتنسيق عبر القنوات الذي يختار القناة الأقل تكلفة والمناسبة لكل مشترك، كلها لها نفس الشكل.
بداية واحدة، بعض الانتظارات، بعض القرارات، بعض الإجراءات، ونهاية واحدة. لا يمكن لستة محفزات مستقلة القيام بذلك. محرك سير عمل واحد يمكنه ذلك. تتضاعف حسابات الاحتفاظ من هناك.
ابدأ بالخطة المجانية لشحن المخطط الأول في أقل من ساعة.
