Жасырын қауіп: GA4 неліктен Kaspi арқылы жасалған төлемдердің жартысын «көрмейді» және біз оны BigQuery арқылы қалай жөндедік

06.08.2026

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

Егер сіз Қазақстанда e-commerce бизнесінің иесі болсаңыз, онда сіздің онлайн-сатылымдарыңыздың 80%-ы Kaspi Pay немесе Kaspi Магазин арқылы өтетіні анық. Ал егер сіз жарнаманың рентабельділігін (ROAS) бағалау үшін Google Analytics 4 (GA4) қолдансаңыз, сізге жаман жаңалығым бар. Сіздің аналитикаңыз сізге кем дегенде 30-50%-ға өтірік айтып тұр.

Бізге электроника сататын ірі интернет-дүкен классикалық мәселемен жүгінді: маркетологтар GA4-те 10 миллион теңге түсімді көреді, ал бухгалтерия Kaspi үзінді көшірмелері бойынша 20 миллионды көрсетеді. Google Ads және Meta Ads-тегі жарнамалық кампаниялар тиімсіз ретінде тоқтатылды, дегенмен шын мәнінде олар өте жақсы пайда әкеліп жатқан болатын.

Деректер қайда жоғалып кетті? Бұл мақалада біз стандартты GA4 пикселі күрделі төлем әдістері үшін неге жұмыс істемей қалғанын, Apple Safari (ITP) құпиялылықты қорғау механизмдері сіздің аналитикаңызды қалай құртатынын және 100% дәлдікті қайтару үшін Google Cloud пен BigQuery базасында сенімді Server-Side трекингін қалай құрғанымызды егжей-тегжейлі талдаймыз.

Транзакциялар қайда жоғалады? Мәселенің анатомиясы

GA4 деректерді неліктен жоғалтатынын түсіну үшін ұялы телефонда Kaspi арқылы типтік сатып алудың қалай жүретінін еске түсіру керек:

Пайдаланушы сіздің сайтыңызға жарнама арқылы (Instagram немесе Google-ден) өтеді. Оның браузеріне client_id бар cookie-файл ілінеді.
Ол тауарды себетке қосып, "Kaspi арқылы төлеу" түймесін басады.
Оны Kaspi.kz қосымшасына (deeplink) лақтырады. Бұл сәтте ол браузерден шығады.
Пайдаланушы тауарды Kaspi қосымшасында сәтті төлейді.
Одан әрі ең қызығы басталады. Кейбір пайдаланушылар "Дүкенге оралу" түймесін басып, /success парақшасына оралады. Бірақ пайдаланушылардың 50%-дан астамы жай ғана Kaspi қосымшасын жауып тастап, телефонын қалтасына салады. Сатып алу жасалды, сайтқа оралудың не қажеті бар?

Стандартты GA4 коды (gtag.js) тек браузерде ғана жұмыс істейді. Егер пайдаланушы сәтті төлем парақшасына оралмаса, GA4 скрипті іске қосылмайды және транзакция аналитикаға кетпейді. GA4 үшін бұл пайдаланушы мәңгілікке "тасталған себет" болып қалады.

Екінші мәселе — Apple-дің Intelligent Tracking Prevention (ITP) және браузерлердегі ұқсас жарнама блокаторлары. ITP жарнамалық cookie файлдарының қызмет ету мерзімін 24 сағатқа дейін (ал кейде first-party үшін 7 күнге дейін) қысқартады. Егер пайдаланушы жарнаманы дүйсенбіде басып, тауарды Kaspi қосымшасында сәрсенбіде төлесе, стандартты веб-трекинг бұл пайдаланушының дереккөзін жоғалтады. Транзакция (тіпті жазылған жағдайда да) Google Ads-ке емес, Direct / None арнасына түседі.

Шешім: Server-Side Tagging және BigQuery

Транзакцияны тіркеудің жалғыз сенімді жолы — деректерді пайдаланушының браузерінен (клиенттік бөліктен) емес, тікелей бэкенд-серверіңіз Kaspi API-інен сәтті төлем туралы webhook алған бойда жіберу. Бұл Server-Side Tracking (серверлік трекинг) деп аталады.

Біз Google Cloud Platform (GCP)-де келесі архитектураны жобаладық:

1. Cloud Run-дағы Google Tag Manager (Server Container)

Деректерді бэкендтен тікелей GA4-ке жіберудің орнына (бұл Measurement Protocol сұрауларын қалыптастыру үшін күрделі код жазуды талап етеді), біз Google Cloud Run базасында GTM серверлік контейнерін өрістеттік.

Оқуға ұсынамыз

Ірі WordPress жобасын Google Cloud-қа қалай көшірдік

17.07.2026

Неліктен Cloud Run? Өйткені ол автоматты түрде масштабтала алады және сіз тек нақты жұмсалған ресурстар үшін ғана тарификацияланасыз.

# Server-Side GTM-ге деректерді жіберетін Node.js (Express) webhook өңдеушісінің мысалы
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 аламыз
    
    // Біздің GTM серверлік контейнеріне HTTP-сұрау жібереміз
    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-ді базадан шығарып, серверлік GTM-ге purchase оқиғасымен бірге жібереміз. Тек осылай ғана 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%-ға төмендетті.

Google Ads-тегі клиентті тарту құны (CPA)

Машиналық оқыту алгоритмдеріне нақты Server-Side сигналдарын бергеннен кейінгі конверсия құнының (CPA) төмендеуі.

Енгізуге арналған Инсайттар мен Кеңестер (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 айтарлықтай трафик тудыруы мүмкін. gtm.js файлының артындағы сұрауларды кэштеу және есептеу қуаттарына түсетін жүктемені азайту үшін Cloud Run алдында Google Cloud CDN пайдаланыңыз.

Қорытынды

Қатаң құпиялылық ережелері мен жарнама блокаторлары дәуірінде тек браузерлік аналитикаға (Client-Side) сүйену — көзді байлап алып көлік жүргізгенмен бірдей. Сіз бұрмаланған деректер негізінде шешім қабылдайсыз.

Google Cloud Run (Server-Side GTM) + BigQuery байламы күрделі e-commerce үшін индустриалдық стандартқа айналды. Иә, бұл техникалық дағдыларды және инфрақұрылымды баптауды талап етеді. Бірақ жарнамалық бюджеттерді дұрыс бөлудің арқасында бұл инвестициялар бірінші айда-ақ өзін-өзі ақтайды.

Егер сіздің GA4-тегі сандарыңыз кассамен сәйкес келмесе — серверлік трекингке көшетін уақыт келді.

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

Инженерлік блог авторы

Google Cloud архитектурасы саласындағы сарапшы және 15 жылдан астам тәжірибесі бар Senior Full-Stack әзірлеушісі. Ақауға төзімді архитектураларға, жоғары жүктемелі жобаларды оңтайландыруға және AI (Vertex AI) интеграциясына маманданған.

Сараптама: GCP, Kubernetes, Микросервистер, React, Node.js