ჩუმი შემოსავლის გაჟონვა

როდესაც თქვენი eCPM ყოველთვიურად რამდენიმე პროცენტით ქვემოთ ცურავს, მიზეზი იშვიათად არის ინვენტარი ან მინიმალური ფასები. უფრო ხშირად ეს არის გატეხილი TC string — IAB Transparency & Consent Framework-ის (TCF) სიგნალი, რომელიც ყოველ რეკლამის მოთხოვნასთან ერთად მოგზაურობს. დამახინჯებული ან გამოტოვებული სტრიქონი ხმამაღალ შეცდომას არ აგდებს. ამის ნაცვლად, რეკლამის სერვერი ჩუმად ბრუნდება არაპერსონალიზებულ რეკლამებზე, მოთხოვნის პარტნიორები ცვივა და შემოსავალი იღვრება ერთი გაფრთხილების გარეშე. აპლიკაციებისა და თამაშების გამომცემლებისთვის, რომლებიც მონეტიზაციას ახდენენ EEA-სა და დიდ ბრიტანეთში, ეს დაკარგული შემოსავლის ყველაზე უგულებელყოფილი მიზეზია.

რას ატარებს TC String სინამდვილეში

TC string არის base64-ით კოდირებული ბლოკი, რომელსაც თქვენი Consent Management Platform (CMP) ქმნის. ის კოდირებს მომხმარებლის არჩევანებს: თანხმობილ მიზნებს, დაშვებულ მომწოდებლებს, თქვენს CMP ID-ს, პოლიტიკის ვერსიას და დროის ნიშნულს. მყიდველები მას მილიწამებში ხსნიან, რათა გადაწყვიტონ, შეუძლიათ თუ არა ბიდი პერსონალიზებული მიზანმიმართვით. ორი სიგნალი ერთნაირად მნიშვნელოვანია:

• gdprApplies — დროშა (1, 0 ან undefined), რომელიც მყიდველებს ეუბნება, GDPR მოქმედებს თუ არა.
• Google Consent Mode v2 — ad_storage, ad_user_data და ad_personalization სიგნალები, რომლებსაც Google კითხულობს TCF სტრიქონისგან დამოუკიდებლად.

თუ რომელიმე ამათგანი არასწორია, მოთხოვნა ორთქლდება — მაშინაც კი, როცა მომხმარებელმა ნამდვილად დათანხმდა.

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

1. გამოტოვებული ან ვადაგასული სტრიქონი. თუ CMP არასოდეს წერს სტრიქონს, ან ქეშირებული თანხმობა ბერდება თქვენი ხელახალი მოთხოვნის ფანჯრის მიღმა, მოთხოვნები სიგნალის გარეშე გადის. მყიდველები "სტრიქონი არ არის"-ს ექცევიან როგორც "თანხმობა არ არის"-ს და ბიდს დებენ მხოლოდ დაბალი eCPM-ის კონტექსტური მოთხოვნით, ან გამოტოვებენ აუქციონს.

2. არასწორი CMP ID. ყველა სერტიფიცირებულ CMP-ს აქვს რეგისტრირებული ID სტრიქონში ჩაშენებული. თუ ამოუცნობი ID იწერება, Google და IAB მომწოდებლები მას უარყოფენ — ხშირია მიგრაციის შემდეგ, როცა ძველი SDK ჯერ კიდევ შეფუთულია.

3. მომწოდებელი არ არის დეკლარირებული. მოთხოვნის პარტნიორს შეიძლება ჰქონდეს სრული თანხმობა, მაგრამ თუ მისი მომწოდებლის ID არ არის დაშვებული მომწოდებლების სიაში, მას არ შეუძლია პერსონალიზებული ბიდი. გამომცემლები ხშირად ივიწყებენ სიის განახლებას პარტნიორის დამატების შემდეგ.

4. დამახინჯებული gdprApplies. სტრიქონ "1"-ის გადაცემა მთელი რიცხვის ნაცვლად, ან მისი undefined-ად დატოვება მომხმარებლისთვის, რომელიც აშკარად EEA-შია, მყიდველებს აბნევს. არასწორი gdprApplies=0 ასევე შეიძლება გაგამხილოთ შესაბამისობის რისკის წინაშე, მაშინ როცა გამოიყურება კარგად.

5. Consent Mode სიგნალები არ ისვრება. TCF სტრიქონი შეიძლება სრულყოფილი იყოს, ხოლო Consent Mode რჩება თავის ნაგულისხმევ უარყოფილ მდგომარეობაში — მაგალითად, როცა SDK რეკლამებს ტვირთავს თანხმობის გადაწყვეტამდე. შემდეგ Google ემსახურება არაპერსონალიზებულ რეკლამებს TC string-ის მიუხედავად.

ნაბიჯ-ნაბიჯ გამართვის სამუშაო ნაკადი

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

• ნაბიჯი 1 — დაიჭირეთ ნედლი სტრიქონი. ვებზე წაიკითხეთ ის __tcfapi('getTCData', 2, cb)-ის მეშვეობით. აპლიკაციაში გადმოწერეთ IABTCF_TCString გასაღები SharedPreferences-დან (Android) ან NSUserDefaults-დან (iOS).
• ნაბიჯი 2 — გაშიფრეთ და დაამოწმეთ. ჩასვით ის IAB TCF დეკოდერში ან CMP ვალიდატორში. დაადასტურეთ, რომ CMP ID თქვენია, რომ პოლიტიკის ვერსია და დროის ნიშნული მიმდინარეა და თქვენი ძირითადი მომწოდებლების ID-ები სიაში ჩანს.
• ნაბიჯი 3 — შეამოწმეთ რეკლამის მოთხოვნა. გამოიყენეთ Charles Proxy ან ქსელის ინსპექტორი GAM მოთხოვნის სათვალთვალოდ და დაამოწმეთ, რომ gdpr და gdpr_consent პარამეტრები სწორ მნიშვნელობებს ატარებენ.
• ნაბიჯი 4 — შეამოწმეთ Consent Mode. გამოიყენეთ Google Tag Assistant იმის დასადასტურებლად, რომ ad_user_data და ad_personalization გადადის granted-ში, როცა მომხმარებელი ეთანხმება.
• ნაბიჯი 5 — დაადასტურეთ GAM-ში. გახსენით Ad Manager-ის არაპერსონალიზებული რეკლამების ანგარიშგების განზომილება. NPA ტრაფიკის ნახტომი, რომელიც არ ემთხვევა თქვენს უარის თქმის მაჩვენებელს, ცუდი სტრიქონის თითის ანაბეჭდია.

ძირეული მიზეზის გამოსწორება

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

აქ Google-ის სერტიფიცირებული CMP ამართლებს თავის ფასს. FlexyConsent გამოსცემს ვალიდურ IAB TCF 2.3 სტრიქონებს სწორი CMP ID-ით და მომწოდებლების დეკლარაციებით, ისვრის Consent Mode v2 სიგნალებს ისე, რომ ad_user_data და ad_personalization თვალყურს ადევნებს მომხმარებლის არჩევანს, და ზედაპირზე გამოაქვს თანხმობის მაჩვენებლის ანალიტიკა ვებზე, Android-სა და iOS-ზე — ისე, რომ გატეხილი სტრიქონი დაფაზე ჩნდება და არა თქვენს გადახდაში.

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

• ცუდი TC string არ ფუჭდება — ის ჩუმად გადაგიყვანთ არაპერსონალიზებულ რეკლამებზე და დაბალ eCPM-ზე.
• ხუთი დამნაშავე: გამოტოვებული/ვადაგასული სტრიქონები, არასწორი CMP ID, დაუდეკლარირებელი მომწოდებლები, დამახინჯებული gdprApplies და მკვდარი Consent Mode სიგნალები.
• გამართეთ მოწყობილობიდან რეკლამის სერვერამდე: დაიჭირეთ, გაშიფრეთ, შეამოწმეთ მოთხოვნა, დაამოწმეთ Consent Mode, შეამოწმეთ GAM.
• უწყვეტად ადევნეთ თვალყური თქვენს პერსონალიზებული-NPA თანაფარდობას — სერტიფიცირებული CMP, როგორიც არის FlexyConsent, ვალიდურ სტრიქონებსა და სწორ Consent Mode v2 სიგნალებს ნაგულისხმევად აქცევს.