რატომ არის PWA თანხმობის სასაზღვრო შემთხვევა

პროგრესული ვებ-აპლიკაცია იქცევა როგორც მშობლიური აპლიკაცია — ის ინსტალირდება მთავარ ეკრანზე, მუშაობს ოფლაინ და აგრესიულად ქეშავს — მაგრამ ის მაინც ბრაუზერიდან მიეწოდება, ამიტომ მოქმედებს cookie-ებისა და ვებ-შენახვის წესები. სწორედ ეს ჰიბრიდული ბუნება აბნევს გამომცემლებს: იგივე GDPR თანხმობის ვალდებულებები, რაც ნებისმიერ ვებსაიტს, დაფენილი service worker-ებსა და მუდმივ ქეშებზე, რომლებსაც შეუძლიათ ჩუმად შეინახონ მონაცემები და სკრიპტები მას შემდეგ, რაც მომხმარებელმა თქვა არა.

სად ინახავენ PWA-ები მონაცემებს

სანამ შენახვას თანხმობით შეზღუდავთ, უნდა იცოდეთ ყველა ადგილი, სადაც PWA-ს შეუძლია მონაცემების შენახვა:

• Cookie-ები — კლასიკური ზედაპირი, რომელსაც, როგორც ყოველთვის, თანხმობა მართავს.
• LocalStorage / IndexedDB — ხშირად გამოიყენება აპლიკაციის მდგომარეობისთვის, მაგრამ ასევე ანალიტიკისა და სარეკლამო იდენტიფიკატორებისთვის.
• Cache Storage — service worker-ს შეუძლია მესამე მხარის სკრიპტების (ანალიტიკა, სარეკლამო SDK-ები) ქეშირება, რათა ისინი ოფლაინაც კი მუშაობდნენ.
• თავად service worker — ნარჩუნდება სესიების მიღმა და შეუძლია თვალთვალის ხელახალი რეგისტრაცია შემდეგ გაშვებაზე.

თანხმობამ უნდა მართოს ეს ყველაფერი, არა მხოლოდ document.cookie.

თანხმობა-პირველი service worker-ის შაბლონი

ძირითადი პრინციპი: service worker-მა უნდა წაიკითხოს თანხმობის მდგომარეობა, სანამ ქეშავს ან ასრულებს რომელიმე არააუცილებელ მესამე მხარის რესურსს. სუფთა შაბლონი ასე გამოიყურება:

• შეინახეთ თანხმობის სიგნალი იქ, სადაც service worker-ს შეუძლია მისი წაკითხვა — IndexedDB ან ქეშის ჩანაწერი, რომელსაც CMP ყოველ არჩევანზე ანახლებს.
• service worker-ის fetch დამმუშავებელში უარი თქვით ანალიტიკის/რეკლამის ბოლოწერტილების ქეშირებაზე, თუ ამ მიზნისთვის თანხმობა არ არსებობს.
• როდესაც მომხმარებელი თანხმობას უკან იბრუნებს, გაუგზავნეთ შეტყობინება service worker-ს, რომ გაასუფთაოს ქეშირებული თვალთვალის სკრიპტები და გაასუფთაოს შესაბამისი IndexedDB საცავები.

ამ ბოლო ნაბიჯის გამოტოვება PWA-ს შესაბამისობის ყველაზე გავრცელებული ხარვეზია: ბანერი ამბობს “უარყოფილია,” მაგრამ ქეშირებული ანალიტიკის სკრიპტი აგრძელებს გააქტიურებას service worker-იდან შემდეგ ოფლაინ გაშვებაზე.

ოფლაინ თანხმობის UX

PWA-ებს შეუძლიათ გაშვება ქსელის გარეშე. თქვენი თანხმობის ბანერი და მომხმარებლის შენახული არჩევანი ორივე უნდა მუშაობდეს ოფლაინ — დააქეშეთ თავად CMP ინტერფეისი და არასოდეს დაუბრუნდეთ ნაგულისხმევად “მინიჭებულს” მხოლოდ იმიტომ, რომ თანხმობის სერვერი მიუწვდომელია. თუ წინა არჩევანის დადასტურება ვერ შეგიძლიათ, მომხმარებელი მიიჩნიეთ თანხმობის არმიმცემად და მიაწოდეთ მხოლოდ აუცილებელი ფუნქციონალი, სანამ ვერ შეძლებთ.

სარეკლამო შემოსავლის შედეგები

რეკლამით მხარდაჭერილი PWA-ებისთვის თანხმობის მდგომარეობამ უნდა მიაღწიოს თქვენს სარეკლამო SDK-ს მოთხოვნის დროს, ონლაინ თუ ოფლაინ. სწორად შეერთებული PWA გადასცემს IAB TCF სტრიქონს და Consent Mode v2 სიგნალებს მოთხოვნის პარტნიორებს ისევე, როგორც ჩვეულებრივი საიტი; არასწორად კონფიგურირებული ქეშავს მოძველებულ “თანხმობის გარეშე” მდგომარეობას და თქვენს eCPM-ს განუსაზღვრელი ვადით ანგრევს არაპერსონალიზებულ ტარიფებამდე. თანხმობის სიახლე მიიჩნიეთ შემოსავლის მეტრიკად.

როგორ ეხმარება FlexyConsent

FlexyConsent ინახავს თანხმობის ჩანაწერს service worker-ისთვის წაკითხვად საცავში, გამოსცემს TCF და Consent Mode v2 სიგნალებს, რომლებიც გადარჩებიან ოფლაინ გაშვებებს, და ააშკარავებს უკან გამოთხოვის ჰუკს, რომელიც ქეშის გასუფთავებას შეგიძლიათ დაუკავშიროთ — რათა თქვენი PWA დარჩეს შესაბამისი და თქვენმა სარეკლამო სტეკმა შეინარჩუნოს მაქსიმალურად ახალი თანხმობის სიგნალი ყველა ზედაპირზე.

ძირითადი დასკვნები

• PWA-ები აწყდებიან GDPR თანხმობის სრულ ვალდებულებებს, პლუს service worker-ისა და ქეშის გართულებებს.
• შეზღუდეთ cookie-ები, LocalStorage, IndexedDB და Cache Storage თანხმობით — არა მხოლოდ cookie-ები.
• უკან გამოთხოვისას გაასუფთავეთ ქეშირებული თვალთვალის სკრიპტები და წაშალეთ შენახული იდენტიფიკატორები.
• შეინარჩუნეთ თანხმობის მდგომარეობა ახალი და ოფლაინ-უსაფრთხო, რათა სარეკლამო შემოსავალი არ გაჭედილიყო არაპერსონალიზებულ ტარიფებზე.