რატომ სჭირდება Prebid.js-ს თანხმობის მართვის მოდული

როცა Prebid.js-ის აუქციონი მიდის, wrapper პარალელურ მოთხოვნებს უგზავნის ყველა კონფიგურირებულ განმცხადებლის ადაპტერს. თითოეულმა ადაპტერმა მომხმარებლის თანხმობის სტრიქონი უნდა ჩართოს თავის bid-მოთხოვნაში — tcfeu (TCF v2.2 EU/UK-სთვის), usp (CCPA/CPRA) და სულ უფრო მეტად gpp (IAB Global Privacy Platform სტრიქონი, რომელიც რამდენიმე აშშ-ის შტატს მოიცავს). ამ სიგნალების გარეშე ქვედა ნაკადის SSP-ები და DSP-ები იძულებულნი არიან ან მომხმარებელი opt-out სტატუსით მოექცნენ, bid-ი სრულად მოიშორონ, ან — უარეს შემთხვევაში — მონაცემები უკანონოდ დაამუშაონ.

Prebid-ის თანხმობის მართვის მოდული თქვენს CMP-სა და bid-მოთხოვნების პაიპლაინს შორის მდებარეობს. ის სტანდარტულ CMP API-ს (__tcfapi, __uspapi, __gppapi) იძახებს, თანხმობის სტრიქონს ელოდება და შემდეგ მას ავტომატურად ყოველი ადაპტერის bid-მოთხოვნის payload-ში ამკვიდრებს. ის ასევე მიზნებზე დაფუძნებულ გეითინგს ახორციელებს GDPR-ის შესრულების გააქტიურებისას, ინახავს საცავის წვდომასა და განმცხადებლის გაშვებას მომხმარებლებისთვის, რომლებმაც შესაბამისი TCF მიზნები არ მიანიჭეს.

ძირითადი მოდულის ინსტალაცია და კონფიგურაცია

Prebid.js გამომცემელ-სპეციფიკურად იბნება docs.prebid.org/download.html-ზე. თქვენი სპეციალური build-ის გენერაციისას სამი მოდული „თანხმობის მართვის" ქვეშ მნიშვნელოვანია:

• consentManagementTcf — EU, UK და შვეიცარიის ტრაფიკისთვის TCF v2.2 სტრიქონებს ამუშავებს.
• consentManagementUsp — ძველ CCPA/CPRA US Privacy String-ს ამუშავებს (ბევრ DSP-ს ჯერ კიდევ სჭირდება).
• consentManagementGpp — IAB GPP სტრიქონს ამუშავებს, მომავალზე ორიენტირებულ სტანდარტს, რომელსაც ახლა Google, TTD და მთავარი SSP-ები ავალდებულებენ.

სამივე ჩართეთ, თუ გლობალური ტრაფიკი გაქვთ. როცა build CDN-ზე გადაედება, მოდულები Prebid-ის კონფიგურაციის სკრიპტში დააკონფიგურიროთ:

TCF v2.2-ის კონფიგურაცია

TCF ბლოკი Prebid-ს ეუბნება, რომელი CMP API გამოიძახოს, სტრიქონისთვის რამდენ ხანს დაელოდოს და timeout-ისას რა გააკეთოს. ტიპური საწარმოო კონფიგურაცია ადგენს cmpApi: 'iab'-ს, timeout: 8000-ს (8 წამი — გამართლებულია ნელი CMP ბანერის ჩატვირთვისთვის) და defaultGdprScope: true-ს, ასე რომ უცნობი იურისდიქციების მომხმარებლები სკოუფში მყოფად ჩაითვლებიან, სანამ სხვა არ დამტკიცდება. actionTimeout-ის ცალ-ცალკე დაყენება კონტროლს ახდენს, რამდენ ხანს ელოდება Prebid, სანამ მომხმარებელი ბანერს ჯერ კიდევ არ შეეხო — ზომიერ მნიშვნელობაზე შენახვა ბანერის იგნორირების შემთხვევაში სარეკლამო ადგილის ცარიელ დარჩენას ასცდება.

US Privacy და GPP

USP მარტივია: მოდული ჩართეთ და Prebid __uspapi-დან ოთხ სიმბოლოიანი სტრიქონს წაიკითხავს. GPP უფრო დახვეწილია, რადგან GPP სტრიქონს შეიძლება მრავალი სექციის ID ჰქონდეს (TCF EU, US ეროვნული, US კალიფორნია, US კოლორადო, US ვირჯინია და სხვ.). Prebid სრულ სტრიქონს ავტომატურად გადასცემს, მაგრამ განმცხადებლები კონკრეტულ სექციებს ამოწმებენ. დარწმუნდით, რომ CMP ყოველი მომხმარებლის იურისდიქციისთვის სწორ GPP სექციებს გამოსცემს — CMP, რომელიც კალიფორნიელ მომხმარებელს მხოლოდ US ეროვნულ სექციას გამოუშვებს, CPRA-თან შეთავსებად DSP-ებს bid-ის გადაგდებინებს.

GDPR-ის შესრულების გარდაც (მიზნებზე დაფუძნებული გეითინგი)

სტანდარტულად, თანხმობის მოდული TCF სტრიქონს გატარებს, მაგრამ არაფერს ბლოკავს. Prebid-ს TCF მიზნების ნამდვილი შესრულება რომ დავავალოთ, gdprEnforcement-ის წესების ნაკრები ჩართეთ. სწორედ აქ ხდება კონფიგურაციის შეცდომები — და სწორედ აქ მდებარეობს შესაბამისი და შეუსაბამო header bidding სტეკის განსხვავება.

სტანდარტული წესების ნაკრები ოთხ ქმედებას ბლოკავს, როდესაც შესაბამის მიზანს თანხმობა არ აქვს:

• storage — მიზანი 1-ით (შენახვა და წვდომა) გარემოცული. უარყოფისას Prebid ახდენს განმცხადებლებს ქუქი-ფაილებისა და localStorage-ის წაკითხვა-ჩაწერა შეეძლოთ.
• basicAds — მიზანი 2-ით (საბაზისო რეკლამები) გარემოცული. უარყოფისას განმცხადებელი სრულად გარიცხება აუქციონიდან.
• measurement — მიზანი 7-ით გარემოცული. გავლენას ახდენს ანალიტიკის ადაპტერებზე.
• transmitPreciseGeo — სპეციალური ნიშანი 1-ით გარემოცული. უარყოფისას Prebid ზუსტ გეოლოკაციას bid-მოთხოვნებიდან ხსნის.

ყოველი წესისთვის ადგენთ enforcePurpose: true-ს, enforceVendor: true-ს და vendorExceptions-ის სიას. ვენდორის გამონაკლისთა სია კრიტიკულია: ნებისმიერ განმცხადებელს, რომელსაც ჩამოთვლით, ნება ეძლევა მონაწილეობა მიიღოს ცალსახა TCF ვენდორის თანხმობის გარეშეც, იმ საფუძველზე, რომ ცალკე სამართლებრივი საფუძველი (მაგ. კანონიერი ინტერესი + სახელშეკრულებო ნაკადი) გაქვთ. ეს ზომიერად გამოიყენეთ — ზედმეტად ფართო გამონაკლისები სწორედ ის შაბლონია, რომლის გამოც მარეგულირებელი ორგანოები გამომცემლებს ჯარიმების დაწესებას შეუდგნენ.

გამომცემლებისთვის შემოსავლის ან შესაბამობის ხარჯის ჩვეულებრივი ხაფანგები

Timeout ძალიან დაბლაა დაყენებული

თუ timeout CMP ბანერის გამოქვეყნების დროზე მოკლეა, Prebid თანხმობის სტრიქონის გარეშე გადის. განმცხადებლები ამას „უთანხმოებად" განიხილავენ და bid-ს გადაყრიან. CMP-ის tcfapi('addEventListener') პირველი გამოძახების შეყოვნება 95-ე პერცენტილზე გაზომეთ და Prebid-ის timeout ამაზე ზევით დაადგინეთ. 8000 ms უსაფრთხო ნაგულისხმევია; 3000 ms სარისკოა, თუ ბაზრებს ემსახურებით, სადაც ბანერების ლოკალიზებას დრო სჭირდება.

US ტრაფიკზე GPP ინტეგრაციის ნაკლებობა

მთავარ SSP-ებსა და DSP-ებს (Google AdX, TTD, Magnite, PubMatic) ახლა US opt-out შესრულებისთვის GPP სტრიქონი სჭირდებათ. მხოლოდ მემკვიდრეობითი USP სტრიქონის გამოცემის შემთხვევაში, ეს DSP-ები სულ უფრო ხშირად ჩამოაქვეითებენ ან გამოტოვებენ თქვენს ინვენტარს. Bid პასუხები გადაამოწმეთ: US ტრაფიკზე 2026 წელს CPM-ის მკვეთრი ვარდნა ხშირად GPP სიგნალის ნაკლებობაა.

SPA ნავიგაციაზე დაძველებული თანხმობის სტრიქონები

ერთგვერდიან აპლიკაციებს, რომლებიც მარშრუტის ცვლილებებზე Prebid აუქციონებს ხელახლა ააქტიურებენ, pbjs.refreshUserIds() უნდა გამოიძახონ და უზრუნველყონ, რომ უახლესი TCF სტრიქონი ამოიღება. 30 წუთის კეშირებულ სტრიქონს შეიძლება წინა მომხმარებლის პარამეტრები ჰქონდეს, თუ საიტი საერთო სესიებს იყენებს.

ანალიტიკის vendorExceptions-ის ნაკლებობა

გამომცემლები ხშირად ავიწყდებათ, რომ Prebid Analytics ადაპტერებიც (Google Analytics, სერვერ-მხარის ანგარიშები) TCF მიზანი 7-ის ქვეშ measurement გეითინგის ქვეშ ექცევიან. თუ შემოსავლების ანგარიშებისთვის ეს გამოიყენება, მათ საზომი წესის ვენდორის გამონაკლისთა ქვეშ ცხადად ჩამოთვალეთ ან უთანხმო ტრაფიკზე მონაცემთა ხარვეზი მიიღეთ.

კონფიგურაციის სწარმოებამდე ტესტირება

Prebid.js ბრაუზერის კონსოლში pbjs.getConfig('consentManagement')-ს გამოავლენს. გადაამოწმეთ, რომ აქტიური კონფიგურაცია თქვენს განზრახვებს ემთხვევა. შემდეგ Chrome-ის გაფართოება Prebid.js Professor ან pbjs.getEvents() გამოიყენეთ, რათა თითოეული bid-მოთხოვნაზე მიმაგრებული თანხმობის სტრიქონი შეამოწმოთ. სამი სცენარი გადაამოწმეთ: სრულად შეთანხმებული მომხმარებელი, მომხმარებელი, რომელმაც „ყველაფრის უარყოფა" დააჭირა და მომხმარებელი, რომელმაც ბანერი ურთიერთობის გარეშე დახურა. თითოეულმა bid-მოთხოვნის payload-ში განსხვავებული დასაკვირვებელი ქცევა უნდა წარმოქმნას.

VPN-ის ან CMP-ის გეოლოკაციის გადაფარვის ფლაგის გამოყენებით სხვადასხვა გეოგრაფიაზე იგივე შემოწმებები ჩაატარეთ. EU ტრაფიკმა TCF სტრიქონი უნდა წარმოქმნას და gdprEnforcement გაააქტიუროს; კალიფორნიის ტრაფიკმა USP და GPP სტრიქონი უნდა წარმოქმნას; არარეგიონული ტრაფიკი defaultGdprScope-ის პარამეტრებს უნდა პატივს სცეს.

ყველაფრის ერთად კომბინაცია

სწორად კონფიგურირებული Prebid-ის თანხმობის მართვის სტეკი ერთდროულად სამ საქმეს აკეთებს: განმცხადებლებს სწორი თანხმობის სიგნალებით ამარაგებს (CPM-ებს ინარჩუნებს), wrapper-ის დონეზე TCF-ისა და US opt-out წესებს ახორციელებს (საკანონმდებლო ექსპოზიციას ამცირებს) და მარეგულირებლის კითხვისას ერთ სამოდელო წერტილს გაძლევს, თუ როგორ პატივს სცემს header bidding კონფიგურაცია მომხმარებელთა არჩევანს. timeout-ები განზრახ დაადგინეთ, US ტრაფიკისთვის USP-თან ერთად GPP ჩართეთ და vendorExceptions-ის სია ყოველ კვარტალში გადახედეთ — ამაში შეცდომის ფასი როგორც ჯარიმებში, ისე დაკარგულ პროგრამული შემოსავლებში ისაზომება.