Часті запитання¶
Запитання позначені за аудиторією: [Баєр] для медіабаєрів та менеджерів кампаній, [DevOps] для інженерів платформи, [Обидва] для спільних запитань.
[Баєр] Чому мій відсоток покриття нижче 100%?¶
Покриття вимірює, скільки комірок «дата x тип звіту» мають дані порівняно з очікуваною кількістю. Типові причини прогалин:
- Google не надіслав звіт за цю дату (державне свято, затримка експорту).
- Автоімпорт Gmail пропустив лист (перевірте статус Gmail).
- Конкретний тип звіту недоступний для вашого сіта (наприклад, дані про якість можуть існувати не для всіх баєрів).
Перевірте сітку свіжості даних на /import, щоб побачити, які саме комірки
відсутні. Див. Імпорт даних.
[Баєр] Яка різниця між «втратами» та «низьким win rate»?¶
Втрати = запити на ставки, які ваш біддер відхилив без участі в торгах. Це QPS, за який ви заплатили, але не змогли використати взагалі. Виправляється претаргетингом.
Низький win rate = запити на ставки, на які ваш біддер зробив ставку, але програв аукціон. Це означає, що ваші ставки недостатньо конкурентні. Виправляється стратегією ставок, а не претаргетингом.
Обидва показники відображаються у воронці, але потребують різних дій. Див. Розуміння вашої воронки QPS.
[Баєр] Чи можу я скасувати зміну претаргетингу?¶
Так. Перейдіть до /history, знайдіть зміну, натисніть «Попередній перегляд
відкату», щоб побачити, що буде скасовано, потім підтвердіть. Сам відкат також
фіксується. Див. Конфігурація претаргетингу.
[Баєр] Як часто потрібно повторно імпортувати дані?¶
Щодня. Автоімпорт Gmail робить це автоматично. Якщо ви імпортуєте вручну, робіть це раз на день після надходження звітів. Застарілі дані означають застарілі рішення.
[Баєр] Що саме змінює оптимізатор?¶
Оптимізатор пропонує зміни до ваших конфігурацій претаргетингу: додавання або видалення географій, розмірів, паблішерів тощо. Він ніколи не застосовує зміни автоматично. Ви переглядаєте та затверджуєте кожну пропозицію. Див. Оптимізатор.
[DevOps] Чому суворий тест стану під час виконання не пройшов?¶
Перевірте логи робочого процесу: gh run view <id> --log-failed. Шукайте FAIL
або BLOCKED:
- FAIL = щось зламалося. Тайм-аут свіжості даних та проблеми з SET statement_timeout є частими причинами. Див. Усунення несправностей.
- BLOCKED = відсутня залежність, не обов'язково помилка коду. Приклади: немає даних про якість для цього баєра, пропозиція не має billing_id. Порівняйте з попередніми запусками, щоб відрізнити регресії від вже існуючих прогалин.
[DevOps] Чому ендпоінт свіжості даних повільний?¶
Запит сканує rtb_daily (~84M рядків) та rtb_bidstream (~21M рядків). Якщо
план запиту деградує до послідовного сканування замість використання індексів
(buyer_account_id, metric_date DESC), це займе хвилини.
Виправлення: переконайтеся, що запити використовують шаблон generate_series + EXISTS
(14 пошуків за індексом замість повного сканування таблиці). Див.
Операції з базою даних.
[DevOps] Як перевірити, яка версія розгорнута?¶
curl -sS https://scan.rtb.cat/api/health | jq -r '.git_sha,.version'
Це повертає git SHA та тег образу. Порівняйте з вашим журналом комітів.
[DevOps] Як розгорнути виправлення?¶
- Запуште до
unified-platform - Дочекайтеся успішного виконання
build-and-push.yml - Запустіть
deploy.ymlчерезgh workflow runзconfirm=DEPLOY - Перевірте через
/api/health
Див. Розгортання для повної процедури.
[DevOps] Користувачі застрягли в петлі входу. Що робити?¶
Перевірте Cloud SQL Proxy: sudo docker ps | grep cloudsql. Якщо він не працює,
перезапустіть його, зачекайте 10 секунд, потім перезапустіть контейнер API. Див.
Усунення несправностей для повної процедури.
[Обидва] Звідки Cat-Scan бере дані?¶
CSV-експорти Google Authorized Buyers. Reporting API не існує. Дані надходять або через ручне завантаження CSV, або через автоматичне отримання з Gmail. Див. Імпорт даних.
[Обидва] Чи безпечно повторно імпортувати той самий CSV?¶
Так. Кожен рядок хешується та дедуплікується. Повторний імпорт ніколи не подвоює дані.
[Обидва] Які мови підтримує інтерфейс?¶
Англійська, нідерландська та китайська (спрощена). Перемикач мови знаходиться в бічній панелі.