Mücevher markalarında POS ve CRM, üç ortak kimlik ve tek yönlü ve hatası izlenen bir aktarım düzeniyle entegre edilir. Ortak kimlikler ürünün varyant kodu, mağazanın kodu ve satışın sipariş ya da fiş numarasıdır. Akış ERP’den siteye ve POS’a stok, POS’tan ve e ticaret altyapısından kayıt sistemine satış, kayıt sisteminden reklam sistemlerine eşleşen olay şeklinde kurulur. Her bildirim tekilleştirilir, başarısız olan bir hata kuyruğuna düşer ve iade, değişim, kapora ve kısmi ödeme satıştan ayrı olaylar olarak eşleştirilir. Entegrasyonun zor kısmı yazılım değil, kimliklerdir. POS’taki ürün kodu sitedekiyle aynı değilse, fişe randevu kodu yazılmıyorsa ve iade satışın yanına bağlanmıyorsa en pahalı entegrasyon bile yanlış bir rapor üretir.
Pırlanta ve tasarım mücevher markalarında ölçüm altyapısı, kayıt sistemi ve reklam entegrasyonu kuruyorum. İstanbul’da iki mağazası olan bir pırlanta markasında online satış Shopify üzerinde çalışıyor, mağazalarda ayrı bir POS ve ön muhasebe yazılımı kullanılıyordu. Eşleşen satışlar HubSpot’ta toplanıp her gün Google’a ve Meta’ya gönderildi. Mayıs’ta dijital kaynaklı mağaza müşterisinin yüzde 84’ü eşleştirilebiliyordu. Bütün süreci mücevher dijital pazarlama vaka analizinde anlattım. Bu yazıda entegrasyonun teknik tarafını anlatıyorum.
Çünkü ikisi farklı işler için kurulmuştur. POS fişi kesmek, ödemeyi almak ve stoktan düşmek için vardır. Müşterinin kim olduğunu, hangi reklamı gördüğünü ve hangi danışmanla mesajlaştığını bilmez. Kayıt sistemi ise konuşmayı, randevuyu ve danışmanı bilir ama mağazada kesilen fişi görmez. Vakadaki markada başlangıçta iki mağazanın aylık cirosu 11,16 milyon TL’ydi ve satışın hangi kısmının reklamdan geldiğini bilen kimse yoktu. GA4 ve iki reklam paneli de her biri kendi satın alma sayısını raporluyordu ve mağaza satışı hiçbir yerde görünmüyordu.
Her biri tek bir yerde doğacak ve hiç değişmeyecek şekilde. Kimliğin doğduğu sistem onun sahibidir, diğer sistemler yalnızca okur.
| Kimlik | Nerede doğar? | Nerede kullanılır? |
|---|---|---|
| Varyant kodu | ERP | Site, POS, ürün feedi, kayıt sistemi ve ayırtma |
| Mağaza kodu | ERP | POS fişi, stok, randevu, mağaza sayfası ve İşletme Profili |
| Online sipariş numarası | E ticaret altyapısı | Ödeme, iade, değişim ve reklam sistemine giden satın alma |
| POS fiş numarası | POS | Mağaza defteri ve eşleşen mağaza satışı |
| Randevu kodu | Kayıt sistemi | Mesaj, hatırlatma ve POS fişinin açıklama alanı |
| Kişi kimliği | Kayıt sistemi | Konuşma, randevu, satış ve onay durumu |
Vakadaki markanın kataloğunda 612 model ve 2.140 varyant vardı. Mağaza bazında stok ürün sayfasında ve müşteri hizmetleri panelinde her varyantın hangi mağazada denenebildiğini gösteriyordu ve bilgi ERP’den saatte bir güncelleniyordu. Bu ancak POS’taki ürün kodu sitedeki varyant koduyla aynı olduğu için mümkündü. Varyant kimliğinin ürün feedindeki yerini pırlanta ürün feedi yazısında anlattım.
Her bilginin tek bir kaynaktan çıkıp diğerlerine gittiği tek yönlü yollarla. İki sistemin aynı alanı birbirine yazması, hangisinin doğru olduğunun bilinmediği döngüler doğurur.
| Kaynak | Hedef | Ne akar? | Ne sıklıkla? |
|---|---|---|---|
| ERP | Site, POS ve feed | Stok, fiyat ve yerine koyma maliyeti | Stok saatte bir, fiyat günlük sabit zamanlarda |
| E ticaret altyapısı | Kayıt sistemi | Sipariş, ödeme onayı, iade, değişim | Olay anında |
| POS | Kayıt sistemi | Fiş, ürün, tutar, randevu kodu | Olay anında ya da günde birkaç kez |
| Mesaj kutusu | Kayıt sistemi | Konuşma, randevu, ayırtma, onay | Olay anında |
| Kayıt sistemi | Google ve Meta | Onaylı ve eşleşen satış olayları | Her gün |
Vakadaki markada fiyat altın kuruna bağlıydı ve gün içinde altı kez değişiyordu. Fiyat değişimi sabah ve öğleden sonra olmak üzere günde iki sabitlemeye indirildi, feed fiyatla aynı anda gönderildi. Ben aynı sabitlemeyi POS fiyatına da uyguluyorum, böylece mağazada ve sitede aynı saatte aynı fiyat görünür.
Her bildirimin bir kimliği, her başarısızlığın bir kaydı olacak şekilde. Olay anında akan veriler çoğu zaman webhook denen sunucudan sunucuya giden bildirimlerle taşınır. E ticaret altyapısı bir sipariş ödendiğinde ya da iade oluştuğunda kayıt sistemine haber verir. Bu bildirimler gecikebilir, sırası karışabilir ya da aynı olay iki kez gelebilir. Entegrasyon bunu baştan varsayarak kurulur.
Bu beş adım benim kullandığım düzendir. Vakadaki markada sessiz hatanın ne kadar pahalı olabileceği Meta tarafında görüldü. Mağaza satışları başlangıçta haftalık toplu dosyayla gönderiliyordu ve Ocak’ın ilk üç haftasında gönderilen 163 olayın 97’si reddedildi, çünkü Meta yedi günden eski bir olay zamanını kabul etmiyor ve böyle bir olay içeren isteğin tamamını reddediyor. Olaylar gitmiş gibi duruyor, ama hiçbir kampanyaya ulaşmıyordu. Yükleme her sabah çalışan günlük bir işe çevrilince sorun bitti.
| Hata defteri ölçüsü | Pay | Payda |
|---|---|---|
| Kuyruğa düşme oranı | İşlenemeyen bildirim | Gelen bütün bildirimler |
| Mutabakat farkı | POS ile kayıt sistemi arasındaki fiş farkı | POS’taki fiş sayısı |
| Reddedilen olay oranı | Reklam sisteminin reddettiği olay | Gönderilen olay |
| Kodlu fiş oranı | Randevu kodu girilmiş fiş | Dijital randevudan gelen müşteriye kesilen fiş |
Satışın kendisine bağlı ayrı olaylar olarak. Mücevherde satış nadiren tek bir ödemeyle ve tek bir sonuçla biter. Ayırtma, kapora, değişim, kısmi iade ve ters ibraz aynı satışın etrafında dolaşır. Her biri satışın kimliğine bağlanmazsa rapor ya satışı iki kez sayar ya da iadeyi hiç görmez.
| Durum | Kayıt sisteminde ne olur? | Reklam sistemine ne gider? |
|---|---|---|
| Online sipariş, ödeme onayı | Satış, ödeme onayı ve sahtecilik incelemesinden sonra | Satın alma, bir kez |
| Mağazada ayırtma ya da kapora | Ayırtma kaydı, satış değil | Gitmez |
| Kalan ödemeyle mağazada satış | Tek satış, ayırtmaya bağlı | Eşleşen mağaza satışı, toplam tutarla |
| Kısmi iade | Satış tutarı iade edilen ürün kadar düşer | Değer düzeltmesi |
| Tam iade ya da ters ibraz | Satış iptal | Dönüşüm geri alınır |
| Mağazada değişim | Online siparişin değişimi, yeni satış değil | Gitmez |
Vakadaki markada bir online sipariş ancak ödeme onayından ve sahtecilik incelemesinden geçince satış sayıldı. Başlangıçta dönüşüm sipariş anında gönderiliyor, iade ve ters ibraz hiç geri alınmıyordu, oysa online siparişlerin yüzde 18’i iade oluyordu. Geçmiş iade ve ters ibrazlar dönüşüm düzeltmesiyle geri alındı. Google’da yüklenmiş bir dönüşümü geri almak ya da değerini değiştirmek ilk kayıttan sonraki 55 gün içinde mümkün, bu yüzden iade akışı da günlük çalışmalıdır. Ödemenin kendisinde de dikkat gerekir. Kuyum ürünlerinde kredi kartı taksidi yasal olarak sınırlıdır ve reklamda ya da sitede bu sınırın ötesinde bir taksit vaadi kullanılmaz.
ERP’den her gün, varyant kodu üzerinden. Vakadaki markada muhasebe her ürünün maliyetini stoğa girdiği günkü fiyatla tutuyordu. Altın yükselirken bu yöntem eski stoğu olduğundan karlı gösteriyordu. Alyans grubunun brüt kâr marjı stoğa giriş maliyetiyle yüzde 44, yerine koyma maliyetiyle yüzde 30 çıkıyordu. Katkı defteri her satıştan iadeyi, ürünün bugünkü yerine koyma maliyetini, sigortalı kargoyu, ödeme komisyonunu ve mağaza satış primini düşüyordu. Bu hesabın yapılabilmesi için maliyet kayıt sistemine satışla aynı varyant koduyla gelmelidir.
Teknik akışı bir kişi, kimliklerin girilmesini ise mağaza ekibi. Vakadaki markada kurulan sistem ilk iki haftada beklendiği gibi çalışmadı, çünkü randevu kodu satışların yalnızca yüzde 38’inde POS’a girilmişti. Neden teknik değil insaniydi. Danışmanlar kodun girildiği satışın primlerini böleceğini düşünüyordu. Prim kuralı yazılı hale gelince Şubat’ta kod girme oranı yüzde 91’e çıktı. Entegrasyonun sahibi bu yüzden yalnızca teknik ekip olamaz. Mağaza müdürü kodlu fiş oranını haftalık toplantıda okur. Mücevher için Klaviyo ve CRM’in hangi işlerde kullanıldığını ayrı bir yazıda ele alıyorum.
Önce ERP, POS, e ticaret altyapısı ve mesaj kutusundaki ürün, mağaza ve kişi kimliklerini yan yana koyun ve aynı olmayanları eşitleyin. Sonra aktarım tablosunu yazın, her alanın tek bir kaynağı olsun. Ardından webhook bildirimlerini tekilleştirmeyle, sıra kontrolüyle ve hata kuyruğuyla kurun, her sabah çalışan bir mutabakat ve reklam sistemlerine günlük yükleme ekleyin. İade, değişim, kapora ve kısmi ödeme kurallarını yazmak ve kodlu fiş oranını mağaza toplantısına koymak bu düzenin son adımıdır. Eşleştirme kurallarının mantığını pırlanta mağaza satışı ölçümü yazısında, GA4 ile reklam panellerinin neden farklı rakam gösterdiğini pırlanta GA4 ve reklam verisi farkı yazısında anlatıyorum. Online tarafta ödemenin nerede yarım kaldığını ise pırlanta sitelerinde ödeme terkinin nasıl azaltılacağını anlattığım yazıda ayrıca ele alıyorum.
Entegrasyon tarafındaki çalışma biçimimi hizmet sayfasının mücevher markaları için CRM ve mağaza satışı ölçümü bölümünde bulabilirsiniz. Ölçümün bütün stratejideki yeri mücevher pazarlaması rehberinde anlatılıyor.
Çoğu zaman gerekmez. Asıl iş ortak kimliklerin kurulması ve tek yönlü bir akışın yazılmasıdır. Vakadaki markada eşleşen satışlar HubSpot’ta toplandı, Google’a Data Manager üzerinden çevrimdışı dönüşüm olarak, Meta’ya Conversions API ile gönderildi.
Meta tarafında bozar. Vakadaki markada mağaza satışları haftalık dosyayla gönderildiğinde Ocak’ın ilk üç haftasında 163 olayın 97’si reddedildi, çünkü Meta yedi günden eski olay zamanını kabul etmiyor. Yükleme günlük işe çevrilince reddedilme durdu.
Kaydedilmez. Kapora bir ayırtmadır ve kendi kaydı olarak tutulur. Satış, kalan ödeme alınıp fiş kesildiğinde ayırtmaya bağlı tek bir kayıt olarak yazılır ve reklam sistemine de o zaman toplam tutarla gider.
Dönüşüm düzeltmesiyle. Vakadaki markada online siparişlerin yüzde 18’i iade oluyordu ve başlangıçta bunlar hiç geri alınmıyordu. Geçmiş iade ve ters ibrazlar düzeltmeyle geri alındı. Google’da bu düzeltme ilk kayıttan sonraki 55 gün içinde yapılabildiği için iade akışı günlük çalışmalıdır.
Hata kuyruğu, günlük uzlaştırma raporu ve iade kaydıyla. Ben POS’taki işlem sayısını CRM’e ulaşan işlem sayısıyla her gün karşılaştırıyor, farkı hata kuyruğundaki kayıtlarla açıklıyorum. İade ve kısmi ödemelerin doğru siparişe bağlandığını her hafta rastgele seçtiğim işlemlerle kontrol ediyorum. Açıklanamayan fark kalırsa entegrasyonu tamamlanmış saymıyorum.
Bu yazıdaki platform ve mevzuat bilgilerini Ekim 2026’da aşağıdaki resmi kaynaklardan kontrol ettim.