Kazım Gökay Çiftci · 10 Ekim 2026 · Güncelleme: 14 Ekim 2026

E-ticarette CRM Entegrasyonu: Sipariş ve Pazarlama Verisi

Bir e-ticaret mağazasında CRM entegrasyonunu seçerken doğru soru "hangi CRM?" değil, "hangi kimlik, hangi sistemde anahtar olacak?" sorusudur. Sipariş numarası, müşterinin e-postası ve tarayıcıdaki ölçüm kimliği aynı kişiyi işaret etmiyorsa, en pahalı CRM bile size yalnızca iki ayrı rapor verir: biri siparişlerin, biri reklamların raporu. Bu yazıda siparişlerinizi pazarlama verinizle nasıl birleştireceğinizi, hangi entegrasyon desenini ne zaman seçeceğinizi ve kurulumda en sık nerede hata yapıldığını anlatıyoruz.

Önce kapsamı söyleyelim: belirli bir CRM markasını öneren bir karşılaştırma yapmıyoruz. Ürün listeleri hızlı eskir; ama bir entegrasyonun mantığı, hangi ürünü seçerseniz seçin aynı kalır. Kendi altyapınızdaki alanların adı değişebilir, kurallar değişmez.

İki veri akışı hangi soruya cevap verir?

E-ticarette birbirinden ayrı iki akış vardır ve entegrasyon, bu ikisini aynı müşteri kaydında buluşturma işidir.

Sipariş akışı: mağaza altyapısından gelir. Sipariş numarası, tutar, ürünler, kupon, ödeme ve kargo durumu, iade ve iptal buradadır. Bu akış "ne sattık, kime sattık, ne kadar kaldı elimizde" sorusunu cevaplar.
Pazarlama akışı: reklam platformlarından ve analitik araçlarından gelir. Hangi kampanyanın, hangi sayfanın, hangi tıklamanın bir ziyareti getirdiği buradadır. Bu akış "satışı neyin getirdiği" sorusunu cevaplar.

İki akış birleşmediğinde tipik tablo şudur: mağaza paneli bir aydaki siparişi gösterir, reklam paneli bunun yalnızca bir kısmını kendine yazar, analitik aracı üçüncü bir sayı verir. Üçü de kendi kuralına göre doğrudur ve hiçbiri tek başına karar vermeye yetmez. CRM entegrasyonunun işi bu üç sayıyı tek bir müşteri ve sipariş kaydı üzerinde uzlaştırmaktır.

Birleştirmenin anahtarı: kimlik alanları

Veri birleştirme, tablo birleştirme gibidir: ortak bir anahtar yoksa satırlar eşleşmez. E-ticarette bu anahtarlar genellikle şunlardır.

Sipariş numarası: mağaza altyapısı ile CRM arasındaki ana bağ. Google Analytics 4 tarafında buna karşılık gelen alan transaction_id'dir ve aynı işlemin iki kez sayılmasını önlemek için kullanılır.
E-posta ve telefon: müşteriyi siparişler arasında tanıyan kalıcı anahtar. Telefon numarası tek biçimde (ülke kodlu) saklanmazsa aynı müşteri üç kayıt olur.
Tarayıcı kimliği: Google Analytics'te client_id, Meta'da fbp ve fbc çerezleri. Bunlar sipariş anında kaydedilip CRM'e yazılmazsa, sipariş sonradan reklam tıklamasıyla eşleştirilemez.
Olay kimliği: aynı siparişin tarayıcıdan ve sunucudan iki kez bildirilmesi halinde tekilleştirmeyi sağlayan değer. Meta tarafında buna event_id denir.

Pratikte en sık yapılan hata, tarayıcı kimliklerinin sipariş formuyla birlikte alınmamasıdır. Sipariş verisi sunucuya düştüğünde çerezler elinizde yoksa, CRM'deki müşteri kaydının hangi kampanyadan geldiği sonradan geri getirilemez. Bu yüzden kimlik alanlarını entegrasyonun ilk günü tasarlamak, aylar sonra yama yapmaktan çok daha ucuzdur.

Üç entegrasyon deseni: hangisi ne zaman?

Mağaza altyapısını CRM'e bağlamanın üç yaygın yolu var. Hangisinin doğru olduğu, sipariş hacminden çok verinin ne kadar özelleştirilmesi gerektiğine bağlıdır.

1. Hazır bağlayıcı veya eklenti

Mağaza altyapısı ile CRM arasında önceden yazılmış bir bağlayıcı kullanılır. Kurulum hızlıdır ve standart alanları (sipariş, müşteri, ürün) taşır. Sınırı şudur: bağlayıcının taşıdığı alanlarla yetinmek zorundasınız. Tarayıcı kimliği, kampanya etiketi ya da özel sipariş notu gibi alanlar bağlayıcıda yoksa onları ekleyemezsiniz. Standart bir mağaza, tek bir satış kanalı ve basit bir müşteri yolculuğu için çoğu zaman yeterlidir.

2. Aracı katman: webhook ve otomasyon

Mağaza her siparişte bir bildirim (webhook) gönderir, aracı bir otomasyon ya da veri aktarım katmanı bu bildirimi alır, alanları dönüştürür ve CRM'e yazar. Alan eşlemesini siz belirlersiniz; yani tarayıcı kimliğini ya da kupon kodunu da taşıyabilirsiniz. Birden fazla kanalınız (kendi siteniz, pazaryeri, telefon siparişi) varsa bu desen en dengeli seçenektir. Karşılığında, aracı katmanın bir başarısızlık kaydı tutması gerekir: bir bildirim kaybolursa sipariş CRM'de hiç görünmez ve bunu kimse fark etmez.

3. Özel API entegrasyonu

Mağaza ve CRM doğrudan yazılımla bağlanır. Her alan, her kural, her hata durumu sizin kontrolünüzdedir; ama bakım yükü de sizindir. Mağaza altyapısı ya da CRM bir güncelleme yaptığında entegrasyonun da güncellenmesi gerekir. Bu yol, standart bağlayıcıların karşılayamadığı iş kuralları olduğunda mantıklıdır: örneğin bayi fiyat listeleri, çok depolu stok ya da kuponun müşteri segmentine göre otomatik atanması.

Varsayımsal bir örnek: günde birkaç düzine sipariş alan, tek kanallı bir mağaza için özel API yazmak çoğu zaman gereksizdir; hazır bağlayıcı yeter. Aynı mağaza pazaryerinde de satmaya başlayıp iki kanalın müşteri verisini tek kayıtta toplamak istediğinde, aracı katmana geçmek mantıklı hale gelir. Karar, bugünkü hacme değil, önümüzdeki bir yıllık ihtiyaç listesine göre verilir.

Hangi alanlar CRM'e eşlenmeli?

Entegrasyon projeleri çoğu zaman "her şeyi aktaralım" diye başlar ve kimsenin kullanmadığı kırk alanla biter. Aktarılacak alanları, cevaplamak istediğiniz sorulardan geriye doğru seçin. Pazarlama ile birleştirme amacıyla tipik asgari liste şudur.

Sipariş numarası, sipariş tarihi ve sipariş durumu (beklemede, kargoda, teslim edildi, iptal, iade).
Net tutar, para birimi ve kargo bedeli. KDV dahil ve KDV hariç tutarları aynı alana karıştırmayın; raporlarda iki farklı "ciro" doğurur.
Kupon kodu ve indirim tutarı.
Satış kanalı: kendi site, pazaryeri, telefon.
Müşteri anahtarları: e-posta, telefon, varsa üyelik kimliği.
Kampanya bilgisi: ilk tıklamadaki ve son tıklamadaki kaynak, mümkünse tıklama kimlikleri.
İade ve iptal kayıtları, tutarıyla birlikte.

Son madde çoğu entegrasyonda unutulur. Sipariş akışta görünür, iade ise başka bir ekranda yaşar. Reklam platformuna "satış" olarak bildirdiğiniz bir sipariş sonradan iade olduysa, pazarlama raporunuz gerçek cirodan daha yüksek görünür. Bu konuya aşağıda ayrıca dönüyoruz.

Siparişi pazarlama platformlarına geri göndermek

Birleştirme tek yönlü değildir. CRM'de doğrulanmış sipariş verisi, reklam ve analitik platformlarına geri gönderildiğinde, o platformlar tarayıcıda kaçırdıkları dönüşümleri tamamlayabilir. İki ana yol var.

Google Analytics 4: Measurement Protocol

Google'ın dokümantasyonuna göre Measurement Protocol, sunucudan sunucuya ve çevrimdışı etkileşimleri doğrudan Google Analytics'e HTTP istekleriyle göndermeye yarar. Çevrimiçi ve çevrimdışı davranışı bağlamak bunun ana kullanım alanlarından biridir. Dikkat edilecek üç sınır var. Birincisi, protokolün etkili çalışması için sitenizde gtag, Tag Manager ya da Firebase üzerinden etiketleme de bulunmalıdır; protokol etiketlemenin yerine geçmez, onu tamamlar. İkincisi, bazı olay ve parametre adları otomatik toplama için ayrılmıştır ve protokolle gönderilemez. Üçüncüsü, Analytics arayüzündeki otomatik olay oluşturma kuralları protokolle gelen olayları tetiklemez. Yani sunucudan gönderdiğiniz bir satın alma olayını, arayüzde kurduğunuz kurallarla yeniden şekillendiremezsiniz; olay baştan doğru biçimde gelmelidir.

Kullanıcı verisi gönderecekseniz kural nettir: e-posta, telefon, isim ve adres SHA-256 ile hashlenir ve hex dizisi olarak iletilir. Hash'ten önce baştaki ve sondaki boşluklar silinir, metin küçük harfe çevrilir, telefon numaraları E.164 biçimine getirilir. Şehir, bölge, posta kodu ve ülke alanları normalize edilir ama hashlenmez. Normalizasyon adımlarından biri atlanırsa, aynı e-posta farklı bir hash üretir ve eşleşme başarısız olur; sessizce, hata mesajı vermeden.

Meta: Conversions API ve tekilleştirme

Meta tarafında aynı mantık Conversions API ile kurulur. Burada kritik konu tekilleştirmedir. Aynı satın alma hem tarayıcıdaki piksel hem sunucu üzerinden gelirse, Meta'nın bunları tek olay saymasını sağlayan şey piksel tarafındaki eventID ile Conversions API tarafındaki event_id değerinin, ayrıca olay adının eşleşmesidir. Meta'nın dokümanına göre olaylar yalnızca, belirli bir event_id ile gelen ilk olayın alınmasından sonraki 48 saat içinde alınırsa tekilleştirilir. Yani sunucu olayını günlerce geciktiren bir entegrasyon, aynı siparişi iki kez saydırabilir.

Müşteri bilgisi parametrelerinde de benzer bir ayrım var. E-posta, telefon, ad, soyad gibi alanlar SHA-256 ile hashlenerek gönderilir. Tarayıcı çerezlerinden gelen fbp ve fbc değerleri ile IP adresi ve tarayıcı bilgisi ise hashlenmez. Eşleşme kalitesi için IP adresi ve tarayıcı bilgisinin birlikte gönderilmesi önerilir. Bu iki alanı da sipariş anında yakalayıp CRM'e yazmazsanız, sonradan sunucudan olay gönderirken elinizde olmaz.

İade, iptal ve durum değişimleri

Sipariş verildiği an "satış" gibi görünür, ama e-ticarette satış çoğu zaman teslimde ve iade süresinin bitiminde kesinleşir. Entegrasyonu yalnızca sipariş oluştuğu anı bildirecek şekilde kurarsanız, reklam platformları iptal edilen siparişleri de başarı olarak öğrenir ve bütçeyi o tür müşterilere yöneltmeye devam eder.

Çözüm iki parçalıdır. Birincisi, CRM'de sipariş durumunun her değişimi kaydedilir ve iade ile iptal, orijinal siparişe sipariş numarasıyla bağlanır. İkincisi, raporlamada hangi sayının "sipariş", hangisinin "net satış" olduğu baştan tanımlanır. Net satışı reklam raporuyla yan yana koymadan önce her iki tarafın aynı tanımı kullandığından emin olun. Aksi halde "reklam sayısı mı doğru, CRM sayısı mı" tartışması bitmez.

KVKK: müşteri verisini birleştirirken sınır nerede?

Sipariş ve pazarlama verisini kişi düzeyinde birleştirdiğiniz anda kişisel veri işliyorsunuz demektir ve 6698 sayılı Kişisel Verilerin Korunması Kanunu devreye girer. Kanunun 4. maddesi, kişisel verilerin hukuka ve dürüstlük kurallarına uygun, belirli, açık ve meşru amaçlar için işlenmesini; işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olmasını ve gerekli süre kadar muhafaza edilmesini zorunlu kılar. Bu ilkelerin entegrasyon tasarımına karşılığı basittir: her alanı "hangi soruyu cevaplamak için aktarıyorum" diye sorgulayın, cevabı olmayan alanı aktarmayın ve saklama sürenizi tanımlayın.

Kanunun 12. maddesi ise veri sorumlusunu, kişisel verilere hukuka aykırı erişimi ve verinin hukuka aykırı işlenmesini önlemek için uygun güvenlik düzeyini sağlayacak teknik ve idari tedbirleri almakla yükümlü kılar. Entegrasyonda bunun anlamı, API anahtarlarının güvenli saklanması, CRM'e erişimin yetkiye göre sınırlanması ve aracı katmanlardaki verinin kimlerde kaldığının bilinmesidir. Veriyi sizin adınıza başka bir hizmet işliyorsa, 12. madde o taraflarla birlikte sorumluluk öngörür. Google ya da Meta'ya hash'lenmiş müşteri verisi göndermek de KVKK'ya göre yurt dışına aktarım sayılıyor; 2024'te değişen 9. madde bu aktarım için yeterlilik kararı ya da standart sözleşme gibi bir dayanak arıyor. Açık rıza, ticari ileti izni ve aydınlatma metni gibi konular işletmenizin durumuna göre değiştiği için, bunları bir hukuk danışmanıyla netleştirmenizi öneririz.

Kurulum sırası ve doğrulama

Entegrasyonu canlıya almadan önce şu sırayı izlemek, sonradan düzeltme maliyetini ciddi biçimde düşürür.

Cevaplamak istediğiniz üç dört soruyu yazın: hangi kampanya net satışı getiriyor, hangi müşteri ikinci siparişi veriyor gibi.
Bu sorular için gereken alanları ve ortak anahtarları belirleyin.
Hazır bağlayıcı, aracı katman ya da özel API arasında, alan listesinin karşılanıp karşılanmadığına bakarak seçim yapın.
Önce on beş yirmi test siparişiyle deneyin; sipariş numarası, tutar, kupon ve kimlik alanlarını mağaza panelinde ve CRM'de tek tek karşılaştırın.
İptal ve iade senaryosunu da test edin; bu, çoğu entegrasyonda atlanan adımdır.
Canlıya aldıktan sonra ilk iki hafta mağaza, CRM ve reklam panelindeki net satış sayısını yan yana izleyin. Fark varsa nedenini bulmadan yeni kampanya bütçesi artırmayın.

Yaygın bir hata da entegrasyonu kurup bir daha bakmamaktır. Mağaza altyapısı ya da CRM bir güncelleme yaptığında alan adları değişebilir; bildirim kaybı fark edilmeden aylarca sürebilir. Düzenli bir uzlaştırma kontrolü, yani haftada bir sipariş sayısının iki sistemde eşleştiğini doğrulamak, bu sorunu erken yakalar.

Sıkça Sorulan Sorular

Küçük bir mağaza için CRM entegrasyonu gerekli mi?

Sipariş sayısı az ve tek kanalsa başlangıçta mağaza altyapısının kendi müşteri kayıtları yeterli olabilir. Ne zaman gerekli hale geldiği, ikinci bir kanal eklediğinizde ya da müşteriyi segmentleyip otomatik iletişim kurmak istediğinizde belli olur. Bu noktada kimlik alanlarını baştan doğru toplamış olmanız işi kolaylaştırır.

Reklam paneli ve CRM neden farklı satış sayısı gösterir?

Sebepler çoğunlukla ölçüm penceresi farkı, tarayıcı kısıtlamaları nedeniyle kaçan dönüşümler, iptal ve iadelerin işlenme zamanı ve KDV bazı gibi tanım farklarıdır. Çözüm tek bir "net satış" tanımı belirleyip her iki tarafı ona göre okumaktır.

Sunucu tarafı olay göndermek tarayıcı etiketinin yerine geçer mi?

Hayır. Google'ın Measurement Protocol dokümanı, protokolün etiketlemeyle birlikte kullanılması gerektiğini söylüyor. Meta tarafında da piksel ile Conversions API birlikte çalışır ve tekilleştirme bu iki kanalın birlikte gönderildiği varsayımıyla tasarlanmıştır.

Hashleme tek başına KVKK uyumu sağlar mı?

Hayır. Hashleme bir güvenlik ve eşleştirme tekniğidir; verinin hangi amaçla, ne kadar süre ve hangi hukuki dayanakla işlendiği sorusunu cevaplamaz. Bu sorular KVKK kapsamında ayrıca ele alınmalıdır.

Sonuç

Doğru CRM entegrasyonu, en kapsamlı ürünü değil, sizin sorularınızı cevaplayacak alanları eksiksiz taşıyan yapıyı kurmaktır. Önce kimlik alanlarını ve net satış tanımını belirleyin, sonra standart bağlayıcı, aracı katman ya da özel API arasından ihtiyacınıza uyanı seçin. İade ve iptali baştan akışa katın, sunucu olaylarını tekilleştirme kurallarına uygun gönderin ve kişisel veri tarafını KVKK ilkeleriyle denetleyin.

Sipariş ve pazarlama verinizi tek yerde toplamak için martech ve analitik danışmanlığı hizmetimiz bu çerçevede çalışıyor. Mağaza altyapınızın kendisini ve ölçüm katmanını birlikte kurmak isterseniz web tasarım ve e-ticaret hizmetimiz de ilgili. Benzer konulardaki yazılarımıza blog sayfamızdan ulaşabilirsiniz.