Tatizo la Mabango Mawili

Programu nyingi ni sehemu ya asili na sehemu ya wavuti. Mchezo huonyesha duka lake, habari au kurasa za usaidizi katika WebView; programu ya matumizi huonyesha makala kutoka tovuti yake; programu mseto hufunika sehemu kubwa ya kiolesura chake kwa maudhui ya wavuti. Kila upande una utaratibu wake wa idhini: programu ya asili hutumia CMP au SDK ndani ya programu, na kurasa za wavuti hupakia CMP ya wavuti. Zisipounganishwa, mtumiaji huulizwa mara mbili, chaguo zilizofanywa mahali pamoja hupuuzwa kwingine, na maombi ya matangazo kutoka ndani ya WebView hutoka na ishara zisizo sahihi.

Mwongozo huu unaeleza jinsi ya kufanya idhini ya asili na ya wavuti ikubaliane, ili watumiaji wajibu mara moja na kila ombi la tangazo lichukue uamuzi uleule.

Kila Upande Unahifadhi Idhini Wapi

Asili

IAB TCF inabainisha jinsi CMP ya ndani ya programu inavyohifadhi idhini: katika NSUserDefaults kwenye iOS na SharedPreferences kwenye Android, ikitumia funguo za kawaida kama IABTCF_TCString, IABTCF_gdprApplies na IABTCF_PurposeConsents. SDK za matangazo husoma funguo hizi moja kwa moja. IAB GPP inafafanua funguo zinazofanana zenye kiambishi awali cha IABGPP_, kama IABGPP_HDR_GppString.

Wavuti

CMP ya wavuti kwa kawaida huhifadhi uamuzi wake katika vidakuzi vya mhusika wa kwanza au hifadhi ya ndani ya kikoa cha tovuti, na huufichua kupitia vitendakazi vya JavaScript vya __tcfapi na __gpp. Lebo za matangazo kwenye ukurasa huita vitendakazi hivyo, si hifadhi ya asili.

Pengo

WebView zina nafasi yao ya vidakuzi na hifadhi, tofauti na kivinjari cha kifaa na tofauti na mapendeleo ya asili ya programu. Kwenye iOS, WKWebView inayotumia hifadhi ya data isiyo ya kudumu husahau kila kitu inapofungwa. Hakuna kinachotiririka kati ya pande hizi mbili isipokuwa uunde daraja.

Chagua Chanzo Kimoja cha Ukweli

Uamuzi wa kwanza ni upande upi unamiliki idhini. Kwa programu nyingi jibu ni CMP ya asili, kwa sababu:

• Inaendeshwa kwanza, kabla WebView yoyote haijafunguliwa.
• SDK za matangazo za asili, ambazo kwa kawaida hupata mapato mengi, husoma hifadhi ya asili.
• Kwenye iOS, inaweza kuratibiwa na ombi la App Tracking Transparency.

Njia ya wavuti kwanza inaweza kuwa na mantiki kwa programu mseto ambazo kiolesura chake chote ni maudhui ya wavuti, lakini basi lazima uandike uamuzi huo tena kwenye hifadhi ya asili kwa SDK za asili.

Kupitisha Idhini ya Asili Ndani ya WebView

Ukiwa na asili kama chanzo cha ukweli, WebView inahitaji kuona uamuzi uleule. Mifumo ya kawaida:

1. Ingiza utekelezaji wa __tcfapi. Kabla hati za ukurasa hazijaendeshwa, ingiza hati ndogo inayofafanua __tcfapi (na __gpp ikihitajika) na kujibu miito kwa TC string na thamani zilizosomwa kutoka hifadhi ya asili. Lebo za matangazo kwenye ukurasa kisha hupata uamuzi wa asili kupitia API ya kawaida.
2. Zuia bango la wavuti. Sanidi CMP ya wavuti ibaki imefichwa ukurasa unapopakiwa ndani ya programu yako, kwa mfano kulingana na kigezo cha hoja au tokeni maalum ya user agent unayoidhibiti. Vinginevyo mtumiaji ataona bango la pili.
3. Pitisha mfuatano wakati wa kupakia. Baadhi ya CMP za wavuti zinaweza kukubali mfuatano uliopo wa idhini wakati wa kuanza na kuutumia. Angalia nyaraka za CMP yako ya wavuti kwa mbinu zinazotumika.

Kwa mfumo wowote utakaotumia, hakikisha thamani zilizoingizwa zinasasishwa mtumiaji anapobadilisha chaguo lake kwenye skrini ya mipangilio ya asili, si tu programu itakapofunguliwa tena.

Kurudisha Idhini ya Wavuti kwa Asili

Ikiwa watumiaji wanaweza kubadilisha idhini ndani ya WebView, kwa mfano kupitia ukurasa wa mipangilio ya faragha, programu lazima ijue. Tumia daraja la JavaScript: kishughulikia ujumbe kwenye iOS au kiolesura cha JavaScript kwenye Android. Upande wa wavuti husikiliza kwa __tcfapi('addEventListener', ...) na kutuma mfuatano mpya kwa msimbo wa asili, ambao huandika funguo za kawaida. Thibitisha ingizo kutoka WebView kabla ya kuandika; kubali ujumbe kutoka kwa maudhui yako mwenyewe pekee.

Matangazo Ndani ya WebView

Matangazo yanayoonyeshwa katika WebView ni matangazo ya wavuti. Husoma idhini kutoka kwa ukurasa, si kutoka hifadhi ya asili, isipokuwa SDK ya matangazo itoe njia ya kuunganisha hizo mbili. Mobile Ads SDK ya Google, kwa mfano, hutoa API ya kusajili WebView ili matangazo ndani yake yaweze kutumia ishara kutoka kwa programu; angalia nyaraka za sasa za SDK yako. Kwa vyovyote vile, thibitisha kwa jaribio kwamba maombi ya matangazo kutoka WebView yanabeba TC string au GPP string ileile kama maombi ya matangazo ya asili.

Orodha ya Majaribio

• Usakinishaji mpya: ombi moja la idhini, si mawili.
• Kataa yote katika CMP ya asili, fungua WebView, kagua maombi ya matangazo: mfuatano unapaswa kuakisi kukataa.
• Badilisha idhini katika mipangilio ya asili, rudi kwenye WebView iliyo wazi: ukurasa unapaswa kuona uamuzi mpya.
• Ikiwa mipangilio ya wavuti ipo, badilisha idhini hapo na uthibitishe kwamba funguo za asili zinasasishwa.
• Funga na uanzishe upya programu: maamuzi hudumu pande zote mbili.
• Jaribu kwenye iOS na Android zote mbili, kwa kuwa hifadhi ya WebView hufanya kazi tofauti kwenye kila moja.

Mambo Muhimu ya Kukumbuka

• Idhini ya asili na ya WebView huishi katika hifadhi tofauti na hazisawazishwi kwa chaguomsingi.
• Chagua chanzo kimoja cha ukweli; kwa programu nyingi ni CMP ya asili.
• Fichua idhini ya asili kwa maudhui ya wavuti kupitia __tcfapi au __gpp iliyoingizwa na ufiche bango la wavuti.
• Tumia daraja la JavaScript kutuma mabadiliko ya wavuti kurudi kwenye hifadhi ya asili.
• Kagua kwamba maombi ya matangazo kutoka WebView yanabeba mfuatano ule ule wa idhini kama ya asili.