Як заповнити заявку на Basic Access до Google Ads API

Подавали заявку на Basic Access до Google Ads API - розібрав основні поля, які викликали труднощі. На заповнення цього всього щастя пішло півдня. Тому надіюся, що це допоможе Вам скоротити час на заповнення і уникнути відхилення заявки. 

І бонус приклад того, як має виглядає Google Ads API Tool Documentation для Вашого інструменту.

Головний принцип форми

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

Опис бізнес-моделі й інструмента

Тут недостатньо одного речення на кшталт "потрібен для роботи з клієнтами" - рев'юер шукає три окремі відповіді: бізнес-модель, конкретний інструмент, аудиторія. Структура, яка спрацювала:

• Business model - хто ви юридично. Я подавав, що ми агенція, яка керує рекламою клієнтів через MCC-структурою. Я подавав приблизно такий текст:

“Business model: {Company name} (website) is a digital marketing agency that manages Google Ads campaigns for clients in the e-commerce, real estate, and education sectors. Client advertising accounts are connected to our manager account, and our revenue comes from fees charged for campaign management services.”

• API tool - що саме робить інструмент, розписано по пунктах: звітність (які метрики, навіщо), автоматизація (які саме дії, за якими правилами), keyword research. Якщо в інструмент вбудований AI-асистент - це варто вказати прямо, а не приховувати: Google вже знайомий зі сценарієм "AI читає дані Google Ads" через власний офіційний MCP-сервер, тож це не викликає підозр, якщо чітко написано, що фінальні зміни в акаунтах затверджує людина.
  
  Мій текст виглядав приблизно так:

API tool: We are developing an internal platform that:

• Uses reporting features to collect campaign, ad group, and keyword performance data for automated client reporting and monitoring of KPIs such as CPA, CPQL, and ROAS.
• Supports routine campaign-management tasks, including bid and budget adjustments and pausing underperforming ads based on predefined rules.
• Uses keyword-planning features to research search terms when creating new campaigns for clients.

The platform also connects to Anthropic’s Claude through API/MCP integration. The AI assistant helps our marketing specialists analyze performance data, summarize findings, and prepare optimization recommendations. Any proposed changes to client accounts are reviewed and approved by our specialists before implementation.

• Intended audience

Три варіанти: internal users / external users / both. Це не формальність  від відповіді залежить, наскільки суворо розглядатимуть заявку. Internal (лише співробітники) - найпростіший шлях: інструмент не потребує повної верифікації сторонніх користувачів.

Я подавав приблизно ось такий текст:

This tool is intended solely for internal use by our agency’s marketing team. It will not be accessible to external users or third parties. Client data will be processed exclusively to manage and support each respective client’s account. The anticipated usage will remain within the Basic Access limit of 15,000 operations per day.

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

Чи використовуєте інструмент, розроблений кимось іншим

Тут пастка для тих, хто підключає готові рішення (MCP-сервери, no-code платформи, сторонні дашборди) і відповідає "No", бо "ми ж самі все налаштовуємо". Логіка інша: якщо код інструмента написаний не вами (навіть офіційний Google Ads MCP-сервер) — це "Yes", з вказанням URL репозиторію. Чесна відповідь тут не шкодить: рев'юер бачить знайомий, легітимний інструмент, а не намагання приховати технологію.

App Conversion Tracking and Remarketing API - окреме питання

Легко сплутати з "просто conversion tracking у Google Ads". Насправді це окремий API для розробників мобільних застосунків і атрибуційних платформ (на кшталт AppsFlyer). Якщо ваші кампанії — веб, а не мобільний застосунок, відповідь тут No, навіть якщо ви активно працюєте з offline conversion tracking через Enhanced Conversions — це інший функціонал.

Campaign types і Capabilities - де перевіряється консистентність найжорсткіше

Список типів кампаній (Search, Performance Max, Display тощо) і чекбокси capabilities (Account Creation, Account Management, Campaign Creation, Campaign Management, Reporting, Keyword Planning) - це поля, які рев'юер звірятиме з PDF-документацією буквально по пунктах.

Правило: відмічайте лише те, що реально плануєте робити зараз, а не "про запас". Наприклад:

1. Account Creation / Account Management - це про програмне створення й адміністрування самих акаунтів (доступи, білінг, лінкування). Якщо ви лінкуєте акаунти вручну через інтерфейс - не відмічайте, навіть якщо технічно колись могли б.
2. Campaign Creation / Campaign Management - це ядро агентського інструмента: бюджети, ставки, статуси оголошень.
3. Keyword Planning Services - окремо, якщо є KeywordPlanIdeaService у ваших планах.

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

Ongoing relationship with a Google representative

Просте так/ні: чи є закріплений акаунт-менеджер від Google. Дзвінки від "менеджерів з оптимізації" не рахуються - це зазвичай аутсорс-підтримка, не персональний контакт. Для більшості агенцій чесна відповідь - "No", і це ніяк не впливає на рішення по заявці.

Документація інструмента (окремий PDF)

Google просить структуру: Company Name → Business Model → Tool Access/Use → Tool Design → API Services Called → мокапи інтерфейсу (якщо інструмент зовнішній - обов'язково, якщо внутрішній - теж підсилює заявку). Головне тут - секція API Services Called має називати конкретні сервіси (GoogleAdsService, CampaignService, KeywordPlanIdeaService тощо), а не загальні фрази "будемо використовувати API для реклами".

Додаю посилання на зразок.

Branding в Google Cloud Console - окрема, але тісно пов'язана частина

Заявку на Basic Access розглядають не у вакуумі - паралельно дивляться на стан вашого Cloud-проєкту. Якщо consent screen порожній чи недозаповнений, це так само сповільнює розгляд, як і слабкий опис у самій формі. Пройшовся по кожному полю Branding окремо, бо тут теж є логіка, а не просто "заповни що просять".

App name. Два правила: не можна використовувати слово "Google" в назві (заборонено правилами брендингу, і застрягне на перевірці), і не варто називати просто іменем компанії — назва має відображати, що це саме інструмент, а не сайт агенції. У нас вийшло щось на кшталт "Ads Hub" - одразу зрозуміло, що це internal tool, а не маркетингова сторінка.

User support email. Тут випадаючий список дає обрати лише email власника Cloud-проєкту або Google Group - тільки той, що прив'язаний до акаунта, яким створювали проєкт.

App logo. Свідомо не завантажували. Нюанс: додавання логотипа тригерить обов'язкову бренд-верифікацію consent screen - окремий процес, який для internal-інструмента просто не потрібен. Без лого сторінка авторизації працює нормально, це не обов'язкове поле.

App domain — тут три підполя, і кожне має свою логіку:

1. Application home page - просто сайт компанії
2. Privacy policy link - саме тут ми зрозуміли, що готової сторінки на сайті ще немає, довелось писати окремо. Без неї Google не дає рухатись далі на sensitive scope
3. Terms of service - так само, окрема сторінка, публічно доступна

Обидві сторінки писали з одним обов'язковим блоком - розділом, що прямо описує: які саме дані з Google Ads API отримує застосунок, з якою метою, і посилання на Google API Services User Data Policy з Limited Use requirements. Без цього посилання заявки на sensitive-scope застосунки часто відхиляють ще на етапі перевірки consent screen, ще до розгляду самої форми на Basic Access.

Authorized domains. Домен без https:// і без www - просто сайт компанії. Важливий технічний момент: Cloud Console не дозволить додати домен, поки він не верифікований у Google Search Console під тим самим Google-акаунтом. Якщо верифікації ще немає — це окремий крок, який варто зробити заздалегідь, а не в момент заповнення Branding.

Developer contact information — email, куди Google шле технічні сповіщення про проєкт. 

Scopes. Окрема вкладка Data Access. Додавали рівно один scope —  https://www.googleapis.com/auth/adwords, повний доступ до Google Ads API.

User type: Internal vs External. Якщо у компанії є Google Workspace на власному домені — можна обрати Internal, і тоді взагалі не потрібна верифікація застосунку, а refresh-токени не мають терміну дії. Без Workspace лишається External - тоді на етапі Testing (поки не подали на повну верифікацію) є ліміт 100 користувачів і кожен email, який буде авторизовуватись, треба вручну додати в Test users.

Publishing status: чому лишили Testing. Спокуса натиснути "Publish app" є, але для internal-інструмента це зайвий крок: перехід у Production з sensitive scope рано чи пізно вимагає повної верифікації застосунку (окремий процес із демо-відео і обґрунтуванням). Для Basic Access токена це не потрібно — статусу Testing достатньо, аби consent screen був повністю налаштований. Плата за це — refresh-токен живе 7 днів, раз на тиждень доводиться переавторизовуватись, але це прийнятний компроміс на етапі, поки інструмент не пішов у постійну щоденну експлуатацію.

Підсумок

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