Сповіщення

Персоналізовані поради щодо оптимізації, аналіз ефективності облікового запису та виконання налаштувань в оновленому розділі Моя сторінка AdMob.

Налаштування для обмеження обробки даних у тегах оголошень видавців Google

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

Налаштування обмеження обробки даних для сторінок із GPT й тегами AdSense

Надсилання запитів оголошень

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

  • Налаштування неперсоналізованих оголошень у тегах оголошень видавців Google
    (Ad Manager, AdMob, Android та iOS, AdSense)
  • Додавання тегів у запити оголошень для користувачів із ЄЕЗ, які не досягли віку згоди (TFUA)
    (Ad Manager, AdMob, AdSense)
  • Додавання тегів у запити оголошень, призначені для дітей (TFCD)
    (Ad Manager, AdMob, AdSense)
    Видавці можуть використовувати параметр TFCD під час додавання тегів у запити для користувачів, які не досягли віку згоди. Якщо ввімкнути цей параметр, активується також режим обмеження обробки даних.

У цій статті описано, як увімкнути режим обмеження обробки даних за допомогою тегів оголошень у запитах. Якщо ж увімкнути зазначений режим, Google обмежуватиме використання даних і показуватиме лише неперсоналізовані оголошення. Щоб увімкнути режим обмеження обробки даних для всіх користувачів, які перебувають у відповідних штатах США й відвідують ваш ресурс, змінювати теги оголошень не потрібно. Щоб дізнатися більше про цей режим, зокрема про те, як увімкнути його в інтерфейсах різних сервісів Google, перейдіть у Довідковий центр Ad Manager, AdMob або AdSense.

Якщо ви хочете ввімкнути режим обмеження обробки даних лише для окремої групи користувачів, скористайтеся тегами видавця Google (GPT) і асинхронними тегами оголошень AdSense/Ad Exchange, щоб застосовувати їх на рівні сторінки. Це ідеальний варіант, якщо вам потрібно розмістити на сторінці посилання "Не продавати особисту інформацію". Якщо користувач заборонить продавати свої дані, вважатиметься, що передавання такого сигналу підтверджуватиме дотримання вами регуляторних вимог. Щоб дізнатися більше про режим обмеження обробки даних, ознайомтеся зі статтею "Допомога видавцям у дотриманні законів окремих штатів США щодо конфіденційності (для Google Ad Manager, AdMob і AdSense).

  • Для тегу GPT, використовуйте такий фрагмент коду:

    googletag.pubads().setPrivacySettings({
    'restrictDataProcessing': true
    });

  • Для асинхронного тегу оголошень AdSense і Ad Exchange використовуйте такий фрагмент коду:

    <ins class="adsbygoogle"
    style="display:inline-block;width:728px;height:90px"
    data-ad-client="ca-pub-0123456789abcdef"
    data-ad-slot="0123456789"
    data-restrict-data-processing="1"></ins>

Ці методи активують режим обмеження обробки даних для запитів оголошень, надісланих у Google за допомогою підтримуваних тегів оголошень: GPT, асинхронних тегів оголошень AdSense чи Ad Exchange (adsbygoogle.js) і IMA SDK. Щоб перевірити, чи тег оголошення обмежує обробку даних, перегляньте запит оголошення в інструментах розробника свого вебпереглядача й знайдіть у ньому параметр &rdp=1.

За допомогою цих API можна вимкнути режим обмеження обробки даних і знову ввімкнути персоналізацію. Для цього потрібно передати значення false або 0 залежно від того, який варіант підтримує API. Якщо сторінка містить кілька типів тегів оголошень Google (наприклад, і тег GPT, і асинхронний тег AdSense/Ad Exchange), слід використовувати параметр контролю RDP для кожного типу тегу.

Налаштування обмеження обробки даних для інших тегів

Теги відкликаних показів GPT

Якщо ви використовуєте теги відкликання показів GPT, можна позначити запит оголошення як запит з обмеженням обробки даних. Для цього задайте такий самий API, який застосовується для стандартного тегу GPT: googletag.pubads().setPrivacySettings.

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

Приклад коду:

<script async
src="https://securepubads.g.doubleclick.net/tag/js/gpt.js"></script>
<div id='gpt-passback'>
  <script>
      indow.googletag = window.googletag || {cmd: []};
     googletag.cmd.push(function() {
       googletag
         .defineSlot('/123/sports', [300, 250], 'gpt-passback')
         .addService(googletag.pubads());
       googletag.pubads().setPrivacySettings({
        'restrictDataProcessing': true
       });
       googletag.enableServices();
       googletag.display('gpt-passback');
     });
  </script>
</div>

Запит без тегів

Якщо використовується запит без тегів, можна позначити запит оголошення як запит з обмеженням обробки даних. Для цього потрібно додати параметр rdp=[int] безпосередньо в URL-адресу запиту з тегом. Ми рекомендуємо додавати параметр на початку тегу, щоб можливе скорочення не вплинуло на нього. Щоб позначити запит оголошення як запит з обмеженням обробки даних, укажіть параметр rdp=1. Якщо не зробити це, за умовчанням буде вимкнено режим обмеження обробки даних і дозволено показ персоналізованої реклами. 

Приклад коду:

https://securepubads.g.doubleclick.net/gampad/ad?iu=/12345/adunit&sz=728x90&rdp=1&c=12345

Google Mobile Ads SDK

Щоб дізнатися більше про Google Mobile Ads SDK, відвідайте сайт для розробників.

Google Interactive Media Ads SDK (для відеооголошень)

У запитах відеооголошень можна вказати, щоб система Google розпізнавала ваш відеоконтент як такий, для якого ввімкнено режим обмеженої обробки даних. Це можна зробити за допомогою створеного вручну тегу основного оголошення (лише в Ad Manager) або IMA SDK для певних платформ (HTML 5 IMA SDK, iOS IMA SDK, Android IMA SDK, Google Cast IMA SDK).

Якщо у вашому відеопрогравачі використовується функція Ad Manager "Динамічна вставка оголошень", параметр rdp=1 можна додати у запит для відео VOD або прямої трансляції, щоб передати його в усі включені запити оголошень (DAI HTML5 SDK, DAI Cast SDK, DAI iOS SDK, DAI Android SDK, DAI Roku SDK, DAI tvOS SDK).

Застарілі теги оголошень видавця Google

Інші типи тегів оголошень Google (наприклад, застарілі теги GAM, теги GUT і синхронні теги AdSense чи Ad Exchange (show_ads.js)) не підтримують запити оголошень з обмеженням обробки даних. Рекомендуємо використовувати теги, які повністю підтримують усі функції персоналізованої реклами й режиму обмеження обробки даних.

AdSense для пошуку

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

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

  • Для тегу вебреклами в користувацькому пошуку додайте наведений нижче параметр до фрагмента pageOptions у тегу реклами в користувацькому пошуку:

    personalizedAds: false,

  • Для тегу AdMob:

    builder.setAdvancedOptionValue("csa_personalizedAds", "false");

  • Для тегу iOS:

    [request setAdvancedOptionValue:@"false" forKey:@"personalizedAds"];

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

Сторінки Accelerated Mobile Pages (AMP)

Ці вказівки застосовуються тільки до сервісів Ad Manager й AdSense. Дізнайтесь, як налаштовувати кожен варіант для AMP-сторінок, з яких запити на оголошення надходять за допомогою тегу <amp-ad type="doubleclick"> або <amp-ad type="adsense">.

Для запитів оголошень, які надходять з AMP-сторінок, видавці можуть обмежити обробку даних для всіх користувачів, які перебувають у відповідних штатах США, або для окремих груп користувачів, виконавши наведені далі вказівки з вимкнення персоналізації. Щоб увімкнути режим обмеження обробки даних, видавці мають використовувати поточні налаштування для вимкнення персоналізації. У цій статті ці терміни – синоніми.

Надсилання запиту щодо неперсоналізованої реклами для користувачів у відповідних штатах США

Якщо ви використовуєте теги AMP AdSense або AMP DoubleClick без функції "Налаштування в реальному часі" (RTC), увімкніть режим обмеження обробки даних в інтерфейсі Google Ad Manager або AdSense. Додаткові зміни в сторінки AMP вносити не потрібно.

Якщо у ваших тегах оголошень AMP використовується Налаштування в реальному часі (RTC), запити RTC надсилатимуться, лише якщо згоду отримано або вона не потрібна. Примітка. Можна дозволити надсилати певні запити RTC незалежно від статусу згоди. Щоб система не надсилала запити RTC користувачам, яким показуватимуться неперсоналізовані оголошення (наприклад, тим, хто перебуває у відповідних штатах США), використовуйте наведені далі компоненти й конфігурації (amp-geo та amp-consent).

<!-- Налаштуйте компонент amp-geo для виявлення кінцевих користувачів зі США. Зараз цей компонент визначає місцезнаходження користувачів лише на рівні країни, але невдовзі це стане можливим і на рівні різних штатів. Переконайтеся, що ви вказали варіант unknown (для тих випадків, коли компонент amp-geo не може визначити країну) і принаймні одна група країн містить цей варіант -->
<amp-geo layout=nodisplay>
  <script type="application/json">
    {
      "ISOCountryGroups": {
        "us": ["us"],
        "eea": ["preset-eea", “unknown”]
      }
    }
  </script>
</amp-geo>

<!-- Налаштуйте компонент amp-consent так, щоб він блокував запити й отримував згоду користувачів. Пізніше ми налаштуємо автоматичне відхилення, щоб не надсилати запит на згоду. Тобто система не надсилатиме запити RTC, а Ad Manager й AdSense отримуватимуть сигнали для показу неперсоналізованих оголошень. -->
<amp-consent layout="nodisplay" id="consent-element">
  <script type="application/json">
    {
     “consentInstanceId”: “my_consent”,
      “consentRequire”: false,
“geoOverride”: {
  “us”: {
    “consentRequired”: “remote”,
    “checkConsentHref”: “https://your-endpoint” 
  }
}     
  </script>
</amp-consent>

Оскільки зараз компонент amp-geo не дає змоги виявляти користувачів із відповідних штатів США, слід скористатися параметром checkConsentHref. За допомогою цього параметра можна вказати кінцеву точку, щоб повідомляти сторінкам AMP, чи потрібно отримувати згоду від конкретного користувача. Об’єкт JSON повертатиметься з кінцевої точки на сторінку AMP. Більше інформації про це можна знайти в цьому документі.

Якщо ви не можете вказати кінцеву точку, виявити користувачів із відповідних штатів США не вдасться. Проте команда з AMP працює над функцією, яка зарадить цій проблемі. А поки що ви можете налаштувати отримання згоди від усіх користувачів зі США. Конфігурація amp-consent виглядає так:

<!-- Налаштуйте компонент amp-consent так, щоб він блокував запити й отримував згоду від усіх користувачів зі США -->
<amp-consent layout="nodisplay" id="consent-element">
  <script type="application/json">
    {
     “consentInstanceId”: “my_consent”,
      “consentRequire”: false,
“geoOverride”: {
  “us”: {
    “consentRequired”: “true”
  }
}     
  </script>
</amp-consent>

Необхідно додати атрибут data-block-on-consent в усі наявні компоненти amp-ad на сторінці, як указано нижче. _auto_reject указує, щоб оголошення не чекало отримання згоди, а система починала показ персоналізованої реклами. 

<!-- Після цього налаштуйте тег оголошення, щоб він автоматично відхиляв запит згоди -->
<amp-ad data-block-on-consent="_auto_reject"
    width=320 height=50
    type="doubleclick"
    data-slot="/4119129/mobile_ad_banner">
</amp-ad>

Показ персоналізованих або неперсоналізованих оголошень за згодою користувача

Оскільки на сторінках AMP не можна використовувати власний код JavaScript, надсиланням запитів на показ персоналізованих або неперсоналізованих оголошень керуватимуть конфігурація компонента amp-consent і атрибути data-block-on-consent та data-npa-on-unknown-consent. Якщо ви налаштували компонент amp-consent і зв’язали його з усіма тегами <amp-ad> на сторінці за допомогою data-block-on-consent, діятимуть наведені нижче умови.

  • Якщо користувач відповів згодою на запит компонента amp-consent (тобто дозволив показ), запити оголошень надсилатимуться у звичайному режимі.
  • Якщо користувач відхилив запит компонента amp-consent (тобто не дозволив показ), запитуватимуться лише неперсоналізовані оголошення.
  • Якщо відповідь користувача на запит компонента amp-consent невідома (тобто він закрив запит):
    • за умовчанням запити оголошень не надсилатимуться взагалі;
    • запитуватиметься неперсоналізована реклама (якщо атрибут data-npa-on-unknown-consent має значення true);
  • запити надсилатимуться у звичайному режимі (якщо ви налаштуєте компонент amp-geo так, що згода користувача не застосовуватиметься на основі його географічного місцезнаходження).

Якщо ваші теги <amp-ad> не використовують атрибут data-block-on-consent або компонент amp-consent налаштовано неправильно, запити надсилатимуться у звичайному режимі.

Нижче наведено приклад конфігурації, яка надсилає запит на отримання згоди користувачам із відповідних штатів США, а також показано результат цієї дії.

<!-- Налаштуйте компонент amp-geo для виявлення кінцевих користувачів зі США. Зараз цей компонент визначає місцезнаходження користувачів лише на рівні країни, але невдовзі це стане можливим і на рівні різних штатів. Переконайтеся, що ви вказали варіант unknown (для тих випадків, коли компонент amp-geo не може визначити країну) і принаймні одна група країн містить цей варіант -->

<amp-geo layout=nodisplay>
  <script type="application/json">
    {
      "ISOCountryGroups": {
        "us": ["us"],
        "unknown": ["unknown"]
      }
    }
  </script>
</amp-geo>

<!--Налаштуйте запит на отримання згоди для користувачів зі США -->

<amp-consent layout="nodisplay" id="consent-element">
  <script type="application/json">
    {
    “consentInstanceId” : “my_consent”,
      “consentRequired”: false,
      “geoOverride”: {
        “us”: {
          “consentRequired”: “true”,
          “promptUI”: “myConsentFlow”
        }
      }
    }
  </script>
  <div id=”myConsentFlow”>...</div>
</amp-consent>

<!-- Після цього налаштуйте тег оголошення, указавши, що за потреби слід очікувати на згоду користувача -->
<amp-ad data-block-on-consent
    data-npa-on-unknown-consent=true
    width=320 height=50
    type="doubleclick"
    data-slot="/4119129/mobile_ad_banner">
</amp-ad>

Ви можете використовувати власні кінцеві точки, щоб вибірково отримувати згоду користувачів. Для цього слід налаштувати надсилання запитів CORS POST зі сторінки в кінцеві точки, указані за допомогою checkConsentHref. Докладнішу інформацію про це можна знайти в документації amp-consent.

Чи корисна ця інформація?

Як можна її покращити?
true
Show your support to promote DEI in Gaming by turning intentions into action!

Check out the newly launched Diversity in Gaming website, where you can find video stories and written pledges from global gaming developers. This campaign centers on 3 pillars: diverse teams, diverse games and diverse audiences showing how diversity is not just good for gamers, but for business as well. Show your support by taking the pledge to promote DEI in Gaming and share it on social!

Learn More

Пошук
Очистити пошук
Закрити пошук
Головне меню
12382084062662772647
true
Пошук у довідковому центрі
true
true
true
true
true
73175
false
false