الـConversions API بقى حاجة الكل عارف إنه لازم يركبها، والنتيجة إن أغلب الحسابات فعلاً راكبة حاجة اسمها كده. اللي مش بيتقال إن التركيب نفسه مش هو الشغل. التركيب ممكن يخلص في يوم، وبعدين الحساب يفضل شهور بيبعت أحداث ناقصة وانت فاكر إن القياس اتظبط.
الفرق ما بين إعداد شغال وإعداد شكله شغال مش في الكود، هو في البيانات اللي بتتبعت مع كل حدث. والموضوع ده موثّق بالتفصيل عند ميتا نفسها، ومحدش بيقراه.
لو لسه مش واضح عندك الـCAPI بيعمل إيه أصلاً وليه، ابدأ من شرح Conversions API والفرق الحقيقي، وارجع هنا بعدها. المقال ده مش تعريف، ده تشخيص.
الخطأ الأول: بتبعت الحدث من غير بيانات العميل
ده الخطأ اللي بيحصل في أغلب الحسابات، وهو اللي بياكل التطابق. الحدث بيوصل ميتا، بيتسجل، وانت شايفه في الـEvents Manager، فبتفتكر إن كله تمام. لكن ميتا لازم تربط الحدث ده بشخص عندها، ولو البيانات اللي بتوصلها مش كفاية، الحدث بيتسجل ومبيتنسبش لحد.
ميتا بتوثّق قايمة بارامترات معلومات العميل اللي بتستخدمها في الربط، وأهمها em للإيميل وph للتليفون وfn وln للاسم وct للمدينة وzp للكود البريدي وcountry للدولة وexternal_id لمعرّف العميل عندك. كل دول لازم يتبعتوا متهاشين بـSHA256.
وفي مقابلهم قايمة تانية ممنوع تتهاش خالص: client_ip_address وclient_user_agent وfbc وfbp وlead_id وpage_id وغيرهم. لو هاشتهم، الحدث بيروح ومعاه بيانات ملهاش لازمة، والنتيجة نفس نتيجة إنك مبعتهاش.
الخطأ التاني: بتهاش من غير تطبيع
ده الخطأ الأخطر لأنه مبيبانش. انت فعلاً بتبعت الإيميل متهاش، والكود شغال، والحدث بيوصل. بس لو الإيميل كان فيه مسافة في الأول أو حرف كابيتال، الهاش هيطلع مختلف تماماً عن الهاش اللي عند ميتا لنفس الشخص، فالتطابق بيفشل من غير أي رسالة خطأ.
قواعد التطبيع الموثّقة في صفحة بارامترات معلومات العميل واضحة ومحددة، وكل واحدة فيها ليها سبب:
| البارامتر | قاعدة التطبيع الموثّقة | الغلط الشائع |
|---|---|---|
| em (إيميل) | شيل المسافات في الأول والآخر، وحوّل كل الحروف لـlowercase | الهاش زي ما المستخدم كتبه بالظبط |
| ph (تليفون) | شيل الرموز والحروف والأصفار البادئة، ولازم يكون فيه كود الدولة | بعت الرقم المحلي بصفر في الأول |
| fn / ln (الاسم) | lowercase، والأحرف اللاتينية a-z هي الموصى بها، وUTF-8 للحروف الخاصة | بعت الاسم بالعربي من غير ترميز صح |
| ct (مدينة) | lowercase، من غير علامات ترقيم ولا مسافات | بعت «القاهرة» ومعاها محافظة |
| country | كود الدولة حرفين بالـlowercase حسب ISO 3166-1 alpha-2 | بعت الاسم كامل بدل eg أو sa |
| db (تاريخ ميلاد) | صيغة YYYYMMDD | بعت التاريخ بصيغة المتصفح |
الاختبار العملي هنا بسيط: خد إيميل عميل حقيقي، طبّق عليه قواعد التطبيع بإيدك، هاشه، وقارن الناتج باللي السيرفر بيبعته. لو الاتنين مش نفس السلسلة، انت عندك المشكلة دي دلوقتي.
الخطأ التالت: الشراء بس
أغلب الإعدادات بتبعت Purchase وخلاص، وأحياناً معاه Lead. ده بيخلي الـCAPI نسخة تانية من البكسل بدل ما يكون إضافة عليه.
المكسب الحقيقي من السيرفر هو الأحداث اللي البراوزر مش شايفها أصلاً: التأكيد بعد المكالمة، الطلب اللي اتأكد في الفرع، الاشتراك اللي اتجدد، الليد اللي اتأهّل في الـCRM بعد أسبوع. دي بيانات مفيش بكسل هيجيبها، وهي اللي بتخلي التعلّم في الحملة مبني على اللي بيتباع فعلاً مش على اللي بيتضغط.
ولو المبيعات عندك بتقفل برة الموقع، الكلام ده بيتوسع أكتر في ليه ROAS المنصة مختلف عن المبيعات الحقيقية.
الخطأ الرابع: الفايروول بيقفل الطريق وانت مش عارف
دي حاجة صغيرة بتوقّف إعدادات كاملة. لو السيرفر بتاعك ورا فايروول بيفلتر الطلبات الخارجة، الطلب ممكن ميخرجش أصلاً. ميتا بتنبّه على ده في صفحة البدء الرسمية وبتقول لو عندك فايروول للطلبات الخارجة، ارجع لصفحة Crawler IPs and User Agents وخد عناوين IP بتاعة فيسبوك واسمح بيها.
في نفس الصفحة كمان حاجة اتغيرت ومفيدة لو كنت واقف عند حدود الوصول: عتبة التأهل للـFull Access نزلت من ١٥٠٠ لـ٥٠٠ استدعاء لـMarketing API في آخر ١٥ يوم. يعني حسابات كتير كانت واقفة عند الحد ده بقت مؤهلة دلوقتي وهي مش واخدة بالها.
منع التكرار: سطر واحد وبس
مش هطوّل هنا لأن الموضوع ده متغطّى بالكامل في مقال منفصل. المهم تعرف إن لو نفس الحدث بيتبعت من البكسل ومن السيرفر، لازم يتبعت بنفس الـevent_id ونفس الـevent_name، وإن نافذة المطابقة عند ميتا ٤٨ ساعة من أول حدث. التفاصيل والحالات اللي بيفشل فيها في شرح Conversions API وحدود التكرار وفي دوكيومنتيشن ميتا نفسه.
قايمة فحص قبل ما تقول إنه اتظبط
لو هتراجع إعداد قايم، راجعه بالترتيب ده. كل بند فيهم بيتقاس مش بيتخمّن:
١. افتح حدث واحد حقيقي في الـEvents Manager وشوف أنهي بارامترات وصلت فعلاً، مش أنهي بارامترات الكود بيبعتها نظرياً.
٢. قارن الهاش اللي بتبعته بهاش محسوب بإيدك على نفس القيمة بعد التطبيع.
٣. عدّ أنواع الأحداث اللي بتبعتها من السيرفر. لو واحد أو اتنين، انت مستخدم جزء صغير من الفايدة.
٤. اتأكد إن الأحداث اللي برة المتصفح ليها طريق توصل بيه.
٥. لو الأرقام لسه غريبة بعد كل ده، المشكلة مبقتش في القياس.
والنقطة الأخيرة دي مهمة: ناس كتير بتفضل تظبط في القياس شهرين والمشكلة كانت في مكان تاني خالص. الترتيب الصح للمراجعة موجود في ازاي تراجع حساب إعلانات جديد.
الحد الأمين
الـCAPI مش بيرجّع البيانات اللي ضاعت قبل ما تركبه. بيحسّن اللي جاي، والتحسّن بيبان على أسابيع مش على أيام، فمتحكمش عليه بعد تلات أيام.
وكمان ده مشروع هندسي مش إعداد في لوحة. لو اللي هيعمله عندك مطوّر، اعتبره تكامل بين نظامين بكل اللي في التكامل ده من مفاجآت، وفي كلام عملي على التكلفة الحقيقية للحاجات دي في نوتة rivl عن تكلفة الربط بين نظامين، وهي بالإنجليزي.
آخر حاجة: لو الموقع أصلاً مبيجمعش بيانات كفاية عن العميل، الـCAPI مش هيخترع بيانات. ساعتها الشغل الحقيقي في فورم الشيك أوت مش في السيرفر، وده قرار منتج مش قرار قياس.
أسئلة شائعة
لازم أشيل البكسل بعد ما أركب الـCAPI؟
لأ. ميتا نفسها بتوصف الاتنين كمصدرين مكمّلين، والإعداد الموصى بيه إنك تبعت من الاتنين مع event_id موحّد عشان منع التكرار يشتغل. شيل البكسل يعني تخسر إشارات المتصفح اللي السيرفر مش شايفها.
ليه التطابق عندي واطي والـCAPI راكب؟
أغلب الوقت السبب واحد من اتنين: بارامترات معلومات عميل ناقصة، أو هاش اتعمل من غير تطبيع. الاتنين بيخلّوا الحدث يوصل ويتسجل من غير ما يتنسب لحد، فبيبان إن كل حاجة شغالة والأرقام واطية.
الأسماء العربية بتتهاش ازاي؟
دوكيومنتيشن ميتا بيوصي بالأحرف اللاتينية a-z للاسم، وبيقول استخدم ترميز UTF-8 للحروف الخاصة. عملياً لو عندك أسماء عربية، اتأكد إن الترميز UTF-8 قبل الهاش وثبّت نفس الطريقة في كل المصادر.
عتبة الـ٥٠٠ استدعاء دي بتخص إيه؟
دي عتبة التأهل لمستوى Full Access في الـMarketing API، ونزلت من ١٥٠٠ لـ٥٠٠ استدعاء في آخر ١٥ يوم حسب صفحة البدء الرسمية. لو كنت واقف عند حدود الوصول قبل كده، يستاهل تراجع حالتك دلوقتي.