ما الذي تغير فعلاً قبل أن نتحدث عن API التحويلات
الشكوى تصل بصيغة واحدة تقريباً: الحملة تعمل، المبيعات موجودة في لوحة المتجر، لكن مدير الإعلانات يعرض رقماً أقل. صاحب العمل يستنتج أن الحملة ضعيفة، فيخفض الميزانية على منتج كان يبيع فعلاً.
السبب في أغلب الحالات ليس الحملة، بل الطريقة التي تجمع بها البيانات. الكود الذي يعمل داخل المتصفح صار يواجه ثلاث عقبات في وقت واحد: متصفحات تحد من عمر الكوكيز أو تمنعها، إضافات حجب تمنع تحميل الكود أصلاً، ومستخدمون يرفضون الموافقة على التتبع الإعلاني. كل عقبة منها تحذف جزءاً من الأحداث قبل أن تصل إلى المنصة.
النتيجة أن المنصة لا تعرف أن الطلب حدث. وحين لا تعرف أن الطلب حدث فإنها لا تتعلم من أي إعلان جاء، وهنا تكمن الخسارة الحقيقية: ليست في تقرير ناقص، بل في خوارزمية توزيع تتعلم من بيانات منقوصة فتوجه الميزانية إلى الجمهور الخطأ.
التمييز الذي يوفر أكثر النقاشات لاحقاً: مشكلة التتبع ليست مشكلة تقارير، إنها مشكلة تعلم. التقرير الناقص يزعجك مرة في الشهر، والخوارزمية التي تتعلم من بيانات ناقصة تكلفك كل يوم.
ما هو API التحويلات وأهميته بعد قيود التتبع
API التحويلات هو قناة ترسل بها الأحداث من خادمك مباشرة إلى المنصة الإعلانية، بدل أن تعتمد على كود يعمل في متصفح الزائر. توثيق ميتا يصف الأمر بأنه اتصال بين بيانات المعلن وأنظمة المنصة، وأن الأحداث القادمة من الخادم تعالج بالطريقة نفسها التي تعالج بها أحداث البكسل، فتستخدم في القياس والتقارير وتحسين التوصيل.
الجملة الأخيرة هي بيت القصيد. الحدث القادم من الخادم ليس نسخة أقل قيمة، إنه مقبول في التحسين مثل حدث المتصفح تماماً. ولهذا فإن السؤال لم يعد هل نفعل هذا، بل كيف نفعله دون أن نفسد الأرقام في الطريق.
الفرق الجوهري في مصدر الحقيقة. البكسل يخبر المنصة بما يبدو أنه حدث في المتصفح. الخادم يخبرها بما تم تسجيله فعلاً في قاعدة بياناتك: طلب برقم ومبلغ وحالة. هذا المصدر لا تمنعه إضافة حجب ولا يمحوه إغلاق المتصفح.
وهذه أيضاً نقطة تلتقي فيها مع اتجاه أوسع شرحناه في دليل بيانات الطرف الأول وحماية أداء إعلانات متجرك: كل ما تملكه أنت من بيانات صار أثمن مما تستعيره من المتصفح.
المتصفح مقابل الخادم: من يرسل ماذا ومتى
الخطأ الشائع أن يفهم الأمر على أنه استبدال. الإعداد الصحيح يشغل القناتين معاً، لأن كلاً منهما يرى ما لا يراه الآخر:
- المتصفح يرى معرفات النقر التي تصل مع الزيارة من الإعلان، وهي أقوى إشارة ربط بين الزيارة والحملة
- المتصفح يرى السلوك قبل الشراء: مشاهدة المنتج، إضافة إلى السلة، بدء الدفع
- الخادم يرى الطلب المؤكد بمبلغه الحقيقي بعد الخصومات
- الخادم يرى ما يحدث بعد الشراء: التأكيد، الإلغاء، المرتجع
- الخادم يعمل حين يكون المتصفح قد أغلق أو منع الكود بالكامل
البند قبل الأخير هو الذي يغفل عنه أغلب المتاجر. حدث الشراء الذي يرسل لحظة الوصول لصفحة الشكر يسجل طلبات ستلغى لاحقاً. الإرسال من الخادم يتيح لك ربط الحدث بحالة الطلب الفعلية، وهذا وحده يقرب رقم المنصة من رقم لوحة مبيعاتك أكثر مما يفعل أي ضبط آخر.
وإن كنت تبني الإعداد من الصفر فابدأ من الأساس قبل الطبقة المتقدمة. خطوات تركيب الأساس مشروحة في دليل تركيب بيكسل فيسبوك على متجرك، والإرسال من الخادم يبنى فوقه لا بدلاً منه.
منع تكرار الأحداث: المعرف الموحد ونافذة 48 ساعة
حين ترسل الطلب الواحد من المتصفح ومن الخادم معاً فأنت ترسل الحدث مرتين. ما الذي يمنع المنصة من احتسابه مبيعتين؟
التوثيق الرسمي لميتا في صفحة إزالة تكرار أحداث البكسل والخادم يحدد الآلية بوضوح: يحدد ما إذا كانت الأحداث متطابقة بناء على المعرف والاسم، أي أن معرف الحدث المرسل من الخادم يجب أن يطابق المعرف المرسل من البكسل، واسم الحدث يجب أن يطابق اسمه. وإذا لم تختلف نسخة الخادم ونسخة المتصفح اختلافاً جوهرياً في محتواها فإن المنصة تفضل عادة الحدث الذي يصل أولاً وتتجاهل ما يليه.
القيد الزمني الذي يغفل عنه كثيرون: إزالة التكرار تتم فقط إذا وصل الحدث الثاني خلال 48 ساعة من استلام أول حدث يحمل المعرف نفسه. أي إرسال متأخر عن هذه النافذة، مثل وظيفة ليلية ترفع طلبات اليوم السابق بتأخير، يحتسب حدثاً مستقلاً لا نسخة مكررة. هذه تفصيلة تحويها مستندات ميتا ولا تحويها أغلب الشروحات.
الأثر العملي لهذا القيد أن جدولة الإرسال جزء من التصميم لا تفصيلة تشغيلية. إن كان نظامك يرسل من الخادم دفعة واحدة كل ليلة فأنت تخاطر بتجاوز النافذة في الطلبات المبكرة من اليوم. الإرسال شبه الفوري بعد تأكيد الطلب أأمن كثيراً.
المفارقة أن أول علامة على فشل منع التكرار تبدو كخبر جيد: عدد التحويلات يقفز فجأة. من رأى هذه القفزة وفرح بها ثم اكتشف السبب سيجد تشريحاً مفصلاً لها على مدونة مصطفى فريد في تحليل مشكلة تكرار الأحداث في البكسل ونافذة 48 ساعة، وهي قراءة موجهة للممارس الذي ينفذ بيده. التفاصيل الرسمية نفسها منشورة في توثيق ميتا للمطورين حول إزالة تكرار الأحداث.
إشارات الموافقة: ما الذي يحدث حين يرفض المستخدم
الإرسال من الخادم لا يلغي حاجتك لاحترام موافقة المستخدم، وهذه نقطة تغيب عن كثير من التطبيقات المتعجلة. القناة تغيرت، أما الالتزام فباق.
في منظومة جوجل، توثيق منصة الوسوم يعرف أربع إشارات موافقة منفصلة: ad_storage لتخزين الكوكيز الإعلانية، وad_user_data لإرسال بيانات المستخدم المتعلقة بالإعلانات إلى جوجل، وad_personalization للإعلانات المخصصة، وanalytics_storage لبيانات القياس التحليلي. الفصل بينها مقصود: المستخدم قد يقبل القياس ويرفض التخصيص.
وحين ترفض إشارة ad_storage فإن التوثيق ينص على أنه لن تضبط كوكيز جديدة لأغراض إعلانية، وأن كوكيز الطرف الثالث التي سبق ضبطها على نطاقي جوجل ودبل كليك لن تستخدم إلا لأغراض مكافحة الاحتيال والرسائل المزعجة.
تفصيلتان عمليتان تستحقان الانتباه من التوثيق نفسه. الأولى أن وضع الموافقة لا يحفظ اختيار المستخدم بنفسه، فأنت مسؤول عن تخزين التفضيل واستعادته في الزيارات التالية. الثانية أن الصفحة إن حملت والموافقة مرفوضة ثم أعيد تحميلها بعد القبول فقد تفقد الوسوم نقاط بيانات من التحميل الأول. أي أن ترتيب ظهور نافذة الموافقة على الصفحة له أثر قياسي حقيقي لا شكلي.
المرجع الكامل منشور في دليل جوجل الرسمي لإدارة إعدادات الموافقة، ويستحق أن يقرأه من يطبق لا أن ينقل عنه.
خطة تطبيق واقعية بترتيب لا يهدر وقتاً
الترتيب الذي يقلل الأخطاء، لأن كل خطوة فيه تتحقق قبل الانتقال لما بعدها:
1. ثبت الأساس أولاً
تأكد أن أحداث المتصفح تعمل وتسجل الأحداث الصحيحة بالقيم الصحيحة. الإرسال من الخادم فوق أساس مكسور يضاعف الخطأ ولا يصلحه.
2. ولد معرفاً موحداً للطلب
معرف واحد للحدث الواحد، يرسل في نسخة المتصفح ونسخة الخادم. هذه الخطوة هي التي تمنع الاحتساب المزدوج، وتجاهلها هو الخطأ الأكثر تكراراً.
3. ابدأ بحدث واحد
حدث الشراء وحده. اضبطه وتحقق منه وقارن أرقامه بلوحة مبيعاتك لأسبوع كامل قبل أن تضيف حدثاً ثانياً.
4. أرسل بعد التأكيد لا قبله
اربط الإرسال بحالة الطلب المؤكدة، وفكر في كيفية التعامل مع الإلغاء والمرتجع منذ التصميم لا بعد ثلاثة أشهر.
5. ثبت إصدار الواجهة وراجعه
حدد إصدار الواجهة الذي ترسل إليه صراحة، وضع في تقويمك مراجعة دورية له. الإصدارات تتقاعد مع الوقت، والطلبات إلى إصدار متقاعد تبدأ بالفشل بلا إنذار في لوحتك.
6. راقب أسبوعين قبل أي حكم
لا تغير الميزانيات بناء على بيانات أول أيام. الأرقام تستقر بعد أن تستقر الأحداث.
وإن كان متجرك يخدم السوق السعودي فهناك تفاصيل إضافية في ضبط الأحداث وبوابات الدفع المحلية جمعناها في دليل إعداد تتبع التحويلات لمتجر سعودي.
كيف تقرأ الأرقام بعد التفعيل دون أن تخدع نفسك
بعد التفعيل ستتغير الأرقام، والسؤال الصحيح ليس هل ارتفعت بل هل صارت أصدق.
ارتفاع معقول في التحويلات المسجلة مع ثبات المبيعات الفعلية في لوحة متجرك علامة جيدة: أنت الآن ترى ما كان يحدث ولا يسجل. أما ارتفاع كبير ومفاجئ بلا تغير في المبيعات الفعلية فهو في الغالب تكرار لم يمنع، ويجب أن يعامل كعطل لا كإنجاز.
والرقم الذي يستحق أن يعلق على الحائط ليس داخل مدير الإعلانات أصلاً، بل الفجوة بين ما تقوله المنصة وما يقوله نظام مبيعاتك. راقب هذه الفجوة شهرياً كنسبة. تضيقها بعد التفعيل هو الدليل العملي على أن ما فعلته نجح، وطريقة حساب العائد على أساس الأرقام الحقيقية لا أرقام المنصة مشروحة في دليل حساب العائد على الإنفاق الإعلاني بشكل صحيح.
ما الذي يبقى مفقوداً مهما أتقنت التطبيق
هذا القسم هو الذي يحذف عادة من الأدلة التي تبيع خدمة، ووجوده هنا مقصود.
الإرسال من الخادم لا يعيد ما رفضه المستخدم. إن رفض الزائر الموافقة على الاستخدام الإعلاني لبياناته فإن تغيير قناة الإرسال لا يغير هذا الرفض ولا يجوز أن يستخدم للالتفاف عليه.
ولا يعيد الإسناد الضائع. إن وصل الزائر من إعلان ثم عاد بعد أسبوعين من بحث مباشر وقد فقد معرف النقر فلن يعرف أحد أن الإعلان هو الذي بدأ الرحلة. سترى الطلب، ولن ترى سببه.
ولا يحل مشكلة المتاجر التي يتم الشراء فيها خارج الموقع كاملاً، عبر محادثة أو مكالمة. هنا تكون الحاجة إلى ربط نظام إدارة العملاء لا إلى إرسال أحداث موقع.
وأخيراً لن يجعل الرقمين متطابقين تماماً أبداً. من يعدك بتطابق كامل بين مدير الإعلانات ولوحة المبيعات يبيعك وهماً، لأن المنصتين تقيسان شيئين مختلفين بنافذتين زمنيتين مختلفتين. الهدف الواقعي فجوة صغيرة ومستقرة ومفهومة، لا فجوة معدومة. والقياس الأوسع الذي يعالج ما يبقى خارج هذه القناة شرحناه في خطة قياس الحملات بدون كوكيز الطرف الثالث.