أكتر جملة بسمعها بعد تركيب Conversions API: "الأرقام زادت، يبقى شغال". وأنا أول سؤال بسأله: زادت ولا اتكررت؟ لأن الاتنين بيبانوا بنفس الشكل في الداشبورد.
المقال ده بيمشي على توثيق ميتا نفسه في النقطة دي تحديداً، لأنها النقطة اللي بتحدد إذا كان القياس بتاعك بقى أدق ولا بقى متفائل.
بيعمل إيه أصلاً
توثيق ميتا لـ Conversions API بيوصفه بإنه بينشئ اتصال بين بيانات المعلن التسويقية، من السيرفر أو منصة الموقع أو التطبيق أو الـ CRM، وبين أنظمة ميتا اللي بتحسّن استهداف الإعلانات.
والنقطة المهمة إن أحداث السيرفر بتتعالج زي الأحداث اللي بتتبعت بالبيكسل أو الـ SDK، وممكن تُستخدم في القياس والتقارير والتحسين بطريقة مشابهة للقنوات التانية.
يعني هو مش قناة بديلة بقواعد تانية. هو نفس النظام بمدخل مختلف، والمدخل ده مش بيتأثر بحاصرات الإعلانات ولا بقيود المتصفح على نفس الدرجة. ودي كل الميزة، ومش ميزة صغيرة.
منع التكرار: الجزء اللي بيغلط فيه الكل
لو هتفتكر حاجة واحدة من المقال ده، خليها دي. صفحة ميتا عن منع تكرار أحداث البيكسل والسيرفر بتحدد طريقتين، والفرق بينهم مش تفصيلة.
| الطريقة | المطلوب | الحدود |
|---|---|---|
| المعرّف والاسم | eventID في البيكسل = event_id في الـ API، و event = event_name | الطريقة الموصى بيها |
| fbp أو external_id | تطابق event_name مع fbp أو external_id | بتشتغل بس لو الحدث اتبعت من المتصفح الأول بعدين السيرفر |
التوثيق بيقول بالنص إن تحديد إذا كانت الأحداث متطابقة بيتم بناءً على المعرّف والاسم. يعني المعرّف لوحده مش كفاية، والاسم لوحده مش كفاية. الاتنين مع بعض.
والحد المهم في الطريقة التانية إنها بتشتغل بس في اتجاه واحد: من المتصفح الأول، وبعدين من السيرفر. لو الترتيب عندك بالعكس، الطريقة دي مش هتمنع تكرار.
نافذة الـ 48 ساعة
الرقم اللي مش بيتقال كفاية: نافذة منع التكرار 48 ساعة. التوثيق بيقول إن الأحداث بيتمنع تكرارها بس لو وصلت خلال 48 ساعة من استلام أول حدث بنفس الـ event_id.
ليه ده مهم عملياً؟ لأن أي إرسال متأخر من السيرفر، زي عملية بتتأكد بعد يومين أو نظام بيبعت دفعات مرة في اليوم وعنده تأخير، ممكن يقع برة النافذة ويتعدّ حدث مستقل. وده بيبان في التقارير كأنه أداء أحسن.
والتوثيق بيقول كمان إن النظام بيفضّل عموماً الحدث اللي وصل الأول. يعني لو انت مفترض إن نسخة السيرفر هي الأدق وهتغلب، الافتراض ده مش مضمون.
بيرجّع إيه فعلاً وبيسيب إيه
خلّيني أكون صريح في الحجم، لأن ده اللي بيتباع غلط.
بيرجّع: أحداث اتمنعت في المتصفح لأسباب تقنية، وأحداث بتحصل أصلاً برة المتصفح زي تأكيد أوردر في نظام داخلي أو مكالمة بتتحول لبيع. الجزء التاني ده هو أكبر مكسب حقيقي وأقل حاجة بتتستخدم.
مش بيرجّع: موافقة المستخدم لو مش موجودة، ولا بيلغي حدود الأتربيوشن، ولا بيخليك تشوف رحلة العميل كاملة. وأي حد بيقولك إن CAPI هيرجّع الأرقام لما كانت عليه قبل قيود الخصوصية بيبيعلك توقع مش منتج.
الفرق اللي بيفضل بعد التركيب الصح موجود وبيختلف من حساب للتاني، ومحدش يقدر يديك نسبة ثابتة عليه. لو حد قالك رقم محدد من غير ما يشوف حسابك، ده تخمين.
الأحداث اللي برة المتصفح هي المكسب الحقيقي
الجزء ده بيتقال بسرعة في أغلب الشروحات وهو أهم جزء عملياً. أغلب الحسابات بتركب CAPI عشان ترجّع أحداث الويب اللي اتمنعت، وده مكسب محدود لأن البيكسل أصلاً بيمسك أغلبها.
المكسب الأكبر بييجي من أحداث مالهاش علاقة بالمتصفح من الأساس: أوردر بيتأكد في نظام داخلي بعد مكالمة، أو ليد بيتحول لعميل بعد أسبوعين في الـ CRM، أو عملية بترجّع فبتلغي التحويل.
الأحداث دي المنصة معندهاش أي طريقة تعرفها غير إنك تبعتها. ولما تبعتها، انت مش بس بتحسّن التقارير، انت بتغيّر اللي النظام بيتعلم عليه، لأن التحسين بيشتغل على الإشارة اللي بتوصله.
وفي الحالة دي تحديداً، نافذة الـ 48 ساعة بتبقى قيد حقيقي لازم تخطط ليه. لو دورة التأكيد عندك أطول من يومين، اقبل إن الربط بالحدث الأصلي مش هيحصل، وابعت الحدث كحدث مستقل بوعي بدل ما تكتشف الازدواج بعدين.
قايمة فحص قبل ما تصدّق الأرقام
قبل ما تبني قرار ميزانية على أرقام بعد CAPI، افحص الآتي:
- هل كل حدث بيتبعت من الجهتين معاه event_id موحّد وثابت؟
- هل الـ event_name متطابق حرفياً بين البيكسل والسيرفر؟
- هل فيه أحداث بتتبعت من السيرفر بعد أكتر من 48 ساعة من الحدث الأصلي؟
- هل جربت تقارن عدد الأحداث قبل وبعد على نفس الفترة، مش على فترتين مختلفتين؟
السؤال الأخير هو اللي بيكشف أغلب الحالات. ناس كتير بتقارن الشهر ده بالشهر اللي فات وتنسب الفرق للتركيب، والشهرين مش قابلين للمقارنة أصلاً.
الحد الأمين
Conversions API خطوة صح ومحتاجها، بس هو تحسين في جودة الإشارة مش استرجاع للماضي. ولو اتركّب من غير منع تكرار مظبوط، هو مش بيحسّن القياس، هو بيخليك واثق في رقم أعلى من الحقيقة، وده أسوأ من إنك تكون عارف إن عندك نقص.
وأنا بفضّل حساب فيه نقص معروف على حساب فيه زيادة مجهولة، لأن الأول بتقدر تصحح عليه.
الموضوع ده مرتبط مباشرة بالفرق بين ROAS المنصة والمبيعات الحقيقية، وكتبت فيه ليه ROAS المنصة مختلف عن المبيعات الحقيقية، وطريقة تحديد هدف واقعي في ازاي تحدد هدف ROAS واقعي، وقراءة الأتربيوشن نفسها في نماذج الأتربيوشن في الإعلانات.
ولو انت بتشرح خطة القياس دي لعميل مش متخصص، وكالة كيه اف كتبت نسخة موجهة لصاحب البيزنس في كيف تقيس الحملات بدون كوكيز الطرف الثالث، وهي أقرب لخطة قياس شاملة منها لتفاصيل التركيب.