يحوّل MailInApp رسالة استعادة السلة إلى مكان لإتمام الدفع فعلًا — زر «اشترِ الآن» حقيقي، وعدّاد تنازلي صادق على الخصم، ودفعة اختيارية عبر عجلة الحظ. بلا برمجة، وبلا متجر إلكتروني منفصل تحتاج إلى صيانته.
رسالة الاستعادة التي تكتفي بالربط بمتجرك تجعل الشخص يبدأ من جديد: يبحث عن المنتج مرة أخرى، ويعيد بناء السلة، ويدفع بشكل منفصل. وكل خطوة إضافية هناك تُفقدك أشخاصًا. مع MailInApp، يعيش زر «اشترِ الآن» في عنصر المنتج، والمؤقّت الدقيق دائمًا في عنصر العدّاد التنازلي، ومكافأة عجلة الحظ الاختيارية، كلها مباشرة داخل رسالة الاستعادة نفسها.
من أين تأتي بيانات «الترك»
لا يدير MailInApp متجرًا إلكترونيًا خاصًا به ولا يتتبّع السلال بنفسه — ولا يحتاج إلى ذلك. فأي نظام يعرف بالفعل أن سلة ما قد تُركت (منصة متجرك، أو نظام CRM، أو ملف مُصدَّر من جدول بيانات) يصبح مصدر بيانات في MailInApp، إما مرتبطًا مباشرة عبر API أو محدَّثًا وفق جدول زمني. ومن هناك، يعيد إرسال متكرر تقييم عامل تصفية للجمهور مثل «تُركت السلة قبل 1-24 ساعة» مقابل الصفوف الحالية في مصدر البيانات ذلك وفق إيقاعه الخاص. ولا يرسل إلا إلى المطابقين الذين لم تشملهم رسالة استعادة سابقة — وهو نمط النافذة المتحركة نفسه المستخدم في استبيانات ما بعد تذاكر الدعم.
العناصر المصمَّمة لاستعادة البيع
- المنتج — زر «اشترِ الآن» حقيقي، يحصّل المبلغ عبر حساب Stripe المرتبط بك. حدّد السعر المخفّض (أو الأصلي) مرة واحدة ويبقى دقيقًا في كل إرسال — بلا صفحة دفع منفصلة تبنيها.
- العدّاد التنازلي — إن كان عرض الاستعادة محدود الوقت، يعيد العدّاد التنازلي رسم نفسه من جديد عند كل فتح، فلا تكون عبارة «ينتهي خلال ساعتين» رقمًا قديمًا أبدًا حين يقرأ أحدهم الرسالة فعلًا.
- عجلة الحظ — دفعة اختيارية بأسلوب الألعاب تمنح مكافأة صغيرة مقابل إتمام الدفع، إضافة إلى رمز خصم عادي بنسبة مئوية أو بدلًا منه.
- العرض الدوّار — ذكّر المستلم بالضبط بما كان يتصفّحه عبر معرض قابل للتمرير للمنتجات المتروكة.
بناء تسلسل استعادة قصير، لا رسالة واحدة فقط
رسالة استعادة واحدة بداية جيدة؛ لكن التسلسل القصير يستعيد عادةً أكثر. فالإرسال المتكرر لا يصل إلا إلى مطابقي عامل تصفية الجمهور الذين لم يشملهم بعد، لذا فإن رسالة ثانية — لنقل «لم يشترِ بعد، ترك السلة منذ 3 أيام أو أكثر» — لا تصل إلا إلى من ما زالوا يحتاجون إلى تلك الدفعة التالية. ولا حاجة إلى أي تلاعب يدوي بالقوائم لمنع تداخل الإرسالين.
ماذا يحدث عند النقر على زر «اشترِ الآن»
يفتح الزر أولًا رابطًا إلى جلسة Stripe Checkout حقيقية على حساب Stripe المرتبط بك ويعيد التوجيه إليها للدفع — لا يحتفظ MailInApp بالأموال أبدًا ولا يرى بيانات البطاقات. وتنضمّ عملية البيع المكتملة إلى لوحة الطلبات والتحليلات نفسها كأي عملية شراء أخرى في MailInApp، فيسهل تمييز البيع المستعاد عن البيع الجديد إن كنت تتتبّع أداء حملات الاستعادة تحديدًا. (إن كانت منصة متجرك تستعيد بالفعل جلسة السلة الخاصة بالمتسوّق عند الدفع، فيمكن بدلًا من ذلك ضبط حقل الدفع في عنصر المنتج على الربط بصفحة الدفع في متجر خارجي وتوجيهه إلى متجرك — ويستحق ذلك الموازنة مع كلفة «البدء من جديد» التي تصفها الفقرة الافتتاحية، إذ لا ينطبق تتبّع الطلبات والمخزون الخاص بـ MailInApp المذكور أعلاه بمجرد أن يتم الدفع خارج المنصة.)
ماذا لو لم يستطع البريد الوارد لدى المستلم عرض العدّاد التنازلي أو عجلة الحظ؟
يظل كل عنصر يوفّر مسارًا يعمل نحو النتيجة نفسها. فحيث لا يمكن عرض حركة العدّاد التنازلي، يحلّ محلها رقم بسيط؛ وحيث لا يمكن عرض عجلة الحظ، يظهر رابط المكافأة نفسه كزر بسيط بدلًا من عجلة متحركة. ولا تتوقف عملية البيع نفسها أبدًا على حركة لا تظهر إلا في بعض تطبيقات البريد — راجع آلية عمل محرك البدائل للصورة الكاملة.
البدء
اربط مصدر البيانات الذي يعرف بالفعل أي السلال تُركت — اتصال API، أو ملف CSV تحدّثه وفق جدولك الخاص. ثم ابنِ رسالة الاستعادة بعنصر المنتج، واختياريًا عنصر العدّاد التنازلي لخصم محدود الوقت. وأعدّ إرسالًا متكررًا بعامل تصفية للجمهور مثل «تُركت قبل N ساعة/يوم» ضمن جهات الاتصال والإرسال ليعمل التسلسل كله تلقائيًا من هناك.