استخدام مستمعي أحداث __tcfapi: دليل للمطورين حول السكربتات الواعية بالموافقة

لماذا ينبغي لسكربتاتك أن تستمع لا أن تستطلع

أي سكربت يعتمد على الموافقة — وسم إعلاني، أو محمّل تحليلات، أو غلاف header bidding — يحتاج إلى معرفة أمرين: هل اتخذ CMP قرارًا بعد، وما هذا القرار. من الأخطاء الشائعة قراءة ملف تعريف ارتباط عند تحميل الصفحة، أو استطلاع CMP بمؤقّت حتى يظهر شيء ما. كلا النهجين يفشل بطرق متوقعة: فصيغة ملف تعريف الارتباط داخلية في CMP ويمكن أن تتغير، والاستطلاع إما ينطلق مبكرًا جدًا وإما يهدر الوقت في الانتظار.

تحدد IAB TCF واجهة JavaScript قياسية لهذه المهمة بالذات: الدالة __tcfapi. يستعرض هذا الدليل الأوامر التي تحتاجها فعلًا، والأحداث التي ستتلقاها، والأخطاء الأكثر ظهورًا في بيئة الإنتاج.

الـ Stub والطابور

يُتوقع من CMP الخاص بـ TCF أن يضع stub صغيرًا في الصفحة في أبكر وقت ممكن، قبل تحميل سكربت CMP الكامل. يعرّف الـ stub الدالة window.__tcfapi ويضع في طابور أي استدعاءات تتم قبل أن يصبح CMP جاهزًا. وعندما ينتهي CMP من التحميل يعالج الطابور ويجيب عن كل استدعاء.

وهذا ما يجعل من الآمن للسكربتات الأخرى استدعاء __tcfapi فورًا: ما دام الـ stub في الصفحة قبلها فلن تضيع استدعاءاتها. وإذا ألقى سكربت خطأً لأن __tcfapi غير معرّفة، فإما أن الـ stub مفقود أو أنه يُحمَّل متأخرًا — أصلح ترتيب التحميل بدلًا من إضافة محاولات إعادة.

الأوامر المهمة

ping

يعيد __tcfapi('ping', 2, callback) حالة أساسية دون انتظار قرار المستخدم. تتضمن الاستجابة cmpLoaded وcmpStatus مثل stub أو loading أو loaded أو error، وdisplayStatus بقيمة visible أو hidden أو disabled. كما تُبلغ عن gdprApplies متى عُرفت. استخدمه للتشخيص ولتقرر هل TCF ذو صلة بهذا الزائر أصلًا.

addEventListener

الأمر __tcfapi('addEventListener', 2, callback) هو الأمر الذي ينبغي لمعظم عمليات التكامل استخدامه. يتلقى الـ callback كائن tcData ومؤشر نجاح، ويُستدعى مجددًا في كل مرة تتغير فيها حالة الموافقة. منذ TCF v2.2 هذه هي الطريقة الموصى بها للحصول على بيانات الموافقة؛ أما الأمر الأقدم getTCData فقد أصبح مهجورًا.

removeEventListener

يحمل كل كائن tcData قيمة listenerId. مرّرها إلى __tcfapi('removeEventListener', 2, callback, listenerId) حين لا يحتاج سكربتك إلى مزيد من التحديثات — كمحمّل يعمل مرة واحدة وقد اتخذ قراره بالفعل.

قراءة eventStatus

الحقل الأساسي في tcData هو eventStatus. له ثلاث قيم:

ينتظر المحمّل النموذجي إما tcloaded أو useractioncomplete، ثم يفحص الأغراض والمزوّدين الذين يحتاجهم. ويتجاهل cmpuishown إلا ربما لتسجيل أن بانرًا ظهر.

فحص الأغراض والمزوّدين

داخل tcData تُعرض الموافقة والمصلحة المشروعة ككائنات مفهرسة بالمعرّف:

افحص الغرض والمزوّد معًا. موافقة على الغرض دون موافقة المزوّد، أو العكس، لا تكفي لمعظم المزوّدين لمعالجة البيانات.

الإطارات المضمّنة والاستدعاءات عبر الإطارات

غالبًا ما تعمل الإعلانات والأدوات داخل iframes لا ترى __tcfapi الخاصة بالصفحة الأم. يحل TCF ذلك ببروتوكول postMessage: يضيف CMP إطارًا باسم __tcfapiLocator إلى الصفحة العليا، ويمكن للشيفرة داخل iframe تحديد موقعه وإرسال رسالة __tcfapiCall واستلام استجابة __tcfapiReturn. تفعل معظم حزم SDK الإعلانية ذلك أصلًا. وإذا كتبت شيفرة iframe خاصة بك فطبّق النمط نفسه بدلًا من قراءة ملفات تعريف الارتباط عبر الإطارات.

الأخطاء الشائعة وكيف تكتشفها

  1. التصرف بناءً على cmpuishown. السكربتات التي تُحمَّل بمجرد انطلاق أي callback ستعمل قبل أن يقرر المستخدم. صفِّ حسب eventStatus.
  2. إزالة المستمع مبكرًا جدًا. إذا أزلته بعد أول callback فستفوتك useractioncomplete لاحقة ولن يتم التحميل أبدًا.
  3. تجاهل حالات السحب. ينبغي للسكربتات الدائمة أن تواصل الاستماع وأن تتوقف أو تعيد ضبط نفسها عند سحب الموافقة.
  4. تجاهل gdprApplies. خارج مناطق TCF قد تكون كائنات الأغراض فارغة؛ واعتبار ذلك «لا موافقة» قد يوقف إيرادات يحق لك كسبها.
  5. عدم فحص مؤشر النجاح. عندما تكون قيمة success هي false فسجّل ذلك؛ فهو يشير عادةً إلى إعداد CMP معطوب.

اختبار التكامل لديك

في وحدة تحكم المتصفح، استدعِ __tcfapi('ping', 2, console.log) للتأكد من وجود CMP، ثم سجّل مستمعًا باستخدام console.log كـ callback وانقر عبر البانر. ينبغي أن ترى cmpuishown يليها useractioncomplete في الزيارة الأولى، وtcloaded عند إعادة التحميل. كرر ذلك مع قبول الكل ورفض الكل وتحديد مخصص، وتأكد من أن سكربتك يتصرف بشكل صحيح في كل حالة.

أهم النقاط

← المدونة قراءة الكل →