بتصرف كل شهر على حملات تطبيقات فيسبوك. الـ CPI (تكلفة الـ install الواحد) بيطلع، وكل ما تقفل ad set (المجموعة الإعلانية اللي جواها الاستهداف والميزانية) وتفتح واحد جديد، الرقم يرجع زي ما هو تقريباً.
في أغلب الحسابات اللي بنراجعها، المشكلة مش الكرياتيف ولا الـ bid. المشكلة تلاتة: هيكلة الحملة، الإشارة اللي بتوصل للخوارزمية، ومصدر الرقم اللي بتحكم بيه. ومفيش واحدة فيهم بتظهر كتحذير في الـ Ads Manager.
تحت هتلاقي 8 أخطاء بالترتيب. مع كل واحد: إزاي تعرف إنك واقع فيه، الإصلاح بالظبط، وكام بيكلفك في الشهر.
السيناريو المرجعي (كل الأرقام تحت بترجع له)
ميزانية 15,000 ريال في الشهر تساوي حوالي 500 ريال في اليوم. بـ CPI 12 ريال، ده حوالي 42 install في اليوم، يعني قرابة 290 install في الأسبوع. كل تقدير مالي في المقال محسوب على السيناريو ده تحديداً، مش إحصائية عامة. حط أرقامك مكانه واحسب نفس النسبة.
قاموس سريع (قبل ما ندخل في التفاصيل)
- الـ learning phase: مرحلة الاستكشاف. الفترة اللي الخوارزمية بتجرب فيها جماهير وأماكن عرض مختلفة عشان تتعلّم مين بيتفاعل. زي سواق جديد لسه بيحفظ الشوارع: بيوصل، بس بوقت وبنزين أكتر.
- حالة Learning limited: جملة بتظهرلك جنب الـ ad set معناها إنه مش هيجمّع أحداث كفاية عشان يخرج من الاستكشاف بالوضع الحالي. يعني هيفضل بيجرّب على حسابك.
- حدث التحسين (optimization event): الحدث اللي بتقول لـ Meta “دوّرلي على ناس تعمله”. install، تسجيل، أول شراء. ده الرقم اللي الخوارزمية بتشتغل عشانه.
- الـ CAC: تكلفة اكتساب العميل اللي دفع فعلاً. صرفت كام عشان توصل لواحد بيدفع.
- نافذة الإسناد: المدة اللي المنصة بتحسب فيها الحدث على إعلانها. الإعداد الافتراضي في Meta هو 7 أيام للنقرة ويوم واحد للمشاهدة.
- الـ MMP: أداة قياس محايدة زي AppsFlyer أو Adjust. بتربط الصرف بالإيراد الحقيقي، وبتحكم بين المنصات لما كل واحدة تدّعي نفس العميل.
- نظام SKAN: نظام SKAdNetwork من Apple. الطريقة البديلة اللي بيوصلك بيها قياس iOS. الإشارة بتيجي مجمّعة ومتأخرة، من غير تفاصيل عن المستخدم نفسه.
- الـ conversion value: خانة صغيرة جوا نظام SKAN فيها 64 احتمال بس (من 0 لـ 63)، بتكتب فيها أهم حاجة عملها المستخدم بعد الـ install. دي كل اللي بيوصلك عن قيمة العميل على iOS.
- نظام AEM: اختصار Aggregated Event Measurement. طريقة Meta في التعامل مع أحداث مستخدمي iOS: مجمّعة ومرتّبة بالأولوية. عملياً إنت بترتّب أحداثك في Events Manager، والترتيب ده بيحدد أنهي حدث يتحسب أصلاً.
- الـ exclusion audience: جمهور بتستبعده من الاستهداف. بتقول لـ Meta “الناس دي عندي أصلاً، متوريهمش الإعلان”.
- نظام Advantage+ App Ads: واختصاره AAA. حملة أوتوماتيك من Meta بتسيبلها الاستهداف وتوزيع الكرياتيف، وإنت بتديها الأحداث والمفاهيم بس.
إيه هي التمن أخطاء اللي بتحرق ميزانية حملات التطبيقات على Meta؟
التمن أخطاء هي: تفتيت الميزانية على ad sets كتير، خلط iOS مع Android في حملة واحدة، حدث تحسين أسطح أو أعمق من اللازم، خلل في الـ SKAN conversion value schema، تصفير الـ learning phase بالتعديلات، غياب الـ exclusion audience، الحكم على iOS من الـ Ads Manager، وتشغيل Advantage+ App Ads على إشارة مفتّتة. كلهم بيضعّفوا نفس الحاجة: الإشارة اللي الخوارزمية بتتعلّم منها.
| # | الخطأ | العلامة في حسابك | الإصلاح في سطر | التكلفة شهرياً (على 15,000 ريال) |
|---|---|---|---|---|
| 1 | تفتيت الميزانية على ad sets كتير | أكتر من 3 ad sets وأغلبها Learning limited | ادمجهم في ad set أو اتنين | 3,000-6,000 ريال |
| 2 | خلط iOS مع Android تحت ميزانية حملة واحدة | 85% من الإنفاق راح لـ Android من غير قرار منك | حملتين، ميزانيتين، قراءتين منفصلين | 2,000-4,000 ريال |
| 3 | حدث تحسين أسطح أو أعمق من اللازم | تحميلات كتيرة والـ retention للمدفوع أقل بكتير من الـ organic | اختار أعمق حدث فوق 50 أسبوعياً | حوالي 4,500 ريال |
| 4 | خلل في الـ SKAN conversion value schema | معظم الـ conversion values راجعة صفر | اعمل mapping سطر بسطر وظبّط النافذة | 30-50% من إشارة iOS |
| 5 | تصفير الـ learning phase بالتعديلات | بتغيّر حاجة في الحملة كل يومين | متغير واحد، وسيبه 5-7 أيام | 1,200-2,400 ريال |
| 6 | مفيش exclusion audience | مفيش جمهور مستبعد مبني على app events | استبعد كل من فتح التطبيق آخر 180 يوم | 1,200-2,250 ريال |
| 7 | الحكم على iOS من الـ Ads Manager | قفلت ad set لأن Meta قالت صفر purchases | خلي القرار المالي من الـ MMP بس | خسارة ad set رابح بالكامل |
| 8 | تشغيل Advantage+ App Ads على إشارة مفتّتة | النتيجة زي ما هي أو أسوأ بعد التشغيل | صلّح الخطأ 1 و 3 الأول، وادخل بـ 4-6 مفاهيم | شهر اختبار من غير إجابة |
ليه حملات تطبيقات فيسبوك بتفشل حتى لو الكرياتيف كويس؟
حملات تطبيقات فيسبوك بتفشل لما تديها إشارة ضعيفة وتحكم عليها برقم غلط. الخوارزمية محتاجة حوالي 50 حدث تحسين في الأسبوع لكل ad set عشان تخرج من الـ learning phase، والرقم ده معلن من Meta نفسها في صفحة About the learning phase. لو مفيش ad set واحد بيوصل للرقم ده، إنت بتدفع سعر الاستكشاف مش سعر التوصيل. الكرياتيف مش هينقذ إشارة فيها خلل.
- الفرق بين سعر الاستكشاف وسعر التوصيل: في الـ learning phase الخوارزمية بتجرّب، فتكلفة النتيجة بتبقى أعلى وأكتر تذبذباً. بعد ما تستقر، بتبطّل تجريب وتصبّ العرض على الشرايح اللي بتعمل الحدث فعلاً. في الحسابات اللي بنراجعها، الفرق بين الحالتين بيتراوح بين 20% و 40% على نفس الكرياتيف ونفس الجمهور. ده مش رقم معلن من Meta، ده اللي بنشوفه عملياً، وكل الحسابات تحت مبنية عليه. يعني إنت مش بتدفع تمن إعلان أسوأ، إنت بتدفع تمن معلومة الخوارزمية مجمّعاهاش لحد دلوقتي.
- مصادر الفشل التلاتة: هيكلة (الميزانية مفتّتة فمفيش ad set بيوصل لـ 50 حدث)، إشارة (بتحسّن على حدث غلط أو الـ mapping فيه خلل)، وقياس (بتاخد قرار مالي من مصدر رقم مش المفروض تحكم بيه). الكرياتيف رقم أربعة في الترتيب، مش رقم واحد.
- الـ Ads Manager بيقولك “إيه” ومش بيقولك “بكام”: شاشة Meta بتكتب “Learning limited” كحالة، وخلاص. مش بتقولك إن الحالة دي معناها إنك بتدفع 20-40% زيادة على كل نتيجة. الفرق بين الاتنين هو الفرق بين تنبيه بتعدّي عليه وبند مصاريف بتوقفه.
لو داخل على حسابك دلوقتي وشايف “Learning limited” على أكتر من نص الـ ad sets، الأخطاء 1 و 3 اللي تحت هما اللي عندك. ابدأ بيهم قبل أي حاجة تانية.
هل تفتيت الميزانية على 6 ad sets هو سبب الـ CPI العالي عندك؟
آه، وده أكتر خطأ متكرر بنشوفه. نفس الـ 15,000 ريال على ad set واحد بتدي حوالي 290 حدث في الأسبوع، يعني فوق الـ 50 بمسافة مريحة. مقسومة على 6 ad sets بتدي حوالي 48 لكل واحد. كلهم تحت الرقم الحاكم، وكلهم عالقين في الاستكشاف للأبد. النتيجة: CPI أعلى بـ 20-40% على نفس الكرياتيف بالظبط.

خد بالك من حاجة بتزوّد المشكلة: الرقم ده محسوب على install. لو بتحسّن على حدث أعمق زي أول شراء، الـ 290 بتنزل لعشرات قليلة قبل ما تقسم أصلاً. يعني كل ما الحدث يعمق، كل ما التفتيت يبقى أغلى.
- اللي تلاحظه: أكتر من 3 ad sets شغالة في نفس الوقت، أغلبها مكتوب عليها “Learning limited”، وكل ad set بياخد أقل من 100 ريال في اليوم. تلاتتهم مع بعض يعني إنك مفتّت.
- الإصلاح: ادمج في ad set أو اتنين. لو بقيت على اتنين، شغّل Advantage campaign budget (يعني تحط الميزانية على مستوى الحملة و Meta توزّعها بين الـ ad sets بنفسها) بس جوا نفس المنصة. لو بقيت على ad set واحد، إنت مش محتاجها أصلاً. وحط قاعدة ثابتة للفريق: ماتفتحش ad set جديد إلا لو ميزانيته لوحده هتوصله لـ 50 حدث في الأسبوع. لو مش هتوصل، الـ ad set ده مش اختبار، ده تبديد.
- الحسبة اللي تعملها في دقيقة: اقسم ميزانيتك الأسبوعية على تكلفة الحدث اللي بتحسّن عليه، والناتج اقسمه على 100 مش على 50. ليه 100؟ لأن الـ 50 ده الحد الأدنى للخروج من الاستكشاف، ولو خطّطت عنده بالظبط، أول أسبوع بطيء بيرجّعك تحته تاني وتدفع الاستكشاف من الأول. مثال على السيناريو المرجعي: 3,500 ريال في الأسبوع ÷ 12 ريال للـ install = 292 حدث، ÷ 100 = 2.9. يعني ad set أو اتنين، مش ستة.
- لو حجم تطبيقك صغير: متفتّتش عشان تختبر. انزل درجة في سلّم الأحداث بدل كده. يعني بدل ما تفتح ad set تاني عشان “تجرّب جمهور”، حسّن على حدث أسطح شوية عشان توصل للـ 50. التفاصيل في الخطأ التالت.
- التكلفة على السيناريو المرجعي: فرق 20-40% على 15,000 ريال يساوي 3,000 لـ 6,000 ريال في الشهر. الفلوس دي مش رايحة لكرياتيف أحسن ولا لجمهور أغلى. رايحة تمن استكشاف بيتعاد كل أسبوع.
ليه لازم تفصل حملة iOS عن Android؟
لأن الاتنين مش نفس السوق ولا نفس نظام القياس. أجهزة Android بتتقاس بشكل مباشر وفوري. أجهزة iOS بتتقاس أساساً عبر نظام SKAN، بنافذة مؤجلة ومجمّعة، و Meta بتكمّل الناقص بتقدير. لما تحط الاتنين تحت ميزانية حملة واحدة، الخوارزمية بتصبّ الفلوس على المنصة اللي بتبلّغ أسرع وأرخص ظاهرياً، مش اللي بتجيب قيمة أعلى فعلياً.

خلّي بالك من تفصيلة عملية هنا: في حملات التطبيقات إنت بتختار التطبيق على مستوى الـ ad set، وتطبيق iOS وتطبيق Android هما تطبيقين مختلفين عند Meta. فالخلط مش بيحصل جوا ad set واحد، بيحصل لما تحط الـ ad setين تحت حملة واحدة بميزانية مشتركة. ساعتها Meta بتاخد قرار التوزيع خلال ساعات، وإشارة iOS بتوصلها بعد يوم أو أكتر. فالسباق محسوم من قبل ما يبدأ.
- اللي تلاحظه: 85% أو أكتر من الإنفاق راح لـ Android من غير ما تقرر إنت ده. للتأكد: افتح تقرير الحملة، ومن قايمة Breakdown اختار Impression Device، وشوف الإنفاق اتوزّع إزاي بين أجهزة iPhone وأجهزة Android.
- الإصلاح: حملتين منفصلتين، ميزانيتين مستقلتين، وقراءتين مختلفتين. ومتقارنش الـ CPI بينهم أصلاً، لأنك بتقارن رقم مقيس بشكل مباشر برقم مقدّر ومجمّع. المقارنة الوحيدة اللي ليها معنى هي مقارنة كل منصة بنفسها عبر الوقت.
- التكلفة على السيناريو المرجعي: في تطبيقات B2C اللي بنشتغل عليها في الخليج، شريحة iOS بتيجي بـ LTV أعلى. يعني الخوارزمية بتخصم من الشريحة الأربح وتديها للأرخص. لو الطبيعي عندك 60% Android و 40% iOS، والحملة الموحّدة دفعت 85% ناحية Android، ده 3,750 ريال في الشهر اتنقلوا للشريحة الأقل قيمة. حسب حجم الميل، الرقم بيقع بين 2,000 و 4,000 ريال. الـ CPI في التقرير بينزل، والربح بينزل معاه.
هل تحسّن على Install ولا على Purchase؟
اختار أعمق حدث بيديك 50 حدث في الأسبوع لكل ad set. لا أعمق ولا أسطح. الـ install بيجيبلك أرخص ناس، مش أحسن ناس. والقفز على الشراء وإنت لسه بتعمل 10 عمليات في الأسبوع بيقتل الإشارة تماماً. السلّم بالترتيب: install، بعده Registration، بعده أول شراء، بعده التحسين على القيمة (Value).
خد الحساب على السيناريو المرجعي. 290 install في الأسبوع. لو 40% منهم بيكملوا التسجيل، يبقى عندك 116 تسجيل في الأسبوع، وده فوق الـ 50 بمسافة. لو 5% بس بيوصلوا لأول شراء، يبقى حوالي 15 عملية في الأسبوع، وده تحت الـ 50 بكتير. يعني في الحالة دي التحسين على Registration هو الاختيار الصح، والتحسين على Purchase هيوقّف التوصيل (يعني Meta تبطّل تعرض إعلانك أصلاً). الحسبة دي تعملها في 5 دقايق على تقرير الـ MMP بتاعك وتخرج منها بقرار.
| الحدث | متى تستخدمه | الحد الأدنى الأسبوعي لكل ad set | المخاطرة |
|---|---|---|---|
| الـ Install | تطبيق جديد، مفيش تاريخ أحداث كافي | 50 install | بيجيب أرخص المستخدمين، والـ retention بينهار بعد يوم |
| الـ Registration | لما التسجيلات تعدي 50 في الأسبوع بثبات | 50 تسجيل | أقرب للجودة، بس لسه مش مربوط بفلوس |
| أول شراء (First Purchase) | لما المشتريات تعدي 50 في الأسبوع لكل ad set | 50 عملية شراء | لو أقل، التوصيل بيتقطع والـ CPM بيطلع |
| التحسين على القيمة (Value) | لما يبقى فيه تفاوت حقيقي في قيمة الطلب | 50 عملية شراء بقيم متفاوتة | لو القيم متقاربة، مفيش مكسب من الـ value أصلاً |
- اللي تلاحظه: إعلانات تحميل التطبيق بتجيب أرقام install كبيرة، وأول ما تبص على الـ retention تلاقيه ضعيف. ومتقارنش هنا بمتوسط السوق، قارن تطبيقك بنفسه: هات نسبة الـ D7 retention (اللي فتحوا التطبيق تاني بعد 7 أيام) للمستخدمين الجايين من الإعلانات، مقابل نفس النسبة للمستخدمين الـ organic في نفس الفترة. لو المدفوع أقل من نص العضوي، حدث التحسين عندك أسطح من اللازم. أو الحالة العكسية: حوّلت على Purchase وبقى التوصيل متقطع والـ CPM طالع من غير سبب واضح.
- الإصلاح: احسب أحداثك الأسبوعية لكل درجة في السلّم من الـ MMP. اختار أعمق درجة فوق الـ 50. واطلع درجة واحدة بس لما تفضل فوق الرقم ده تلات أسابيع متتالية. الترقّي بيبقى قرار برقم، مش بحماس.
- التكلفة على السيناريو المرجعي: افتح الـ MMP وهات نسبة الـ installs المدفوعة اللي مفتحتش التطبيق تاني بعد اليوم الأول. لو الرقم عندك 30%، ده حوالي 375 install في الشهر × 12 ريال، يعني قرابة 4,500 ريال بتدفعها على ناس مش هتفتح التطبيق تاني. حط نسبتك إنت مكان الـ 30% وهتطلع برقمك.
الأخطاء اللي فاتت بتشوفها بنفسك. اللي جاي مش هتشوفه.
هيكلة الحملات والـ ad sets ظاهرة قدامك في الـ Ads Manager. لكن جدول الأحداث اللي بيتبعت لـ iOS (الـ SKAN schema) ومصدر الإسناد مش بيظهروا في أي شاشة. في جلسة استشارية (30 دقيقة) بـ $50، نراجع هيكلة حملاتك وجدول أحداثك، ونقولك بالظبط فين ميزانيتك بتروح كل شهر.
إزاي الـ SKAN conversion value schema بيخرّب حملات iOS؟
بيخرّبها لما الـ schema (يعني الجدول اللي بيحدد أنهي حدث بياخد أنهي رقم في خانة الـ conversion value) ماتبقاش مرآة للأحداث اللي بتحسّن عليها في Meta. ساعتها إنت بتحسّن على إشارة مش هي اللي بتجيب فلوس. والجزء اللي بيعدّي من غير ما حد ياخد باله هو نافذة القياس. مستخدم بيشتري يوم 4 والنافذة عندك مقفولة على 24 ساعة، يبقى الشراء ده غير موجود خالص في عيون الخوارزمية.
- اللي تلاحظه: أسماء الأحداث في الـ MMP مش هي نفسها في Meta (مثلاً “purchase” هناك و “first_order” هنا)، أو النافذة سايبها على الإعداد الافتراضي من غير ما حد يراجعها، أو تفتح تقرير الـ SKAN وتلاقي معظم الـ conversion values راجعة صفر.
- الإصلاح في خطوتين: الأولى، اقعد مع الجدولين جنب بعض واعمل mapping سطر بسطر بين أحداث Meta والـ schema، وراجع كمان ترتيب أحداثك بالأولوية في Events Manager، لأن الترتيب ده هو اللي بيحدد أنهي حدث يتحسب لمستخدم iOS أصلاً (ده نظام AEM). التانية، ظبّط النافذة على وقت الشراء الحقيقي عندك: افتح تقرير الـ cohort في الـ MMP، هات الوسيط (median) لزمن أول شراء، ومدّد النافذة عشان تغطي أغلب المشتريات مش نصها. الرقم ده موجود في الـ MMP، متخمّنش فيه.
- اتأكد من نسخة SKAN اللي شغال بيها: لو الـ MMP والشبكة عندك مفعّلين نسخة SKAN 4، بيوصلك لحد 3 تقارير (postbacks) على فترات متتالية بتوصل لحد 35 يوم بعد الـ install، يعني المشتريات المتأخرة ليها فرصة تتقاس. ده إعداد بيتفعّل، مش بيشتغل لوحده. اسأل عليه بالاسم قبل ما تفترض إنك شغال بيه.
- التكلفة على السيناريو المرجعي: لو 30-50% من مشترياتك بتحصل بعد نافذتك الحالية، إنت بتدرّب الخوارزمية على نص البيانات. مش بتخسر فلوس مباشرة هنا، بتخسر حاجة أغلى: كل حملات iOS بتتعلّم غلط، والقرارات اللي بعدها كلها مبنية على نص الصورة.
لو عايز تفهم النظام ده من الأول قبل ما تلمس الـ schema، ده مفصّل في إزاي SKAdNetwork بيشتغل فعلاً.
هل بتصفّر الـ learning phase كل أسبوع من غير ما تحس؟
أي تعديل جوهري بيرجّع الـ ad set لنقطة الصفر. قفزة كبيرة في الميزانية، تغيير حدث التحسين، تغيير الجمهور، أو استبدال الكرياتيف كله مرة واحدة. كل reset بيكلفك 5 لـ 7 أيام بسعر الاستكشاف. لو بتعمل كده مرتين في الشهر، إنت عملياً بتشتري نص الشهر بسعر أغلى.
- اللي تلاحظه: بتدخل الحساب وتغيّر حاجة كل يومين. أو بتحكم على ad set بعد 48 ساعة وتقفله. لو فتحت سجل التعديلات (Edit history) ولقيت أكتر من 4 تعديلات جوهرية في الشهر على نفس الـ ad set، ده هو.
- الإصلاح: زوّد الميزانية على دفعات محدودة كل 3-4 أيام بدل القفزة المضاعفة. غيّر متغير واحد بس في المرة. وسيب الـ ad set 5-7 أيام بعد أي تعديل قبل ما تحكم عليه. لو الفريق بتاعك أكتر من واحد، اكتب القاعدة دي في مكان مشترك، لأن أغلب الـ resets بتحصل من تعديلين مختلفين في نفس اليوم من شخصين.
- التكلفة على السيناريو المرجعي: ريسيت مرتين في الشهر يساوي 10-12 يوم بسعر استكشاف. يعني حوالي 6,000 ريال من ميزانيتك بتتصرف في المرحلة الأغلى. بفرق التكلفة نفسه (20-40%)، ده 1,200 لـ 2,400 ريال في الشهر بتدفعها تمن إعادة تعلّم كنت مستغني عنها.
هل بتدفع فلوس عشان تجيب ناس التطبيق عندهم أصلاً؟
آه، لو مفيش عندك exclusion audience مبني على app events. من غيرها إنت بتدفع تكلفة اكتساب على مستخدمين حاليين وعلى إعادة تنزيل (reinstalls). والنتيجة مخادعة: الـ CPI الظاهر في الـ Ads Manager بيبقى أحلى من الحقيقة، لأن الناس دي بتنزّل بسهولة. والـ CAC الحقيقي بيبقى أسوأ، لأنهم مش عملاء جداد. فبتوسّع حملة إنت فاكرها رابحة.
- اللي تلاحظه: مفيش custom audience مستبعد من app events في أي ad set. أو تفتح الـ MMP وتلاقي فرق واضح بين الـ new installs والـ total installs. الفرق ده هو اللي بتدفع فيه مرتين.
- الإصلاح: ابني exclusion audience من نشاط التطبيق: كل من فتح التطبيق آخر 180 يوم (وده أقصى مدى بيسمح بيه جمهور نشاط التطبيق في Meta)، واستبعده من كل حملات الاكتساب. وضيف فوقه قائمة عملائك الحاليين كـ customer list لو عندك إيميلات أو أرقام، لأن جمهور الـ app activity بيشوف بس المستخدمين اللي أحداثهم بتوصل Meta فعلاً. وافصل حملة re-engagement لوحدها بميزانية وهدف منفصلين، لأن استرجاع مستخدم قديم شغل مختلف تماماً عن اكتساب واحد جديد، وتكلفته المقبولة مختلفة كمان.
- التكلفة على السيناريو المرجعي: إجمالي الـ installs في الشهر حوالي 1,250. لو 8-15% منهم مستخدمين عندك أصلاً، ده 100 لـ 190 install × 12 ريال، يعني 1,200 لـ 2,250 ريال في الشهر بتتدفع مرتين على نفس المستخدم.
وفيه حتة تانية: الرقم ده بيدخل في حساب الـ CAC بتاعك ويخليه يبان أحسن من الحقيقة. عشان كده ابدأ من هنا: احسب الـ CAC الحقيقي مش الظاهر.
تحكم على أداء iOS من الـ Ads Manager ولا من الـ MMP؟
من الـ MMP، دايماً. اختلاف الرقمين طبيعي، لأن نوافذ الإسناد مختلفة ونظام SKAN مؤجل ومجمّع. اللي مش طبيعي إنك تقفل ad set أو تكبّره بناءً على الرقم الأول. القاعدة الوحيدة اللي بتوقف النزيف في قياس حملات التطبيقات: القرارات المالية من مصدر واحد ثابت طول الوقت.
- اللي تلاحظه: قفلت ad set الأسبوع اللي فات لأن Meta قالت صفر purchases، وبعدين فتحت الـ MMP ولقيته مسجّل عليه مشتريات فعلية. الفجوة دي بتكبر على iOS تحديداً لأن جزء من الإشارة بيوصل متأخر أو بيتحجب لحماية خصوصية المستخدمين.
- الإصلاح: اكتب “مصدر الحقيقة” حرفياً في أول سطر في الـ reporting sheet بتاعك. اقفل نافذة الإسناد على إعداد واحد وماتغيّرهاش كل شهر. وماتخلطش أرقام المصدرين في نفس الجدول أبداً، حتى لو في عمودين منفصلين، لأن أول مقارنة بصرية بينهم بتنتهي بقرار مختلط.
- التكلفة على السيناريو المرجعي: قفل ad set واحد رابح بالغلط يعني إنك خسرت كل الـ learning اللي دفعت فيه، وهتبدأ من الصفر بسعر الاستكشاف تاني. يعني التكلفة مش الأسبوع اللي فات بس، دي أسبوع جديد كمان بسعر أعلى.
لو عايز تشوف مصدر الفجوة دي بالتفصيل والأمثلة، ده مشروح في ليه أرقام فيسبوك مش بتطابق المبيعات.
ليه Advantage+ App Ads مش بيدي نتيجة أحسن عندك؟
لأن نظام AAA بيشتغل مكبّر صوت، مش ورشة تصليح. بيدي نتيجة أحسن لما يتغذى صح: حجم أحداث كافي وتنوّع حقيقي في مفاهيم الكرياتيف. لو دخّلته إشارة مفتّتة و 20 نسخة من نفس الفيديو، هتوصل لنفس النتيجة الضعيفة بس أسرع. الأتمتة بتكبّر اللي عندك، مش بتصلحه.
- اللي تلاحظه: شغّلت AAA والنتيجة زي ما هي أو أسوأ. وتفتح مكتبة الإعلانات بتاعتك تلاقي كل الكرياتيفات نفس المفهوم بألوان وموسيقى مختلفة. ده مش تنوّع، ده نسخ.
- الإصلاح: صلّح الخطأ 1 والخطأ 3 الأول. وبعدين ادخل بـ 4-6 مفاهيم مختلفة فعلاً: زاوية بيع مختلفة، مشكلة مختلفة، شكل مختلف. الفرق بين المفهوم والـ variation إن المفهوم بيغيّر السبب اللي بيخلي المستخدم يهتم، والـ variation بتغيّر الشكل بس.
- إزاي تقرا النتيجة صح: اعمل جدول بسيط فيه صف لكل مفهوم، واجمع تحته كل الأصول اللي طلعت منه. قارن على مستوى المفهوم: الـ CPI، ونسبة اللي وصلوا لحدث التحسين من إجمالي الـ installs. مقارنة الأصول فرادى بتوقعك في فخ إنك تقفل مفهوم كويس عشان نسخة واحدة منه كانت ضعيفة.
- التكلفة على السيناريو المرجعي: مش رقم بالريال، ده شهر كامل من الاختبار بيخلص من غير ما تقدر تطلع منه بإجابة. وبعده بترجع تبدأ من نفس النقطة اللي بدأت منها.
لو محتاج طريقة عملية تولّد بيها مفاهيم مش نسخ، ده مشروح في إزاي تطلّع مفاهيم كرياتيف مختلفة فعلاً.
تصلّح إيه بالظبط في أول أسبوع؟
أسبوع واحد يكفي لتلات إصلاحات هيكلية بس: فصل iOS عن Android في حملتين، دمج الـ ad sets مع ضبط حدث التحسين، وتركيب الـ exclusion audience. وبعدها خمس أيام ماتلمسش فيها حاجة. متحاولش تعمل التمانية مرة واحدة، لأن كل تعديل بيصفّر الـ learning، وهتقع في الخطأ الخامس وإنت بتصلّح الباقي.
- يوم 1: افصل iOS عن Android في حملتين بميزانيتين مستقلتين. ده أسرع إصلاح وأوضح أثر.
- يوم 2: ادمج الـ ad sets في واحد أو اتنين، وارجع لحدث تحسين بيديك فوق 50 حدث في الأسبوع حسب حسبة السلّم فوق.
- يوم 3: ركّب الـ exclusion audience (كل من فتح التطبيق آخر 180 يوم)، واكتب في الـ reporting sheet إن مصدر الحكم هو الـ MMP.
- من يوم 4 لـ يوم 8: اقفل إيدك. ماتلمسش حاجة خالص. مفيش تعديل ميزانية، مفيش كرياتيف جديد، مفيش استهداف.
تنبيه مهم: الأسبوع الأول ممكن الأرقام تسوء قبل ما تتحسن. ده متوقع، لأن الـ learning بيعيد البناء مرة أخيرة على هيكلة سليمة. لو حكمت يوم 3 وقلبت كل حاجة تاني، هتفضل في نفس الحلقة للأبد. الحكم يوم 8، مش قبله.
وقبل ما تبدأ الأسبوع ده، اتأكد إن الأحداث نفسها بتوصل صح من الأساس. لو الـ tracking فيه خلل، الإصلاحات دي هتتبني على أرقام غلط: أخطاء التتبع اللي بتسبق ده كله.
الأخطاء التمانية دي مش بتظهر كتحذير في أي مكان
لو بتصرف على حملات تطبيقك وحاسس إن الأرقام مش منطقية، إحنا بنراجع إدارة حملات تطبيقات B2C في المنطقة كل يوم. في جلسة استشارية (30 دقيقة) بـ $50، نبص على هيكلة الحملات والـ event mapping ومصدر الإسناد، ونطلّعلك قائمة إصلاحات مرتبة بالفلوس اللي بترجعها كل شهر.
أسئلة شائعة عن حملات التطبيقات على Meta
كام ad set المفروض أشغّل في حملة تطبيق على فيسبوك؟
واحد لاتنين في أغلب الحالات. القاعدة الحاكمة مش عدد الـ ad sets، دي إن كل ad set لازم يوصل لـ 50 حدث تحسين في الأسبوع لوحده. اقسم ميزانيتك على تكلفة الحدث اللي بتحسّن عليه، وشوف كام ad set تقدر تموّله فوق الرقم ده. لو الناتج واحد، شغّل واحد. فتح ad set خامس مش اختبار، ده تقسيم الإشارة على خمسة.
قد إيه سعر الإعلان على فيسبوك للتطبيقات؟
مفيش رقم واحد ينفع تبني عليه، لأنه بيتغير حسب الدولة والمنصة والفئة والموسم. بس الحاجة اللي محدش بيقولهالك: الهيكلة لوحدها بتفرق 20-40% في تكلفة النتيجة على نفس الكرياتيف ونفس الجمهور. يعني قبل ما تدوّر على متوسط السوق، شوف إنت واقف فين من الـ 50 حدث في الأسبوع. ده أسرع تخفيض تكلفة متاح قدامك.
ليه أرقام Meta مختلفة عن أرقام الـ AppsFlyer؟
لسببين. الأول إن نوافذ الإسناد مختلفة بين المصدرين، فكل واحد بيحسب فترة مختلفة. والتاني إن إشارة iOS بتوصل عبر نظام SKAN مؤجلة ومجمّعة، فـ Meta بتكمّل الناقص بتقدير. الاختلاف نفسه طبيعي ومتوقع. اللي مش طبيعي إنك تاخد قرار مالي من المصدرين بالتبادل. اختار مصدر واحد للقرارات المالية والزمه.
قد إيه بستنى قبل ما أقفل ad set؟
من 5 لـ 7 أيام بعد آخر تعديل جوهري، مش من تاريخ الإطلاق. لو عدّلت الميزانية يوم 3، العداد بيبدأ من يوم 3 تاني. والحكم قبل كده بيبقى على أرقام مرحلة الاستكشاف، يعني على أسوأ نسخة من الـ ad set. على iOS استنى ناحية الـ 7 أيام، لأن الإشارة بتوصل متأخرة أصلاً.
هل Advantage+ App Ads أحسن من الحملات اليدوية؟
أحسن لما الإشارة سليمة. الأتمتة بتحتاج حجم أحداث كافي وتنوّع حقيقي في المفاهيم عشان تلاقي أنماط. لو الإشارة مفتّتة أو حدث التحسين غلط، بيوصل لنفس النتيجة الضعيفة بس أسرع وبميزانية أكبر. الترتيب الصح: صلّح الهيكلة وحدث التحسين، وبعدين شغّله.
إزاي أعرف إن حملات تطبيقات فيسبوك عندي فيها مشكلة قياس مش مشكلة كرياتيف؟
تلات فحوصات في ربع ساعة. واحد: كام ad set مكتوب عليه “Learning limited”؟ لو أكتر من النص، المشكلة هيكلية. اتنين: قارن أرقام Meta بأرقام الـ MMP لنفس الأسبوع، وشوف حجم الفجوة على iOS تحديداً. تلاتة: افتح نافذة الـ conversion value وقارنها بالوسيط الحقيقي لزمن أول شراء عندك. لو أي فحص من التلاتة طلع غلط، متغيّرش الكرياتيف. الكرياتيف الجديد هيتحاكم بنفس الأرقام الغلط.
اقرأ كمان
- 7 علامات إن الـ tracking setup بتاعك بيكذب عليك
- شرح SKAdNetwork بالعربي: إزاي iOS غيّر قياس التطبيقات
- إزاي تحسب الـ CAC الحقيقي لتطبيقك
- ليه أرقام فيسبوك مش بتطابق المبيعات
- إبداعات إعلانات بالذكاء الاصطناعي: إزاي تطلّع winners