أكتر سوء فهم شايفه دلوقتي في حسابات ميتا مش في الكرياتيف ولا في الميزانية. هو في إن المعلن فاكر إنه بيحدد جمهور، والنظام شايف إنه بيدي اقتراح. الاتنين شغالين على نفس الشاشة وبيقروا نفس الحقول بشكل مختلف تماماً.
الموضوع ده موثّق، مش تخمين، والتوثيق أوضح مما معظم الناس فاكرة. خلينا نمشي عليه بالترتيب، وبعدين على اللي ينفع تعمله.
أربع حاجات بس بتتحسب كقيد
توثيق ميتا للمطورين بيحدد بالنص إن القيود التجارية غير القابلة للتفاوض مش بتتوسع، وبيعددها: قيود الموقع، الحد الأدنى للسن، اللغة، واستثناءات الجمهور المخصص. الأربعة دول وبس.
| اللي بتحطه | النظام بيتعامل معاه إزاي |
|---|---|
| الموقع الجغرافي | قيد. مش بيتوسع بره حدوده |
| الحد الأدنى للسن | قيد، وبشروط هنشرحها تحت |
| اللغة | قيد. مش بيتوسع |
| استثناءات الجمهور المخصص | قيد. اللي مستثنيه بيفضل مستثنى |
| الاهتمامات والسلوكيات التفصيلية | اقتراح. نقطة بداية بيتحرك بره منها |
| الجمهور المشابه | اقتراح. نقطة بداية |
الصف الأخير هو اللي بيوجع. المعلن اللي عامل جمهور مشابه واحد بالمية وفاكر إنه ضيّق الاستهداف، فعلياً إداه نقطة بداية والنظام بيتحرك بره منها لما يتوقع نتيجة أحسن. ده مش عيب في التركيب، ده الشكل الموثّق للمنتج.
حكاية السن، وهي غريبة
دي تفصيلة تقنية بس بتغيّر الاستهداف فعلياً وقليل ما بتتقال. التوثيق بيقول إنه لما Advantage+ audience يبقى شغال، نظام التوصيل بيرجّع age_min و age_max لقيمهم الافتراضية، والمعلن يقدر يحدد age_min بين ١٨ و ٢٥ بس، و age_max بيتثبت عند ٦٥.
يعني لو إنت بتبيع حاجة للفئة من ٣٥ لـ ٤٥، وشغّال Advantage+ audience، إنت مش بتستهدف من ٣٥ لـ ٤٥. إنت بتستهدف من الحد الأدنى المسموح لحد ٦٥، والنظام هو اللي بيقرر مين جوه ده يشوف الإعلان. لو ده مش اللي كنت فاكره، إنت مش لوحدك.
على مستوى الـ API نفسه الإعداد ده بسيط: advantage_audience بقيمة واحد جوه targeting_automation عشان تشغّله، وصفر عشان تقفله. اللي مش بسيط هو إن الشغل من الواجهة مش دايماً بيوضح إنك بتقلب حاجة بالحجم ده.
الإشارة الحقيقية جاية من عندك مش من الاستهداف
دلوقتي الجزء اللي فعلاً بيحدد الديليفري. النظام بيتعلم من أحداث التحويل اللي بتبعتهالوه، ولو الأحداث دي ناقصة أو مش متطابقة، إنت بتجوّعه وإنت فاكر إنك بتضبط استهداف.
توثيق Conversions API بيعدد ٢٣ باراميتر لبيانات العميل، وبيقول إن لازم تبعت واحد على الأقل منهم بالتنسيق الصح. والتقسيمة بينهم مهمة عملياً:
- بيانات التواصل: الإيميل، التليفون، الاسم الأول والأخير، تاريخ الميلاد، النوع، المدينة، المحافظة، الرقم البريدي، البلد. دي كلها لازم تتشفّر بـ SHA256 بعد التطبيع.
- المعرّف الخارجي external_id: بيتشفّر برضه.
- بيانات المتصفح والجهاز: عنوان الـ IP و user agent و fbc و fbp. دي مش بتتشفّر خالص.
- معرّفات تانية زي lead_id ومعرّف الصفحة: مش بتتشفّر.
التوثيق بيقول بالنص إن بعت client_ip_address و client_user_agent مع بعض ممكن يساعد في تحسين مطابقة الأحداث وكمان ممكن يساعد في تحسين توصيل الإعلان. ودي جملة تستاهل توقف عندها: مطابقة الأحداث مش موضوع تقارير بس، هي مدخل للديليفري نفسه.
وفيه تفصيلة صغيرة بتكسر حسابات كتير: التوثيق بيوصي إنك تحط كود الدولة دايماً كجزء من رقم التليفون. أرقام متبعتة من غير كود دولة بتقلل المطابقة، والمعلن مش بيشوف السبب لأن الحدث بيوصل ومبيرجعش خطأ. شرحت الجزء التقني ده في شرح Conversions API.
ازاي بتجوّع النظام من غير ما تعرف
أربع طرق شايفها بشكل متكرر، مرتبة من الأكتر شيوعاً:
الأولى: استثناءات كتير متراكمة من حملات قديمة. الاستثناء قيد حقيقي مش اقتراح، يعني كل واحد بتضيفه بيقلل المساحة فعلاً. حساب فيه عشر قوايم استثناء اتراكموا على سنتين ممكن يكون مقفّل نص السوق بتاعه من غير ما حد ياخد باله.
التانية: تقسيم الميزانية على مجموعات إعلانية كتير. كل مجموعة بتتعلم لوحدها، فبتقسم البيانات على عدد أكبر من الخانات وكل خانة بتوصل لعدد أحداث أقل. ده الرابط بين هيكل الحساب وبين مرحلة التعلم، وشرحته في مرحلة التعلم في اعلانات ميتا.
التالتة: قياس ناقص. بكسل لوحده من غير قياس من السيرفر بيوصّل جزء من الأحداث بس، والنظام بيتعلم من الجزء ده كأنه الكل.
الرابعة: تحسين على حدث بعيد جداً مع حجم صغير. لو التحويل النهائي بيحصل خمس مرات في الشهر، النظام مش هيتعلم منه حاجة، والحل مش استهداف أدق، الحل حدث أقرب وأكتر.
الترتيب اللي بشتغل بيه
لو هتراجع حساب، الترتيب ده بيوفر وقت، لأن كل خطوة بتخلي اللي بعدها أوضح:
ابدأ من الاستثناءات. اعمل جرد لكل قايمة استثناء شغالة واسأل عن كل واحدة: ليه دي هنا وإمتى اتحطت. اللي مالوش سبب دلوقتي يتشال. دي أسرع مكسب في المراجعة كلها لأنها قيود حقيقية.
بعدين اتأكد إن السن اللي إنت فاكره متطبّق فعلاً متطبّق. لو Advantage+ audience شغال، راجع الفقرة اللي فوق قبل ما تفترض حاجة.
بعدين راجع جودة الإشارات: كام باراميتر بتبعت، والتشفير مظبوط، وكود الدولة موجود. ده بيدي مردود أكبر من أي تعديل في الاستهداف نفسه.
وآخر حاجة، بس مش أقلهم، راجع الفرق بين اللي إنت شايفه كجمهور واللي فعلاً بيوصله الإعلان. الموضوع ده ليه حدود حقيقية شرحتها في ازاي تمنع الاعلان من استهداف جمهور غلط، وفي التارجيت الواسع مقابل التفصيلي.
ولو إنت في موقع صاحب البيزنس مش الميديا باير، والسؤال عندك هو نوع الحملة نفسها مش إعداداتها، فريق kfagency كاتبين مقارنة عملية في الفرق بين حملة الرسائل وحملة الليدز وامتى تستخدم كل نوع.
حدود وتحفظات
أول حاجة: كل التوثيق اللي فوق بتاع ميتا للمطورين، وهو بيوصف الـ API. الواجهة في Ads Manager ممكن تسمي نفس الحاجة باسم تاني أو تخفي إعداد موجود في الـ API، والفرق ده بيتغير. لو قرار بفلوس متعلق بالكلام ده، افتح التوثيق نفسه وشوف تاريخ آخر تعديل.
تاني حاجة: مقلتش إن Advantage+ audience أحسن ولا أوحش. التوثيق بيوصف سلوك مش نتيجة، والنتيجة بتختلف حسب حجم الداتا وطبيعة المنتج. اللي أنا متأكد منه إن اللي شغّاله من غير ما يعرف حكاية السن دي بياخد قرار مش عارف إنه بياخده.
تالت حاجة: مفيش رقم هنا لنسبة تحسّن المطابقة لما تضيف باراميتر. ميتا بتعرض مؤشر جودة مطابقة داخل Events Manager، وده الرقم الوحيد اللي يخصك، وهو بيختلف من حساب للتاني. أي رقم عام في الموضوع ده يتقال من غير مصدر يبقى مخترع.
أسئلة شائعة
يعني الاهتمامات بقت ملهاش لازمة؟
لأ، بس دورها اتغير. هي بقت اقتراح ونقطة بداية للنظام مش سور. القيود الحقيقية أربعة بس حسب التوثيق: الموقع، الحد الأدنى للسن، اللغة، واستثناءات الجمهور المخصص.
لو حددت السن من ٣٥ لـ ٤٥ هيتنفذ؟
لو Advantage+ audience شغال، لأ. التوثيق بيقول إن النظام بيرجّع age_min و age_max للقيم الافتراضية، وإنك تقدر تحدد age_min بين ١٨ و ٢٥ بس و age_max بيتثبت عند ٦٥.
إيه أهم حاجة أعملها لتحسين الديليفري؟
جودة الإشارات اللي بتبعتها، مش عدد الفلاتر. اتأكد إنك بتبعت أكبر عدد ممكن من باراميترات بيانات العميل بالتشفير الصح، وإن كود الدولة موجود مع أرقام التليفون.