تتبع التحويلات الحقيقية عندما يتم البيع عبر واتساب لا صفحة الدفع

الفجوة بين ما تراه ميتا وما حدث فعلاً

بيكسل ميتا القياسي مبني حول أحداث الموقع: شخص يُشاهد منتجاً، يُضيفه للسلة، يُتم عملية الدفع. يفترض هذا النموذج أن البيع يحدث على الموقع. بالنسبة لمعظم المتاجر الجزائرية التي تُدير قنوات رسائل وواتساب، الأمر ليس كذلك — ينقر المشتري على إعلان، يصل إلى محادثة، ويُؤكَّد الطلب فعلياً في المحادثة، غالباً بعد يوم أو يومين. لا يظهر أي من هذا كحدث شراء، فتُحسّن الحملة نحو "من ينقر" بدل "من يشتري".

ما الذي يفعله Conversions API فعلاً

يُرسل Conversions API بيانات الحدث إلى ميتا مباشرة من خادم بدل المتصفح. عملياً، هذا يعني التقاط معرّف النقرة — تُسمّيه ميتا ctwa_clid، وليس fbclid المستخدم في إعلانات المواقع — لحظة وصول أول رسالة ناتجة عن ذلك النقر. يصل مرة واحدة فقط، مع تلك الرسالة الأولى، لذا يجب تخزينه مع العميل المحتمل فوراً وإلا يضيع نهائياً. بعدها يُرسل حدث "شراء" من جهة الخادم بمجرد تأكيد الطلب فعلاً — لا عند بدء المحادثة، بل عند دفعه أو تثبيته فعلياً.

كيف يُبنى هذا فعلاً

هذا ليس إعداداً داخل Ads Manager. إنه سير عمل أتمتة — من النوع الذي تناولناه في إعداد n8n وبوتات تيليغرام لإدارة الطلبات — يُخزّن معرّف النقرة مع كل عميل محتمل عند وصوله، ويُرسل حدث CAPI بمجرد أن يُعلّم بوت أو أحد الموظفين الطلب كمؤكد. بمجرد ربطه مرة واحدة، يعمل على كل طلب دون أن يُفكر فيه أحد مجدداً.

لا يمكن للخوارزمية أن تُحسّن إلا نحو ما قيل لها إنه حدث فعلاً. إذا اختفت كل عملية بيع حقيقية داخل محادثة واتساب دون أي إشارة تعود لميتا، فإن الحملة تُدار بتخمين مُقنّع كبيانات.