Get in touch
Back to archive
10.15Веб-аналитика и GTM

Спецификация DataLayer: единый контракт событий для банка

intermediate8 min readanalytics · gtm · datalayer

TL;DR

  • dataLayer - это не "куда-то пушнуть событие для GTM". Это контракт между продуктом, фронтендом, аналитикой, CRM и рекламными системами.
  • Нормальный контракт позволяет один раз описать событие и дальше маппить его в Google Ads, Meta CAPI, TikTok Events API, Yandex Metrica, GA4, BI и CRM.
  • Главное поле - стабильный идентификатор события или заявки. Без него не будет дедупликации, offline postback, value-based bidding и нормального QA.
  • PII нельзя разбрасывать по фронтенду. Email, phone, ИИН и клиентские ID должны жить в понятном consent-safe процессе, с нормализацией, хешированием и ограничением доступа.

1. Что это такое

dataLayer - это JavaScript-массив, через который сайт передает события в Google Tag Manager:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: "credit_limit_form_apply",
event_id: "evt_01HY7M9R2P",
lead_id: "REQ-112233",
value: 5000000,
currency: "KZT"
});

Сам по себе этот пуш ничего не решает. Ценность появляется, когда команда заранее договорилась, что означает каждое поле, кто его генерирует, где оно хранится и как уходит в рекламные платформы.

Плохой dataLayer: каждый подрядчик добавляет свои поля, фронтенд пушит form_submit, submitForm, lead_success, send_form, аналитик в GTM пишет Custom JS, а через месяц никто не понимает, какое событие реально означает заявку.

Хороший dataLayer выглядит как API-контракт: единая модель события, обязательные поля, дедупликация и QA-чеклист. Новый продукт добавляет product_id, а не новую аналитику.

2. Как работает механика

В банковском маркетинге событие редко заканчивается на сайте. Пользователь может увидеть рекламу, оставить телефон, пройти OTP и только через несколько дней открыть продукт.

Если dataLayer сохраняет только факт формы, рекламная система учится искать дешевые формы. Если dataLayer передает lead_id, click IDs, value и user matching fields, этот лид можно связать с CRM-результатом и отправить обратно в Google, Meta или TikTok как качественное событие.

Минимальная логика такая:

Visual brief

  • Asset: 10.15-datalayer-contract-schema.png
  • Type: process schema
  • Learning goal: показать, что dataLayer - это мост между рекламным кликом, сайтом, GTM, CRM и postback.
  • Layout: вертикальная схема сверху вниз: реклама, лендинг, dataLayer, три ветки в Web GTM, sGTM/backend и CRM, затем offline postback и возврат value в рекламные платформы.
  • Text labels: "click context", "event_id", "lead_id", "user_data", "consent", "offline value".
  • Style: Goodlabs typography-first, clean flat UI, off-white background, no glow, no stock metaphors.
  • Alt text: путь банковского события от рекламного клика до CRM-выдачи и обратной передачи value в рекламные системы.

3. Базовая схема события

Для BCC-подобного банка я бы не начинал с платформенных полей Meta или Google. Сначала нужен нейтральный внутренний контракт.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: "credit_limit_form_apply",
event_id: "evt_01HY7M9R2P",
event_time: "2026-05-06T14:30:00+05:00",
event_source: "web",
product: {
product_id: "credit_limit",
product_type: "business_credit",
funnel_step: "lead_submit"
},
value: {
amount: 5000000,
currency: "KZT",
value_type: "requested_limit"
},
identity: {
lead_id: "REQ-112233",
transaction_id: "REQ-112233",
user_id: null,
anonymous_id: "a_01HY7KZV0T"
},
user_data: {
email: "director@example.kz",
phone: "77001112233"
},
traffic: {
gclid: "EAIaIQob...",
fbclid: null,
ttclid: null,
utm_source: "google",
utm_medium: "cpc",
utm_campaign: "b2b_credit_almaty"
},
consent: {
analytics_storage: "granted",
ad_storage: "granted",
ad_user_data: "granted",
ad_personalization: "granted"
}
});

Ключевой момент: event_id и lead_id - не одно и то же.

event_id уникален для события. Он нужен для дедупликации: браузерный пиксель и серверный CAPI должны отправить один и тот же event_id.

lead_id живет дольше. Он связывает все шаги одной заявки: форма, OTP, approval, выдача, отмена.

4. Как это маппится в платформы

Внутреннее полеGoogle Ads / GA4Meta CAPITikTok Events APIYandex Metrica
eventconversion event / GA4 event nameevent_nameeventgoal / ecommerce action
event_idorder ID / event parameterevent_idevent_idcustom parameter
identity.transaction_idtransaction/order IDcustom data / dedupe helperpropertiesecommerce order id
value.amountconversion valuecustom_data.valueproperties valueecommerce revenue
value.currencycurrencycustom_data.currencycurrencycurrency
user_data.emailenhanced conversions user-provided datauser_data.em after hashingadvanced matching email after hashingusually not needed
user_data.phoneenhanced conversions user-provided datauser_data.ph after hashingadvanced matching phone after hashingusually not needed
traffic.gclidclick matchingnot usednot usednot used
traffic.fbclid, _fbc, _fbpnot usedmatch keysnot usednot used
traffic.ttclidnot usednot usedclick matchingnot used

Не надо заставлять фронтенд знать, как Meta называет email или как TikTok принимает phone. Фронтенд отправляет внутреннюю модель, а GTM, sGTM или backend переводят ее в конкретный API.

5. Примеры по банковской воронке

Lead: заявка создана

Это слабый, но полезный сигнал для базовой оптимизации и диагностики объема.

window.dataLayer.push({
event: "business_credit_lead_submit",
event_id: "evt_lead_112233",
product: { product_id: "business_credit", funnel_step: "lead_submit" },
value: { amount: 0, currency: "KZT", value_type: "none" },
identity: { lead_id: "REQ-112233", transaction_id: "REQ-112233" },
user_data: { phone: "77001112233" }
});

CompleteRegistration: OTP пройден

OTP - сильнее обычной формы: пользователь подтвердил телефон, а банк получил более чистый лид.

window.dataLayer.push({
event: "business_credit_otp_success",
event_id: "evt_otp_112233",
product: { product_id: "business_credit", funnel_step: "otp_success" },
identity: { lead_id: "REQ-112233", transaction_id: "REQ-112233" },
user_data: { phone: "77001112233" }
});

Purchase / Issue: продукт открыт или кредит выдан

Финальное событие лучше отправлять с backend или CRM. Фронт должен заранее передать lead_id, чтобы CRM outcome было к чему привязать.

{
"event_name": "business_credit_issued",
"event_id": "evt_issue_112233",
"lead_id": "REQ-112233",
"value": 18500,
"currency": "KZT",
"value_type": "expected_margin_90d"
}

Для банка value - это не всегда сумма кредита. Если передать 5 000 000 KZT как ценность, алгоритм может оптимизироваться на большой principal, а не на прибыль. Чаще правильнее передавать expected margin, комиссию, риск-скорректированную ценность или lead quality score.

6. Ошибки и диагностика

Самые частые поломки:

СимптомВероятная причинаКак чинить
Meta показывает дубли событийPixel и CAPI отправляют разные event_idГенерировать event_id один раз и прокидывать в обе стороны
Google Enhanced Conversions не проходит диагностикуemail/phone отсутствует на conversion event или не включен user-provided data flowПроверить GTM variable, consent и страницу, где доступны данные
TikTok не дедуплицирует browser и server событияevent_id есть только в Events API или только в PixelОтправлять один и тот же event_id через оба канала
CRM не может вернуть offline conversionв форме не сохранили lead_id, gclid, _fbc, ttclidСоздать click context и сохранять его вместе с заявкой
ROAS выглядит красиво, но продажи не растутв value передается лимит, сумма кредита или мусорный proxyПерейти на expected margin или validated status
Юристы блокируют запускPII передается без понятного consent и ownershipРазделить analytics consent, ads consent, PII hashing и backend ownership

Диагностика начинается не с GTM Preview, а с вопроса: "Можно ли по одной заявке пройти путь от клика до CRM-статуса и обратно?" Если нет, теги не спасут.

7. Локальный контекст РК и СНГ

В Казахстане банковская воронка часто смешанная: сайт, приложение, WhatsApp, отделение и call center. Поэтому dataLayer должен быть не просто web-аналитикой, а мостом к CRM.

Есть несколько локальных особенностей:

  • Телефон важнее email. Для matching и CRM phone обычно надежнее, но его нужно нормализовать: 8701... переводить в 7701..., убрать пробелы, скобки и плюс.
  • Kaspi-поведение изменило ожидания пользователей. Люди ждут быстрый статус, понятный next step и минимум полей. Если форма просит лишнее, CR падает.
  • WhatsApp и Telegram часто становятся продолжением воронки. Если переход в мессенджер не сохраняет lead_id, attribution ломается.
  • Банк может иметь сильный внутренний ID, включая ИИН, но это не значит, что его можно отправлять наружу. В рекламные платформы лучше отправлять разрешенные phone/email/click IDs и держать внутренние ключи внутри банка.

8. Кейс BCC: зачем нужен единый payload

В B2B-банке типичная боль такая: рекламные кампании дают заявки, но качество неизвестно. CPL выглядит дешевым, менеджеры жалуются на мусор, скоринг отсекает большую часть лидов, а рекламный кабинет продолжает оптимизироваться на форму.

Единый dataLayer решает первый слой проблемы:

  1. На первом визите сохраняются gclid, fbclid, ttclid, UTM и anonymous_id.
  2. При отправке формы создается lead_id.
  3. Все последующие web-события несут тот же lead_id.
  4. CRM получает lead_id и click context.
  5. Когда заявка проходит скоринг, одобрение или выдачу, backend отправляет offline event с ценностью.
  6. Рекламные платформы начинают получать не только лиды, но и quality feedback.

После этого маркетолог сравнивает не "Google дал 500 лидов, Meta дала 700", а "Google дал 80 одобренных заявок с expected margin X, Meta дала 60 с expected margin Y". Это разговор про P&L, а не про красивый dashboard.

9. Чеклист внедрения

  • Описаны все ключевые события воронки: view, lead, OTP, approval, issue, reject.
  • Для каждого события есть owner: frontend, backend, CRM или analytics.
  • event_id генерируется один раз на событие и используется для browser/server дедупликации.
  • lead_id сохраняется в CRM и проходит через все статусы заявки.
  • Click IDs сохраняются до гидратации SPA и до перехода в мессенджер/приложение.
  • Phone/email нормализуются до хеширования.
  • Consent status передается вместе с событием.
  • В GTM есть Data Layer Variables для всех обязательных полей.
  • Есть тестовая заявка, по которой можно показать путь от рекламы до CRM outcome.
  • В документации есть mapping table для Google, Meta, TikTok и Yandex.

Видео к теме

Google Analytics 4 Events and Key Events Tutorial

Базовый разбор событий и key events в GA4. Подходит как видео-подложка к части про event, event_id и conversion mapping.

How to install server-side Google Tag Manager with Stape

Полезно, если dataLayer дальше уходит в sGTM, Meta CAPI, TikTok Events API или backend postback.

Главный совет

Не начинайте с вопроса "какой тег поставить в GTM". Начинайте с контракта события. Если у события нет стабильного ID, owner, бизнес-смысла и связи с CRM, это шум. Хороший dataLayer должен пережить смену подрядчика, новый рекламный кабинет, переезд на sGTM и появление нового продукта. Тогда маркетинг перестает покупать лиды вслепую.

Sources / Notes