Conversion API تعطي البيزنس طريقة Server-Side لإرسال أحداث التحويل إلى منصة إعلانات أو Analytics مدعومة.
بشكل عملي، يبدأ المسار من Event حقيقي في مصدر مدعوم، ثم تتم مراجعة الحدث وتجهيزه داخل Server-Side workflow، وبعدها يتم إرساله إلى API endpoint موثقة للمنصة المطلوبة. الـAPI مسؤولة عن Delivery إلى الوجهة، أما Tracking Architecture الأوسع فهي المسؤولة عن جمع الحدث وجودة البيانات والمعرّفات وDeduplication والمراقبة.
ماذا تفعل Conversion API فعليًا؟
Conversion API جزء من Delivery Layer.
وظيفتها أن تسمح لمصدر أو نظام Server-Side بإرسال Conversion Data مباشرة إلى Platform endpoint بدل الاعتماد فقط على Request من المتصفح.
لكن الـAPI لا تنشئ Conversion من نفسها.
الحدث التجاري يجب أن يكون موجودًا أولًا.
عميل يكمل Order. الـbackend يؤكد Transaction. Source مدعوم ينتج Event Data. بعدها فقط يمكن تجهيز هذه البيانات وإرسالها إلى Destination.
وهنا فرق مهم.
API Delivery قد تعمل تقنيًا بشكل صحيح بينما Event نفسها خاطئة.
إذا كانت Purchase Value غير صحيحة من المصدر، يمكن للـAPI إرسال القيمة الخاطئة بنجاح كامل.
وإذا تم تمثيل نفس Order مرتين، يمكن إرسال النسختين ما لم توجد Deduplication Logic صحيحة.
لذلك Conversion API ليست بديلًا عن Event Design أو Data Quality.
هي آلية Delivery تنقل Event جاهزة إلى Workflow Server-Side خاص بوجهة معينة.
كيف ينتقل التحويل من المتجر إلى منصة الإعلانات؟
أسهل طريقة لفهم Server-Side Event Delivery هي متابعة Order واحدة.
العميل يكمل عملية شراء في المتجر.
هذه Transaction تصبح Source لحدث Conversion.
بعدها يمر Event بعدة مراحل قبل أن تستطيع منصة الإعلانات استخدامه.
إنشاء الحدث
أولًا، يجب أن يكون Business Event موجودًا.
المصدر قد يكون Ecommerce Platform أو Backend أو App أو أي نظام مدعوم آخر.
المهم أن يمثل الحدث فعلًا حقيقيًا قابلًا للقياس، مثل Purchase مكتملة.
في هذه المرحلة، دقة المصدر أهم من أي شيء بعده.
إذا أنشأ المصدر Event Name خاطئًا، أو Value غير صحيحة، أو Event مكررة، فباقي Delivery Path يرث المشكلة.
تجهيز البيانات
قبل الإرسال، قد يحتاج Event إلى Normalization وMapping بالشكل المطلوب للوجهة.
قد يشمل ذلك مراجعة:
- Event Name.
- Value وCurrency.
- Event ID أو Order ID.
- Identifiers المسموح بها والمناسبة.
- هل نفس Conversion موجودة أيضًا من Browser Path أم لا.
هذه المرحلة هي التي تجعل Server-Side workflow المتحكم فيها مفيدة.
بدل التعامل مع كل Platform كتنفيذ Tracking منفصل تمامًا، يمكن البدء من Event واضحة ثم تجهيزها للـDestination المدعومة.
API Delivery
بعد تجهيز Event، يتم إرسالها إلى API endpoint الموثقة الخاصة بالوجهة.
وهذا هو الجزء الذي يقصده أغلب الناس عندما يقولون "Conversion API".
لكن إرسال Request ليس نهاية العملية.
لازم تعرف:
هل نجح Request؟
هل Destination قبلت Event؟
هل البيانات نفسها مفيدة وصحيحة؟
Successful API call لا تساوي تلقائيًا Conversion Signal موثوقة.
استقبال المنصة للحدث
المرحلة الأخيرة هي التأكد مما حدث داخل Destination.
هل استقبلت المنصة Event؟
هل تمت معالجتها؟
هل تم رفضها أو ظهر عليها Error؟
وهل Conversion ما زالت تتطابق مع Order الأصلية؟
Diagnostic tools والحقول الدقيقة تختلف من منصة لأخرى، لذلك يجب مراجعتها حسب الـimplementation الحالي.
لكن المبدأ ثابت: Event Delivery يجب أن تكون قابلة للمراقبة بما يكفي لمعرفة أين حدث Failure.
ما البيانات التي يمكن أن يحتوي عليها حدث التحويل من الخادم؟
لا توجد Payload واحدة تناسب كل المنصات.
كل Destination قد يكون لها Schema ومتطلبات مختلفة.
بشكل عام، Server-Side Conversion Event تحتاج بيانات تصف الفعل التجاري وتساعد الوجهة على معالجته بشكل صحيح.
قد يشمل ذلك:
- Event Name.
- Timestamp أو Event Timing.
- Purchase Value.
- Currency.
- Event ID أو Order ID.
- Customer أو Click Identifiers المسموح بها عندما تكون مطلوبة ومتاحة.
- Destination-specific fields أخرى.
القاعدة ليست "أرسل أكبر قدر ممكن من البيانات".
القاعدة هي إرسال البيانات المطلوبة والمسموح بها والمفيدة للـworkflow الموثق.
Identifiers مهمة جدًا.
Event ID ثابتة قد تساعد في تنسيق Browser وServer representations لنفس Business Event عندما يكون المساران فعالين معًا.
Value وCurrency أيضًا أساسيتان، لأن Purchase Event بقيمة مالية خاطئة تظل Tracking Data سيئة حتى لو وصلت بنجاح.
قائمة الحقول الدقيقة يجب أن تُراجع من متطلبات Destination الحالية، وليس نسخها من Integration مختلف.
الفرق بين Conversion API ومنظومة Server-Side Tracking
Conversion API وServer-Side Tracking مرتبطتان، لكنهما ليسا نفس الشيء.
Conversion API هي آلية Delivery المواجهة للـDestination.
أما Server-Side Tracking فهي Architecture أوسع حول Event نفسها.
وقد تشمل:
- Collection من Source مدعوم.
- Event Validation.
- Normalization للحقول والقيم.
- Identifier handling.
- تنسيق Browser وServer Events.
- Deduplication.
- Routing.
- Delivery Monitoring.
- Failure Diagnosis.
يمكنك التفكير في الـAPI على أنها طريق الإرسال الأخير.
أما Tracking Architecture فهي النظام الذي يحدد ما الذي يدخل هذا الطريق، وهل البيانات جاهزة، وماذا يحدث إذا فشلت مرحلة من المراحل.
لهذا عبارة "عندنا CAPI integration" لا تكفي لإثبات أن Tracking سليمة.
يجب أن تعرف أيضًا:
هل Source Event صحيحة؟
هل Duplicates تحت السيطرة؟
هل Delivery موثوقة؟
وهل Destination Data يمكن مقارنتها بالمعاملة الأصلية؟
كيف تتحقق أن الأحداث تصل إلى المنصة؟
لا تتحقق من Conversion API فقط لأن API Request رجعت Successful.
ابدأ من Transaction نفسها.
خذ Order حقيقية من Source of Truth، ثم تابع Event المقابلة لها خلال Delivery Path.
راجع أربع نقاط.
أولًا: هل Source أنشأ Event المتوقعة؟
ثانيًا: هل Server-Side workflow جهز وأرسل البيانات الصحيحة؟
ثالثًا: هل Destination استقبلت أو عالجت Event حسب Diagnostic View المتاحة؟
رابعًا: هل Event ما زالت تتطابق مع Order الأصلية؟
بالنسبة إلى Purchase، راجع عناصر مثل:
- Order ID أو Event ID.
- Value.
- Currency.
- Duplicate representations.
- Delivery Status.
- Destination Outcome.
إذا لم توجد Source Event من الأصل، فالمشكلة Upstream.
إذا كانت Event موجودة لكنها لا تخرج من Server-Side workflow، فالمشكلة في Processing أو Delivery.
إذا تم إرسالها لكن Destination لم تقبلها، فالتنفيذ الخاص بالوجهة يحتاج Investigation.
أما إذا وصلت Event ومع ذلك استمرت الأرقام في الاختلاف، فقد تكون الخطوة التالية مراجعة Attribution أو Reporting وليس Transport.
هذه هي القيمة العملية من التعامل مع Conversion API كجزء من Event Path يمكن مراقبته، وليس مجرد Integration يتم تنفيذها مرة واحدة ثم نسيانها.
السياق السابق: Server-Side Tracking
أدلة مرتبطة
الأسئلة الشائعة
كيف ترسل Conversion API حدثًا بدون الاعتماد فقط على المتصفح؟
يتم Mapping وفحص حدث من مصدر مدعوم ثم إرساله Server-Side إلى API endpoint موثقة.
ماذا يحدث للحدث قبل وصوله للمنصة؟
قد يتم Normalization وMapping وفحص القيم/المعرّفات وتجهيز Deduplication.
ماذا يمكن أن يحتوي Server-Side Conversion Event؟
اسم الحدث والقيم والـIDs والمعرّفات المناسبة؛ الحقول الدقيقة تختلف حسب الوجهة.
هل CAPI هي نفسها Server-Side Tracking؟
لا؛ CAPI آلية Delivery لوجهة، بينما Server-Side Tracking هو البنية الأوسع للمعالجة.
كيف تتحقق من وصول الأحداث؟
افحص الحدث من المصدر وحالة الإرسال واستقبال الوجهة ثم قارنه بطلبات مصدر الحقيقة.
