فيسبوك بيقول 200 عملية شراء. بتفتح الـ backend تلاقي 120. أول رد فعل طبيعي: “أنا مغشوش؟”. اطمن، الفجوة دي طبيعية ومتوقّعة في معظم الحالات. السؤال اللي بيجي في دماغ أي حد بيصرف على إعلانات هو نفسه: ليه ارقام فيسبوك مش بتطابق المبيعات اللي شايفها في حسابي؟
الإجابة المختصرة: لأن فيسبوك ونظامك بيعدّوا حاجتين مختلفتين بطريقتين مختلفتين. مش لأن حد بيغشّك.
لكن السؤال الحقيقي مش “ليه الفجوة موجودة”. السؤال: هل الفجوة في الحدود الطبيعية؟ ولا فيه setup غلط بيخليك تاخد قرارات ميزانية على رقم بيكذب عليك؟ الفرق بين الاتنين هو الفرق بين إنك تنام مرتاح، وإنك توقف حملة شغّالة بإيدك.
قاموس سريع (قبل ما نبدأ)
- الـ attribution (نسب المبيعة): ربط الشراء بالإعلان اللي جابه. زي لما تسأل زبون: إنت جاي من أنهي إعلان؟
- الـ backend / CRM: النظام اللي بيسجّل مبيعاتك الحقيقية. الإيراد الفعلي بيظهر هنا، مش في المنصّة الإعلانية.
- الـ attribution window (نافذة النسب): المدة اللي فيسبوك بينسب فيها الشراء للإعلان. مثلاً 7 أيام بعد الضغط.
- الـ over-reporting: المنصّة بتدّعي مبيعات أكتر من الحقيقة. الرقم بتاعها أعلى من الـ backend.
- الـ under-reporting: المنصّة بتفوّت مبيعات. الرقم بتاعها أقل من الـ backend.
- الـ view-through conversion: حد شاف إعلانك من غير ما يضغط، وبعدين اشترى. فيسبوك بيحسبها ليه.
- الـ double counting: نفس عملية الشراء بتتعدّ مرتين. مرة في فيسبوك ومرة في جوجل، أو مرتين جوّه فيسبوك نفسه.
- الـ de-duplication: إن المنصّة تعرف إن النسختين من نفس الحدث هما حدث واحد، فتعدّه مرة واحدة.
- الـ Pixel / SDK: الكود اللي بيتسجّل فيه الأحداث من الموقع أو التطبيق.
- الـ CAPI (Conversions API): طريقة بتبعت بيها الأحداث من الـ backend مباشرة للمنصّة، بدل ما تعتمد على الـ Pixel في المتصفح بس.
- الـ ATT: إعداد في آيفون بيسأل المستخدم لو موافق يتتبّعوه. أغلب الناس بترفض.
- الـ SKAdNetwork (SKAN): نظام Apple اللي بيرجّع بيانات الحملات بشكل متأخر ومجمّع للحفاظ على الخصوصية.
- الـ modeled conversions: مبيعات فيسبوك بيقدّرها بالحساب الإحصائي بدل ما يعدّها واحدة واحدة.
- الـ cross-device: المستخدم بيبدأ على جهاز ويكمّل على جهاز تاني. ضغط على الموبايل واشترى على اللابتوب.
- الـ MMP: أداة قياس محايدة بتجمع أرقام كل القنوات في مكان واحد، زي حكم مستقل بدل ما كل قناة تحكم على نفسها.
ليه فيسبوك ونظامك بيطلّعوا أرقام مختلفة من الأساس؟
لأن المنصّتين بيعدّوا حاجتين مختلفتين بطريقتين مختلفتين، وده بالتصميم مش بالصدفة. فيسبوك بيقيس “تأثير الإعلان” حسب نموذجه: مين شاف أو ضغط الإعلان وبعدها اشترى. الـ backend بيقيس حاجة تانية خالص: اللي حصل فعلاً في الحساب. فطبيعي مايتطابقوش. الفجوة مش دليل غش، دي نتيجة منهجين قياس مختلفين.
خليها بتشبيه. تخيّل محل عنده عدّاد على الباب بيعدّ كل اللي دخلوا، وكاشير بيعدّ كل اللي دفعوا. لو العدّاد قال 200 والكاشير قال 120، ده مش معناه إن حد سرق. ده معناه إن الاتنين بيعدّوا حاجة مختلفة. واحد بيعدّ الاهتمام، والتاني بيعدّ الفلوس.
فيسبوك أقرب للعدّاد على الباب. هو بيقولك “أنا ساعدت في 200 عملية”. الـ backend أقرب للكاشير. بيقولك “وصلني 120 بالفعل”. الرقمين صح، كل واحد في سياقه. المشكلة بس لما تعامل رقم العدّاد كإنه رقم الكاشير وتبني عليه قرار ميزانية.
إيه الفرق بين فيسبوك بيضخّم الرقم وفيسبوك بيقلّله؟
اتجاه الفجوة بيقولك مشكلة مختلفة تماماً، فأول حاجة تعملها قبل أي حل: اعرف فجوتك رايحة فين. فيه حالتين.
الحالة الأولى، فيسبوك بيدّعي أكتر من الحقيقة (over-reporting). فيسبوك بيقول 200 والـ backend بيقول 120. ده غالباً بسبب double counting، أو view-through conversions، أو نافذة نسب طويلة بتنسب مبيعات قديمة لحملة جديدة. الرقم متضخّم لأن المنصّة بتدّعي فضل في مبيعات ماهياش سببها بالكامل.
الحالة التانية، فيسبوك بيدّعي أقل من الحقيقة (under-reporting). فيسبوك بيقول 80 والـ backend بيقول 200. ده غالباً بسبب آيفون والـ ATT، أو الـ cross-device، أو نافذة نسب قصيرة بتفوّت اللي اشتروا متأخر. الرقم ناقص لأن المنصّة مش شايفة جزء من المبيعات اللي هي فعلاً ساعدت فيها.
القاعدة العملية: متروحش تدوّر على حل قبل ما تعرف الاتجاه. علاج الـ over غير علاج الـ under تماماً. واحد بيتحل بتنضيف الإعداد، والتاني بتتعايش معاه وتعدّله في حساباتك.
إزاي الـ attribution window بيغيّر الرقم؟ (السبب 1)
لأن الـ attribution window هو المدة اللي فيسبوك بينسب فيها الشراء للإعلان، وأي شراء بره المدة دي بيختفي من رقمه. الإعداد الافتراضي بقى 7 أيام بعد الضغط ويوم واحد بعد المشاهدة (7-day click و 1-day view).
يعني إيه عملياً؟ لو حد ضغط الإعلان النهارده واشترى بعد 9 أيام، الشراء ده مش هيتحسب لفيسبوك. خرج بره الـ 7 أيام. النتيجة under-reporting طبيعي تماماً، خصوصاً في التطبيقات اللي قرار الشراء فيها بياخد وقت زي العقارات أو الكورسات أو أي حاجة سعرها عالي.
والعكس بيحصل برضه. لو وسّعت النافذة جداً، ممكن فيسبوك ينسب مبيعات قديمة كانت جاية من حملة قبل كده، لحملة جديدة شغّالة دلوقتي. ده over-reporting. النافذة الطويلة بتدّي الفضل لإعلان لمس العميل بالصدفة في آخر لحظة.
الخلاصة اللي تطبّقها بكرة: اعرف نافذة النسب المفعّلة في حسابك، واعرف متوسط المدة بين أول تفاعل والشراء في تطبيقك. لو الناس بتشتري متأخر عن النافذة، إنت بتشوف under-reporting طبيعي، والرقم الحقيقي أعلى من اللي فيسبوك بيقوله.
حاسس إن الفجوة عندك أكبر من الطبيعي؟
في الغالب السبب في الـ setup مش في الإعلانات. ده بالظبط اللي بنكشفه في الـ Free Audit. في 30 دقيقة نراجع نافذة النسب والـ tracking ونقولك الفجوة طبيعية ولا فيه خلل بيكلّفك.
ليه نفس عملية الشراء بتتعدّ مرتين عبر القنوات؟ (السبب 2)
لأن كل منصّة شايفة آخر تفاعل عندها بس، وبتدّعي الفضل في الشراء لنفسها. ده اسمه double counting بسبب منطق الـ last-click، يعني كل قناة بتنسب العميل لآخر مرة لمسها فيها.
الصورة بالأرقام بسيطة. تخيّل عميل واحد شاف إعلان فيسبوك، وبعدها بيومين دوّر على جوجل وضغط إعلان واشترى. فيسبوك بيقول “أنا اللي عرّفته بيك، فهو بتاعي”. جوجل بيقول “أنا اللي جبت الضغطة الأخيرة، فهو بتاعي”. الاتنين بيعدّوا نفس العميل.
لو جمعت الأرقام كده، فيسبوك بيقول 150، جوجل بيقول 100، المجموع 250. بينما الـ backend شايف 180 عملية حقيقية بس. الـ 70 الزيادة دي مبيعات اتعدّت مرتين، مش مبيعات جديدة.
ده بالظبط ليه جمع أرقام المنصّات مع بعض بيطلّع رقم متضخّم دايماً. كل منصّة بتحسب لصالحها، ومحدش بيخصم التداخل. عشان كده المشغّلين اللي بيعتمدوا على مصدر واحد مستقل بيشوفوا الصورة الحقيقية، بدل ما يجمّعوا ادّعاءات متعارضة.
الخلاصة اللي تطبّقها بكرة: متجمعش رقم فيسبوك على رقم جوجل وتعتبره مبيعاتك. المجموع ده أكبر من الحقيقة بنسبة التداخل. خد رقمك من الـ backend، واستخدم أرقام المنصّات للمقارنة النسبية بينها بس.
إيه الـ view-through conversions وإزاي بتضخّم رقم فيسبوك؟ (السبب 3)
الـ view-through conversion هي إن حد شاف إعلانك من غير ما يضغط، وبعدين اشترى خلال يوم واحد (1-day view)، وفيسبوك بيحسبها على إنها نتيجة إعلانه. ده بيرفع رقم المنصّة لأنه بينسب مبيعات لناس ممكن كانت هتشتري أصلاً من غير الإعلان.
المشكلة هنا في طبيعة القياس نفسها. الـ backend مابيفرّقش بين “العميل ده شاف إعلان قبل ما يشتري” و”العميل ده اشترى عادي لأنه عرف عنك من زمان”. هو بيسجّل عملية شراء وخلاص. لكن فيسبوك بيقول “أنا السبب” لأن العين عدّت على الإعلان قبل الشراء بساعات.
ده مش معناه إن الـ view-through بلا قيمة. الإعلان اللي حد شافه فعلاً ممكن يكون أثّر في قراره. بس معناه إنك لو حسبت كل view-through على إنها مبيعة من الإعلان، رقمك هيبقى متضخّم، وهتفتكر الحملة بتجيب أكتر من اللي بتجيبه فعلاً.
الخلاصة اللي تطبّقها بكرة: افصل الـ view-through عن الـ click في تقاريرك. لو معظم “مبيعات” فيسبوك جاية من view-through، الرقم بتاعه متضخّم، والمبيعات الحقيقية اللي الإعلان جابها أقل بكتير من اللي الداشبورد بيحتفل بيه.
إزاي الـ de-duplication الغلط بيخلّي الحدث يتعدّ مرتين؟ (السبب 4)
ده السبب الوحيد لحد دلوقتي اللي مش طبيعي، ده خلل في الإعداد لازم تصلّحه. بيحصل لما الـ Pixel والـ CAPI يبعتوا نفس الحدث من غير معرّف موحّد (event ID)، فيسبوك مايعرفش إنهم نفس الحدث، فيعدّه مرتين.
إيه اللي بيحصل بالظبط؟ إنت فعّلت الـ CAPI عشان تحسّن دقة الإشارة بعد ما الـ Pixel بقى بيضيّع جزء بسبب الخصوصية. لحد هنا صح. بس لو كل حدث بيتبعت بمعرّف مختلف من الـ Pixel ومن الـ CAPI، فيسبوك بيشوفهم حدثين منفصلين. النتيجة شراء واحد بيظهر كأنه عمليتين.
العلامة اللي تلاحظها: قفزة مفاجئة وغير منطقية في رقم فيسبوك بعد ما فعّلت الـ CAPI مباشرة. الرقم نط فجأة من غير ما الصرف أو الأداء الحقيقي يتغير. ده مش نجاح، ده عدّ مكرر.
الحل واضح: كل حدث لازم يتبعت بمعرّف واحد (event ID موحّد) من الـ Pixel والـ CAPI، عشان فيسبوك يدمج النسختين ويعدّهم مرة واحدة. ده واحد من أكتر أخطاء الإعداد اللي بنشوفها، وفيه تفاصيل أكتر عنه وعن غيره في أخطاء الـ tracking الشائعة.
الخلاصة اللي تطبّقها بكرة: لو رقم فيسبوك نط فجأة بعد تفعيل الـ CAPI، افحص الـ de-duplication فوراً. اتأكد إن الـ Pixel والـ CAPI بيستخدموا نفس الـ event ID لكل حدث. ده setup غلط بيخليك تدفع ميزانية على عدّ مكرر.
ليه iOS و ATT و SKAdNetwork بيخلّوا الرقم تقدير مش عدّ؟ (السبب 5)
لأن بعد الـ ATT، اللي رفضوا التتبّع مابيتعدّوش فعلياً، فيسبوك بيقدّر مبيعاتهم بالحساب بدل ما يعدّها. النتيجة إن رقم آيفون بقى تقريبي ومتأخر، وغالباً under-reporting.
نشرحها خطوة خطوة. نظام الـ ATT (App Tracking Transparency) هو السؤال اللي بيظهر للمستخدم: “توافق إن التطبيق ده يتتبّعك؟”. أغلب الناس بترفض. فجزء كبير من المبيعات الحقيقية بقى مش متاح لفيسبوك يربطه بالإعلان. هو شايف الشراء حصل، بس مش عارف يقول حصل بسبب أنهي إعلان. لو عايز تفهم النظام ده بالتفصيل، اقرأ ATT بالعربي.
عشان يسدّ الفجوة، فيسبوك بيستخدم حاجتين. الأولى الـ modeled conversions، يعني مبيعات بيقدّرها بالحساب الإحصائي مش بالعدّ الفعلي. التانية بيانات الـ SKAdNetwork، وهو نظام Apple اللي بيرجّع للمنصّة postbacks (تقارير) متأخرة بين 24 و 48 ساعة، ومجمّعة من غير تفاصيل كل مستخدم. شرح النظام ده كامل في SKAdNetwork بالعربي.
يعني رقم آيفون عندك مش عدّ دقيق. هو خليط من تقدير إحصائي وبيانات متأخرة ومجمّعة. وده بيخلّيه غالباً أقل من الحقيقة، وبيتأخر يظهر. مش عطل في حسابك، ده طبيعة القياس على آيفون بعد سياسات الخصوصية.
الخلاصة اللي تطبّقها بكرة: لما تشوف under-reporting على آيفون، اعرف إنه طبيعي في الغالب مش خلل. تعامل مع رقم آيفون كتقدير متأخر، استنى اكتمال بيانات الـ SKAN قبل أي حكم، وقارن دايماً بالـ backend قبل ما توقف حملة على آيفون.
ليه مقارنة “يوم بيوم” بتطلّع فروقات وهمية؟ (السبب 6 + 7)
لأن فيسبوك والـ backend بيسجّلوا الشراء في تاريخين مختلفين، فلما تقارنهم يوم بيوم بتطلع فجوة مش حقيقية. ده سببين بيشتغلوا مع بعض: اختلاف تاريخ التسجيل، والـ cross-device.
السبب السادس، اختلاف التاريخ. فيسبوك بينسب الشراء ليوم الضغط على الإعلان. الـ backend بيسجّله يوم الشراء الفعلي. لو حد ضغط الإعلان يوم الاثنين واشترى يوم الأربعاء، فيسبوك بيحطها في الاثنين والـ backend بيحطها في الأربعاء. لو بصّيت على يوم لوحده، هتلاقي فجوة، مع إن العملية نفسها موجودة عند الاتنين، بس في يومين مختلفين.
السبب السابع، الـ cross-device. المستخدم ضغط الإعلان على الموبايل، وبعدين فتح اللابتوب واشترى. الربط بين الجهازين بيتكسر، خصوصاً مع قيود الخصوصية. فمبيعة حقيقية جابها الإعلان مابتتنسبش له، لأن فيسبوك مش عارف إن اللي اشترى على اللابتوب هو نفسه اللي ضغط على الموبايل.
الخلاصة اللي تطبّقها بكرة: بطّل المقارنة يوم بيوم. قارن على مدى أسبوع أو شهر كامل عشان فروق التواريخ تتساوى. ولو الفجوة عندك كبيرة وجمهورك بيشتري على أجهزة مختلفة، اعرف إن جزء منها cross-device طبيعي مش خطأ في الإعلان.
طيب أعتمد على أنهي رقم وآخد قراراتي إزاي؟
اعتمد مصدر واحد للحقيقة، والـ backend أو الـ MMP هما المرشّحين. واستخدم رقم فيسبوك كمؤشر اتجاه للمقارنة بين الحملات، مش كرقم مطلق تبني عليه ميزانيتك.
القاعدة الأولى: مصدر حقيقة واحد. اختار الـ backend لو مبيعاتك كلها بتمر منه، أو الـ MMP لو عندك قنوات كتير ومحتاج حكم محايد بيجمّعها. المهم إن قرار الميزانية يطلع من مصدر واحد ثابت، مش إنك تقفز بين رقم فيسبوك ورقم جوجل ورقم الـ backend حسب اللي مريّحك.
القاعدة التانية: راقب النسبة والاتجاه، مش الرقم المطلق. لو فيسبوك بيدّعي دايماً أعلى من الـ backend بنسبة ثابتة، النسبة دي بقت معامل تصحيح إنت عارفه. تقدر تستخدم رقم فيسبوك للمقارنة بين الحملات وانت عارف إزاي تترجمه للحقيقة.
القاعدة التالتة: افحص بطريقة مستقلة. اعمل holdout test، يعني توقف الإعلان عن جزء من جمهورك وتشوف المبيعات نقصت قد إيه فعلاً، ده بيوريك التأثير الحقيقي للإعلان بعيد عن ادّعاءات المنصّة. أو اعمل blended check، يعني قارن إجمالي صرفك بإجمالي مبيعاتك من الـ backend عبر الوقت.
اللي يستاهل انتباهك مش إن الأرقام مختلفة. الأرقام هتفضل مختلفة دايماً وده طبيعي. اللي يكلّفك فعلاً إنك توقف حملة شغّالة لأن فيسبوك بيقلّل رقمها (under-reporting طبيعي)، أو تكبّر حملة ضعيفة لأن فيسبوك بيضخّم رقمها (over-reporting). القرار الغلط بيطلع من إنك صدّقت رقم المنصّة من غير ما تترجمه. للطريقة الكاملة بالخطوات، اقرأ إزاي تحسب الـ CAC الحقيقي.
الخلاصة اللي تطبّقها بكرة: ثبّت مصدر حقيقة واحد لقرارات الميزانية، وحوّل رقم فيسبوك لمؤشر اتجاه بنسبة تصحيح إنت حاسبها. قبل ما توقف أو تكبّر أي حملة، راجع المبيعة في الـ backend مش في الداشبورد.
الاتجاه بيقولك إيه؟
ده جدول ترجعله بسرعة عشان تعرف فجوتك رايحة فين، وهل تقلق ولا تطمن. اعرف الاتجاه الأول، وبعدها قرّر الحل.
| اتجاه الفجوة | إيه اللي بيحصل | الأسباب المحتملة | طبيعي ولا setup؟ |
|---|---|---|---|
| فيسبوك أكبر من الحقيقة (over) | المنصّة بتدّعي مبيعات أكتر | الـ double counting / view-through / نافذة طويلة / de-dup غلط | خليط: غالباً طبيعي مع احتمال setup |
| فيسبوك أقل من الحقيقة (under) | المنصّة بتفوّت مبيعات | آيفون والـ ATT / cross-device / نافذة قصيرة | غالباً طبيعي (آيفون) |
| فجوة كبيرة ومفاجئة | قفزة غير منطقية في الرقم | الـ de-duplication غلط / الحدث بيتبعت مرتين | setup غلط، افحص فوراً |
اقرأ كمان
أسئلة شائعة
هل الفجوة بين فيسبوك والمبيعات معناها إني مغشوش؟
لأ، في الغالب طبيعية بسبب اختلاف منهج القياس بين المنصّة والـ backend. الغش نادر. الأهم إنك تتأكد إن حجم الفجوة منطقي ومافيش setup غلط زي double counting بيضخّم الرقم.
قد إيه الفجوة الطبيعية؟
مفيش رقم ثابت لكل الحسابات، بس فجوة بين 15% و 30% شائعة، خصوصاً مع آيفون والـ ATT. الأهم من الرقم إنه ثابت عبر الوقت. القفزات المفاجئة هي اللي تقلق، مش وجود فجوة من الأساس.
إزاي أعرف لو المشكلة setup ولا طبيعية؟
افحص الاتجاه. over-reporting مفاجئ بعد تفعيل الـ CAPI غالباً double counting، وده setup غلط. under-reporting غالباً آيفون أو cross-device، وده طبيعي. الفحص الدقيق محتاج مراجعة الـ tracking نفسه.
هل أوقف الاعتماد على أرقام فيسبوك خالص؟
لأ. استخدمها كمؤشر اتجاه للأداء النسبي بين الحملات. بس خُد قرار الميزانية من مصدر حقيقة واحد، الـ backend أو الـ MMP، مش من الداشبورد لوحده.
الـ CAPI هيحل مشكلة الفرق؟
بيحسّن دقة الإشارة بعد ما الـ Pixel بقى بيضيّع جزء. بس لو اتظبط غلط من غير event ID موحّد، بيزوّد المشكلة بـ double counting. الإعداد الصح هو المهم، مش مجرد إنك فعّلته.
أقدر أجمع أرقام فيسبوك وجوجل عشان أعرف إجمالي مبيعاتي؟
لأ. لو جمعت ادّعاء كل منصّة لوحدها، الرقم بيطلع أكبر من الحقيقة بسبب الـ double counting، لأن نفس العميل بيتعدّ في فيسبوك وفي جوجل. خُد إجمالي مبيعاتك من الـ backend أو الـ MMP، واستخدم أرقام المنصّات للمقارنة النسبية بينها بس.
مش عارف الفجوة عندك طبيعية ولا في setup غلط بيكلّفك فلوس؟
احجز Free Audit ونوريك أنهي حملة بتبيع فعلاً. في 30 دقيقة نراجع الـ tracking ونافذة النسب والـ de-duplication، ونقولك الرقم الصح اللي تبني عليه ميزانيتك.