Когда вы интегрируете типичный SaaS SDK для рекламной медиации, весь поток событий — каждый рекламный запрос, каждый показ, каждый идентификатор пользователя — сначала отправляется на серверы поставщика. Там данные обрабатывают, обогащают и иногда возвращают в ваше хранилище копию с удалённой конфиденциальной информацией. К моменту, когда вы получаете данные, они уже прошли через систему, которую вы не контролируете.
SDK с нативной интеграцией Firebase работает наоборот. События сначала записываются в ваши собственные Firestore и BigQuery. Поставщик читает данные из вашего проекта, а не вы получаете их от него. Разница кажется чисто теоретической — до первого аудита на соответствие GDPR.
Что меняется, когда данные хранятся в вашем проекте
- Запрос на удаление данных выполняется одним запросом к Firestore — без обращения в поддержку поставщика и ожидания по SLA
- Расходы на BigQuery предсказуемы, потому что вы контролируете схему экспорта
- Миграции схемы данных проходят по вашему графику, а не по расписанию релизов поставщика
- Список субобработчиков, которых нужно раскрывать, сокращается — часто весьма существенно
Компромиссы, о которых молчат на звонке с отделом продаж
Нативная интеграция Firebase не избавляет от расходов. Вы платите Google за хранение данных и запросы, которые в другом случае обрабатывал бы поставщик. Для приложения с 5 млн DAU счёт за BigQuery составляет примерно от 400 до 1 200 долларов в месяц. Сумма заметная, но на фоне рекламного дохода, который она помогает защитить, — почти погрешность округления.
Кроме того, придётся учитывать квоты. Количество записей в Firestore в секунду, потоковые вставки в BigQuery и холодные старты Cloud Functions — реальные ограничения, которые SaaS SDK незаметно берёт на себя. В Apps Kit SDK есть механизм управления потоком записи — backpressure. Он объединяет записи в пакеты, чтобы большинство приложений с аудиторией менее 1 млн DAU оставались в пределах квот бесплатного тарифа.
За что вы на самом деле платите Google
Модель расходов скучная — и в этом её плюс: каждая статья видна в вашей консоли биллинга. Ниже приведены диапазоны затрат, которые мы наблюдаем в проектах, использующих Apps Kit SDK в 2026 году. Они учитывают механизм backpressure и автоматическое удаление партиций BigQuery через 90 дней — обе настройки включены у нас по умолчанию.
- 1 млн DAU: Firestore — 40–90 долларов, хранение в BigQuery — 20–50 долларов, запросы к BigQuery — 30–80 долларов, Cloud Functions — 10–30 долларов. Итого: менее 250 долларов в месяц
- 5 млн DAU: Firestore — 180–350 долларов, хранение в BigQuery — 100–220 долларов, запросы к BigQuery — 120–400 долларов, Cloud Functions — 40–110 долларов. Итого: 400–1 200 долларов в месяц
- 25 млн DAU: Firestore — 700–1 400 долларов, хранение в BigQuery — 450–900 долларов, запросы к BigQuery — 500–1 800 долларов, Cloud Functions — 150–400 долларов. Итого: 1 800–4 800 долларов в месяц
Настройки, которые действительно снижают расходы
Большая часть разброса в цифрах выше объясняется тремя решениями. Первое — использовать потоковые вставки в BigQuery или пакетную загрузку через GCS. Пакетная загрузка снижает стоимость приёма данных на 80% и более, но отчётность обновляется с задержкой в 30 минут. Второе — срок хранения партиций. Для всех оперативных запросов, которые нам когда-либо требовались, хватало 90 дней; более старые сырые данные стоит переносить в холодное хранилище. Третье — дисциплина работы с запросами. Один дашборд с неограниченным SELECT * по данным о показах за год может обойтись дороже всего остального вместе взятого.
Почему в 2026 году это особенно важно
В этом году два изменения в регулировании поменяли расклад. Требования DMA к переносимости данных теперь распространяются на любого поставщика, который обрабатывает данные конечных пользователей из ЕС, а переходный период перед началом правоприменения индийского DPDP завершился в марте. Оба режима предполагают, что вы можете по запросу предоставить полную выгрузку всех событий, связанных с конкретным пользователем.
Если основная система учёта данных находится у поставщика SDK, вы зависите от его инструментов экспорта. Если такой системой служит ваш проект Firebase, для выгрузки достаточно запроса, который вы уже умеете писать.
Как на практике проходит аудит на соответствие GDPR / DPDP
Когда регулятор или крупный корпоративный клиент запрашивает аудит, ему нужны четыре вещи: список всех субобработчиков, имеющих доступ к данным конечных пользователей, полная выгрузка по указанному пользователю, подтверждение удаления данных и описание сроков их хранения. С SaaS SDK первый пункт вы готовите по раскрытой поставщиком информации, следующие два — через обращения в поддержку, а четвёртый — на основе догадок.
При нативной интеграции Firebase все четыре пункта закрываются запросами под вашим контролем. Субобработчики: список сервисов GCP в вашем проекте. Выгрузка по пользователю: один запрос к Firestore и один к BigQuery, шаблоны обоих входят в SDK. Подтверждение удаления: функция Cloud Functions, возвращающая количество затронутых строк. Сроки хранения: ваша политика автоматического удаления партиций, доступная в консоли. Вместо двух недель аврала аудит занимает полдня.
Как перейти с SaaS SDK и не сломать атрибуцию
Команды боятся миграции, потому что представляют её как переход за один релиз. Мы действуем иначе. SDK с нативной интеграцией Firebase работает параллельно с существующим SaaS SDK в течение двух–четырёх недель: пишет данные в новый пайплайн, пока старый продолжает передавать их во все действующие дашборды и MMP.
- Неделя 1: интегрируйте SDK с нативной интеграцией Firebase в теневом режиме, без изменений для пользователей, и проверьте совпадение событий в BigQuery
- Неделя 2: переведите постбэки атрибуции на новый контур Firebase, оставив медиацию на старом SDK
- Неделя 3: переключите медиацию, но сохраните отправку событий через SaaS SDK в режиме «только чтение» для сверки при расхождениях
- Неделя 4: удалите SaaS SDK в следующем обновлении приложения, полностью устранив зависимость от него
Когда SaaS всё ещё выигрывает
Если ваша команда не использует Firebase и не планирует внедрять его, сопровождение SDK с нативной интеграцией Firebase действительно создаст дополнительную нагрузку. SaaS-медиация подходит студиям, которым важно интегрировать решение и забыть о нём, а также прототипам, для которых владение данными ещё не стало стратегическим преимуществом. Это не технический выбор — вопрос в том, кому вы хотите доверить контроль над журналом событий для аудита.
Владеть потоком событий — не значит просто декларировать заботу о конфиденциальности. Это разница между переговорами о следующем контракте с поставщиком с сильной позиции и переговорами, где у вас на руках только скриншот.
Что сделать в этом квартале
Если вы уже используете Firebase Analytics, то на 60% готовы к внедрению рекламного SDK с нативной интеграцией Firebase — и, скорее всего, даже не подозреваете об этом. Выделите спринт на описанную выше интеграцию в теневом режиме и принимайте решение по отчёту о совпадении данных, а не по продающей презентации. Большинство команд, завершивших теневой этап, решают полностью перейти на новую схему в течение 90 дней.
