مشكلة تكرار الاحداث في البكسل: نافذة الـ48 ساعة الرسمية

أكتر رقم بيتسأل عنه في حسابات الميديا باينج هو رقم مضروب: عدد المشتريات في مدير الإعلانات أكبر من عدد الأوردرات الحقيقي. ومعظم الردود على السؤال ده بتبدأ بكلمة «غالباً».

الحقيقة إن الموضوع ده متوثق بدقة، ومفيهوش تخمين. ميتا كاتبة بالظبط ايه اللي بيخلي حدثين يتحسبوا واحد، وايه اللي بيخليهم يتحسبوا اتنين. المقالة دي هي الكلام ده بالعربي، مع اللي بيترتب عليه في الشغل.

المشكلة بتحصل امتى بالظبط

التكرار مش عيب في البكسل. هو نتيجة طبيعية لإعداد انت عملته: نفس الحدث بيتبعت مرتين، مرة من متصفح المستخدم عن طريق البكسل، ومرة من السيرفر عن طريق Conversions API.

وده مقصود. توثيق Conversions API بيوصفها بإنها وسيلة لبناء وصلة بين بيانات المعلن من السيرفر أو المنصة أو التطبيق أو الـCRM وبين أنظمة ميتا، عشان تحسن الاستهداف وتقلل تكلفة النتيجة وتقيس المخرجات. والإرسال المزدوج ده هو اللي بيغطي الحالات اللي البكسل لوحده بيقع فيها.

يعني الهدف مش إنك تبعت مرة واحدة. الهدف إنك تبعت مرتين وتسيب ميتا تشيل الزيادة. والسؤال الوحيد المهم: هي بتشيلها ازاي.

ولو انت لسه مش مركب CAPI أصلاً وبتقرا الكلام ده عشان تقرر، شرح Conversions API والفرق الحقيقي وحدود التكرار هي نقطة البداية الأصح قبل المقالة دي.

الطريقتين اللي ميتا بتطابق بيهم

في صفحة إزالة تكرار أحداث البكسل والسيرفر، ميتا بتحدد طريقتين مش واحدة:

الجملة اللي بتحسم كل حاجة هي شرط الطريقة الأولى: الـeventID من البكسل لازم يطابق الـevent_id في الحدث الجاي من Conversions API.

كلمة «يطابق» هنا حرفية. مش متشابه، مش قريب، مش نفس رقم الأوردر بصيغة مختلفة. أي فرق في صيغة الكتابة بين الجهتين معناه حدثين مختلفين عند ميتا، وبالتالي رقم مضروب عندك. وده أشيع سبب للمشكلة كلها، وأسهل واحد في الإصلاح.

نافذة الـ48 ساعة، والجملة التانية اللي وراها

النقطة اللي بتتنسي: المطابقة مش شغالة على طول الوقت.

التوثيق بيقول إن الأحداث بيتشال تكرارها بس لو وصلت في خلال 48 ساعة من وقت استلام أول حدث بنفس الـevent_id.

وبيقول جملة تانية جنبها مهمة بنفس القد: أحداث السيرفر مش هتتشال لو محصلش إن حدث متصفح وصل في الـ48 ساعة اللي فاتت.

الجملتين مع بعض بيقولوا حاجة عملية جداً: لو السيرفر بتاعك بيبعت الأحداث في دفعات متأخرة، أو بيرفعها من الـCRM بعد يوم أو اتنين، انت خارج النافذة. وساعتها مفيش إعداد هيصلح الرقم، لأن ميتا استلمت حدثين في وقتين متباعدين وعاملتهم على إنهم اتنين فعلاً.

الفرق بين إعداد مظبوط وإعداد مكسور هنا مش في الكود، هو في التوقيت. ودي حاجة بتفوت على ناس شاطرة لأنها مش بتظهر في أي رسالة خطأ.

ترتيب التشخيص لما الرقم يبان مضروب

لو عندك فرق بين مدير الإعلانات وعدد الأوردرات، امشي بالترتيب ده بالظبط. الترتيب نفسه هو نص الشغل، لأن كل خطوة بتلغي احتمال كامل:

• الأول: هل الحدثين ليهم نفس event_name أصلاً؟ Purchase من ناحية وpurchase من ناحية تانية مش نفس الحاجة.
• التاني: هل الـevent_id بيتولد من مصدر واحد للجهتين، ولا كل جهة بتولده لوحدها؟ لو كل جهة بتولده لوحدها، انت لقيت المشكلة.
• التالت: هل الحدثين بيوصلوا في خلال 48 ساعة؟ لو بتبعت من السيرفر في دفعات، ده السؤال اللي هيكشفك.
• الرابع: لو بتعتمد على الطريقة التانية، هل fbp أو external_id موجودين فعلاً في حدث السيرفر، ولا بتتبعت فاضية؟
• الخامس، وبعد التلاتة دول بس: شوف هل في تركيب تاني على الموقع بيبعت نفس الحدث، زي تطبيق متجر أو أداة تانية مركبة من زمان ونسيتها.

الخطوة الخامسة دي بالذات بتحل حالات كتير بيتقال عنها إنها «مشكلة في ميتا». تطبيق قديم على المتجر بيبعت Purchase، والبكسل بيبعت Purchase، وولا واحد فيهم بيعرف التاني. ولو الأخطاء الشائعة دي هي اللي بتدور عليها، جمعتها في ازاي تظبط Conversions API صح والأخطاء اللي بتضيع الداتا.

ليه ميتا مش بتشيل التكرار من نفسها

ده السؤال اللي بيتسأل بصيغة زعل: انتوا شايفين إن الاتنين نفس الأوردر، أومال ليه بتحسبوهم اتنين.

الإجابة إن ميتا مش شايفة أوردر، هي شايفة حدثين وصلوها من مصدرين مختلفين. حدث من متصفح وحدث من سيرفر. مفيش حاجة فيهم بتقول إنهم نفس العملية غير اللي انت بتقوله بنفسك في الـevent_id.

وعشان كده الطريقة الأولى هي الموصى بيها: لأنها الوحيدة اللي انت بتحدد فيها الهوية صراحة. الطريقة التانية، اللي بتطابق على event_name مع fbp أو external_id، بتشتغل بالاستنتاج، ولما تغلط بتغلط في الاتجاهين. ممكن تشيل حدثين مختلفين فعلاً حصلوا لنفس الشخص في نفس الوقت، وممكن تسيب حدثين هما نفس العملية.

النتيجة العملية: لو عندك قدرة تولّد معرف واحد للعملية من المتجر وتبعته للجهتين، اعملها. ولو مش عندك، شغّل التانية وانت عارف إنها تقريب مش دقة، ومتبنيش عليها حسابات نسب دقيقة.

اللي مينفعش تعمله عشان تخفي المشكلة

في حلين بيتقالوا كتير والاتنين بيأذوا:

الأول: توقف واحد من الاتنين. تقفل البكسل وتسيب السيرفر، أو العكس. ده بيصلح الرقم في التقرير وبيخسرك سبب وجود الإعداد المزدوج من الأساس. الرقم بقى نضيف وأقل من الحقيقة.

التاني: تظبط التقرير بدل ما تظبط الإرسال. يعني تقسم الرقم على اتنين في الشيت. ده بيمشي لحد أول ما نسبة التكرار تتغير، وهي بتتغير، وساعتها انت بتقارن بأرقام تاريخية كلها غلط.

المشكلة مكانها الإرسال. تصليحها في أي مكان تاني بيأجلها مش بيحلها. ولو الرقم اتغير فجأة من غير ما تغير حاجة، ترتيب تشخيص نزول معدل التحويل بيمشي على نفس المنطق.

حدود صريحة تتقال مرة واحدة

إزالة التكرار بتحل مشكلة واحدة: إن نفس الحدث ما يتحسبش مرتين. وخلاص.

مش بتخلي رقم ميتا يساوي رقم المتجر، ومش المفروض يساويه أصلاً، لأن الاتنين بيقيسوا حاجتين مختلفتين بنوافذ إسناد مختلفة. لو انت مستني إن الرقمين يطابقوا بعض بعد ما تظبط الإعداد، هتظبطه صح وتفضل مش راضي عن النتيجة.

والنقطة التانية: التوثيق بيتكلم عن المطابقة والنافذة. مش بيتكلم عن دقة الإسناد، ولا عن البيانات اللي ضاعت بسبب رفض الموافقة. دي مواضيع تانية، والخلط بينها وبين التكرار هو اللي بيخلي حد يركب إعداد كامل وهو بيعالج مشكلة تانية خالص.

ولو بتبعت أحداث أوفلاين كمان، النوافذ والشروط هناك مختلفة تماماً وكتبتها في ازاي تقيس الاعلانات الاوفلاين. ولو المتجر بتاعك سعودي والإعداد لسه من الصفر، في دليل عربي عملي على kfagency.net عن إعداد تتبع التحويلات لمتجر سعودي بيمشي خطوة بخطوة من أول الحساب.