Conversions API لإعلانات WhatsApp 2026: تتبع CTWA من جانب الخادم [دليل تقني]

, Editorial Team

من يُطلق إعلانات Click-to-WhatsApp دون Conversions API يخسر 20-40% من دقة التتبع. هذا الدليل التقني يشرح: إعداد CAPI، أربعة أحداث قياسية لـ CTWA، ربط Click-ID، تشفير SHA-256، وتكامل webhook مع SendSeven.

TL;DR

يُرسل Meta Conversions API (CAPI) أحداث التحويل مباشرةً إلى ميتا من جانب الخادم — بمعزل عن ملفات تعريف الارتباط ومانعات الإعلانات. لحملات Click-to-WhatsApp، CAPI ليس خياراً بل ضرورة: لأن التحويل (Lead، موعد، شراء) يحدث في محادثة واتساب لا في المتصفح، فالبكسل التقليدي لا يستطيع تسجيله أصلاً. أربعة أحداث قياسية تغطي مسار CTWA: Lead، Schedule، AddToCart، Purchase. البيانات الشخصية يجب تشفيرها بـ SHA-256 قبل الإرسال، وClick-ID من الإعلان الأصلي يضمن الإحالة الصحيحة.

هذا المقال يعمّق قسم Conversions API من الدليل الشامل لإعلانات CTWA. من أكمل الإعداد في 7 خطوات سيجد هنا الطبقة التقنية للتتبع.

لماذا البكسل وحده غير كافٍ

بكسل ميتا أداة JavaScript تعمل في المتصفح. في السنوات الأخيرة انخفضت موثوقيته بشكل حاد:

  • App Tracking Transparency (ATT) من آبل (iOS 14.5، أبريل 2021) — بحسب السوق والجمهور المستهدف، يرفض 60–75% من مستخدمي iPhone التتبع — وفي الأسواق الحساسة للخصوصية تميل النسبة نحو الطرف الأعلى من هذا النطاق.
  • قيود الخصوصية في المتصفحات — Safari (ITP) وFirefox يحجبان الكوكيز الخارجية تماماً.
  • مانعات الإعلانات — uBlock Origin، AdBlock Plus، Brave تحجب طلبات البكسل على مستوى الشبكة.
  • iOS 17 وما بعده — Link Tracking Protection يزيل معاملات التتبع من URL في البريد والرسائل.

النتيجة العملية: التطبيقات التي تعتمد البكسل وحده تفقد عادةً 20-40% من التحويلات القابلة للقياس. لحملات CTWA المشكلة أحدّ: التحويل الحقيقي يقع في محادثة واتساب. البكسل يرى النقرة على الإعلان لكنه لا يرى هل تم تأهيل الـ Lead أو حجز الموعد أو إتمام الشراء. بدون CAPI يُحسّن خوارزم ميتا للنقرات — لا للمحادثات المؤهّلة.

كيف يعمل CAPI تقنياً

CAPI لا يحل محل البكسل بل يكمله. سير العمل في أربع خطوات:

سير عمل CAPI لتحويلات CTWA1. التحويلفي صندوق الواردLead مؤهّل،موعد، شراء2. حدث الخادمالمنصة تبني payloadClick-ID + بياناتمشفرة SHA-2563. HTTPS POSTإلى Meta CAPIendpointgraph.facebook.com4. المطابقةميتا تُسندعبر Click-IDإلى الإعلان

أربعة أحداث قياسية لمسار CTWA

الحدثالمُشغِّل في المسارالـ Payload الموصى بهأثر التحسين
Leadالبوت أهّل الاستفسار أو الوكيل البشري أعطى أول ردcurrency, value (قيمة الـ Lead), content_nameالخوارزم يُحسّن للـ Leads المؤهّلة لا مجرد النقرات
Scheduleتم حجز موعد عبر واتسابcurrency, value (قيمة الموعد)قيّم لقطاعات الاستشارة (صيانة، صحة، B2B)
AddToCartمنتج محدد استُفسر عنه أو حُجز في محادثة واتسابcurrency, value, content_ids, num_itemsجسر لمسارات التجارة الإلكترونية
Purchaseتمت عملية الشراء وتأكيد الدفعcurrency, value (الإيراد الفعلي), content_ids, order_idالمقياس الرئيسي لـ ROAS، مصدر Lookalike للحملات المستقبلية

التوصية: ابدأ بـ Lead وPurchase فقط — هما الحدّ الأدنى. أضف Schedule وAddToCart عندما يعمل المسار باستقرار.

ربط Click-ID والإحالة

كي تستطيع ميتا إسناد تحويل الخادم إلى الإعلان الأصلي، يحتاج حدث CAPI إلى معرّف النقرة. في CTWA ترسل ميتا هذا المعرّف عند نقر الإعلان إلى واتساب (معاملات داخلية مثل ctwa_clid).

سير العمل العملي:

  1. المستخدم ينقر على إعلان CTWA → ميتا تُنشئ Click-ID وترسله إلى واتساب.
  2. واتساب يُرسل Click-ID مع أول رسالة إلى صندوق وارد المنصة.
  3. المنصة تحفظ Click-ID في ملف تعريف جهة الاتصال.
  4. عند وقوع التحويل (مثلاً: علامة „Lead” في صندوق الوارد)، تستخرج المنصة Click-ID المحفوظ وترسله مع حدث الخادم إلى ميتا.
  5. ميتا تعثر على الإعلان وتُسند التحويل إلى حساب الحملة.

من يستخدم منصة بدون استمرارية Click-ID يخسر معظم الإحالة. مع Webhooks الخاصة بـ SendSeven، تحصل على ctwa_clid كمعامل مرجعي مع أول رسالة واردة من إعلان CTWA — احفظه بنفسك في ملف تعريف جهة الاتصال عبر REST API.

تشفير SHA-256 لبيانات المستخدم

البيانات الشخصية لا يمكن إرسالها إلى ميتا كنص واضح. Conversions API يُلزم بالتشفير — عادةً SHA-256 — للحقول التالية:

  • البريد الإلكتروني (em) — قبل التشفير: أزل المسافات، حوّل لأحرف صغيرة
  • رقم الهاتف (ph) — تنسيق E.164 دون رمز +، أرقام فقط
  • الاسم الأول/الأخير (fn/ln) — أزل المسافات، أحرف صغيرة، أزل الأحرف الخاصة
  • المدينة/المنطقة/الرمز البريدي — نورملة مماثلة قبل التشفير
  • External ID — معرّفك الداخلي للمستخدم، يشفَّر هو أيضاً

ميتا تطابق القيم المشفرة مع مجموعات بياناتها الخاصة دون نقل البيانات الواضحة أو تخزينها بشكل دائم. بموجب PDPL وPDPR، المعالجة لا تزال خاضعة لالتزام الإشعار — انظر مقال CTWA وحماية البيانات.

مثال على payload الحدث

حدث CAPI كامل بصيغة JSON لحدث Lead من مسار CTWA:

POST https://graph.facebook.com/v19.0/<PIXEL_ID>/events

{
  "data": [{
    "event_name": "Lead",
    "event_time": 1746091800,
    "event_source_url": "https://wa.me/966501XXXXXX",
    "action_source": "business_messaging",
    "messaging_channel": "whatsapp",
    "user_data": {
      "ph": ["a1b2c3d4..."],          // SHA-256 رقم الهاتف
      "em": ["e5f6a7b8..."],          // SHA-256 البريد الإلكتروني
      "ctwa_clid": "ARDEr...",         // CTWA Click-ID
      "client_user_agent": "Mozilla/5.0..."
    },
    "custom_data": {
      "currency": "EUR",
      "value": 50.00,
      "content_name": "طلب خدمة تكييف"
    }
  }],
  "access_token": "<ACCESS_TOKEN>"
}

أحداث CAPI المُشغَّلة من المتصفح (مثلاً عند الضغط على زر „اشتراء” في موقعك) تخضع لنفس متطلبات الموافقة الخاصة بالبكسل — تحتاج موافقة التسويق في شريط الكوكيز.

أحداث الخادم النقية (مثلاً: علامة „Lead” في صندوق وارد واتساب تُشغّل حدث CAPI) لها وضع مختلف: المُشغِّل هو إجراء تجاري واعٍ، لا إجراء متصفح. طالما توفر الأساس القانوني (عادةً بموجب المصلحة المشروعة أو تنفيذ العقد) وذكرت ذلك في سياسة الخصوصية، فلا حاجة لموافقة كوكيز إضافية.

تكامل CAPI مع SendSeven — عبر Webhooks و REST API

SendSeven لا يمتلك حالياً تكامل CAPI قائم على واجهة المستخدم. من يريد إرسال أحداث CAPI من مسار واتساب إلى ميتا يبني هذا بنفسه باستخدام كتل المطور المتاحة — Webhooks و REST API توفران كل ما يلزم. أربع خطوات:

  1. تكوين webhook في SendSeven. سجّل endpoint يرسل payload إلى خادمك عند تغيير حالة المحادثة أو رسالة واردة. راجع دليل Webhook.
  2. بناء handler الخادم. يستقبل خادمك حدث webhook، يستخرج Conversation-ID وContact-ID ومعلومات الحالة. عند الحاجة، استدعاء REST API الخاصة بـ SendSeven لجلب بيانات الاتصال (بريد، هاتف).
  3. بناء CAPI payload. شفّر بيانات المستخدم بـ SHA-256، استخرج Click-ID من ملف تعريف جهة الاتصال، أكمل event_name وcustom_data بقيمة الإيراد.
  4. HTTPS POST إلى Meta Graph API: graph.facebook.com/v<version>/<PIXEL_ID>/events مع System User Access Token.

استمرارية Click-ID تبنيها بنفسك: WhatsApp Business API يوفر ctwa_clid كمعامل مرجعي مع أول رسالة واردة من إعلان CTWA — احفظه فوراً في ملف تعريف جهة الاتصال. تشفير SHA-256 يتولاه أي مكتبة تشفير قياسية في لغتك (Python hashlib، Node crypto، PHP hash) في سطر واحد.

CTWA + CAPI مع SendSeven

Webhooks و REST API لتكامل CAPI المخصص. استضافة في الاتحاد الأوروبي.

14 يوم مجاناً  الأسعار

أخطاء التطبيق الشائعة

  1. إرسال البيانات دون تشفير. ميتا ترفض الحدث صامتةً أو تُخفض معدل المطابقة إلى الصفر. شفّر دائماً SHA-256 قبل الإرسال.
  2. غياب استمرارية Click-ID. من لا يحفظ ctwa_clid في ملف تعريف جهة الاتصال يخسر الإحالة حتى لو أرسل الحدث بشكل صحيح.
  3. تتبع مزدوج دون إزالة التكرار. إذا أرسل البكسل وCAPI نفس الحدث دون event_id للتمييز، تُضاعف ميتا عدد التحويلات.
  4. أحداث تجريبية في تتبع الإنتاج. أحداث التجربة المنسية تتراكم وتشوّه بيانات التحسين.
  5. قيمة action_source خاطئة. أحداث CTWA تحتاج business_messaging، لا website.
  6. طابع زمني للحدث أقدم من 7 أيام. ميتا لا تقبل أحداث بطابع زمني أقدم من سبعة أيام.

الأسئلة الشائعة

هل أحتاج CAPI حتى مع نافذة الـ 72 ساعة المجانية؟

نعم — حتى في هذه الحالة، CAPI هو السبيل الوحيد لإخبار ميتا بأن المحادثة انتهت بتحويل حقيقي. بدون CAPI ترى ميتا النقرة فقط وتُحسّن الخوارزم للنقرات لا لنتائج الأعمال.

ما معدل المطابقة الطبيعي لـ CAPI في حملات CTWA؟

في الإعدادات الجيدة يتراوح معدل المطابقة بين 85-95% (وفق Meta Events Manager Diagnostics) — أعلى بكثير من البكسل وحده (60-75%). السبب الرئيسي: رقم الهاتف وClick-ID مفاتيح مطابقة مستقرة جداً.

هل يمكنني تطبيق CAPI مباشرةً بدون منصة؟

تقنياً نعم — عبر Server-Side SDK بـ Python أو Node أو PHP. عملياً يتطلب استمرارية Click-ID، pipeline التشفير، إزالة تكرار الأحداث، وسجل المراجعة. لمعظم الأعمال في الخليج، حل المنصة المتكامل أكثر كفاءةً بكثير.

مقالات ذات صلة: