რას ნამდვილად ცვლის Privacy Sandbox

მესამე მხარის ქუქიებს ოთხი განსხვავებული სარეკლამო ფუნქცია ჰქონდა: ინტერესზე დაფუძნებული ტარგეტინგი, რეტარგეტინგი, კონვერსიის გაზომვა და სიხშირის შეზღუდვა. Privacy Sandbox ამ ფუნქციებს ცალკეულ API-ებად ჰყოფს, თითოეულს თავისი თანხმობის პროფილით.

Topics API — ინტერესზე დაფუძნებული ტარგეტინგი

Topics API-ი თითოეულ ბრაუზერს ანიჭებს მსხვილმარცვლოვანი ინტერეს თემების პატარა ნაკრებს — დაახლოებით კვირაში ხუთი თემა, რამდენიმე ასეული კატეგორიის კურირებული ტაქსონომიიდან. როდესაც გამომცემელი ეძახის document.browsingTopics()-ს, ბრაუზერი აბრუნებს მაქსიმუმ სამ თემას, რომელიც ad tech-ის ეკოსისტემას შეუძლია გამოიყენოს კონტექსტური პერსონალიზებისთვის ნებისმიერი საიტებს შორის იდენტიფიკატორის გარეშე. თემები ლოკალურად გამოითვლება, მოწყობილობაზე ინახება, ყოველ კვირას ტრიალებს და ექვემდებარება მომხმარებლის კონტროლს chrome://settings/adPrivacy-ში.

Protected Audience API — რეტარგეტინგი და რემარკეტინგი

Protected Audience, ადრე FLEDGE, რეტარგეტინგს ცოცხლად ინარჩუნებს გაზიარებული საიტებს შორის იდენტიფიკატორის გარეშე. რეკლამის განმთავსებლები მომხმარებელს ინტერეს ჯგუფს ამატებენ თავიანთ საიტზე; როდესაც მომხმარებელი ეწვევა მონაწილე გამომცემელს, მოწყობილობაზე აუქციონი Fenced Frame-ში მიმდინარეობს და ირჩევს კრეატივს. გამარჯვებული რეკლამა რენდერდება გამომცემლის ცოდნის გარეშე, რომელი ინტერეს ჯგუფი შეესაბამა.

Attribution Reporting API — კონვერსიის გაზომვა

Attribution Reporting ცვლის კონვერსიის პიქსელებს გაზომვის გამოყენების შემთხვევების ქვეჯგუფისთვის. ის მხარს უჭერს მოვლენის დონის ანგარიშებს (ხმაური, დანაკარგი, კონვერსიაზე) და ჯამური შეჯამების ანგარიშებს (სტატისტიკურად მიუკერძოებელი შეჯამებები). ძველი პიქსელისგან განსხვავებით, ის არ ამჟღავნებს ინდივიდუალური მომხმარებლიდან კონვერსიის კავშირს.

Shared Storage და Fenced Frames

Shared Storage არის ნებისმიერ ადგილას ჩასაწერი, sandbox-ში წასაკითხი გასაღები-მნიშვნელობის საცავი საიტებს შორის გამოყენების შემთხვევებისთვის, როგორიცაა სიხშირის შეზღუდვა და A/B ექსპერიმენტის თანმიმდევრულობა. Fenced Frames არის იზოლირებული iframe-ები, რომლებიც ხელს უშლის გარშემო გვერდს წაიკითხოს რენდერული რეკლამა ან მისი ინტერაქციის მონაცემები.

Privacy Sandbox-ს სჭირდება თანხმობა?

ეს 2026 წლის ad tech ლანდშაფტში ყველაზე გაუგებარი კითხვაა, და პასუხი იურისდიქციაზე დამოკიდებულია.

GDPR და ePrivacy-ს მიხედვით

ევროპული მონაცემთა დაცვის საბჭომ ზოგადი პოზიცია არ გამოუქვეყნებია, მაგრამ ეროვნული ორგანოები უფრო მკაფიო იყვნენ. UK ICO, იტალიური Garante და საფრანგეთის CNIL-ი ყველა მიიჩნევს, რომ Topics-ს და Protected Audience-ს სჭირდება წინასწარი opt-in თანხმობა პირადი მონაცემების დამუშავების შემთხვევაში, მათ შორის ნებისმიერი დამუშავება, რომელიც მომხმარებლის მოწყობილობაზე მდგომარეობას წერს ან კითხულობს. ლოგიკა: ბრაუზერი კვლავ ლოკალურად ინახავს ინტერეს თემებს და ინტერეს ჯგუფებს, და document.browsingTopics()-ს გამოძახება გამოყვანილ პირად მონაცემებს მესამე მხარეს გადასცემს. ეს რეგულირდება ePrivacy დირექტივის მუხლი 5(3)-ით, რომელიც მოითხოვს თანხმობას მომხმარებლის ტერმინალ აღჭურვილობაზე ნებისმიერი წვდომისთვის ან შენახვისთვის, თუ ეს მოთხოვნილი სერვისისთვის მკაცრად საჭირო არ არის.

Google-ის პოზიცია უფრო შემოვლითია — ისინი ამტკიცებენ, რომ API-ები კონფიდენციალობის დამცავი დიზაინით არის შექმნილი და თანხმობის მოთხოვნები ყველა კონტექსტში არ გამოიყენება. ეს არ არის მარეგულირებლის პოზიცია. Privacy Sandbox-ის თანხმობისგან გათავისუფლებული ევროპაში განხილვა მაღალი რისკის პოზაა.

CCPA, CPRA და აშშ სახელმწიფო კანონების მიხედვით

შეერთებულ შტატებში, Privacy Sandbox-ის ნაკადები, როგორც წესი, განიხილება CPRA-ს მიხედვით კონტექსტთაშორისი ქცევითი რეკლამისთვის პირადი ინფორმაციის გაზიარებად. ეს ნიშნავს, რომ ისინი იწვევენ opt-out უფლებას და უნდა დაცული იყოს Global Privacy Control სიგნალებისა და სხვა უნივერსალური opt-out მექანიზმების მეშვეობით. ის ფაქტი, რომ Topics მონაცემები ბრაუზერიდან არის მიღებული და არა მესამე მხარის ბროკერისგან გაყიდული, მათ არ ათავისუფლებს.

Chrome-ის საკუთარი კონტროლები

Chrome გვთავაზობს მომხმარებელზე ორიენტირებულ გადართვებს chrome://settings/adPrivacy-ში Topics, Protected Audience და Attribution Reporting-ისთვის. ეს მომხმარებლის არჩევანები CMP-ის თანხმობის მდგომარეობის გვერდით — არა მის ნაცვლად — დგას. მომხმარებელი, რომელმაც სარეკლამო ქუქიებზე უარი თქვა თქვენს ბანერში, მაგრამ Topics-ზე დათანხმდა Chrome-ის გლობალურ პარამეტრებში, მაინც გითხრათ უარი ბანერის მეშვეობით. თქვენი სტეკი ორი სიგნალიდან უფრო მკაცრს უნდა პატივს სცემდეს.

თანხმობის ფენა, რომელიც ნამდვილად გჭირდებათ

2026 წლის წარმოების დონის თანხმობის სტეკი Privacy Sandbox API-ებს ცალკეულ დამუშავების საქმიანობებად განიხილავს, თითოეული IAB TCF მიზნებით ან თანაბარი სახელმწიფო სამართლის კატეგორიებით კარიბჭეებული.

Sandbox API-ების TCF მიზნებზე დარგვა

• Topics API — IAB TCF მიზანი 2 (ძირითადი რეკლამების არჩევა) და მიზანი 3 (პერსონალიზებული რეკლამის პროფილის შექმნა) მინიმუმ; მიზანი 4 (პერსონალიზებული რეკლამების არჩევა) თუ თემები ტარგეტინგს კვებავს.
• Protected Audience — მიზანი 3 და 4, პლუს მიზანი 7 (რეკლამის მუშაობის გაზომვა) თუ აუქციონი შედეგის მონაცემებს იყენებს.
• Attribution Reporting — მიზანი 7 (რეკლამის მუშაობის გაზომვა) და მიზანი 9 (სტატისტიკით აუდიტორიის გაგება).
• Shared Storage სიხშირის შეზღუდვისთვის — მიზანი 3 სადაც ის პერსონალიზებას კვებავს, ან კანონიერი ინტერესის საფუძველი სადაც ის წმინდა სიხშირის კონტროლია.

Google Consent Mode v2-ზე დარგვა

Google Consent Mode v2 სიგნალები Privacy Sandbox ქცევაზე ირგვება:

• ad_storage უარყოფილი — Topics და Protected Audience API გამოძახებები სრულად გამორთეთ
• ad_user_data უარყოფილი — Attribution Reporting-ს მომხმარებლის სფეროს მონაცემების გაგზავნა დაბლოკეთ
• ad_personalization უარყოფილი — Topics შეყვანები ტარგეტინგის ლოგიკაში გამოტოვეთ

აშშ სახელმწიფო სიგნალების დამუშავება

აშშ ტრაფიკისთვის, თქვენი თანხმობის ფენა Global Privacy Control-ს და გამოყენებადი სახელმწიფოს opt-out სიგნალებს უნდა ამოწმებდეს. როდესაც აშშ მომხმარებელმა გაზიარებისგან opt-out გაიარა, document.browsingTopics() ჩაახშეთ, joinAdInterestGroup არ გამოიძახოთ და Attribution Reporting-ის რეგისტრაციის სათაურები ამოიღეთ.

პრაქტიკული განხორციელების შაბლონები

Privacy Sandbox-ის განვითარებულ გამომცემლები ჩვეულებრივ ორი არქიტექტურული შაბლონიდან ერთს მიჰყვებიან.

შაბლონი 1: სერვერის მხრივ ორქესტრაცია

თქვენს წარმოშობაზე პირველი მხარის ტეგ მენეჯერი თანხმობის მდგომარეობას, მომხმარებლის იურისდიქციასა და სიგნალის ნებისმიერ გადაფარვას აგროვებს, შემდეგ პირობითად Privacy Sandbox hooks-ს გვერდზე ასახავს. სარეკლამო სერვერი და SSP ტენდერის მოთხოვნის მეშვეობით თანხმობის ფლაგებს იღებს, და ისინი წყვეტენ Topics, Protected Audience ან არცერთი გამოიძახონ. ეს შაბლონი ლოგიკას ცენტრალიზებს და თანხმობის მდგომარეობას ავტორიტეტულს ინარჩუნებს.

შაბლონი 2: Header Bidding Wrapper ინტეგრაცია

Prebid.js და სხვა header bidding wrapper-ები ახლა Privacy Sandbox მოდულებს უჭერს მხარს. Wrapper-ი თანხმობის სიგნალს კითხულობს, Topics-ის გამოძახების ქცევას კონფიგურირებს და ნებართვის შემთხვევაში Protected Audience-ის მეშვეობით აუქციონის შედეგს გადასცემს. ეს მიდგომა განვითარებისთვის სუბუქია, მაგრამ კლიენტში უფრო მეტ ლოგიკას ყენებს და wrapper-ის გამოშვების კადენციაზე დამოკიდებულებას ამჭიდროებს.

რის აუდიტი ჩაატაროთ

• დაადასტურეთ, რომ document.browsingTopics() არ გამოიძახება, გარდა CMP-ის სარეკლამო თანხმობა დადებითი არ არის და opt-out სიგნალი არ არსებობს
• დაადასტურეთ, რომ joinAdInterestGroup და runAdAuction ერთი და იმავე პირობებით კარიბჭეებულია
• დაადასტურეთ, რომ Attribution Reporting-ის რეგისტრაციის სათაურები მხოლოდ იმ მომხმარებლების პასუხებს ეგზავნება, რომელთა თანხმობის მდგომარეობა გაზომვის ნებართვას იძლევა
• დაადასტურეთ, რომ TCF სტრიქონში თქვენი მოვაჭრეების სია კვლავ შეესაბამება SSP-ებსა და DSP-ებს, რომლებიც Sandbox API-ებს თქვენს ინვენტარზე იყენებენ
• დაადასტურეთ, რომ თქვენი კონფიდენციალობის პოლიტიკა Topics, Protected Audience და Attribution Reporting-ს ცალკეულ დამუშავების საქმიანობებად აღწერს, კანონიერი საფუძვლითა და შენახვით

რასაც Privacy Sandbox არ აკეთებს

რამდენიმე გავრცელებული შეცდომის გაგება სიკვდილს საჭიროებს, სანამ ბიუჯეტს მათ წინააღმდეგ ჩამოაყალიბებთ.

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

API-ები რეკლამის განმთავსებლებზე გამოვლენილ პირად მონაცემებს ამცირებს, მაგრამ ისინი ევროპული კანონის მიხედვით ძირეულ დამუშავებას თანხმობის-გათავისუფლებულს არ ხდის. Sandbox-ის მიღება CMP-ის გამოტოვების საშუალებას იძლევა, ეს შესაბამისობის თეორია EU/EEA-ს ყველა იურისდიქციაში არასწორია.

ეს დღეს ქუქიების სრული შემცვლელი არ არის

Topics მსხვილ, დანაკარგ ტარგეტინგის სიგნალს გამოაქვს, რომელიც ჩვეულებრივ ქუქი-ზე დაფუძნებულ აუდიტორიებზე სუსტია. Protected Audience-ის რეტარგეტინგის მასშტაბები ჯერ კიდევ მომწიფდება. Attribution Reporting-ს გაზომვის ხმაურის სართულები აქვს, რამაც შეიძლება მცირე კონვერსიის ზრდა დამალოს. გამომცემელი, რომელიც დღეს ყველა მონეტიზაციას Sandbox-ზე გადაიტანს, ტიპიური ინვენტარის ქუქი-ზე დაფუძნებულ სტეკთან შედარებით RPM-ის 10-30 პროცენტიანი კლების მოლოდინი უნდა ჰქონდეს.

ეს მის ამჟამინდელ ფორმაში მუდმივი არ არის

Privacy Sandbox-ის სპეციფიკაცია კვლავ ვითარდება. Topics-ის ტაქსონომია ფართოვდება, Protected Audience-ის ინტერეს ჯგუფის ლიმიტები გადასინჯვაშია და მარეგულირებელი პასუხი მიმდინარეობს. შეიმუშავეთ თქვენი თანხმობის ფენა კონფიგურაციაზე ორიენტირებული, არა ამჟამინდელ სპეციფიკაციაზე მყარი კოდი.

2026 წლის სწორი პოზა

Privacy Sandbox ყველაზე კარგად ფართო cookie-ს გარეშე სტრატეგიის ერთ ფენად ესმება, პირველი მხარის მონაცემებთან, გამყიდველის მიერ განსაზღვრულ აუდიტორიებთან, კონტექსტური ტარგეტინგთან და სერვერის მხრივ header bidding-თან ერთად. 2026 წელს გამარჯვებულები ის გამომცემლები იქნებიან, ვინც თანხმობას მარბიტრად კი არ განიხილავს, არამედ მის გარეშე — Sandbox API-ებს მხოლოდ იქ კვებავს, სადაც კანონი და მომხმარებლის არჩევანი ნებართვას იძლევა, სხვაგან კონტექსტუალზე სუფთად ბრუნდება და ორივე გზაზე შედეგებს ზომავს ინსტრუმენტებით, რომლებიც იდენტობას არ ვარაუდობს.

ყველაზე ცუდი პოზა მოლოდინისა და ნახვის პოზაა. მარეგულირებლები უკვე წესების შემდეგ ტალღას წერენ — UK Competition and Markets Authority-ის Sandbox ვალდებულებები, მიმდინარე CNIL სახელმძღვანელო და EU AI Act-ის პროფილირების დებულებები ყველა ამ ნიადაგს ეხება. 2026 წელს Privacy Sandbox-ს სათანადოდ კარიბჭეებულ თანხმობის სტეკში ჩამყოფი გამომცემლები ამ წესებისთვის მზად იქნებიან. ვინც ბოლო წუთს ქუქის შემცვლელად მიამაგრებს, თავს პრესიაქვეშ ხელახლა ჩაწერის მდგომარეობაში მიიყვანს.