Gizlilik

E-Ticaret Reklamlarında Veri Kaybını Önleme: iOS, Çerez ve Tracking Rehberi

DEData4Ad Ekibi9 Ekim 202617 dk okuma

Güvenilir içerik: Yazılarımız yayına alınmadan önce teknik doğruluk açısından gözden geçirilir. Ürün iddialarımızı ölçülebilir olanla sınırlı tutarız.

E-ticaret reklamlarında veri kaybı, dönüşüm eventlerinin eksik veya hatalı işlenmesidir. Purchase eventi hiç üretilmeyebilir. Event reklam platformuna ulaşmayabilir. Platform eventi kullanıcıyla eşleştiremeyebilir. Satış farklı bir kanala atfedilebilir.

iOS gizlilik kontrolleri, Safari kısıtları ve consent tercihleri farklı sorunlar oluşturur. Hatalı Pixel ve CAPI kurulumları da teknik kayıp yaratır.

Server-side tracking bazı kayıpları azaltır. Ancak kullanıcı rızasını geçersiz kılmaz. Yanlış sipariş statüsünü düzeltmez. Bütün reklam panellerini eşitlemez.

Buradaki amaç gizlilik kontrollerini aşmak değildir. Amaç, izinli veriyi daha dayanıklı ve doğrulanabilir biçimde işlemektir.

Sağlıklı ölçüm şu katmanları birlikte yönetir:

Kullanıcı rızası
Browser eventleri
First-party veri
Server eventleri
Event deduplication
Platform eşleştirmesi
Sipariş mutabakatı

Reklam Veri Kaybı Nedir?

Reklam veri kaybı tek bir teknik problemi ifade etmez.

Bir WooCommerce mağazasında 100 geçerli sipariş bulunabilir. Meta Ads yalnızca 72 Purchase gösterebilir. Google Ads 34 dönüşüm raporlayabilir. GA4 ise 89 satın alma kaydedebilir.

Bu fark doğrudan 28 siparişin kaybolduğu anlamına gelmez.

Sistemler farklı sorulara cevap verir:

WooCommerce sipariş oluşumunu kaydeder.
Ödeme sistemi tahsilatı kaydeder.
Meta Ads kendi reklam temasını değerlendirir.
Google Ads kendi dönüşüm tanımını kullanır.
GA4 kullanıcı yolculuğunu raporlar.
Muhasebe net geliri hesaplar.

Bu nedenle önce farkın türü belirlenmelidir.

1. Teknik Event Kaybı

Teknik kayıpta event hiç üretilmez veya hedefe ulaşmaz.

Yaygın nedenler:

Meta Pixel yüklenmez.
Google tag çalışmaz.
JavaScript hata verir.
Ad blocker isteği engeller.
Kullanıcı sayfayı erken kapatır.
Checkout yönlendirmesi tamamlanmaz.
Webhook başarısız olur.
Server tag hata verir.
API isteği zaman aşımına uğrar.
Consent durumu yanlış uygulanır.

Bu senaryoda satış mağazada bulunur. Ancak reklam veya analitik platformuna ulaşmaz.

2. Kimlik Eşleştirme Kaybı

Event platforma ulaşabilir. Ancak kullanıcıyla eşleşmeyebilir.

Yaygın nedenler:

Reklam tıklama kimliği kaybolur.
E-posta gönderilmez.
Telefon numarası eksiktir.
Veri formatı yanlıştır.
Cookie süresi dolar.
Kullanıcı farklı cihazdan satın alır.
ATT izni verilmez.
Browser tanımlayıcıları aktarılamaz.

Bu durumda event teknik olarak vardır. Optimizasyon değeri ise düşebilir.

3. Atribüsyon Kaybı

Event doğru biçimde platforma ulaşır. Ancak satış reklama bağlanmaz.

Yaygın nedenler:

Satış atribüsyon penceresi dışında kalır.
Son temas organik kanaldır.
Kullanıcı farklı cihazdan dönüşür.
Reklam tıklamasıyla sipariş arasındaki bağ kopar.
Platform farklı atribüsyon modeli kullanır.
View-through dönüşüm rapor kapsamına alınmaz.

Bu durum gerçek event kaybından farklıdır.

4. Çift Event Problemi

Bazı mağazalar eksik değil, fazla dönüşüm gönderir.

Yaygın nedenler:

İki Pixel eklentisi aktiftir.
GTM ve platform eklentisi birlikte çalışır.
Thank-you sayfası yeniden yüklenir.
Browser ve server eventleri farklı Event ID kullanır.
Webhook retry işlemi yeni Event ID üretir.
Purchase hem sipariş oluşumunda hem ödeme sonrasında gönderilir.

Bu hata ROAS değerini yapay biçimde yükseltir.

5. Finansal Mutabakat Farkı

Reklam platformu geçerli bir Purchase alabilir. Sipariş daha sonra finansal değerini kaybedebilir.

Örnekler:

Sipariş iptal edilir.
Ödeme başarısız olur.
Tam iade yapılır.
Kısmi iade yapılır.
Kapıda ödeme teslim edilmez.
Fraud kontrolü siparişi reddeder.
Test siparişi rapora dahil edilir.

Reklam paneli bu değişiklikleri otomatik öğrenmeyebilir.

Kayıp türü	Event var mı?	Eşleşme var mı?	Sipariş geçerli mi?
Teknik kayıp	Hayır	Hayır	Evet olabilir
Kimlik kaybı	Evet	Hayır	Evet
Atribüsyon kaybı	Evet	Kısmen	Evet
Çift event	Fazla	Evet	Evet
Finansal fark	Evet	Evet	Hayır veya kısmen

Önce eventin varlığını doğrulayın. Sonra atribüsyonu değerlendirin.

iOS Reklam Takibini Nasıl Etkiler?

iOS etkisi tek bir teknoloji üzerinden oluşmaz.

Şu kavramlar ayrılmalıdır:

App Tracking Transparency
Safari
Intelligent Tracking Prevention
Uygulama içi tarayıcı
Mobil uygulama SDK’ları
Cross-device attribution

App Tracking Transparency Nedir?

App Tracking Transparency, mobil uygulamalardaki tracking iznini yönetir.

Apple, bir uygulama kullanıcı verilerini başka şirketlerin uygulama ve web siteleri arasında tracking amacıyla kullanıyorsa ATT izni istemesini zorunlu tutar. Çerçeve ayrıca kullanıcının izin durumunu uygulamaya bildirir.

ATT durumları şunlardır:

Authorized
Denied
Restricted
Not determined

Kullanıcı izin vermezse uygulama reklam kimliğine tracking amacıyla erişemez. Apple, iOS 14.5 ile ATT izni olmadan cihazın reklam kimliğinin kullanılamayacağını açıklamıştır.

ATT Web Mağazalarını Doğrudan Etkiler mi?

ATT esas olarak uygulama tracking iznidir.

Sadece WooCommerce web sitesi işleten bir marka, Safari tracking kurallarını ATT ile karıştırmamalıdır.

Ancak dolaylı etkiler oluşabilir:

Kullanıcı reklama mobil uygulamadan tıklar.
Satış mobil web sitesinde tamamlanır.
Kullanıcı uygulama içi tarayıcı kullanır.
Reklam teması ile web satışı eşleşmez.
Kullanıcı uygulamada keşfeder.
Satın alma farklı cihazda tamamlanır.

Mobil uygulaması bulunan markalarda ATT ayrıca app SDK eventlerini etkiler.

iOS Kaynaklı Veri Kaybı Nasıl Teşhis Edilir?

Şu segmentleri karşılaştırın:

Karşılaştırma	İncelenen risk
iOS ve Android	İşletim sistemi farkı
Safari ve Chrome	Tarayıcı farkı
Mobil web ve uygulama	Veri kaynağı farkı
Browser ve server Purchase	Event iletim farkı
Tıklama ve sipariş zamanı	Uzun dönüşüm süreci
Yeni ve tekrar müşteri	Kimlik devamlılığı

iOS trafiğindeki düşük eşleşme her zaman bozuk Pixel anlamına gelmez.

ATT, Safari ve cross-device davranış birlikte değerlendirilmelidir.

Safari ve Çerez Kısıtları Dönüşüm Takibini Nasıl Etkiler?

Safari, WebKit tracking prevention teknolojilerini kullanır.

WebKit, üçüncü taraf çerezleri varsayılan olarak engellediğini açıkça belirtir. Genel üçüncü taraf çerez erişimi bulunmaz. Belirli gömülü kullanım senaryolarında Storage Access API devreye girebilir.

Third-Party Cookie Nedir?

Third-party cookie, kullanıcının ziyaret ettiği domain dışındaki bir domain tarafından okunur veya yazılır.

Örnek:

Mağaza domaini: magaza.com Reklam domaini: reklam-platformu.com

Reklam platformunun mağaza üzerinde üçüncü taraf bağlamında kullandığı cookie, tarayıcı kısıtlamalarından etkilenebilir.

First-Party Cookie Nedir?

First-party cookie, kullanıcının ziyaret ettiği domain bağlamında oluşturulur.

Örnek:

Kullanıcı: magaza.com Cookie domaini: magaza.com

First-party yapı genellikle daha dayanıklıdır.

Ancak üç sınırlama devam eder:

Consent gerekir.
Tarayıcı politikaları uygulanır.
Saklama süresi sınırsız değildir.

First-party tracking, izinsiz tracking anlamına gelmez.

Safari ITP Neyi Sınırlar?

Intelligent Tracking Prevention, cross-site tracking yöntemlerini sınırlar.

Etkilenen alanlar:

Üçüncü taraf çerezler
Cross-site kullanıcı tanıma
Bazı script tabanlı depolama yöntemleri
Link decoration
Uzun yeniden ziyaret döngüleri
Yeniden hedefleme
Cross-domain checkout

WebKit, link decoration sonrasında kullanılan bazı client-side veri biçimleri için ek sınırlamalar uyguladığını açıklamıştır.

Safari Private Browsing ayrıca URL içindeki belirli tracking parametrelerine karşı Link Tracking Protection uygular.

Çerez Kısıtları Hangi Senaryolarda Daha Belirgindir?

Satın alma kararı yedi günden uzun sürer.
Kullanıcı birçok kez mağazaya döner.
Checkout farklı domain üzerinde çalışır.
Reklam tıklaması uygulama içi browser’dan gelir.
Kullanıcı farklı cihazda satın alır.
Kampanya yeniden hedeflemeye dayanır.
View-through dönüşümler önemlidir.

First-Party Altyapı Tek Başına Yeterli mi?

Hayır.

First-party endpoint şu faydaları sağlayabilir:

Veri akışı kontrolü
Daha dayanıklı event iletimi
Merkezi event işleme
Platform yönlendirme
Parametre doğrulama

Ancak şu sorunlar devam eder:

Consent reddi
Yanlış event şeması
Yanlış sipariş statüsü
Cross-device kaybı
Atribüsyon farkı
İade mutabakatı

Yöntem	Dayanıklılık	Consent	Ana sınırlama
Third-party cookie	Düşük	Gerekli	Tarayıcı engeli
First-party cookie	Orta	Gerekli	Süre ve kullanım
Browser event	Orta	Gerekli	Script ve blocker
Server event	Yüksek	Gerekli	Kaynak veri kalitesi
CRM kaydı	Yüksek	Amaca bağlı	Güncellik ve eşleştirme

Consent Veri Kaybı mı Oluşturur?

Consent, kullanıcının veri işleme tercihidir.

Consent reddi sonrasında event hacminin düşmesi her zaman teknik hata değildir. Sistem kullanıcının tercihini doğru uyguluyor olabilir.

CMP Ne Yapar?

Consent Management Platform şu görevleri yürütür:

Kullanıcı tercihini toplar.
İşleme amaçlarını açıklar.
Tercihi saklar.
Tag davranışını yönetir.
Kullanıcının değişiklik yapmasını sağlar.
Bölgesel kuralları uygular.

CMP yalnızca görsel bir cookie banner değildir.

Consent Mode Ne Yapar?

Google Consent Mode, Google tag ve SDK davranışını kullanıcının consent durumuna göre ayarlar.

Google şu temel consent parametrelerini kullanır:

ad_storage
analytics_storage
ad_user_data
ad_personalization

Consent Mode kendi banner’ını sağlamaz. Mevcut CMP ile birlikte çalışır. Tag davranışının kullanıcı tercihine uymasını sağlar.

Basic ve Advanced Consent Mode Farkı

Basic Consent Mode

Kullanıcı karar verene kadar ilgili tag’ler engellenir.

Consent verilmediğinde ilgili Google tag’leri veri göndermez.

Advanced Consent Mode

Google tag’leri varsayılan consent durumuna göre yüklenebilir.

Consent reddedildiğinde cookieless sinyaller gönderilebilir. Google bu sinyalleri modelleme süreçlerinde kullanabilir. Uygulama kararı hukuki ve kurumsal gereksinimlerle değerlendirilmelidir.

Consent Sonrasında Veri Neden Düşer?

Doğal nedenler

Kullanıcı reklam consent’i vermez.
Kullanıcı analytics consent’i vermez.
Bölgesel consent gereksinimleri devreye girer.

Teknik nedenler

Varsayılan consent yanlış ayarlanır.
CMP geç yüklenir.
Tag’ler consent öncesinde çalışır.
Consent update gönderilmez.
Sayfa yenilendiğinde tercih kaybolur.
Server eventine consent durumu taşınmaz.
CMP ve GTM tetikleyicileri çakışır.

Consent Kurulumu Nasıl Test Edilir?

Her senaryo ayrı test edilmelidir:

Siteyi yeni kullanıcı olarak açın.
Hiçbir seçim yapmayın.
Analytics request’lerini kontrol edin.
Reklam request’lerini kontrol edin.
Bütün kategorileri kabul edin.
Eventleri yeniden kontrol edin.
Bütün kategorileri reddedin.
Consent state değerlerini kontrol edin.
Tercihi sonradan değiştirin.
Server eventlerini ayrıca doğrulayın.

Google, Consent Mode uygulamasının Tag Assistant ile doğrulanmasını destekler.

Server-side GTM kullanılıyorsa consent durumu server container’a doğru taşınmalıdır. Google bunun için ayrı server-side Consent Mode kurulum rehberi sunar.

Browser-Side Tracking Nasıl Çalışır?

Browser-side tracking, eventlerin kullanıcının tarayıcısında çalışan JavaScript ile üretilmesidir.

Yaygın araçlar:

Meta Pixel
Google tag
Google Tag Manager
TikTok Pixel
Microsoft UET
Pinterest Tag

Browser Eventlerinin Güçlü Yönleri

Browser eventleri kullanıcı davranışını doğrudan gösterir.

Örnek eventler:

PageView
ViewContent
Search
AddToCart
BeginCheckout
AddPaymentInfo
Purchase
Lead

Browser tarafı şu sinyalleri yakalayabilir:

Görüntülenen sayfa
Tıklanan buton
Sepete eklenen ürün
Tarayıcı tanımlayıcıları
Reklam tıklama parametreleri
Kullanıcı etkileşim sırası

Browser Eventlerinin Sınırlamaları

JavaScript çalışmayabilir.
Ad blocker request’i engelleyebilir.
Sayfa erken kapanabilir.
Network bağlantısı kesilebilir.
Checkout başka domaine geçebilir.
Tag iki kez tetiklenebilir.
Cookie süresi sona erebilir.

Browser Tracking Kaldırılmalı mı?

Hayır.

Browser eventleri davranış sinyali sağlar.

Server eventleri ise mağaza ve ödeme kayıtlarına daha yakın çalışır.

İki kaynak farklı görevler taşır.

Server-Side Tracking Veri Kaybını Nasıl Azaltır?

Server-side tracking, ölçüm verisinin kontrol edilen bir sunucu ortamında işlenmesini sağlar.

Google server-side tagging, ölçüm işlevlerinin bir bölümünü web sitesinden veya uygulamadan server container’a taşır. Container Google Cloud veya başka bir altyapıda çalışabilir.

Örnek Mimari

WooCommerce veya Shopify ↓ Browser eventleri ↓ First-party endpoint ↓ Server container ↓ Event doğrulama ↓ Meta / Google / TikTok

Server-Side Tracking Faydaları

Event kontrolü

Server container gelen payload’ı kontrol eder.

Yanlış veya gereksiz parametreler filtrelenebilir.

Parametre standardizasyonu

Farklı mağaza ve platform eventleri ortak şemaya dönüştürülebilir.

Veri minimizasyonu

Hedef tag’lerin erişebileceği event parametreleri sınırlandırılabilir.

Google server-side transformations özelliği, tag’lere açılan event parametrelerinin kontrol edilmesini sağlar.

Merkezi log

Eventler Order ID düzeyinde incelenebilir.

Retry

Geçici API hatalarında kontrollü yeniden gönderim uygulanabilir.

Çoklu platform routing

Aynı doğrulanmış event farklı platformlara uygun formatta gönderilebilir.

Server-Side Tracking Neyi Çözmez?

Server-side tracking şu problemleri tek başına çözmez:

Consent reddi
Yanlış sipariş statüsü
Yanlış ürün değeri
Eksik iade modeli
Hatalı Event ID
Atribüsyon farkı
Hatalı CRM kaydı
Düşük veri hacmi

Server-side tracking, kötü veriyi otomatik olarak iyi veriye dönüştürmez.

Server-Side Tracking Ne Zaman Gerekir?

Durum	Öncelik
Yeni ve düşük hacimli mağaza	Düşük–Orta
Tek reklam platformu	Orta
Meta ve Google birlikte	Yüksek
Panel verileri ayrışıyor	Çok yüksek
Aylık 500+ sipariş	Çok yüksek
Refund oranı yüksek	Çok yüksek
Ajans çoklu mağaza yönetiyor	Çok yüksek
Özel CRM veya ERP bulunuyor	Çok yüksek

Meta Pixel ve Conversions API Birlikte Nasıl Kullanılır?

Meta Pixel browser tarafında çalışır.

Conversions API ise işletmenin pazarlama verisiyle Meta arasında doğrudan server bağlantısı kurar. Meta, CAPI’nin web, uygulama, fiziksel mağaza ve farklı müşteri temaslarından event alabileceğini belirtir.

Meta Pixel Ne Sağlar?

Browser davranışları
Sayfa görüntüleme
Sepet hareketleri
Reklam tıklama bağlamı
Remarketing sinyalleri
Browser tanımlayıcıları

Conversions API Ne Sağlar?

Server event aktarımı
Sipariş sistemine yakın veri
Müşteri eşleştirme parametreleri
Event doğrulama
Browser eventine tamamlayıcı kaynak
Kontrollü event routing

Pixel ve CAPI Neden Birlikte Kullanılır?

Browser tarafı davranışı yakalar.

Server tarafı siparişi doğrular.

İki kaynak aynı Purchase eventini gönderdiğinde deduplication gerekir.

Meta, Pixel ve CAPI üzerinden gelen eventlerin tekilleştirilmesi için event kimliği kullanılmasını destekler.

Kriter	Pixel	CAPI
Browser davranışı	Güçlü	Sınırlı
Ad blocker etkisi	Yüksek	Daha düşük
Sipariş kaydına yakınlık	Düşük–Orta	Yüksek
Consent gereksinimi	Var	Var
Log imkânı	Sınırlı	Daha güçlü
Deduplication	CAPI ile gerekir	Pixel ile gerekir

First-Party Data Veri Kaybını Nasıl Azaltır?

First-party data, işletmenin müşterisiyle doğrudan ilişkisi sonucu elde ettiği veridir.

Örnekler:

Sipariş kaydı
E-posta
Telefon
Customer ID
Ürün geçmişi
Abonelik bilgisi
CRM kaydı
İade geçmişi
Sadakat üyeliği
LTV

First-Party Data Nerede Kullanılır?

Enhanced Conversions
Advanced Matching
Customer Match
Offline conversion
CRM segmentasyonu
Tekrar satın alma
LTV bazlı optimizasyon
Yeni müşteri analizi

Data Enrichment Nedir?

Basit event:

Purchase Value: 2.000 Currency: TRY

Zenginleştirilmiş event:

Purchase Order ID Event ID Value Currency Product IDs Customer ID Hashed email Hashed phone Consent state Event time

Zenginleştirme, eventin platform tarafından daha doğru işlenmesini destekleyebilir.

Ancak daha fazla alan göndermek her zaman daha iyi değildir.

Hangi Veriler Gönderilmemelidir?

İşleme amacı bulunmayan veri
Gereksiz kişisel veri
Açık metin hassas veri
Güncel olmayan CRM kaydı
Kullanıcının tercihine aykırı pazarlama verisi
Platformun kabul etmediği parametreler

Data enrichment, fazla veri göndermek değildir. Doğru veriyi uygun formatta göndermektir.

Event Deduplication Nasıl Yapılır?

Deduplication, aynı satışın browser ve server üzerinden iki kez sayılmasını önler.

Temel Alanlar

Event name
Event ID
Order ID
Transaction ID
Event time
Value
Currency

Browser ve server eventleri aynı satış için aynı kimliği taşımalıdır.

Çift Purchase Nasıl Oluşur?

İki tracking eklentisi çalışır.
GTM ile native eklenti çakışır.
Thank-you sayfası yenilenir.
Browser ve server farklı Event ID üretir.
Retry yeni kimlik oluşturur.
Purchase iki farklı sipariş statüsünde tetiklenir.

Örnek Audit

Order ID	Browser	Server	Event ID eşleşiyor	Sonuç
20101	Var	Var	Evet	Tek satış
20102	Var	Var	Hayır	Çift risk
20103	Yok	Var	Yok	Server-only
20104	Var	Yok	Yok	Browser-only

İki kaynaktan event göndermek yeterli değildir.

İki kaynak aynı ticari olayı aynı kimlikle temsil etmelidir.

Event Match Quality Nasıl Artırılır?

Event teslimi ile kullanıcı eşleştirmesi farklı işlemlerdir.

Bir Purchase Meta’ya ulaşabilir. Ancak reklam tıklamasıyla bağ kuramayabilir.

Eşleşmeyi Etkileyen Alanlar

Hashed e-posta
Hashed telefon
External ID
FBP
FBC
IP adresi
User agent
Reklam tıklama kimliği
Event zamanı
Consent state

Eşleşme Sorunları Nasıl Teşhis Edilir?

Alanların gönderildiğini doğrulayın.
Formatları kontrol edin.
Hashing işlemini doğrulayın.
Event zamanını kontrol edin.
Browser tanımlayıcılarını inceleyin.
Consent durumunu kontrol edin.
Platform diagnostics ekranını inceleyin.

Eşleşme skorunu artırmak için gereksiz veri toplanmamalıdır.

Refund ve İptal Eventleri Neden İzlenmelidir?

Purchase eventleri brüt dönüşüm sinyali oluşturur.

İadeler ve iptaller net performansı değiştirir.

İzlenmesi Gereken Senaryolar

Tam iade
Kısmi iade
Sipariş iptali
Failed ödeme
Kapıda ödeme teslim edilememesi
Fraud iptali
Test siparişi

Refund Event Alanları

Original Order ID
Transaction ID
Refund value
Currency
Product IDs
Refund time
Refund type

Kapıda Ödeme Riski

Kapıda ödeme siparişi, sipariş oluştuğunda tahsil edilmiş sayılmaz.

Purchase eventini sipariş oluşumunda göndermek şu sorunu yaratabilir:

Reklam platformu siparişi gelir olarak kabul eder.
Sipariş teslim edilmez.
Tahsilat gerçekleşmez.
Platform yanlış sinyalle optimizasyon yapar.

Bu yapılarda şu eventler ayrılabilir:

OrderCreated
OrderConfirmed
OrderPaid
Purchase

Reklam Panelleri Neden Farklı Satış Gösterir?

Reklam platformları aynı satışı farklı biçimde sahiplenebilir.

Atribüsyon Penceresi

Bir platform yedi günlük tıklama penceresi kullanabilir.

Başka bir rapor bir günlük görünüm penceresini dahil edebilir.

Bu fark dönüşüm sayılarını değiştirir.

Click-Through ve View-Through

Click-through

Kullanıcı reklama tıklar. Sonra satın alır.

View-through

Kullanıcı reklamı görür. Tıklamaz. Daha sonra satın alır.

Platform raporları iki dönüşüm türünü farklı işleyebilir.

Cross-Device Yolculuk

Kullanıcı telefonda reklam görür.

Masaüstünde mağazaya girer.

Siparişi tablette tamamlar.

Bu yolculuk her sistemde aynı kullanıcıya bağlanmayabilir.

Conversion Modeling

Bazı platformlar doğrudan gözlemlenemeyen dönüşümleri modelleyebilir.

Modelleme, mağaza sipariş kaydı değildir.

Platform optimizasyonu için kullanılan tahmini bir ölçüm katmanıdır.

Platformlar Arası Çifte Sahiplenme

Meta ve Google aynı satışa katkı vermiş olabilir.

Her iki platform da satışı kendi atribüsyon kuralları içinde raporlayabilir.

Bu nedenle platform gelirleri toplanıp şirket cirosu gibi kullanılmamalıdır.

Sistem	Cevapladığı soru
WooCommerce	Kaç sipariş oluştu?
Ödeme sistemi	Kaç ödeme gerçekleşti?
Muhasebe	Net gelir nedir?
Meta	Hangi satış Meta temasına bağlandı?
Google Ads	Hangi dönüşüm Google reklamıyla ilişkilendirildi?
GA4	Kullanıcı yolculuğu nasıl gerçekleşti?

Birlikte İzlenmesi Gereken Metrikler

Platform ROAS
Blended ROAS
MER
CAC
Net ciro
Katkı marjı
Refund oranı
Yeni müşteri geliri
LTV

Reklam paneli optimizasyon aracıdır. Finansal muhasebe sistemi değildir.

E-Ticaret Veri Kaybı Nasıl Teşhis Edilir?

Doğru teşhis sipariş sistemiyle başlar.

1. Kaynak Siparişleri Belirleyin

İncelenecek kayıtlar:

Oluşan siparişler
Ödenen siparişler
İptal edilenler
İade edilenler
Test siparişleri
Kapıda ödeme siparişleri

2. Browser Eventlerini Kontrol Edin

Meta Pixel
Google tag
GA4
GTM
Network request
Data layer
Consent state

3. Server Eventlerini Kontrol Edin

Meta CAPI
Server GTM
WooCommerce webhook
API logu
Retry kayıtları
Hata kodları

4. Parametreleri Karşılaştırın

Her siparişte şu alanları kontrol edin:

Order ID
Event ID
Value
Currency
Product IDs
Event time
Sipariş durumu

5. Platform Araçlarını Kullanın

Meta tarafında:

Test Events
Diagnostics
Event Match Quality
Deduplication durumu

Google tarafında:

Tag Assistant
GA4 DebugView
Google Ads conversion diagnostics
Consent state

6. Atribüsyon Ayarlarını Karşılaştırın

Atribüsyon penceresi
Click-through
View-through
Saat dilimi
Conversion date
Modelleme
Cross-device

7. Finansal Mutabakat Yapın

Brüt Sipariş − İptal − Tam İade − Kısmi İade − Tahsil Edilmeyen Sipariş \= Net Geçerli Gelir

Tracking Health Score Nasıl Hesaplanır?

Tracking Health Score, platformların sunduğu standart bir metrik değildir.

Bu model, e-ticaret tracking audit’i için kullanılabilecek önerilen bir değerlendirme çerçevesidir.

Purchase Tamlığı

Purchase Tamlığı \= Geçerli Purchase Eventi ÷ Uygun Sipariş × 100

Örnek:

Uygun sipariş: 100
Geçerli Purchase: 91

Purchase Tamlığı \= %91

Event Tekilliği

Event Tekilliği \= Tekil Purchase ÷ Toplam Purchase Eventi × 100

Örnek:

Gönderilen Purchase: 105
Tekil satış: 100

Event Tekilliği \= %95,2

Parametre Doğruluğu

Parametre Doğruluğu \= Doğru Value ve Currency Taşıyan Event ÷ Geçerli Event × 100

Refund Mutabakatı

Refund Mutabakatı \= Doğru İşlenen Refund ÷ Gerçek Refund × 100

Event Zamanlaması

Zamanında Event Oranı \= Hedef Sürede Ulaşan Event ÷ Toplam Event × 100

Önerilen Ağırlıklar

Metrik	Ağırlık
Purchase tamlığı	%30
Event tekilliği	%25
Parametre doğruluğu	%20
Refund mutabakatı	%15
Event zamanlaması	%10

Tracking Health Score \= (Purchase Tamlığı × 0,30) + (Event Tekilliği × 0,25) + (Parametre Doğruluğu × 0,20) + (Refund Mutabakatı × 0,15) + (Event Zamanlaması × 0,10)

Skor Yorumlama

Skor	Durum
90–100	Sağlıklı
75–89	İyileştirme gerekli
60–74	Kritik risk
0–59	Güvenilmez ölçüm

Bu eşikler önerilen audit modelidir.

Her işletmenin sipariş akışına göre uyarlanmalıdır.

Sık Sorulan Sorular

iOS reklam verisini neden azaltır?

iOS uygulamalarda tracking iznini ATT üzerinden yönetir. Safari ise web tracking için ayrı gizlilik kuralları uygular.

ATT ile Safari ITP aynı şey mi?

Hayır. ATT uygulama tracking iznidir. ITP Safari tabanlı web tracking sınırlamasıdır.

Çerez engelleri tamamen aşılabilir mi?

Hayır. Tarayıcı politikaları ve kullanıcı tercihleri atlatılmamalıdır. First-party ve server-side ölçümle teknik dayanıklılık artırılabilir.

Server-side tracking veri kaybını bitirir mi?

Hayır. Browser kaynaklı bazı kayıpları azaltabilir. Consent, yanlış sipariş statüsü ve atribüsyon farklarını tek başına çözmez.

Meta Pixel kaldırılmalı mı?

Hayır. Pixel browser davranışını yakalar. CAPI siparişe yakın server sinyali sağlar. Birlikte kullanıldıklarında eventler tekilleştirilmelidir.

Pixel ve CAPI birlikte kullanılmalı mı?

Birçok e-ticaret yapısında birlikte kullanılabilir. Aynı eventler Event ID üzerinden eşleştirilmelidir.

Consent reddedildiğinde event gönderilebilir mi?

Event davranışı hukuki temel, veri amacı ve kullanıcının tercihi doğrultusunda yönetilmelidir. Consent reddi bypass edilmemelidir.

First-party data nedir?

İşletmenin müşterileriyle doğrudan ilişkisi sonucunda elde ettiği sipariş, CRM, iletişim ve müşteri davranışı verileridir.

Event Match Quality neden düşer?

Eksik müşteri bilgisi, yanlış format, kaybolan tıklama kimliği ve geç gönderilen event eşleşmeyi zayıflatabilir.

Meta ve WooCommerce siparişleri neden tutmaz?

Eksik event, çift Purchase, atribüsyon penceresi, view-through, iptal ve Refund farkları etkili olabilir.

Reklam paneli gerçek ciroyu gösterir mi?

Reklam paneli platforma atfedilen dönüşümleri gösterir. Net ciro mağaza, ödeme ve muhasebe kayıtlarıyla doğrulanmalıdır.

Refund eventi neden önemlidir?

İadeler aktarılmazsa reklam platformu artık geçerli olmayan brüt satış sinyalleriyle optimizasyon yapabilir.

Tracking audit nasıl yapılır?

Siparişler browser, server ve platform eventleriyle Order ID seviyesinde karşılaştırılır. Event tamlığı, tekilliği ve parametre doğruluğu ölçülür.

Data4Ad veri kaybını nasıl azaltır?

Data4Ad, WooCommerce sipariş eventlerini server katmanında doğrular. Browser ve server sinyallerini karşılaştırır. Eventleri tekilleştirir. İzinli first-party alanları uygun formatta zenginleştirir.