في مقال ROAS وصلنا لنتيجة: خوارزمية ميتا بتتعلّم على الطلب الوارد، فبتدوّر لك على ناس بتملأ فورمات — مش ناس بتستلم وتدفع. والحل المنطقي يبدو بديهياً: علّمها على الطلب الواصل.
الفكرة صحيحة. والتنفيذ فيه جدار تقني محدش بيتكلم عنه، ولو اصطدمت بيه من غير ما تعرفه، هتفتكر إن الحل مش شغال.
الفكرة في سطر
بدل حدث واحد («شراء» عند دخول الطلب)، تبعت حدثين منفصلين:
- حدث عند دخول الطلب — للقياس ومعرفة حجم الوارد.
- حدث مخصّص عند التسليم الفعلي — من السيرفر، وهو اللي بتوجّه الخوارزمية تتحسّن عليه.
الحدث التاني لازم يتبعت عبر Conversions API لا عبر البكسل، لأن لحظة التسليم بتحصل خارج المتصفح أصلاً — المندوب بيسلّم، والموظف بيغيّر حالة الطلب في لوحة التحكم.
الجدار: قيدان كلاهما سبعة أيام
هنا اللي بيوقع معظم المحاولات. ميتا عندها قيدان زمنيان منفصلان، وكلاهما سبعة أيام:
1. مهلة إرسال الحدث (event_time)
Conversions API بيقبل أحداثاً بتاريخ يرجع لحد سبعة أيام فقط. وفيه تفصيلة قاسية: لو أي حدث في الطلبية أقدم من سبعة أيام، ميتا بترفض الطلبية كاملة ولا تعالج أي حدث فيها — مش الحدث المخالف وحده.
يعني حدث تسليم متأخر واحد كفيل بإسقاط دفعة كاملة من الأحداث السليمة معاه.
2. نافذة الإسناد (Attribution Window)
أقصى نافذة إسناد متاحة حالياً هي 7-day click. خيارات 28 يوماً لم تعد مدعومة.
ومعنى ده إن الحدث لو وصل بعد أكتر من سبعة أيام من ضغطة الإعلان، ميتا مش هتنسبه للإعلان أصلاً — حتى لو قبلت الحدث نفسه.
احسب دورتك قبل ما تبدأ
خد دورة طلب نموذجية في الدفع عند الاستلام:
| المرحلة | المدة | تراكمي |
|---|---|---|
| التأكيد الهاتفي (حتى 10 محاولات) | 3 أيام | 3 |
| التجهيز والشحن | يوم | 4 |
| التوصيل | يومان | 6 |
| الإجمالي | 6 أيام | |
الهامش المتبقي: يوم واحد.
أي تأخير — محافظة بعيدة، أجازة رسمية، محاولة تسليم تانية، أو فريق تأكيد مشغول — وحدث التسليم بيسقط خارج النافذتين معاً.
ولاحظ المفارقة: المتابعة المكثّفة على تلات أيام — وهي ممارسة تشغيلية ممتازة في ذاتها — بتاكل نص النافذة قبل ما المنتج يتحرك من المخزن أصلاً.
الحل: تدرّج بدل قفزة
بدل ما تقفز مباشرة للتحسين على التسليم وتصطدم بالجدار، امشِ على مرحلتين.
المرحلة الأولى: حسّن على الطلب المؤكَّد
حدث التأكيد بيحصل خلال يوم إلى تلاتة — جوّه النافذة بأمان. وهو مش مثالي زي التسليم، لكنه أفضل بوضوح من الطلب الوارد:
| الأداء | جودة إشارة «الطلب الوارد» | جودة إشارة «الطلب المؤكد» | التحسّن |
|---|---|---|---|
| ضعيف | 18% | 30% | +67% |
| متوسط | 33% | 47% | +43% |
| جيد | 52% | 65% | +25% |
(«جودة الإشارة» هنا = احتمال أن الحدث الذي علّمت الخوارزمية عليه سيتحول فعلاً إلى فلوس.)
وكل ما أداؤك أضعف، كل ما المكسب من الخطوة دي أكبر.
المرحلة الثانية: حسّن على التسليم
انتقل لها فقط بعد ما تضبط الأول:
- دورة الطلب الكاملة أقل من 5 أيام باستمرار — عشان يبقى فيه هامش أمان.
- حجم تسليم كافٍ (التفصيل تحت).
- آلية تستبعد الأحداث المتأخرة بدل ما تبعتها فتسقط الدفعة.
شرط الحجم — وده بيستبعد كثيرين
الخوارزمية محتاجة حوالي 50 حدث أسبوعياً لكل مجموعة إعلانية عشان تخرج من مرحلة التعلّم وتتحسّن بثقة. ولو بتحسّن على حدث نادر، محتاج حجم وارد أكبر بكثير:
| الأداء | طلبات/أسبوع للتحسين على التسليم | طلبات/أسبوع للتحسين على التأكيد |
|---|---|---|
| ضعيف (وصول 18%) | 278 | 83 |
| متوسط (وصول 33%) | 150 | 71 |
| جيد (وصول 52%) | 96 | 62 |
لو مش بتعمل مئة طلب أسبوعياً على الأقل، التحسين على التسليم مش هينفع معاك — الخوارزمية مش هتلاقي إشارات كفاية وهتفضل في التعلّم للأبد. ابدأ بالتأكيد، وده متاح لحجم أصغر بكثير.
الخطوات التنفيذية
- جهّز الوصول. من إعدادات مجموعة البيانات (Dataset) في Events Manager، استخرج مُعرّف الداتا سيت ورمز وصول (Access Token) مخصص للسيرفر — لا تضعه أبداً في كود يُرسَل للمتصفح.
- عرّف حدثين مخصصين: واحد عند تغيير حالة الطلب إلى «مؤكد»، والتاني عند «تم التسليم».
- اربطهما بتغيّر الحالة في نظامك — لا بزر يضغطه موظف، عشان ما يحصلش تكرار أو نسيان.
- ابعت بيانات تعريف قوية ومشفّرة: رقم التليفون والاسم والمحافظة، مُجزّأة بـ SHA-256. جودة المطابقة هي اللي بتحدد قيمة الحدث — حدث بلا مطابقة كويسة بلا فائدة.
- مرّر القيمة الفعلية المحصَّلة في حدث التسليم، لا قيمة الطلب الاسمية. ده بيخلي ROAS في اللوحة يقترب من الحقيقة.
- افلتر المتأخر قبل الإرسال. ضع شرطاً صريحاً: لو فرق التوقيت أكبر من 6 أيام، لا تبعت الحدث نهائياً. سطر واحد بيحميك من رفض دفعات كاملة.
- راقب جودة المطابقة والتكرار في Events Manager أول أسبوعين قبل ما تبني قرارات على الأرقام.
متى تحوّل التحسين فعلاً؟
ماتحوّلش يوم ما تركّب الحدث. سيب الحدث الجديد يتجمّع أسبوعين على الأقل وإنت لسه محسّن على الطلب الوارد، وراقب:
- هل وصل الحدث الجديد لـ 50 مرة أسبوعياً؟
- هل جودة المطابقة مقبولة؟
- هل الأعداد في اللوحة قريبة من أعدادك في نظامك؟
لما التلاتة يبقوا نعم، حوّل — وعلى مجموعة إعلانية واحدة أولاً لا على الحساب كله. وتوقّع في الأسبوعين الأولين انخفاضاً في عدد الطلبات وارتفاعاً في تكلفة الطلب المعروضة. ده طبيعي: الخوارزمية بتدوّر على جمهور أندر وأغلى. الحكم يكون على تكلفة الطلب الواصل، لا على تكلفة الطلب في اللوحة.
خلاصة
- القيدان الحاكمان: مهلة إرسال الحدث 7 أيام، ونافذة إسناد أقصاها 7 أيام.
- دورة طلب نموذجية = 6 أيام، فالهامش يوم واحد — وأي تأخير يُسقط الحدث.
- حدث متأخر واحد بيرفض الدفعة كاملة، فالفلترة قبل الإرسال ضرورية لا اختيارية.
- ابدأ بالتحسين على الطلب المؤكَّد: يحسّن جودة الإشارة 25% إلى 67% ومتاح لحجم أصغر.
- التحسين على التسليم يحتاج 96 إلى 278 طلباً أسبوعياً حسب معدل وصولك.
وفيه استنتاج تشغيلي أهم من كل ما سبق: تقصير دورة الطلب مش تحسيناً لوجستياً فقط — هو شرط تقني لكي تتعلّم خوارزمية الإعلان على الإشارة الصحيحة. كل يوم توفّره بين الطلب والتسليم بيزوّد نسبة الأحداث اللي بتوصل ميتا في وقتها.
القيود الزمنية المذكورة من وثائق Meta للمطوّرين ومركز مساعدة الأعمال، وهي قابلة للتغيير — راجعها قبل التنفيذ. مدد دورة الطلب ونِسب الوصول من نطاقات تشغيل فعلية في السوق المصري 2026، وتختلف حسب المنتج والمحافظة وشركة الشحن.
