Закон суров: Как легально использовать Google Analytics в Казахстане и не получить штраф за утечку ПДн
Представьте ситуацию: вы запустили крутой e-commerce проект, прикрутили к нему Google Analytics 4 (GA4), настроили сквозную аналитику и спокойно льете трафик. Цифры сходятся, ROAS радует, жизнь прекрасна. А потом в один непрекрасный день к вам в офис стучится регулятор (Министерство цифрового развития) и выкатывает штраф, от которого у финдиректора начинает дергаться глаз.
За что? А за то, что вы, сами того не ведая, сливаете персональные данные (ПДн) граждан Казахстана на сервера дяди Сэма в США, нарушая Закон РК «О персональных данных и их защите». И незнание закона, как известно, не освобождает от ответственности (а от штрафов — тем более).
«Ну всё, тушите свет, удаляем GA4 и переходим на счетчики из 2000-х», — скажет паникер. «Подержите мое пиво», — скажет Data Engineer. В этой статье мы разберем (с щепоткой инженерного юмора и реальными примерами кода), как настроить аналитику так, чтобы и юристы были довольны, и маркетологи не плакали от нехватки данных.
Где прячется состав преступления? (Что не так с базовым GA4)
Закон РК четко говорит: сбор и обработка ПДн возможны только с согласия субъекта, а хранение баз данных должно осуществляться на территории Казахстана. Что происходит, когда вы просто вставляете стандартный gtag.js на сайт?
- IP-адрес юзера летит в Google: Да, IP-адрес может быть признан косвенными персональными данными. Google, конечно, клянется, что в GA4 IP-адреса анонимизируются по умолчанию, но до того, как они будут анонимизированы, они физически пересекают границу РК.
- PII (Personally Identifiable Information) в URL: Разработчик Вася забыл настроить метод POST для формы регистрации, и теперь email пользователя (
?email=vasya@mail.kz) летит прямиком в отчеты GA4. За это Google может не только забанить ваш аккаунт (по своим правилам), но и регулятор задаст вопросы. - User-ID: Вы радостно передаете номер телефона или ИИН в качестве
user_idдля кросс-девайс трекинга. Бинго! Статья обеспечена.
Архитектура спасения: Серверный GTM как «чистилище» данных
Чтобы спасти ситуацию, мы не можем отправлять данные напрямую из браузера пользователя в Google. Нам нужен посредник — эдакое «чистилище», которое будет принимать сырые данные, вырезать из них все незаконное и только потом отправлять в буржуйские дата-центры. Этот посредник — Server-Side Google Tag Manager (sGTM).
Схема выглядит так:
- Браузер отправляет данные не на
google-analytics.com, а на ваш собственный поддомен (например,metrics.yoursite.kz). - Этот поддомен смотрит на сервер в казахстанском дата-центре (или на легальном облаке).
- Серверный GTM берет запрос, безжалостно вырезает из него PII (хэширует email-ы, дропает точные IP-адреса, меняя их на гео-координаты).
- «Обезличенный» лог улетает в GA4. Закон соблюден.
// Пример кастомного Client-скрипта в sGTM для очистки PII
const claimRequest = require('claimRequest');
const getRequestPath = require('getRequestPath');
const setPixelResponse = require('setPixelResponse');
const log = require('logToConsole');
const computeSHA256 = require('sha256Sync');
// Перехватываем запрос с фронтенда
let url = getRequestPath();
// Если в URL затесался email - хэшируем его от греха подальше
if (url.indexOf('@') > -1) {
const rawEmail = url.match(/([a-zA-Z0-9._-]+@[a-zA-Z0-9._-]+.[a-zA-Z0-9_-]+)/gi)[0];
const hashedEmail = computeSHA256(rawEmail.toLowerCase());
url = url.replace(rawEmail, hashedEmail);
log('PII Sanitized: Email hashed.');
}
// Удаляем IP-адрес из полезной нагрузки, оставляем только страну/город (это легально)
const eventData = claimRequest();
delete eventData.ip_override;
// Отправляем очищенные данные дальше по пайплайну
setPixelResponse('Sanitization complete', 200);Google Consent Mode v2: Когда "Да" значит "Да", а "Нет" — это головная боль маркетолога
В 2024 году Google выкатил Consent Mode v2. Если вы таргетируетесь на Европу (GDPR), это уже мастхэв, но и для стран СНГ это отличный инструмент соблюдения комплаенса. Суть в том, что пока пользователь не нажал кнопку «Согласен» на дурацком поп-апе с куки-файлами, GA4 работает в «бескуки» режиме (Cookieless pings).
O2O (Offline-to-Online) аналитика: Как связать клики из Google Ads с реальными визитами в точки продаж в Алматы через BigQuery
Как это выглядит под капотом?
- Пользователь зашел, но не дал согласие (
ad_storage='denied',analytics_storage='denied'). - Браузер НЕ сохраняет
_gaкуки (Client ID). - Данные о просмотре страниц все равно улетают на сервер, но они полностью анонимны и не связаны в сессии.
- В GA4 эти данные используются для поведенческого моделирования (Behavioral Modeling) на основе машинного обучения. Алгоритм «достраивает» картину, угадывая, откуда пришел этот аноним, опираясь на данные тех, кто согласие дал.
Инженерная боль: Внедрение Consent Mode требует филигранной настройки Data Layer. Если вы просто скроете баннер через CSS, вас ждут сюрпризы в виде полностью пустых отчетов. Триггеры в GTM должны стрелять строго ПОСЛЕ события consent_update.
Потеря данных: Базовый GA4 vs Consent Mode v2
Процент учтенных сессий при отказе пользователя от cookies (отказ = 40% трафика).
BigQuery: Экспорт без компромиссов
Многие компании экспортируют сырые данные из GA4 в BigQuery для глубокой аналитики. И тут возникает вопрос: а где физически находится ваш BigQuery датасет? Если он в США, то передача туда нехэшированных данных (например, User-ID, который вы связали с телефоном в вашей CRM) — это опять нарушение.
Как делать правильно (Data Engineering Best Practices):
- Создавайте датасет BigQuery в европейской юрисдикции (которая признается РК обеспечивающей адекватную защиту) или используйте локальные DWH.
- Никогда не передавайте в GA4 открытые персональные данные. Используйте SHA-256 хэширование с солью (salt) еще на стороне бэкенда до отправки в Data Layer.
- В BigQuery ваши дата-аналитики будут джоинить (JOIN) данные GA4 с базой данных CRM именно по этому хэшу. Аналитика работает, PII не утекает. Шах и мат, проверяющие!
Экономика комплаенса: Штрафы vs Настройка
Сравнение потенциальных штрафов за утечку ПДн с затратами на внедрение Server-Side GTM.
Инсайты и Советы (Tips & Tricks)
- Аудит на регулярках: Настройте автоматический алерт (через Cloud Functions), который будет парсить логи sGTM и искать совпадения по RegEx на email, ИИН (12 цифр) и номера телефонов. Если скрипт нашел PII — бейте тревогу и чините фронтенд.
- Следите за субподрядчиками: Убедитесь, что ваше рекламное агентство не устанавливает левые пиксели через GTM в обход серверного контейнера. Включите GTM Approval Workflow (когда изменения публикует только ваш Senior Engineer).
- First-Party Data — король: Собирайте данные сами, храните их у себя (в KZ), а в рекламные кабинеты (Google/Meta) отправляйте только агрегированные и хэшированные сигналы через Conversions API (CAPI).
Итоги: Комплаенс — это не конец света
Защита персональных данных — это не просто прихоть юристов, это глобальный тренд. Настроить легальную аналитику в Казахстане можно, и это не требует отказа от мощных инструментов вроде GA4.
Да, это требует перехода от простой вставки скрипта в <head> к полноценной Server-Side архитектуре. Да, ваши инженеры выпьют не один литр кофе, настраивая sGTM и Consent Mode. Но зато вы получите не просто «законную» аналитику, а более чистые данные (потому что sGTM обходит блокировщики рекламы) и крепкий сон для вашего финдиректора. А крепкий сон, как известно, бесценен.
Рустам Шарафутдинов
Эксперт в области архитектуры Google Cloud и Senior Full-Stack разработчик с более чем 15-летним опытом. Специализируется на отказоустойчивых архитектурах, оптимизации высоконагруженных проектов и интеграции AI (Vertex AI).