Праблема двайнога банера

Многія дадаткі часткова натыўныя, часткова вэб. Гульня паказвае краму, навіны або даведку ў 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 звычайна захоўвае сваё рашэнне ва ўласных (first-party) cookie або лакальным сховішчы для дамена сайта і прадастаўляе яго праз JavaScript-функцыі __tcfapi і __gpp. Рэкламныя тэгі на старонцы выклікаюць гэтыя функцыі, а не натыўнае сховішча.

Разрыў

У WebView ёсць уласная прастора cookie і сховішча, асобная ад браўзера прылады і ад натыўных налад дадатку. На iOS WKWebView з нястойкім сховішчам даных забывае ўсё пры закрыцці. Паміж двума бакамі нічога не перадаецца, калі вы самі гэтага не пабудуеце.

Абярыце адну крыніцу ісціны

Першае рашэнне — які бок валодае згодай. Для большасці дадаткаў адказ — натыўны CMP, таму што:

• Ён запускаецца першым, да адкрыцця любога WebView.
• Натыўныя рэкламныя SDK, якія звычайна прыносяць асноўны даход, чытаюць натыўнае сховішча.
• На iOS яго можна скаардынаваць з запытам App Tracking Transparency.

Прыярытэт вэбу можа мець сэнс для гібрыдных дадаткаў, увесь інтэрфейс якіх — вэб-кантэнт, але тады рашэнне давядзецца запісваць назад у натыўнае сховішча для натыўных SDK.

Перадача натыўнай згоды ў WebView

Калі крыніца ісціны — натыўны бок, WebView павінен бачыць тое самае рашэнне. Распаўсюджаныя шаблоны:

1. Укараніць рэалізацыю __tcfapi. Да запуску скрыптоў старонкі ўкараніце невялікі скрыпт, што вызначае __tcfapi (і __gpp, калі трэба) і адказвае на выклікі TC string і значэннямі, прачытанымі з натыўнага сховішча. Рэкламныя тэгі на старонцы тады атрымліваюць натыўнае рашэнне праз стандартны API.
2. Схаваць вэб-банер. Наладзьце вэб-CMP так, каб ён не паказваўся, калі старонка загружана ўнутры вашага дадатку, напрыклад па параметры запыту або ўласным токене user agent, які вы кантралюеце. Інакш карыстальнік убачыць другі банер.
3. Перадаць радок пры загрузцы. Некаторыя вэб-CMP могуць прыняць існуючы радок згоды падчас ініцыялізацыі і выкарыстаць яго. Падтрымліваемыя метады шукайце ў дакументацыі вашага вэб-CMP.

Які б шаблон вы ні абралі, пераканайцеся, што ўкараняемыя значэнні абнаўляюцца, калі карыстальнік змяняе выбар на натыўным экране налад, а не толькі пры наступным запуску дадатку.

Перадача вэб-згоды назад у натыўны дадатак

Калі карыстальнікі могуць змяняць згоду ўнутры WebView, напрыклад на старонцы налад прыватнасці, дадатак павінен пра гэта даведацца. Выкарыстоўвайце JavaScript-мост: апрацоўшчык паведамленняў на iOS або JavaScript-інтэрфейс на Android. Вэб-бок слухае праз __tcfapi('addEventListener', ...) і адпраўляе новы радок натыўнаму коду, які запісвае стандартныя ключы. Правярайце даныя з WebView перад запісам; прымайце паведамленні толькі ад вашага ўласнага кантэнту.

Рэклама ўнутры WebView

Рэклама, што адлюстроўваецца ў WebView, з'яўляецца вэб-рэкламай. Яна чытае згоду са старонкі, а не з натыўнага сховішча, калі толькі рэкламны SDK не дае спосаб звязаць іх. Напрыклад, Google Mobile Ads SDK прапануе API для рэгістрацыі WebView, каб рэклама ўнутры іх магла выкарыстоўваць сігналы дадатку; актуальную дакументацыю для вашага SDK глядзіце асобна. У любым выпадку тэстам пераканайцеся, што рэкламныя запыты з WebView нясуць той самы радок TC або GPP, што і натыўныя рэкламныя запыты.

Чэк-ліст тэсціравання

• Свежая ўстаноўка: адзін запыт згоды, а не два.
• Адхіліце ўсё ў натыўным CMP, адкрыйце WebView, вывучыце рэкламныя запыты: радок павінен адлюстроўваць адмову.
• Змяніце згоду ў натыўных наладах, вярніцеся ў адкрыты WebView: старонка павінна ўбачыць новае рашэнне.
• Калі ёсць вэб-налады, змяніце згоду там і пераканайцеся, што натыўныя ключы абнавіліся.
• Прымусова закрыйце і нанова запусціце дадатак: рашэнні захоўваюцца з абодвух бакоў.
• Тэстуйце і на iOS, і на Android, бо сховішча WebView паводзіць сябе на іх па-рознаму.

Галоўныя высновы

• Натыўная згода і згода WebView жывуць у розных сховішчах і па змаўчанні не сінхранізуюцца.
• Абярыце адну крыніцу ісціны; для большасці дадаткаў гэта натыўны CMP.
• Перадайце натыўную згоду вэб-кантэнту праз укараняемыя __tcfapi або __gpp і схавайце вэб-банер.
• Выкарыстоўвайце JavaScript-мост, каб адпраўляць вэб-змены назад у натыўнае сховішча.
• Праверце, што рэкламныя запыты з WebView нясуць той самы радок згоды, што і натыўныя.