Headless E-Ticarette Analytics Neden Bozulur? SPA, Page View ve Attribution Problemleri

Headless commerce migration'larında en fazla gözden kaçan problemlerden biri analytics'tir.

Site tasarım olarak kusursuz çalışabilir, sepet ve checkout çalışabilir, performans iyileşebilir.

Ama birkaç hafta sonra ekip şunu fark eder:

• GA4 oturumları düştü.
• Page view'lar eksik.
• Meta conversion'ları farklı.
• Landing page raporları anlamsız.

Problem çoğu zaman reklam platformunda değildir.

Storefront'un navigation modeli değişmiştir.

Klasik web tracking nasıl çalışıyordu?

Klasik multi-page application'da kullanıcı route değiştirdiğinde browser yeni document request oluşturur.

Analytics script:

page load → page_view

mantığıyla çalışabilir.

Headless SPA mimarisinde ise URL değişir ve UI değişir ama yeni page load olmayabilir.

GA4 otomatik page view yeterli mi?

Her zaman değil.

Uygulamanın router lifecycle'ı analytics event layer ile entegre edilmelidir.

Örneğin:

Router navigation completed

↓

Normalized page context

↓

Analytics event

↓

GA4 / Meta / Internal analytics

Yanlış yaklaşım

Her page component içinde useEffect(() => sendPageView(), []) kullanmak zamanla duplicate veya missing event üretebilir.

Tracking UI component lifecycle'ına fazla bağımlı hale gelir.

Doğru yaklaşım

Framework seviyesinde route transition tamamlandığında tek bir canonical event üretilir.

Örneğin:

commerce.page_view

payload:

• url
• path
• page_type
• product_id
• collection_id
• referrer
• customer_state
• timestamp

Sonra adapter'lar bu event'i kendi formatlarına dönüştürür.

Product view da aynı problem

Client-side navigation'da ürün sayfası değiştiğinde view_item event'i eksik veya duplicate olabilir.

Event component rendered değil, commerce state transitioned mantığına bağlanmalıdır.

Cart tracking daha da karmaşık

PDP button, quick add, recommendation carousel, drawer ve agent gibi farklı giriş noktaları aynı cart mutation'ı yaratabilir.

İdeal architecture:

Cart Mutation → Commerce Event → UI + Analytics

şeklindedir.

Server-side tracking sorunu tamamen çözer mi?

Hayır.

Server-side tracking purchase gibi doğrulanmış transaction event'lerinde çok güçlüdür.

Ama page view, search, filter ve UI interaction gibi event'ler browser tarafında anlamlıdır.

İdeal yapı çoğunlukla hibrittir.

Purchase nereden gönderilmeli?

Revenue event'leri mümkün olduğunca doğrulanmış commerce state'inden gelmelidir.

payment verified → order paid → purchase event

Ancak browser event'leriyle server event'lerinin duplicate oluşturmayacağı bir deduplication strategy gerekir.

Consent headless storefront'ta unutulmamalı

Headless migration sırasında analytics kodları yeniden yazılırken consent state kolayca kaybolabilir.

Attribution neden bozulabilir?

Kullanıcı Google Ads → landing page → client-side navigation → checkout akışından geçtiğinde ilk acquisition context korunmalıdır.

UTM, referrer ve checkout attribution state'i doğru taşınmalıdır.

Checkout başka domain ise?

Cookie scope, client ID, checkout attribution ve platform-specific session transfer mekanizmaları incelenmelidir.

Analytics event contract nasıl tasarlanmalı?

Headless analytics test checklist

• Initial page view geliyor mu?
• Client navigation page view üretiyor mu?
• Back/forward navigation ölçülüyor mu?
• Product değişiminde view_item doğru mu?
• Quick add ölçülüyor mu?
• Cart drawer ölçülüyor mu?
• Quantity change ölçülüyor mu?
• Search event'i var mı?
• Filter event'i var mı?
• Checkout attribution korunuyor mu?
• Purchase backend siparişiyle eşleşiyor mu?
• Duplicate purchase var mı?
• Consent state navigation boyunca korunuyor mu?
• UTM parametreleri kayboluyor mu?
• GA4 ve backend revenue farkı ölçülüyor mu?
• Meta event ID stratejisi var mı?

Observability eklenmeli

Internal dashboard gerçek sipariş sayısı ile GA4/Meta purchase sayılarını karşılaştırabilir ve fark belirli eşik üzerine çıkınca alert üretebilir.

Headless'ta page view neden doğal olarak gelmez?

SPA/headless uygulamada route client-side değişebilir.

Analytics layer:

• route completed,
• document title,
• canonical URL,
• referrer semantics

bilgisini uygulama router'ından almalıdır.

Event contract UI component'ine bağlı olmamalı

Kötü: ProductCard onClick → select_item

Daha doğru:

commerceAnalytics.selectItem({
  product,
  list_context,
  position
})

Session boundary

Storefront ile checkout farklı domain/subdomain ise:

• linker/cross-domain,
• session continuity,
• consent state,
• click identifiers,
• first-party cookie scope

kontrol edilmelidir.

Server + browser event ownership

Bu tablo projeye göre değişir; amaç event'in rastgele iki yerde uygulanmasını önlemektir.

Event ID contract

purchase:{order_id}
cart:{cart_id}:line-added:{operation_id}

gibi deterministik kimlikler reconciliation sağlar.

Consent-aware event pipeline

Event oluşur → consent policy değerlendirilir → izin verilen destination'lara route edilir.

Tracking QA CI'ya girebilir

Playwright/Cypress ile PDP açma, varyant seçme, add-to-cart ve checkout-start network/dataLayer assertion yapılabilir.

Reconciliation

orders
analytics_purchase
meta_purchase
google_ads_conversion

order_id/event_id üzerinden eşleştirilebilir.

Performance cost

Her destination için:

• lazy load,
• consent gating,
• worker/server routing,
• performance budget

değerlendirilmelidir.

Analytics architecture için event catalog

Her event dokümanında:

• event name,
• trigger,
• owner,
• required properties,
• source,
• destination,
• PII classification

bulunmalıdır.

Bu catalog yoksa ekipler aynı davranışı farklı adlarla ölçmeye başlar.

Data quality score

Haftalık:

• missing event rate,
• duplicate event rate,
• schema error,
• backend reconciliation delta

tek health score altında raporlanabilir.

Sonuç

Headless storefront'a geçiş yalnız frontend framework değişimi değildir.

Browser lifecycle değiştiği için analytics lifecycle da değişir.

Reliefers olarak headless veya özel storefront projelerinde analytics'i proje bittikten sonra GTM kurulacak ayrı bir katman olarak değil, commerce architecture'ın parçası olarak tasarlıyoruz.