تتبع التحويلات من جهة الخادم في 2026: دليل عملي إلى Conversion API لإعلانات Meta وGoogle وChatGPT

الإجابة باختصار: واجهة Conversion API هي الواجهة التي يقوم عليها تتبع التحويلات من جهة الخادم. فهي ترسل أحداث التحويل، مثل عملية بيع أو إرسال نموذج أو تسجيل حساب، من خادمك أنت إلى المنصة الإعلانية بدلًا من إرسالها من متصفح الزائر. وتُعرف لدى Meta باسم Conversions API (CAPI). أما لدى Google فتؤدي المهمة نفسها التحويلات المحسّنة (Enhanced Conversions) وواجهة Data Manager API، وفي إعلانات ChatGPT تستخدم OpenAI واجهة Conversions API الخاصة بها. وتوصي Meta بتشغيل CAPI إلى جانب Pixel لا بدلًا منه: فالحدث نفسه يصل من المتصفح ومن الخادم، ويُستخدم معرّف حدث مشترك (event_id) لإزالة التكرار (Deduplication). والقيمة الحقيقية للإعداد من جهة الخادم أن البيانات التي تتلقاها المنصات تأتي من سجلات الطلبات ونظام إدارة علاقات العملاء (CRM) لديك، لا من المتصفح.

أعددنا هذا الدليل لمسؤولي التسويق والبرمجيات في شركات التجارة الإلكترونية وشركات B2B (بين الشركات) التي تعلن بانتظام على Meta وGoogle، ولديها موقع إلكتروني أو نظام CRM مطوَّر حسب الطلب (Laravel أو Node.js أو ‎.NET)، أو تُتم مبيعاتها خارج الإنترنت. وإذا كنت تبيع في السوق التركية أو تعمل مع شركاء أتراك، فستفيدك أيضًا الأقسام المتعلقة ببيانات العملاء الأتراك وبقانون حماية البيانات الشخصية التركي (KVKK). وقد تحققنا من المعلومات بالرجوع إلى وثائق Meta وGoogle وOpenAI والتشريعات التركية لحماية البيانات، ونذكر المصادر الثانوية بشكل منفصل. هذا المقال محدّث حتى 31 أكتوبر 2026.

ما هي واجهة Conversion API، وكيف يختلف تتبع التحويلات من جهة الخادم عن Pixel؟

يُعد Pixel مقطعًا من كود JavaScript يرسل الحدث من متصفح الزائر. وقد يضيع الحدث في الطريق بسبب مانع إعلانات أو قيود المتصفح أو صفحة لم يكتمل تحميلها. أما مع Conversion API، فإن خادمك هو الذي ينشئ الحدث ويرسله مباشرة إلى واجهة API الخاصة بالمنصة. ويعني ذلك أنك تستطيع أيضًا إرسال أحداث لا يراها المتصفح أبدًا، مثل تأكيد الدفع، أو صفقة أُبرمت في المتجر، أو عميل محتمل صُنّف في CRM على أنه «مؤهل».

ما هي Meta CAPI؟ هي واجهة الأحداث من جهة الخادم لدى Meta، ويبحث عنها الناس أيضًا باسم «Facebook Conversion API» في محركات البحث. ويسميها مركز المساعدة لدى Meta باللغة التركية «Dönüşümler API'si»، وهي معلومة مفيدة إذا كان فريقك أو وكالتك في تركيا يستخدم Meta باللغة التركية. وتوصي Meta بتشغيل CAPI إلى جانب Pixel، وتسمي وثائقها للمطورين هذا النهج «إعدادًا احتياطيًا مزدوجًا» (Redundant Setup). فإذا تطابق eventID في Pixel مع event_id في CAPI وكانت أسماء الأحداث متطابقة، تُحتسب النسختان حدثًا واحدًا. وتعمل إزالة التكرار عبر event_id خلال 48 ساعة من استلام أول حدث يحمل ذلك المعرّف، وعادةً ما تحتفظ Meta بالنسخة التي تصل أولًا. أما الطريقة البديلة القائمة على fbp أو external_id فلا تستطيع عادةً مطابقة الأحداث إلا إذا وصلت نسخة المتصفح قبل نسخة الخادم. لذلك امنح كل حدث قيمة event_id فريدة.

أما لدى Google فيتكوّن المقابل من جزأين: التحويلات المحسّنة، التي ترسل عنوان البريد الإلكتروني ورقم الهاتف بعد تجزئتهما (Hashing) مع التحويل، وواجهة Data Manager API، التي أصبحت الآن المسار الرئيسي لاستيراد التحويلات غير المتصلة بالإنترنت (Offline Conversions). وبالنسبة إلى إعلانات ChatGPT، تعمل واجهة Conversions API من OpenAI وفق المبدأ نفسه.

إضافة جاهزة أم إعداد بنقرة واحدة أم تكامل Conversion API مخصص؟

لا تحتاج كل الشركات إلى إعداد مخصص. ففي 15 أبريل 2026، أعلنت Meta عن إعداد CAPI بنقرة واحدة لأحداث الويب لا يتطلب خبرة تقنية ولا تكلفة ولا صيانة، ولا تتغير الإعدادات الحالية عبر الشركاء أو الإعدادات المخصصة. ووفقًا لموقع PPC Land، يغطي هذا الإعداد الويب فقط، ولا يمكنك اختيار الأحداث والمعلمات التي يرسلها: فكل ما يرسله Pixel يُرسَل أيضًا من الخادم. أما أحداث التطبيقات والأحداث غير المتصلة بالإنترنت فتحتاج إلى تكامل منفصل. ومن الخيارات الجاهزة الأخرى مستويات مشاركة البيانات التي تستخدم CAPI في Shopify، وإضافة «Facebook Conversion API» في ikas، وهي منصة تجارة إلكترونية تركية.

في نظام تجارة إلكترونية مطوَّر حسب الطلب، أنظف طريقة هي إنشاء الحدث من جدول الطلبات. وقد ناقشنا قرارًا مشابهًا بين الحل الجاهز والحل المخصص في مقالنا عن ربط موقع التجارة الإلكترونية بنظام ERP والفوترة الإلكترونية.

ما الذي تغيّر لدى Meta وGoogle وOpenAI في عام 2026؟

لدى Google النصيب الأكبر من هذه التغييرات. ويعتمد صف 12 نوفمبر على مصادر ثانوية.

إعداد «قياس التحويلات على أجهزة العملاء» لدى Meta في 12 نوفمبر 2026: ما الذي يغيّره؟

نشرت Meta في مركز المساعدة مقالة بعنوان «حول قياس التحويلات على أجهزة العملاء» (About measuring conversions on customer devices). أما التفاصيل فتأتي من منشورات متخصصة تقتبس نص لوحة Events Manager والرسالة الإلكترونية التي أرسلتها Meta إلى المعلنين. ووفقًا لموقع PPC Land، تعرض Events Manager عبارة «Measurement starting November 12, 2026» (يبدأ القياس في 12 نوفمبر 2026) تحت خيار «قياس التحويلات على أجهزة العملاء» (Measure conversions on customer devices). ويكون الإعداد مفعّلًا افتراضيًا لمجموعات البيانات (Datasets) التي ترسل أحداثًا. ويمكنك إيقافه لكل مجموعة بيانات على حدة في أي وقت، ولا يتطلب ذلك أي تعديل في الكود. ووفقًا للتقرير نفسه، سيكون الإطلاق تدريجيًا اعتبارًا من 12 نوفمبر. ووفقًا لموقع MetricMaven، نقلًا عن Meta، تجري المطابقة على جهاز العميل. ولا تعرف Meta سوى أن عملية شراء قد تمت، والحملة التي يُنسب إليها التحويل. ولا تتغير نافذة الإسناد ولا نموذجه.

وفقًا لموقعي MetricMaven وStape، لا تعمل هذه الميزة للأشخاص الموجودين في الاتحاد الأوروبي والمملكة المتحدة. وهناك أيضًا شروط للأهلية، مثل أن يتطلب الموقع تسجيل الدخول بعنوان بريد إلكتروني أو رقم هاتف. وإذا صحّ ذلك، فقد تقع المتاجر التي تتيح الشراء دون تسجيل (Guest Checkout) خارج نطاقها. أما النقاط التي لم توضحها Meta بعد فهي حاسمة: كيفية إزالة التكرار بين المشتريات المستعادة وأحداث CAPI، والتأثير في المزايدة، وهل تُنقل القيمة والعملة، وكيف تُعالَج الموافقة. والتوقيت حساس أيضًا: فيوم 12 نوفمبر يأتي مباشرة بعد حملات 11.11 (يوم العزاب) وقبل الجمعة السوداء في 27 نوفمبر بمدة 15 يومًا. ونصيحتنا أن تتخذ قرارك استنادًا إلى القياس بدلًا من إيقاف الإعداد دون تبصّر. وفيما يلي قائمة التحقق التي نعتمدها، وهي تتوافق مع ما تذكره مصادر القطاع:

1. سجّل الوضع الحالي: دوّن لكل مجموعة بيانات ما إذا كان الإعداد مفعّلًا أم متوقفًا. وأضف علامة عند 12 نوفمبر إلى لوحات الأداء وإلى تقارير 11.11 والجمعة السوداء.
2. حدّد خط أساس: احسب لكل يوم قبل 12 نوفمبر النسبة «المشتريات التي أبلغت عنها Meta ÷ الطلبات الفعلية». ثم تابع هذه النسبة وأي قفزات ناتجة عن الاحتساب المزدوج لمدة تتراوح بين أربعة وستة أسابيع.
3. أنشئ مجموعة ضبط (Holdout): استخدم مجموعة ضبط حسب المنطقة أو الحملة للتحقق من الزيادة المُبلَّغ عنها مقارنةً بالطلبات الفعلية.
4. في القطاعات الخاضعة للتنظيم، من الخيارات المتاحة إيقاف الإعداد إلى حين اكتمال المراجعة القانونية وتوثيق السبب.

إعداد Conversion API: كيف تنفّذ تتبع التحويلات من جهة الخادم خطوة بخطوة

في المعمارية المرجعية التي نعتمدها، يكون سجل الطلب أو سجل CRM هو مصدر البيانات الموثوق. وتُغذَّى Meta وGoogle، وكذلك OpenAI إن أردت، من تدفق أحداث واحد يُنشأ من هذا السجل ويحمل حالة الموافقة. وأنشئ رمز الوصول (Access Token)، أي رمز Meta CAPI، في Events Manager، ضمن قسم Conversions API في علامة تبويب الإعدادات (Settings) الخاصة بأداة Pixel لديك. ولا يظهر هذا الرابط إلا للمستخدمين الذين يملكون صلاحية المطور في النشاط التجاري. واحتفظ بالرمز سرًّا على الخادم.

1. أنشئ الحدث من السجل. تقع عملية الشراء عند التحقق من إشعار الدفع وتأكيد الطلب، لا عند تحميل صفحة «شكرًا لك». وقد تناولنا هذه الخطوة في دليلنا إلى Webhook في نقاط البيع الافتراضية (الدفع الإلكتروني بالبطاقة).
2. التقط معرّفات النقر. بالنسبة إلى Meta، التقط قيمة fbc المُنشأة من fbclid (fb.${subdomain_index}.${creation_time}.${fbclid}) وقيمة fbp، وبالنسبة إلى Google قيم gclid وgbraid وwbraid، وبالنسبة إلى OpenAI ملف تعريف الارتباط __obref إذا سمحت قواعد الموافقة لديك بذلك. وتُرسل هذه المعرّفات وعنوان IP ووكيل المستخدم (User Agent) دون تجزئة.
3. استخدم معرّفًا واحدًا للحدث. اجعل رقم الطلب هو قيمة eventID في Pixel، وevent_id في CAPI، وtransactionId لدى Google، وحقل id لدى OpenAI في آن واحد.
4. دوّن الموافقة داخل الحدث. احفظ اختيار المستخدم في تلك اللحظة مع الحدث. وتوفر Data Manager API الحقلين adUserData وadPersonalization لهذا الغرض.
5. وحّد الصيغة (Normalization) وطبّق التجزئة (انظر القسم التالي).
6. ضع الحدث في قائمة انتظار وأرسله إرسالًا لا يتكرر أثره (Idempotent). يُكتب الحدث في قائمة انتظار، وترسله عملية خلفية (Worker)، وإذا فشل الإرسال أعادت المحاولة على فترات متزايدة. ولا تتسبب إعادة المحاولة في احتساب مزدوج. فكل من Meta وOpenAI تحتفظ بأولى النسخ التي تصل بالمفتاح نفسه. أما Google فتعامل معرّف المعاملة (Transaction ID) المعروف على أنه تعديل (Adjustment) لا تحويل جديد، ولا تزيد عدد التحويلات.
7. اختبر وطابق. استخدم test_event_code لدى Meta (واحذفه في بيئة الإنتاج)، وvalidateOnly وrequestStatus.retrieve لدى Google، وvalidate_only لدى OpenAI في مرحلة الاختبار. وبعد الإطلاق، قارن تقرير المنصة بطلباتك الفعلية كل يوم.

قواعد الإرسال حسب المنصة

فخاخ توحيد الصيغة والتجزئة في البيانات التركية

تطلب المنصات الثلاث استخدام خوارزمية SHA-256 في تجزئة عناوين البريد الإلكتروني وأرقام الهاتف. ويؤدي اختلاف حرف واحد إلى قيمة تجزئة (Hash) مختلفة تمامًا. ولذلك فإن خطأ توحيد الصيغة يعني خسارة صامتة في المطابقات لا تظهر معها أي رسالة خطأ.

• لا تُنسَّق أرقام الهاتف بالطريقة نفسها في كل مكان. فرقم الجوال التركي 0532 123 45 67، المكتوب هنا بالصيغة المحلية، تُوحَّد صيغته ويُجزَّأ بالشكل 905321234567 في واجهتي Conversions API لدى Meta وOpenAI (احذف الصفر الأول، وأضف رمز الدولة، دون علامة «+»). أما في Google Data Manager API وعمليات رفع الجماهير لدى OpenAI فيصبح +905321234567 (E.164). وتنبّه OpenAI نفسها إلى عدم افتراض أن قاعدة الهاتف في إحدى واجهات API تسري على واجهة أخرى.
• تحويل الحرفين التركيين İ وI إلى أحرف صغيرة يغيّر قيمة التجزئة. تضم اللغة التركية زوجًا من الأحرف المنقوطة (İ/i) وزوجًا من الأحرف غير المنقوطة (I/ı). ووفق القاعدة الافتراضية في Unicode، ينتج عن تحويل «İ» إلى حرف صغير قيمة من حرفين هي «i̇» (i + U+0307). ولا تحوّل «İ» إلى «i» العادية و«I» إلى «ı» إلا الإعدادات المحلية التركية (Locale). ففي اختبارنا، أعاد "İLKER".lower() في Python القيمة «i̇lker»، ولم تتطابق قيمة تجزئتها مع قيمة تجزئة «ilker». وأعاد "IŞIK".lower() القيمة «işik» بدلًا من الكلمة التركية «ışık». ومنذ PHP 8.2، لا تحوّل strtolower() إلى أحرف صغيرة سوى أحرف ASCII، ولذلك تترك «İ» و«Ş» دون تغيير. أما mb_strtolower()، التي تستخدمها الدالة المساعدة Str::lower() في Laravel، فتحوّل «İ» إلى «i̇». والعكس لا يقل خطورة: فمع الإعدادات المحلية التركية (toLocaleLowerCase('tr') في JavaScript، وToLower() ضمن الثقافة tr-TR في ‎.NET) تتحول «[email protected]» إلى «ılker@fırma.com» عند التحويل إلى أحرف صغيرة.
• قواعد منفصلة لعناوين البريد الإلكتروني والأسماء. بالنسبة إلى عناوين البريد الإلكتروني، استخدم تحويلًا إلى الأحرف الصغيرة مستقلًا عن الإعدادات المحلية، وحوّل «İ» إلى «i» أولًا. فعندما تكتب لوحة مفاتيح الجوال الحرف الأول كبيرًا وفق القاعدة التركية، قد يُحفظ العنوان بالشكل «İlker@…». أما الأسماء فتختلف قواعدها: إذ توصي Meta بالأحرف a–z لكنها تقبل UTF-8، وتطلب OpenAI الإبقاء على العلامات المضافة إلى الحروف (Accents)، وتريد Google أحرفًا صغيرة دون ألقاب. ولا توجد وثائق تبيّن أي صيغة من الأحرف التركية تحقق مطابقة أفضل، لذا اختبر ذلك ببياناتك الخاصة.
• قاعدة Gmail تسري لدى Google فقط: في عناوين gmail.com وgooglemail.com، احذف النقاط الواردة قبل الرمز @، واحذف علامة «+» مع كل ما يليها حتى الرمز @ نفسه. ولا تتضمن قواعد Meta وOpenAI خطوة كهذه. وتطلب OpenAI صراحةً عدم حذف النقاط ووسوم علامة الزائد (Plus Tags) في عمليات رفع الجماهير.
• لا تخلط بين الليرة والقرش (Kuruş). تريد Google أن تكون القيمة المرفوعة بالصيغة والوحدة نفسيهما المستخدمتين في العلامة. وتحذر من أن استخدام وحدة مختلفة، مثل السنتات بأعداد صحيحة (وهي في حالة الليرة التركية القروش: 100 قرش تساوي ليرة واحدة)، يسبب «تضخمًا شديدًا في قيمة التحويل»، وأن النظام لا يحوّل الوحدة من تلقاء نفسه. فإذا أُرسلت 24990 قرشًا كما هي، فسيظهر طلب بقيمة 249.90 ليرة تركية على أنه 24,990 ليرة تركية.

نحصر توحيد الصيغة في دالة واحدة مغطاة باختبارات الوحدة (Unit Tests). ومن أمثلة قيم الاختبار: تعطي « İ[email protected]» النتيجة [email protected]، وتعطي «[email protected]» في حالة Google النتيجة ([email protected]).

واجهة Google Data Manager API، والتحويلات غير المتصلة بالإنترنت، وجودة العملاء المحتملين من CRM لديك

لدى Google: التحويلات المحسّنة وواجهة Data Manager API

وفقًا للجدول الزمني من Google، أصبحت التحويلات المحسّنة للويب وللعملاء المحتملين إعداد تشغيل/إيقاف واحدًا اعتبارًا من يونيو 2026، ويمكنك إيقافها لإجراءات تحويل بعينها. وتصف Google واجهة Data Manager API بأنها المسار الرئيسي لاستيراد التحويلات غير المتصلة بالإنترنت، ولذلك نبدأ المشاريع الجديدة عليها مباشرة. النقاط التي ينبغي الانتباه إليها عند الانتقال:

• لا حاجة إلى رمز مطور (ومنذ 9 سبتمبر 2026 تتجاهل Google Ads API هذا الرمز أيضًا). وترتبط الحصص بمشروع Google Cloud المعني.
• يجب أن يكون operating_account هو الحساب المالك لإجراء التحويل. ولا تُقبل الحسابات الأم أو الحسابات الفرعية.
• تمر عمليات الرفع والتعديل عبر استدعاء IngestEvents نفسه. ويُعد إرسال معرّف معاملة موجود بقيمة جديدة تعديلًا. أما بشأن سحب التحويلات (Retractions) فالوثائق متناقضة: إذ يذكر دليل الترقية وصفحة التعديلات أنه لا يمكن إعادة تحديد سوى القيمة وأن عدد التحويلات لا يتغير، بينما تتحدث صفحة التحويلات غير المتصلة بالإنترنت عن السحب. اختبر سيناريو استرداد الأموال لديك قبل الإطلاق.
• أرسل GCLID مع كل حدث كلما أمكن ذلك. وهو إلزامي إذا كنت لا تجمع بيانات المستخدم عبر العلامة.

أما الجديد الحقيقي فهو التحويلات متعددة المصادر (إصدار تجريبي). إذ يمكنك إضافة نظام CRM أو قاعدة بيانات الطلبات مصدرًا ثانيًا إلى تحويل ويب جرى إعداده عبر علامة Google أو GTM بصورة يدوية. وتُزال السجلات المكررة بناءً على معرّف المعاملة. وفي الأحداث المتطابقة، يستبدل المصدر المضاف قيمة العلامة ويصبح المرجع الوحيد للقيمة. وخلال فترة التجربة الأولى البالغة 14 يومًا، تكون تحديثات القيمة متوقفة ولا تُستخدم التحويلات الجديدة في المزايدة.

لدى Meta: إعادة إرسال مراحل العملاء المحتملين من CRM

للحصول على أفضل النتائج من تكامل Conversion Leads، توصي Meta بتخزين Meta Lead ID المكوّن من 15 إلى 17 رقمًا في نظام CRM لديك. وبدونه، ترسل بدلًا منه معرّف النقر أو رقم الهاتف أو عنوان البريد الإلكتروني. أما المتطلبات فهي: 200 عميل محتمل على الأقل شهريًا؛ وأن تقع المرحلة التي تحسّن حملاتك من أجلها خلال 28 يومًا من ورود العميل المحتمل وبمعدل تحويل من 1% إلى 40%؛ والرفع مرة واحدة يوميًا على الأقل. وتقدّر Meta فترة التعلم بمدة من 2 إلى 4 أسابيع. وفي مجال B2B ذي دورات البيع الطويلة، قد يستغرق إبرام الصفقة أكثر من 28 يومًا. ولذلك قد تحتاج إلى التحسين لمرحلة أبكر، مثل «عميل محتمل مؤهل» بدلًا من «صفقة ناجحة» (Won). ويُرسل التغيير نفسه في المرحلة إلى Google عبر Data Manager API، مع GCLID وعنوان البريد الإلكتروني بعد تجزئته، بوصفه تحويلًا محسّنًا للعملاء المحتملين. وفي مشاريع CRM وERP التي ننفذها، نصمم حقول المراحل لهذه الحاجة منذ البداية.

قانون KVKK والموافقة: ما الأسئلة التي ينبغي طرحها على فريقك القانوني؟

هذا القسم ليس استشارة قانونية. وKVKK هو الاختصار الشائع لقانون حماية البيانات الشخصية التركي (القانون رقم 6698) وللهيئة التي تتولى إنفاذه. ويُصدر مجلس هذه الهيئة قرارات مبادئ.

• هل إشعار الخصوصية والموافقة الصريحة منفصلان؟ بموجب قرار المبادئ رقم 2026/347 الصادر عن المجلس، يجب تقديم إشعار الخصوصية (aydınlatma) قبل المعالجة، أيًا كان الأساس القانوني. وإذا كنت تعتمد على الموافقة الصريحة (açık rıza)، فيُصاغ النصان بشكل منفصل وتحت عنوانين مختلفين. أما إذا كنت تعتمد على أساس قانوني آخر، فلا تقدّم نص موافقة صريحة.
• ما الأساس القانوني لنقل البيانات إلى الخارج؟ تشترط المادة 9 من القانون، بصيغتها السارية منذ 1 يونيو 2024، توفر شرط من شروط المعالجة، ويُشترط إضافة إلى ذلك قرار ملاءمة أولًا، أو ضمانات مناسبة مثل العقد النموذجي إذا لم يوجد هذا القرار. ويجب إخطار الهيئة بالعقد النموذجي خلال خمسة أيام عمل من توقيعه. ولا تمثل الموافقة الصريحة سوى مسار استثنائي لعمليات النقل «العارضة» (arızi). وتعرّف اللائحة التنفيذية النقل العارض بأنه نقل غير منتظم، يحدث مرة واحدة أو بضع مرات فقط، وليس مستمرًا، وليس جزءًا من السير المعتاد للأعمال. فهل ينطبق هذا التعريف على تدفق بيانات يعمل مع كل طلب؟
• هل التجزئة إخفاء للهوية؟ الغرض من التجزئة هو مطابقة الشخص مع حساب على المنصة، وGoogle أيضًا تقارن البيانات المجزّأة بالحسابات المسجَّل دخولها. ونتعامل مع التجزئة بوصفها تدبيرًا أمنيًا، لا إخفاءً للهوية (Anonymization).
• ما الإعداد الافتراضي للموافقة؟ يهيّئ OpenAI Pixel الموافقة بالقيمة true افتراضيًا. وحيثما كانت الموافقة مطلوبة، استدعِ oaiq('consent', false) قبل خطوة التهيئة (init).
• هل تعلن لمستخدمين في أوروبا؟ تشمل سياسة موافقة المستخدمين في الاتحاد الأوروبي من Google المستخدمين في المنطقة الاقتصادية الأوروبية والمملكة المتحدة وسويسرا. وتشترط موافقة صالحة لجمع البيانات الشخصية ومشاركتها واستخدامها في تخصيص الإعلانات. ويقع المُصدِّر الذي يتخذ من تركيا مقرًا له ويصل إلى مستخدمين في ألمانيا عبر منتجات Google ضمن نطاق هذه السياسة بالنسبة إلى هؤلاء المستخدمين. أما الزيارات القادمة من تركيا فيحدد قانون KVKK إطارها.

حدّد جرد البيانات والضمانات لديك عبر مراجعة امتثال KVKK وGDPR قبل تصميم التكامل.

كيف تساعدك Partnerfy

لا ننظر إلى Conversion API على أنها تركيب علامة (Tag)، بل مشروع تكامل ينطلق من بيانات الطلبات وCRM لديك. نبدأ بتدقيق أحداث Pixel والخادم الحالية لديك. ثم نربط مخطط الأحداث بمنصات Meta وGoogle، وكذلك OpenAI عند الحاجة، ونثبّت استراتيجية event_id وقواعد توحيد الصيغة عبر قيم اختبار. ونبني طبقة الإرسال على حزمة التقنيات (Tech Stack) لديك (مثل Laravel أو Node.js أو ‎.NET) مع قائمة انتظار وإعادة محاولة لا يتكرر أثرها (Idempotent) ومراقبة للأخطاء، ونجعل حالة الموافقة جزءًا من الحدث. وبعد الإطلاق، نُعدّ أيضًا واجهة للمطابقة والمراقبة تقارن تقارير المنصات بطلباتك الفعلية. وستجد التفاصيل في صفحة تكاملات Conversion API لدينا. ولمراجعة إعدادك الحالي معًا، تواصل معنا.

المصادر

• Meta for Developers: إزالة التكرار، معلمات معلومات العميل، استخدام API، رمز الوصول، Conversion Leads
• Meta: إعلان 15 أبريل 2026؛ مركز مساعدة الأعمال: حول Conversions API، حول قياس التحويلات على أجهزة العملاء
• Google Ads API: عمليات الإيقاف (Deprecations)، رمز المطور، مدونة المطورين، 15 مايو 2026
• مساعدة Google Ads: التحويلات المحسّنة للعملاء المحتملين، تحديثات إعدادات التحويلات المحسّنة، التحويلات متعددة المصادر
• Google Data Manager API: دليل الترقية، التحويلات غير المتصلة بالإنترنت، التعديلات، events.ingest، نموذج الأخطاء، التنسيق، الموافقة (Consent)؛ Google: سياسة موافقة المستخدمين في الاتحاد الأوروبي
• OpenAI Ads: Conversions API، Measurement Pixel، Custom Audiences، الاستهداف، سجل التغييرات، توفر Ads Manager
• KVKK (باللغة التركية): الإعلان الخاص بقرار المبادئ رقم 2026/347، القانون رقم 6698؛ الجريدة الرسمية التركية (Resmî Gazete، باللغة التركية): لائحة نقل البيانات الشخصية إلى الخارج
• مصادر تقنية: Unicode SpecialCasing، MDN، Microsoft Learn، PHP strtolower؛ المنصات الجاهزة: ikas، Shopify
• المصادر الثانوية: PPC Land، 27 أكتوبر 2026، PPC Land، 27 أبريل 2026، Stape، 22 أكتوبر 2026، MetricMaven، 19 أكتوبر 2026

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