مشكلة البانر المزدوج

كثير من التطبيقات أصلية جزئيًا وويب جزئيًا. تعرض لعبة متجرها أو أخبارها أو صفحات المساعدة في WebView؛ ويعرض تطبيق أدوات مقالات من موقعه؛ ويغلّف تطبيق هجين معظم واجهته بمحتوى ويب. ولكل جانب آلية موافقة خاصة: يستخدم التطبيق الأصلي CMP أو SDK داخل التطبيق، وتحمّل صفحات الويب CMP للويب. وما لم يُربط الجانبان، يُسأل المستخدم مرتين، وتُتجاهل الخيارات المتخذة في أحدهما في الآخر، وتخرج طلبات الإعلانات من داخل WebView بإشارات خاطئة.

يتناول هذا الدليل كيف تجعل الموافقة الأصلية وموافقة الويب متفقتين، ليجيب المستخدمون مرة واحدة ويحمل كل طلب إعلان القرار نفسه.

أين يخزّن كل جانب الموافقة

الأصلي

تحدد IAB TCF كيف يخزّن CMP داخل التطبيق الموافقة: في NSUserDefaults على iOS وSharedPreferences على Android، باستخدام مفاتيح قياسية مثل IABTCF_TCString وIABTCF_gdprApplies وIABTCF_PurposeConsents. وتقرأ حزم SDK الإعلانية هذه المفاتيح مباشرة. وتحدد IAB GPP مفاتيح مشابهة بالبادئة IABGPP_، مثل IABGPP_HDR_GppString.

الويب

يخزّن CMP للويب قراره عادةً في ملفات تعريف ارتباط من الطرف الأول أو التخزين المحلي لنطاق الموقع، ويعرضه عبر دالتي JavaScript ‏__tcfapi و__gpp. وتستدعي وسوم الإعلانات في الصفحة هاتين الدالتين، لا التخزين الأصلي.

الفجوة

لدى WebViews مساحتها الخاصة لملفات تعريف الارتباط والتخزين، منفصلة عن متصفح الجهاز وعن تفضيلات التطبيق الأصلية. وعلى iOS، يفقد WKWebView الذي يستخدم مخزن بيانات غير دائم كل شيء عند إغلاقه. ولا يتدفق شيء بين الجانبين ما لم تبنِ ذلك بنفسك.

اختر مصدرًا واحدًا للحقيقة

القرار الأول هو أي جانب يملك الموافقة. بالنسبة لمعظم التطبيقات الإجابة هي CMP الأصلي، لأن:

• يعمل أولًا، قبل فتح أي WebView.
• حزم SDK الإعلانية الأصلية، التي تحقق عادةً معظم الإيرادات، تقرأ التخزين الأصلي.
• يمكن في iOS تنسيقه مع نافذة App Tracking Transparency.

قد يكون الويب أولًا منطقيًا للتطبيقات الهجينة التي تكون واجهتها كلها محتوى ويب، لكن عندها يجب أن تكتب القرار مجددًا في التخزين الأصلي لحزم SDK الأصلية.

تمرير الموافقة الأصلية إلى WebView

حين يكون الأصلي هو مصدر الحقيقة، يحتاج WebView إلى رؤية القرار نفسه. الأنماط الشائعة:

1. حقن تنفيذ لـ __tcfapi. قبل تشغيل سكربتات الصفحة، احقن سكربتًا صغيرًا يعرّف __tcfapi (و__gpp إذا لزم) ويجيب عن الاستدعاءات بسلسلة TC والقيم المقروءة من التخزين الأصلي. وبذلك تحصل وسوم الإعلانات في الصفحة على القرار الأصلي عبر الواجهة القياسية.
2. إخفاء بانر الويب. اضبط CMP للويب على البقاء مخفيًا عند تحميل الصفحة داخل تطبيقك، مثلًا بناءً على معامل في الاستعلام أو رمز مخصص في user agent تتحكم به. وإلا يرى المستخدم بانرًا ثانيًا.
3. تمرير السلسلة عند التحميل. تستطيع بعض أنظمة CMP للويب قبول سلسلة موافقة موجودة عند التهيئة واعتمادها. راجع وثائق CMP للويب لديك لمعرفة الطرق المدعومة.

أيًّا كان النمط الذي تستخدمه، تأكد من أن القيم المحقونة تتحدث عندما يغيّر المستخدم اختياره في شاشة الإعدادات الأصلية، لا عند الإطلاق التالي للتطبيق فقط.

إعادة موافقة الويب إلى الأصلي

إذا استطاع المستخدمون تغيير الموافقة داخل WebView، مثلًا عبر صفحة إعدادات الخصوصية، فيجب أن يعلم التطبيق بذلك. استخدم جسر JavaScript: معالج رسائل على iOS أو واجهة JavaScript على Android. يستمع جانب الويب عبر __tcfapi('addEventListener', ...) ويرسل السلسلة الجديدة إلى الشيفرة الأصلية، التي تكتب المفاتيح القياسية. تحقق من المدخلات القادمة من WebView قبل كتابتها؛ ولا تقبل إلا الرسائل الصادرة من محتواك أنت.

الإعلانات داخل WebViews

الإعلانات المعروضة في WebView هي إعلانات ويب. تقرأ الموافقة من الصفحة، لا من التخزين الأصلي، ما لم توفر حزمة SDK الإعلانية طريقة للربط بينهما. فمثلًا تقدم حزمة Google Mobile Ads SDK واجهة لتسجيل WebViews بحيث تستطيع الإعلانات داخلها استخدام إشارات التطبيق؛ راجع الوثائق الحالية لحزمة SDK لديك. وفي كل الأحوال، تأكد باختبار من أن طلبات الإعلانات من WebView تحمل سلسلة TC أو GPP نفسها التي تحملها طلبات الإعلانات الأصلية.

قائمة تحقق الاختبار

• تثبيت جديد: نافذة موافقة واحدة، لا اثنتان.
• ارفض الكل في CMP الأصلي، وافتح WebView، وافحص طلبات الإعلانات: ينبغي أن تعكس السلسلة الرفض.
• غيّر الموافقة في الإعدادات الأصلية، وعد إلى WebView مفتوح: ينبغي أن ترى الصفحة القرار الجديد.
• إذا وُجدت إعدادات ويب، غيّر الموافقة فيها وتأكد من تحديث المفاتيح الأصلية.
• أغلق التطبيق وأعد تشغيله: تستمر القرارات على الجانبين.
• اختبر على iOS وAndroid معًا، لأن تخزين WebView يتصرف بشكل مختلف في كل منهما.

أهم النقاط

• تعيش الموافقة الأصلية وموافقة WebView في مخزنين منفصلين ولا تتزامنان افتراضيًا.
• اختر مصدرًا واحدًا للحقيقة؛ وهو لدى معظم التطبيقات CMP الأصلي.
• اعرض الموافقة الأصلية لمحتوى الويب عبر __tcfapi أو __gpp محقونتين، وأخفِ بانر الويب.
• استخدم جسر JavaScript لإرسال تغييرات الويب إلى التخزين الأصلي.
• تحقق من أن طلبات الإعلانات من WebViews تحمل سلسلة الموافقة نفسها التي تحملها الطلبات الأصلية.