ორმაგი ბანერის პრობლემა

ბევრი აპი ნაწილობრივ ნატიურია და ნაწილობრივ ვებ. თამაში თავის მაღაზიას, სიახლეებს ან დახმარების გვერდებს WebView-ში აჩვენებს; უტილიტა-აპი თავისი საიტიდან სტატიებს ხატავს; ჰიბრიდული აპი ინტერფეისის უმეტეს ნაწილს ვებ კონტენტში ახვევს. თითოეულ მხარეს საკუთარი თანხმობის მექანიზმი აქვს: ნატიური აპი აპშიდა CMP-ს ან SDK-ს იყენებს, ვებ გვერდები კი ვებ CMP-ს ტვირთავს. თუ ისინი დაკავშირებული არ არის, მომხმარებელს ორჯერ ეკითხებიან, ერთ ადგილას გაკეთებულ არჩევანს მეორეგან უგულებელყოფენ, ხოლო WebView-ს შიგნიდან გაგზავნილი სარეკლამო მოთხოვნები არასწორი სიგნალებით გადის.

ეს სახელმძღვანელო აღწერს, როგორ შეათანხმოთ ნატიური და ვებ თანხმობა, რათა მომხმარებლებმა ერთხელ უპასუხონ და ყოველი სარეკლამო მოთხოვნა ერთსა და იმავე გადაწყვეტილებას ატარებდეს.

სად ინახავს თითოეული მხარე თანხმობას

ნატიური

IAB TCF განსაზღვრავს, როგორ ინახავს აპშიდა CMP თანხმობას: iOS-ზე NSUserDefaults-ში და Android-ზე SharedPreferences-ში, სტანდარტული გასაღებებით, როგორიცაა IABTCF_TCString, IABTCF_gdprApplies და IABTCF_PurposeConsents. სარეკლამო SDK-ები ამ გასაღებებს პირდაპირ კითხულობენ. IAB GPP მსგავს გასაღებებს განსაზღვრავს IABGPP_ პრეფიქსით, მაგალითად, IABGPP_HDR_GppString.

ვებ

ვებ CMP თავის გადაწყვეტილებას ჩვეულებრივ საიტის დომენის first-party ქუქი-ფაილებში ან ლოკალურ საცავში ინახავს და მას JavaScript ფუნქციებით __tcfapi და __gpp ამჟღავნებს. გვერდზე არსებული სარეკლამო თეგები ამ ფუნქციებს იძახებენ და არა ნატიურ საცავს.

ხარვეზი

WebView-ებს ქუქი-ფაილებისა და საცავის საკუთარი სივრცე აქვთ, მოწყობილობის ბრაუზერისგან განცალკევებული და აპის ნატიური პარამეტრებისგან განცალკევებული. iOS-ზე WKWebView, რომელიც არამუდმივ მონაცემთა საცავს იყენებს, დახურვისას ყველაფერს ივიწყებს. ორ მხარეს შორის არაფერი მოძრაობს, სანამ თავად არ ააგებთ.

აირჩიეთ ჭეშმარიტების ერთი წყარო

პირველი გადაწყვეტილებაა, რომელი მხარეა თანხმობის მფლობელი. აპების უმეტესობისთვის პასუხია ნატიური CMP, რადგან:

• ის პირველი გადის, ნებისმიერი WebView-ის გახსნამდე.
• ნატიური სარეკლამო SDK-ები, რომლებიც ჩვეულებრივ შემოსავლის უმეტეს ნაწილს გამოიმუშავებს, ნატიურ საცავს კითხულობენ.
• iOS-ზე მისი კოორდინაცია App Tracking Transparency მოთხოვნასთან შეიძლება.

ვებ-პირველი მიდგომა შეიძლება აზრიანი იყოს ჰიბრიდული აპებისთვის, რომელთა მთელი ინტერფეისი ვებ კონტენტია, მაგრამ მაშინ გადაწყვეტილება ნატიურ საცავში უკან უნდა ჩაწეროთ ნატიური SDK-ებისთვის.

ნატიური თანხმობის გადაცემა WebView-ში

როცა ჭეშმარიტების წყარო ნატიურია, WebView-მ იგივე გადაწყვეტილება უნდა დაინახოს. გავრცელებული შაბლონები:

1. ჩაშალეთ __tcfapi-ის იმპლემენტაცია. გვერდის სკრიპტების გაშვებამდე ჩაშალეთ პატარა სკრიპტი, რომელიც განსაზღვრავს __tcfapi-ს (და საჭიროების შემთხვევაში __gpp-ს) და გამოძახებებს პასუხობს TC string-ით და ნატიური საცავიდან წაკითხული მნიშვნელობებით. გვერდზე არსებული სარეკლამო თეგები ნატიურ გადაწყვეტილებას სტანდარტული API-ით იღებენ.
2. ჩახშეთ ვებ ბანერი. დააკონფიგურირეთ ვებ CMP, რომ დამალული დარჩეს, როცა გვერდი თქვენს აპში იტვირთება, მაგალითად, query პარამეტრის ან თქვენ მიერ კონტროლირებადი მორგებული 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-დან სარეკლამო მოთხოვნები ნატიურების იმავე თანხმობის სტრიქონს ატარებს.