لماذا لا نستخدم AMP للبريد الإلكتروني؟

AMP للبريد الإلكتروني هو تقنية Google لتشغيل مكوّنات تفاعلية حقيقية — عروض دوّارة، ونماذج، وأسعار حيّة — بشكل أصلي داخل الرسالة، دون الحاجة إلى النقر للانتقال إلى صفحة أخرى. إنها تقنية مشروعة، والسؤال عنها طبيعي: لماذا لا يبني MailInApp عليها بدلًا من HTML/CSS الحركي (أو إلى جانبه)؟ تعرض هذه الصفحة المفاضلة بوضوح، لأنها رهان مقصود، لا سهو.

ما هو AMP للبريد الإلكتروني فعلًا، وتكلفتاه

تُشحن رسائل AMP كجزء MIME إضافي إلى جانب HTML المعتاد، وتُبنى بمجموعة محدودة من مكوّنات amp-* (إطار عمل AMP من Google، مُعاد توظيفه للبريد الإلكتروني). وحيث يُعرض، يكون أصليًا حقًا — دون حاجة إلى بديل ثابت في ذلك البريد الوارد.

لكنه يأتي بتكلفتين لا تظهران في جدول مقارنة الميزات:

1. موافقة لكل مُرسِل. يجب أن يُسجَّل كل نطاق إرسال لدى Google ويجتاز مراجعة قبل أن يرى أي مستلم رسالة AMP منه — وهي بوابة خارج سيطرتك، بجدول زمني خاص بها ومخاطر رفض، تقف أمام كل حملة.
2. دعم عرض محدود. لا يعرض AMP أصلًا سوى Gmail وYahoo Mail وMail.ru. أما كل التطبيقات الأخرى — Apple Mail، وOutlook (الكلاسيكي والجديد)، وFastmail، وProton، وSamsung Mail — فتتجاهل جزء AMP كليًا وتعود إلى جزء HTML العادي الذي شُحن معه.

حسابات الوصول

باستخدام بيانات Litmus لحصص تطبيقات البريد في السوق (نحو 1B عملية فتح متتبَّعة، مايو 2026):

يشكّل Gmail وYahoo معًا جمهور AMP الفعلي الوحيد، بما يعادل نحو 27% من عمليات الفتح. أما النسبة الباقية ~73%، التي يتصدّرها Apple Mail وحده بما يقارب ثلثي عمليات الفتح كلها، فلن ترى أي مكوّن AMP مهما أُتقن بناؤه. وحتى داخل Gmail، لا يعمل AMP للبريد الإلكتروني إلا إذا كان المستلم يقرأ حساب Gmail عبر تطبيق Gmail نفسه؛ فتطبيق الهاتف الذي يقرأ بريدًا واردًا غير تابع لـGmail (IMAP) لا يؤهَّل أيضًا.

أي قائمة من المستلمين الحقيقيين ستكون غالبيتها من مستخدمي Apple Mail. والمراهنة بالتجربة التفاعلية على AMP تعني أن معظم تلك القائمة لن يراها أبدًا.

لماذا يُعدّ HTML الحركي الرهان الأفضل لقائمة نموذجية

يصل المستوى الحركي في MailInApp — آلات حالة CSS المعتمدة على :checked للعروض الدوّارة، والقوائم القابلة للطي، والاستطلاعات، وعجلة الحظ، إضافة إلى إرسال <form> حقيقي داخل الرسالة حيث يكون مدعومًا — إلى Gmail (على الويب والهاتف)، وApple Mail، وYahoo Mail، وSamsung Mail: أي الغالبية العظمى من صناديق البريد الوارد لدى المستهلكين، بما فيها Apple Mail. راجع دعم تطبيقات البريد للاطلاع على المصفوفة الكاملة، وكيف تعمل البدائل لمعرفة كيف تُبنى المستويات الثلاثة من تصميم واحد.

هذا هو جوهر المفاضلة: الاستثمار نفسه في محرك البدائل يؤتي ثماره عبر القائمة كلها تقريبًا، لا عبر نحو 27% فقط قد يصل إليها AMP في أحسن الأحوال — ويُطرح دون بوابة موافقة لكل مُرسِل تقف أمام كل حملة. سقف AMP أعلى في المكان الوحيد الذي يُعرض فيه (مكوّنات أصلية حقًا، دون أي نقر للانتقال)، لكنه لا يمكن أن يكون الطبقة التفاعلية الأساسية لجمهور لا يستخدم Gmail في غالبيته الساحقة.

هل يستبعد هذا AMP نهائيًا؟

ليس من الناحية المعمارية. فـHTML/CSS الحركي وبديل الروابط العادية في المستوى 2 هما بالفعل الأساس الآمن الذي يعود إليه كل تطبيق — ويمكن لنموذج المستويات الثلاثة نفسه الذي تصفه هذه الصفحة أن يحمل يومًا ما جزءًا رابعًا خاصًا بـAMP لمستلمي Gmail/Yahoo فوقه، دون المساس بطريقة عمل المستويات الأخرى. لكنه ببساطة ليس الوجهة الأولى لجهود محرك البدائل: فالوصول إلى كل بريد وارد بتقنية واحدة موثوقة أفضل من الوصول إلى ربع صناديق البريد الوارد بشكل أصلي وعدم الوصول إلى البقية إطلاقًا.