İkiqat banner problemi

Bir çox tətbiq qismən native, qismən vebdir. Oyun mağazasını, xəbərlərini və ya kömək səhifələrini WebView-də göstərir; utilit tətbiqi məqalələri saytından render edir; hibrid tətbiq interfeysinin çoxunu veb məzmuna sarıyır. Hər tərəfin öz razılıq mexanizmi var: native tətbiq tətbiqdaxili CMP və ya SDK istifadə edir, veb səhifələr isə veb CMP yükləyir. Bunlar əlaqələndirilməzsə, istifadəçidən iki dəfə soruşulur, bir yerdə edilən seçimlər digərində nəzərə alınmır və WebView daxilindən gedən reklam sorğuları yanlış siqnallarla çıxır.

Bu bələdçi native və veb razılığının necə uyğunlaşdırılacağını əhatə edir ki, istifadəçilər bir dəfə cavab versin və hər reklam sorğusu eyni qərarı daşısın.

Hər tərəf razılığı harada saxlayır

Native

IAB TCF tətbiqdaxili CMP-nin razılığı necə saxladığını müəyyən edir: iOS-da NSUserDefaults-da və Android-də SharedPreferences-də, IABTCF_TCString, IABTCF_gdprApplies və IABTCF_PurposeConsents kimi standart açarlarla. Reklam SDK-ları bu açarları birbaşa oxuyur. IAB GPP IABGPP_ prefiksi ilə oxşar açarlar müəyyən edir, məsələn IABGPP_HDR_GppString.

Veb

Veb CMP qərarını adətən saytın domeni üçün first-party cookie-lərdə və ya lokal yaddaşda saxlayır və onu __tcfapi və __gpp JavaScript funksiyaları ilə təqdim edir. Səhifədəki reklam teqləri native yaddaşı yox, bu funksiyaları çağırır.

Boşluq

WebView-lərin cihaz brauzerindən və tətbiqin native parametrlərindən ayrı, öz cookie və yaddaş sahəsi var. iOS-da qalıcı olmayan data store istifadə edən WKWebView bağlananda hər şeyi unudur. Özünüz qurmasanız, iki tərəf arasında heç nə axmır.

Bir həqiqət mənbəyi seçin

İlk qərar razılığın hansı tərəfə məxsus olmasıdır. Əksər tətbiqlər üçün cavab native CMP-dir, çünki:

• O, hər hansı WebView açılmazdan əvvəl birinci işləyir.
• Adətən gəlirin çoxunu qazanan native reklam SDK-ları native yaddaşı oxuyur.
• iOS-da onu App Tracking Transparency sorğusu ilə əlaqələndirmək olar.

Veb-birinci yanaşma interfeysinin hamısı veb məzmun olan hibrid tətbiqlər üçün məntiqli ola bilər, lakin bu halda qərarı native SDK-lar üçün native yaddaşa geri yazmalısınız.

Native razılığı WebView-ə ötürmək

Native həqiqət mənbəyi olduqda, WebView eyni qərarı görməlidir. Ümumi nümunələr:

1. __tcfapi implementasiyasını inyeksiya edin. Səhifənin skriptləri işləməzdən əvvəl __tcfapi-ni (lazım gələrsə __gpp-ni) müəyyən edən və çağırışlara TC string və native yaddaşdan oxunmuş dəyərlərlə cavab verən kiçik skript inyeksiya edin. Səhifədəki reklam teqləri native qərarı standart API vasitəsilə alır.
2. Veb banneri sıxışdırın. Səhifə tətbiqiniz daxilində yüklənəndə veb CMP-ni gizli qalacaq şəkildə konfiqurasiya edin, məsələn, query parametri və ya nəzarət etdiyiniz fərdi user agent tokeni əsasında. Əks halda istifadəçi ikinci banneri görür.
3. Sətri yükləmə zamanı ötürün. Bəzi veb CMP-lər inisializasiya zamanı mövcud razılıq sətrini qəbul edib mənimsəyə bilər. Dəstəklənən üsullar üçün veb CMP-nizin sənədlərini yoxlayın.

Hansı nümunədən istifadə etsəniz də, inyeksiya edilmiş dəyərlərin istifadəçi native parametrlər ekranında seçimini dəyişdikdə yeniləndiyinə əmin olun, yalnız tətbiqin növbəti açılışında yox.

Veb razılığını native-ə geri ötürmək

İstifadəçilər razılığı WebView daxilində, məsələn, məxfilik parametrləri səhifəsi vasitəsilə dəyişə bilirsə, tətbiq bunu bilməlidir. JavaScript körpüsündən istifadə edin: iOS-da message handler və ya Android-də JavaScript interfeysi. Veb tərəf __tcfapi('addEventListener', ...) ilə dinləyir və yeni sətri standart açarları yazan native koda göndərir. WebView-dən gələn girişi yazmadan əvvəl yoxlayın; mesajları yalnız öz məzmununuzdan qəbul edin.

WebView-lərdə reklamlar

WebView-də render edilən reklamlar veb reklamlardır. Reklam SDK-sı ikisini əlaqələndirmək yolu təmin etməyibsə, onlar razılığı native yaddaşdan yox, səhifədən oxuyur. Məsələn, Google-ın Mobile Ads SDK-sı WebView-ləri qeydiyyatdan keçirmək üçün API təklif edir ki, onların içindəki reklamlar tətbiqdən gələn siqnallardan istifadə edə bilsin; SDK-nız üçün cari sənədləri yoxlayın. Hər halda, sınaqla təsdiqləyin ki, WebView-dən gələn reklam sorğuları native reklam sorğuları ilə eyni TC və ya GPP sətrini daşıyır.

Sınaq çek-listi

• Təmiz quraşdırma: iki yox, bir razılıq sorğusu.
• Native CMP-də hamısını rədd edin, WebView açın, reklam sorğularını yoxlayın: sətir rədd etməni əks etdirməlidir.
• Native parametrlərdə razılığı dəyişin, açıq WebView-ə qayıdın: səhifə yeni qərarı görməlidir.
• Veb parametrlər varsa, orada razılığı dəyişin və native açarların yeniləndiyini təsdiqləyin.
• Tətbiqi söndürüb yenidən açın: qərarlar hər iki tərəfdə qalır.
• Həm iOS, həm Android-də sınayın, çünki WebView yaddaşı hər birində fərqli davranır.

Əsas nəticələr

• Native və WebView razılığı ayrı yaddaşlarda yaşayır və susmaya görə sinxronlaşmır.
• Bir həqiqət mənbəyi seçin; əksər tətbiqlər üçün bu native CMP-dir.
• Native razılığı inyeksiya edilmiş __tcfapi və ya __gpp vasitəsilə veb məzmuna açın və veb banneri gizlədin.
• Veb dəyişikliklərini native yaddaşa geri göndərmək üçün JavaScript körpüsündən istifadə edin.
• WebView-lərdən gələn reklam sorğularının native sorğularla eyni razılıq sətrini daşıdığını yoxlayın.