Реклама Adgora на сайтах з обліковими записами

Чи можуть видавці Adgora розміщувати рекламу на сайтах із обліковими записами користувачів і персональними даними?

Одна частина сайту може бути загальнодоступною, а інша — приватною. Відвідувач може прочитати відкриту статтю, а потім увійти в систему, щоб переглянути історію платежів, приватні повідомлення чи налаштування облікового запису. Розміщення реклами в розділі, доступному після входу, порушує конкретне питання: чи передає рекламний запит інформацію, пов’язану з користувачем облікового запису?

Відповідь залежить від сторінки, даних, які вона обробляє, та вимог, що поширюються на видавця. Сам факт наявності входу до системи не визначає, чи відповідає сторінка вимогам для розміщення реклами. Видавцям варто оцінювати кожне місце розміщення окремо й не передавати дані облікового запису в рекламних запитах, якщо відповідні вимоги прямо не дозволяють цього. Перед запуском перевірте актуальні вимоги Adgora до видавців.

Чим сайт з обліковими записами відрізняється від загальнодоступного сайту?

Загальнодоступна сторінка зазвичай показує ту саму статтю багатьом відвідувачам. На сторінці, доступній через обліковий запис, вміст або дії можуть бути пов’язані з конкретним користувачем. Наприклад, панель із збереженими користувачем матеріалами відрізняється від загальнодоступної сторінки з переліком популярних матеріалів, навіть якщо їхнє оформлення схоже.

Ця відмінність важлива, адже сторінка може розкривати більше, ніж можна припустити з її URL-адреси. На сторінці з назвою «Огляд облікового запису» в основній частині можуть відображатися ім’я користувача, його статус учасника чи нещодавня активність. Рекламний запит, що передає ці відомості, або URL-адреса, яка їх містить, може винести дані облікового запису за межі сайту.

Оцінюйте доцільність розміщення реклами окремо від самого факту входу до системи. Для кожного типу сторінок визначте, що бачить відвідувач, які дані відображає сторінка та що передає рекламний код. Не слід автоматично ставитися однаково до сторінки профілю авторизованого користувача й загальнодоступної довідкової статті.

Чи можуть видавці використовувати Adgora на сторінках, доступних лише після входу?

Видавцям не варто вважати, що будь-яка сторінка за формою входу дозволена для розміщення реклами або що весь вміст для авторизованих користувачів заборонений. Оцінюйте конкретну сторінку та місце розміщення відповідно до актуальних вимог Adgora до видавців, зокрема правил щодо обмеженого вмісту, персональної інформації та способу інтеграції реклами.

Почніть з переліку сторінок. Зазначте типи сторінок для авторизованих користувачів, де може з’явитися реклама: загальна панель учасника, приватна скринька, сторінка оплати чи сторінка уроку курсу. Потім зафіксуйте, що відображає кожна сторінка і чи містить вона дані, пов’язані з конкретним обліковим записом. Це допоможе видавцеві визначити, які місця розміщення потрібно переглянути, виключити або протестувати.

Наприклад, на сайті спільноти можуть бути загальнодоступний список обговорень і приватні гілки повідомлень. Список можна оцінювати як окреме місце розміщення, а до перегляду повідомлень слід поставитися обережно, адже там може міститися особисте листування. Те, що для доступу до обох сторінок потрібен вхід, саме по собі не дає відповіді, чи відповідає кожна з них вимогам.

Перш ніж розміщувати рекламу на сторінці, доступній лише після входу, перевірте чинні правила, а не покладайтеся на загальні припущення щодо сайтів з обліковими записами. Якщо вимога незрозуміла, зверніться до Adgora по роз’яснення й не вмикайте розміщення, доки не отримаєте чітку відповідь. Тому на запитання «Чи можна розміщувати рекламу Adgora на сторінках після входу?» слід відповідати лише після оцінки конкретної сторінки та підтвердження її відповідності чинним вимогам.

Які персональні дані не слід передавати в рекламних запитах?

Не передавайте дані облікового запису в рекламних запитах, якщо документально підтверджена й затверджена вимога не передбачає іншого. Імена, адреси електронної пошти, паролі, приватні повідомлення, номери телефонів, платіжні дані та ідентифікатори облікових записів не слід додавати до рекламних тегів, параметрів запитів чи URL-адрес, пов’язаних із рекламою. Коли перевіряєте, які саме значення потрібно виключити, зважайте на запитання «Які персональні дані не можна передавати в рекламних запитах?» і не надсилайте такі відомості без чітко застосовної та документованої підстави.

Особливу увагу приділіть URL-адресам. Посилання на кшталт /[email protected] може розкрити адресу електронної пошти системам, які отримують або записують URL-адресу. Те саме стосується рядків запиту, що містять номер облікового запису, токен для скидання пароля чи ідентифікатор приватного повідомлення. За можливості використовуйте маршрути, які не розкривають особу, і ніколи не вказуйте секретні дані в URL-адресах.

Перевіряйте не лише видимий код рекламного тегу, а й усі дані, які передає сторінка. Змінні сторінки, рівні даних, інформація про джерело переходу та мережеві запити можуть передавати значення з екранів облікового запису. Розробник сайту може переглянути запити в мережевих інструментах браузера й перевірити, чи з’являються в URL-адресі запиту або його тілі ім’я чи дані облікового запису.

Не передавайте пароль у рекламний запит. Не передавайте приватні повідомлення. Це чіткі межі, навіть якщо на сайті для загальнодоступних сторінок і сторінок після входу використовуються спільні скрипти реклами.

Як видавцям працювати з вмістом сторінок, пов’язаним з обліковими записами?

Деякі сторінки облікових записів розкривають діяльність або обставини користувача, навіть якщо на них немає очевидних ідентифікаторів. Наприклад, сторінка з інформацією про медичний прийом, запит на фінансову допомогу чи приватну суперечку може містити чутливі дані через саму тему. Перш ніж розміщувати рекламу поруч, видавцям варто перевірити, що саме розкриває сторінка.

Проводьте перевірку на рівні шаблонів сторінок і переглядайте реальні приклади за допомогою тестових облікових записів. Для навчальної платформи перевірте, чи розкриває сторінка уроку прогрес учня або результати оцінювання. Для сайту з членством перевірте, чи показує сторінка поновлення статус оплати. Ці дані можуть впливати на доречність рекламного місця, навіть якщо жодні персональні дані навмисно не передаються в рекламному запиті.

Подумайте про те, щоб не розміщувати рекламу на сторінках із приватним, особливо чутливим вмістом або інформацією, що може змінюватися залежно від обставин конкретного користувача. Не вважайте наявність рекламного блоку в спільному шаблоні доказом того, що він доречний на кожній сторінці, де використовується цей шаблон.

Якщо на сторінці поєднано загальну інформацію з даними облікового запису, перевіряйте разом і структуру сторінки, і потік даних. Реклама поруч із типовою довідковою статтею може становити інший ризик, ніж реклама біля персоналізованого повідомлення, навіть якщо обидві сторінки розташовані в одному меню облікового запису.

Що слід перевірити перед показом реклами авторизованим користувачам?

Перед запуском перевірте чотири речі: актуальні вимоги Adgora до видавців, політику конфіденційності сайту, вибір користувача щодо надання згоди та правила, що діють у країні видавця. Застосовні вимоги можуть залежати від послуги, оброблюваних даних і місця перебування користувача.

Переконайтеся, що в політиці конфіденційності практики використання реклами описані точно й зрозуміло. Перевірте, чи впливає вибір користувача щодо згоди на показ реклами або передавання даних, і чи відповідає реалізація сайту цьому вибору. Сам банер згоди не доводить, що кожен запит враховує вибір користувача.

Документуйте результати перевірки. У короткому записі можна зазначити шаблон сторінки, дані, які вона відображає, рішення щодо рекламного місця, перевірену поведінку механізму згоди та особу, яка погодила зміни. Якщо згодом на сайті з’явиться нове поле облікового запису або зміниться рекламний код, цей запис стане чіткою відправною точкою для повторної перевірки.

За потреби видавцям слід підтвердити застосовні законодавчі вимоги й вимоги платформ у фахових консультантів. Не робіть висновків щодо правил на підставі вимог іншої країни або загальнодоступної сторінки, для якої передбачено інший потік даних.

Як видавцям тестувати рекламу, не розкриваючи справжні дані облікових записів?

Використовуйте тестові облікові записи із синтетичними даними, а не реальними записами клієнтів. У тестовому профілі можна вказати явно вигадане ім’я та тестову адресу електронної пошти. Використовуйте паролі, унікальні для тестового середовища, і ніколи не вводьте облікові дані з виробничого середовища в інструменти налагодження чи рекламні запити.

Перевірте кожен тип сторінок, де може з’явитися реклама: панель, екран профілю, сторінку оплати та інші відповідні шаблони. Відкрийте інструменти розробника браузера, перегляньте мережеві запити й пошукайте імена користувачів, адреси електронної пошти, текст повідомлень, ідентифікатори чи інші приватні дані в URL-адресах і тілах запитів. Перевірте як початкове завантаження сторінки, так і дії на кшталт перемикання вкладки чи відкриття модального вікна.

Також перевірте сторінку з різними варіантами згоди. Відповідно до налаштованої політики сайту переконайтеся, що місце розміщення працює належним чином, коли користувач приймає, відхиляє або змінює свій вибір. Очікувану поведінку слід задокументувати до початку тестування.

Насамкінець перевірте, чи не потрапляють чутливі дані до історії браузера, інформації про джерело переходу або журналів помилок через URL-адреси, пов’язані з обліковим записом. Відсутність персональних даних в одному рекламному запиті під час тестування — корисний результат, але він не охоплює всіх сторінок і дій користувачів. Щоб систематизувати таку перевірку, поставте запитання: «Як перевірити сайт на витік даних облікового запису в рекламних запитах?» — і пройдіть відповідні шаблони сторінок та дії користувачів із тестовими даними.

Що робити видавцям, якщо персональні дані потрапили в рекламний трафік?

Спочатку призупиніть показ реклами в проблемному місці. Якщо рекламний запит містить адресу електронної пошти реальної людини чи інші дані облікового запису, вимкнення цього розміщення допоможе обмежити подальше розкриття даних на час розслідування. Безпечно збережіть інформацію, потрібну для розслідування, і не копіюйте чутливі дані у звичайні заявки чи чати.

Дотримуйтеся процедури реагування на інциденти, установленої на сайті. Визначте, яких сторінок і запитів торкнулася проблема, коли вона виникла та чи передавалися дані зовнішній службі. Потім усуньте джерело проблеми — наприклад, параметр URL-адреси або змінну сторінки, яку додали до рекламного коду, — і перед відновленням розміщення повторіть тест із синтетичними даними облікового запису.

Повідомте відповідальну за конфіденційність або безпеку особу у видавця та дотримуйтеся застосовних процедур звітування. Необхідність повідомляти регулятора, постраждалих користувачів або Adgora залежить від обставин і чинних правил; уточніть ці зобов’язання у відповідальної команди або кваліфікованого юриста.