التفاعلات والتحليلات
حين يصوّت مستلم في استطلاع، أو يرسل نموذجًا، أو ينقر تقييمًا، تسجّل نقاط النهاية المستضافة في MailInApp ذلك التفاعل وتنسبه إلى مشروعك — في الوقت الفعلي.
كيف تنتقل التفاعلات
تصل العناصر التفاعلية إلى نقاط نهاية التسجيل بطريقتين، وفقًا لفلسفة البدائل:
- الروابط (شاملة). كل خيار في استطلاع أو تقييم رابط عادي. والنقر عليه يفتح صفحة مستضافة خفيفة تؤكّد الإجراء وتسجّله. ويعمل هذا المسار في 100% من تطبيقات البريد.
- إرسال النماذج داخل الرسالة (تحسين). في تطبيقات البريد التي تدعم ذلك (Gmail على الويب/Android، وYahoo)، يمكن إرسال النماذج والاستطلاعات مباشرة من الرسالة باستخدام ترميز نماذج HTML القياسي — دون الانتقال إلى صفحة أخرى. وبعد الإرسال، يُعاد توجيه المستلمين إلى الصفحة التي تختارها.
يقبل المساران البيانات نفسها، فتنتهي النتائج في مكان واحد أيًّا كان تطبيق البريد الذي استخدمه المستلم.
والاستثناء الوحيد هو النقر على «اشترِ الآن» في عنصر المنتج: فلا يمكنه التسجيل عبر نقطة النهاية هذه إطلاقًا، لأن الشراء لا يكتمل إلا على صفحة الدفع المستضافة لدى Stripe نفسها. ومع ذلك يصل هنا حدثًا من نوع purchase — مع المبلغ والعملة والكمية — لكن فقط بعد أن يؤكّد Webhook الخاص بـ Stripe أن الدفعة قد تمّت فعلًا، لا بمجرد نقر المشتري.
حماية من الروبوتات وأدوات الفحص
تجلب أدوات الأمان في الشركات مسبقًا كل رابط في كل رسالة تفحصها. ولو كان النقر المجرد على رابط كافيًا لتسجيل صوت، لامتلأت نتائج استطلاعك بالروبوتات. لذا لا يسجّل MailInApp أي شيء عند طلب GET بسيط: فالإجراءات القائمة على الروابط تتطلب إجراء تأكيد صريحًا من المستلم، وتُسجَّل تفاعلات العرض المباشر عبر إرسال النماذج. راجع روابط العرض المباشر.
ولأن نقاط النهاية عامة بالضرورة (فالبريد الوارد لا يستطيع المصادقة)، يُتحقَّق من كل حمولة على الخادم، وتُنسب الإرسالات الشخصية عبر الرموز الموقّعة نفسها التي تحمي روابط العرض المباشر — ويُرفض أي رمز مزوّر أو غير مطابق.
وتحافظ طبقتان إضافيتان على نزاهة النتائج:
- إزالة التكرار لكل مستلم. صوت المستلم أو تقييمه أو كشفه أو إرساله للنموذج يُحتسب مرة واحدة — فإعادة النقر على رابطه (نقرة مزدوجة متعجّلة، أو إعادة تحميل الصفحة) لا تفعل شيئًا، ولا تضيف صفًّا ثانيًا. أما مشاهدات شرائح العرض الدوّار المتكررة فلا تُزال عنها التكرارات عمدًا، لأن التكرار هناك إشارة تفاعل ذات معنى لا احتساب مزدوج.
- الحدّ من الإغراق المجهول. معرّف
campaignIdالخاص بالحملة ظاهر بوضوح في شيفرة HTML للرسالة نفسها، فلا شيء يمنع سكربتًا من إرسال أصوات عشوائية دون أي رمز مستلم إطلاقًا. لذا تُحدّ الإرسالات غير المنسوبة لكل عنوان IP، ولكل حملة، ولكل دقيقة. وهذه شبكة أمان بأفضل جهد، لا تحديد دقيق للهوية — فشبكات الشركات أو البريد عبر الويب المشتركة قد تضع كثيرًا من المستلمين الحقيقيين خلف عنوان IP واحد — لذا يبقى الحدّ سخيًّا بما يكفي كي لا يحجب دفعة مشروعة من مرات الفتح.
ما الذي يُسجَّل
يلتقط كل حدث تفاعل ما يلي:
- المشروع (الحملة) الذي ينتمي إليه،
- العنصر الذي أنتجه (أيّ استطلاع، وأيّ نموذج)،
- القيمة (الخيار المختار، أو الحقول المرسلة، أو عدد النجوم)،
- صف المستلم، حين تكون الرسالة مخصّصة بمصدر بيانات — فترى من أجاب، لا عدد المجيبين فقط،
- طابعًا زمنيًا.
دورة حياة الاستبيان
يمكن تعيين تاريخ إغلاق للمشروع و/أو حدّ أقصى للردود (يُضبطان إلى جانب إعدادات الإرسال). وبمجرد بلوغ أيٍّ منهما، تتوقف نقاط نهاية التسجيل عن قبول أحداث جديدة لذلك المشروع — ويستبدل العرض المباشر العناصر التفاعلية بإشعار الإغلاق بدلًا من إظهار خطأ — بينما يبقى كل ما جُمع قبل الإغلاق كما سُجّل تمامًا. راجع الردود وWebhooks.
تتبّع النقرات
الروابط العادية (زر، أو صورة مرتبطة، أو أيقونة شبكة اجتماعية) ليست استطلاعًا ولا تقييمًا، لكن معرفتها تظل مفيدة. فحين تُرسل رسالة برابط مستلم شخصي، يمرّر MailInApp هذه النقرات العادية عبر إعادة توجيه متتبَّعة في طريقها إلى وجهتها الحقيقية. تُسجَّل النقرة، ثم يصل المستلم إلى الرابط الذي عيّنته، دون خطوة إضافية ودون تأخير. أما الرسائل التي لا تحمل سياق مستلم (مثل الإرسال الحر عبر واجهة API للبريد المعاملاتي) فترتبط مباشرة بالوجهة، إذ لا يوجد ما تُنسب إليه النقرة.
وبخلاف الأصوات والتقييمات، يمكن أن تُحتسب النقرات مرة أخرى: فالنقرات المتكررة خارج نافذة إعادة التشغيل البالغة خمس دقائق تبقى إشارة تفاعل ذات معنى. أما التكرارات السريعة للهدف الموقّع نفسه فتُدمج، حتى لا يتمكن رابط طويل الأمد مسرَّب من توليد عمل غير محدود في التحليلات أو Webhooks. وتُجمَّع النتائج في خريطة حرارية للنقرات لكل عنصر — راجع الردود وWebhooks.
عمق التمرير
تُبلغ صفحة العرض المباشر المستضافة أيضًا عن مدى تمرير المستلم (25%، و50%، و75%، و100% من الصفحة) أثناء القراءة. وهذا هو الموضع الوحيد في MailInApp الذي يشغّل سكربتًا صغيرًا. فالرسالة المرسلة نفسها تبقى خالية من السكربتات بنسبة 100%، كما ينبغي، لكن العرض المباشر صفحة ويب مستضافة عادية أصلًا، فلا يضرّ مستمع التمرير فيها بشيء. وتُجمَّع المراحل في قمع عمق التمرير؛ راجع الردود وWebhooks.
تتبّع الفتح
تحمل كل رسالة مرسلة من لوحة التحكم أيضًا بكسلًا صغيرًا غير مرئي لتتبّع الفتح، فتحصل على إشارة تميّز «فُتحت دون تفاعل» عن «لم تُفتح قط» إلى جانب التفاعلات الصريحة. ويظهر ذلك في عرض الردود مؤشرًا مستقلًا باسم فُتحت (مع الطابع الزمني لأول فتح) لكل مستلم، بدلًا من خلطه بقائمة التفاعلات.
وهذا حدّ أدنى بأفضل جهد، لا قياس دقيق: فميزة حماية الخصوصية في Apple Mail ووكيل الصور في Gmail كلاهما يجلب الصور مسبقًا أو يخزّنها مؤقتًا بمعزل عن فتح المستلم للرسالة فعلًا، فقد يُحتسب الفتح بأقل من حقيقته أو إيجابيًا زائفًا. تعامل معه إشارةً اتجاهية، لا مصدرًا للحقيقة.
أين توجد النتائج
تُجمع بيانات التفاعل لكل مشروع وتعود إليك بثلاث طرق:
- الردود لكل مستلم — يجمع عرض الردود في لوحة التحكم كل تفاعل حسب المستلم، مربوطًا بمصدر بياناتك، فترى من أجاب لا عدد المجيبين فقط. راجع الردود وWebhooks.
- Webhooks — يمكن دفع كل تفاعل إلى نقطة النهاية الخاصة بك لحظة وصوله، موقّعًا حتى تتحقق من أنه صادر عن MailInApp. وهذا مشروح أيضًا في الردود وWebhooks.
- النتائج الحيّة للمستلمين — يمكن لعناصر الاستطلاع عرض النتائج الحيّة للمستلمين على صفحة النتائج المستضافة الخاصة بهم.
ملاحظة الخصوصية: يسجّل MailInApp التفاعلات التي يجريها المستلمون عن قصد — الأصوات والإرسالات والتقييمات — إضافة إلى بكسل تتبّع الفتح الموصوف أعلاه. وقد صُمّمت نقاط النهاية بحيث لا تسجّل أي تتبّع عرضي آخر عند الجلب المجرد للروابط.