Скрытая угроза: Почему GA4 «не видит» половину оплат через Kaspi и как мы починили это с помощью BigQuery

06.08.2026

Шарафутдинов Р.

Если вы владелец e-commerce бизнеса в Казахстане, то скорее всего 80% ваших онлайн-продаж проходит через Kaspi Pay или Kaspi Магазин. И если вы используете Google Analytics 4 (GA4) для оценки рентабельности рекламы (ROAS), у меня для вас плохие новости. Скорее всего, ваша аналитика врет вам минимум на 30-50%.

К нам обратился крупный интернет-магазин электроники с классической проблемой: маркетологи видят в GA4 выручку в 10 миллионов тенге, а бухгалтерия по выпискам из Kaspi показывает 20 миллионов. Рекламные кампании в Google Ads и Meta Ads останавливались как неэффективные, хотя на самом деле они приносили отличную прибыль.

Куда пропадали данные? В этой статье мы подробно разберем, почему стандартный пиксель GA4 больше не работает для сложных способов оплаты, как механизмы защиты приватности Apple Safari (ITP) уничтожают вашу аналитику, и как мы построили надежный Server-Side трекинг на базе Google Cloud и BigQuery, чтобы вернуть 100% точность.

Куда пропадают транзакции? Анатомия проблемы

Чтобы понять, почему GA4 теряет данные, нужно вспомнить, как происходит типичная покупка через Kaspi на мобильном телефоне:

Пользователь переходит на ваш сайт с рекламы (в Instagram или Google). На его браузер вешается cookie-файл с client_id.
Он добавляет товар в корзину и нажимает "Оплатить через Kaspi".
Его перекидывает в приложение Kaspi.kz (deeplink). В этот момент он покидает браузер.
Пользователь успешно оплачивает товар в приложении Kaspi.
Дальше происходит самое интересное. Некоторые пользователи нажимают кнопку "Вернуться в магазин" и возвращаются на страницу /success. Но более 50% пользователей просто смахивают приложение Kaspi и кладут телефон в карман. Покупка совершена, зачем возвращаться на сайт?

Стандартный код GA4 (gtag.js) работает только в браузере. Если пользователь не вернулся на страницу успешной оплаты, скрипт GA4 не сработает, и транзакция в аналитику не уйдет. Для GA4 этот пользователь навсегда останется "брошенной корзиной".

Вторая проблема — Intelligent Tracking Prevention (ITP) от Apple и аналогичные блокировщики рекламы в браузерах. ITP обрезает срок жизни рекламных cookie до 24 часов (а иногда и до 7 дней для first-party). Если пользователь кликнул на рекламу в понедельник, а оплатил товар в приложении Kaspi в среду, стандартный веб-трекинг потеряет источник этого пользователя. Транзакция (даже если она запишется) попадет в канал Direct / None, а не в Google Ads.

Решение: Server-Side Tagging и BigQuery

Единственный надежный способ зафиксировать транзакцию — отправлять данные не из браузера пользователя (клиентская часть), а напрямую с вашего бэкенд-сервера, как только он получает webhook об успешной оплате от API Kaspi. Это называется Server-Side Tracking (серверный трекинг).

Мы спроектировали следующую архитектуру в Google Cloud Platform (GCP):

1. Google Tag Manager (Server Container) в Cloud Run

Вместо отправки данных напрямую из бэкенда в GA4 (что требует написания сложного кода для формирования Measurement Protocol запросов), мы развернули серверный контейнер GTM на базе Google Cloud Run.

Рекомендуем к прочтению

Масштабирование бессерверных микросервисов в Google Cloud Run

16.07.2026

Почему Cloud Run? Потому что он умеет автомасштабироваться и вы тарифицируетесь только за фактически потребленные ресурсы.

# Пример webhook-обработчика на Node.js (Express), который отправляет данные в Server-Side GTM
app.post('/api/kaspi-webhook', async (req, res) => {
  const { orderId, amount, status } = req.body;
  
  if (status === 'SUCCESS') {
    const order = await db.getOrder(orderId); // Получаем данные заказа и client_id
    
    // Отправляем HTTP-запрос на наш серверный контейнер GTM
    await fetch('https://gtm.yourdomain.kz/mp/collect', {
      method: 'POST',
      body: JSON.stringify({
        client_id: order.ga_client_id, // Критически важно передать тот самый client_id из браузера
        events: [{
          name: 'purchase',
          params: {
            transaction_id: orderId,
            value: amount,
            currency: 'KZT',
            items: order.items
          }
        }]
      })
    });
  }
  res.sendStatus(200);
});

Самое важное здесь — это склейка сессий. Когда пользователь изначально заходит на сайт, наш бэкенд должен поймать его _ga cookie (Client ID) и сохранить в базу данных вместе с черновиком заказа. Когда от Kaspi приходит вебхук об оплате, мы достаем этот client_id из базы и отправляем вместе с событием purchase на серверный GTM. Только так GA4 свяжет покупку с первоначальным кликом по рекламе.

2. BigQuery: Единый источник правды

GA4 — отличный инструмент для маркетологов, но у него есть ограничения: лимиты на хранение данных (до 14 месяцев), проблемы с кардинальностью (сообщения "(other)" в отчетах) и сэмплирование данных.

Чтобы избежать этих проблем, мы настроили ежедневный экспорт сырых данных из GA4 напрямую в Google BigQuery — мощное хранилище данных (Data Warehouse). В BigQuery мы объединяем данные из GA4, выгрузки расходов из Google Ads/Meta (через сервисы-коннекторы) и данные из CRM-системы.

Доля учтенных транзакций в GA4 от реальной базы (CRM)

Сравнение Client-Side и Server-Side трекинга по неделям. Целевой показатель — 100%.

Как видно из графика выше, после внедрения Server-Side трекинга в середине февраля, количество отслеживаемых транзакций в GA4 практически сравнялось с реальными данными из CRM. Расхождение сократилось с 45% до статистической погрешности в 2-3% (которая возникает из-за возвратов или отмененных платежей).

Преимущества Server-Side интеграции (СГТ)

Что дал этот подход нашему клиенту?

Точность ROAS: Маркетологи наконец-то увидели реальную окупаемость рекламы. Кампании, которые считались убыточными и отключались, оказались главными драйверами прибыли.
Обход блокировщиков (ITP/Adblock): Поскольку серверный GTM развернут на субдомене клиента (например, metrics.client.kz), cookie-файлы устанавливаются от первого лица (First-Party) и не блокируются Safari ITP.
Обучение алгоритмов: Точные данные о конверсиях передаются обратно в Google Ads и Meta Pixel (через Conversions API). Умные кампании (Performance Max) получили больше качественных сигналов и снизили стоимость привлечения клиента (CPA) на 22%.

Стоимость привлечения клиента (CPA) в Google Ads

Снижение стоимости конверсии (CPA) после передачи точных Server-Side сигналов в алгоритмы машинного обучения.

Инсайты и Советы (Tips & Tricks) для внедрения

Настройте First-Party Domain: Если ваш сайт работает на example.kz, серверный GTM должен висеть на gtm.example.kz. Иначе Safari будет блокировать ваши куки точно так же, как и сторонние.
Передавайте User Data: Отправляйте не только client_id, но и хэшированные email-адреса или телефоны клиентов (User ID). Это позволит GA4 распознать пользователя, даже если он кликнул на рекламу с телефона, а завершил оплату на компьютере (Cross-Device Tracking).
Следите за расходами на Cloud Run: Серверный GTM может генерировать приличный трафик. Используйте Google Cloud CDN перед Cloud Run, чтобы кэшировать запросы за файлом gtm.js и снизить нагрузку на вычислительные мощности.

Итоги

В эпоху жестких правил приватности и блокировщиков рекламы полагаться только на браузерную аналитику (Client-Side) — это всё равно что ехать с завязанными глазами. Вы принимаете решения на основе искаженных данных.

Связка Google Cloud Run (Server-Side GTM) + BigQuery стала индустриальным стандартом для серьезного e-commerce. Да, это требует технических навыков и настройки инфраструктуры. Но эти инвестиции окупаются в первый же месяц благодаря корректному распределению рекламных бюджетов.

Если ваши цифры в GA4 не сходятся с кассой — самое время переходить на серверный трекинг.

Рустам Шарафутдинов

Автор инженерного блога

Эксперт в области архитектуры Google Cloud и Senior Full-Stack разработчик с более чем 15-летним опытом. Специализируется на отказоустойчивых архитектурах, оптимизации высоконагруженных проектов и интеграции AI (Vertex AI).

Экспертность: GCP, Kubernetes, Микросервисы, React, Node.js