E-Ticaret Sitesi WhatsApp Entegrasyonu: Site Olayı Nasıl Haber Verir?

WhatsApp modülü konuşmaları genellikle mesaj metniyle başlar: ne yazalım, ne zaman gönderelim, kupon verelim mi. Kurulum başladığında ise gündem bir anda değişir ve tek bir soruya iner: site bu olayı bize nasıl haber verecek? Mesaj kurgusu ne kadar iyi olursa olsun, sipariş bilgisi yirmi dakika gecikmeli geliyorsa kargo bildirimi geç gider; müşteri kaydı telefonla eşleşmiyorsa doğum günü mesajı yanlış kişiye gider.

Bu yazı entegrasyonun teknik tarafını anlatıyor: olay nasıl taşınır, müşteri verisi neyle eşleşir, hangi altyapıda ne değişir ve iki örnek akış bu parçaları nasıl kullanır.

E-ticaret sitesi WhatsApp entegrasyonu neyi kapsar?

Entegrasyon üç parçadan oluşur ve üçü de bağımsız olarak bozulabilir.

1. Olay: Mağazada bir şey oldu ve bunun haber verilmesi gerekiyor. Üyelik oluştu, sipariş verildi, kargo hareket etti, ürün stoğa girdi.
2. Kimlik: Bu olay kime ait? Telefon numarası hangi müşteriye, hangi izne, hangi geçmişe bağlanıyor?
3. İzin: Bu kişiye bu türden mesaj gönderilebilir mi? İzin ne zaman alındı, geri çekildi mi?

Kritik nokta şu: WhatsApp modülleri mağaza yazılımının içine gömülmez. Mağaza altyapısı olayı üretir, modül dışarıda çalışır. Bu ayrım entegrasyonun tamamını taşınabilir kılar; altyapı değiştiğinde yalnızca olayın geldiği kaynak değişir, izin havuzu ve akış kurgusu yerinde kalır.

Olay nasıl gelir? Üç yöntem, üç farklı gecikme

Pratikte sağlıklı kurgu bu üçünü karıştırır: kritik olaylar webhook ile, doğrulama gerektiren durumlar sorgulama ile taşınır. Örneğin sipariş webhook ile anlık düşse bile, mesaj gönderilmeden hemen önce siparişin hâlâ geçerli olduğu API'den teyit edilir. Bu ikinci kontrol, iptal edilmiş siparişe kargo mesajı gitmesini önler.

Webhook kullanırken atlanan iki şey

• Tekrar teslim: Webhook altyapıları, teslim edildiğinden emin olmak için aynı bildirimi birden fazla gönderebilir. Sipariş kimliği ile olay türünü birleştiren tekil bir anahtar tanımlanmazsa aynı müşteri aynı mesajı iki kez alır.
• Sessiz kopma: Webhook bir gün çalışmayı bırakabilir ve hata vermeden, sadece hiç olay gelmeyerek bunu yapar. Belirli bir süre olay gelmediğinde uyaran basit bir kontrol, akışın günlerce sessizce durmasını engeller.

Müşteri verisi nasıl eşleşir?

WhatsApp'ta adres telefon numarasıdır; dolayısıyla entegrasyonun kalitesi büyük ölçüde numara yönetiminin kalitesidir.

Numarayı tek biçime çevirin

Aynı numara mağaza veritabanında birçok farklı şekilde durur: başında sıfırla, ülke kodlu, boşluklu, tireli, parantezli. Kayıt sisteme girerken tek biçime çevrilmelidir; aksi hâlde aynı kişi birden fazla kayıt olarak görünür, izin bir kayıtta bulunurken ret başka kayıtta kalır ve müşteri vazgeçtiğini söylediği hâlde mesaj almaya devam eder.

Yalnızca numaraya güvenmeyin

Numara tek başına kimlik değildir. Sahada sık karşılaşılan üç durum:

• Kullanıcı üyelikte kendi numarasını, siparişte teslim alacak kişinin numarasını yazar. Sipariş bildirimi doğru kişiye gitmelidir, ama pazarlama izni ilk numaraya aittir.
• Aynı numara birden fazla üyelikte kullanılır; küçük işletmelerde ve aile hesaplarında yaygındır.
• Kullanıcı numarasını değiştirir; eski numara bir süre sonra başkasına tahsis edilir. Uzun süredir teslim edilmeyen numaraları temizlemek, yanlış kişiye sipariş bilgisi gitmesini önler.

Bu yüzden eşleştirme; numara, sipariş e-postası ve altyapıdaki müşteri kimliği üçlüsüyle kurulur. Hangi kaydın hangisine üstün geleceği baştan yazılmalıdır.

İzin verisi nerede durur?

Entegrasyonun en çok ihmal edilen parçası izin. Form üzerinde bir kutu vardır, kullanıcı işaretler, ama bu bilginin nereye yazıldığı ve akışlara nasıl aktarıldığı çoğu kurulumda belirsiz kalır. İzin kaydında bulunması gerekenler: numara, onay tarihi ve saati, onayın alındığı ekran, o gün gösterilen metnin sürümü. Ret kaydı ise kişi bazında ve tek bir merkezî listede tutulur; her akış gönderimden önce bu listeyi sorgular.

İşlem bildirimleri ile pazarlama mesajlarının izin gereksinimi farklıdır ve bu ayrım veri modeline de yansımalıdır. Ayrımın hukuki dayanağını İYS ve KVKK rehberinde madde madde açıkladık; entegrasyon tarafındaki karşılığı, izin alanını tek bir doğru-yanlış değeri olarak değil kanal ve amaç bazında saklamaktır.

E-ticaret WhatsApp bağlantısı hangi altyapıda ne değiştirir?

Modüller altyapıdan bağımsız çalışır; değişen tek şey olayın nereden okunduğudur. Aşağıdaki tablo, sık karşılaştığımız altyapılarda pratikte neyin farklılaştığını özetliyor.

Hazır altyapılar arasında seçim yapıyorsanız İkas mı Shopify mi karşılaştırmamız işinize yarayabilir; kendi altyapınızı kurmayı düşünüyorsanız RapiSoft e-ticaret altyapısı tarafında olay üretimi baştan bu akışlara uygun tasarlanmıştır. Standart dışı bir sistemde çalışıyorsanız gereken tek şey, olayı ileten bir uç noktanın tanımlanmasıdır; bu tür bağlantıları özel çözümler kapsamında biz kuruyoruz.

Örnek akış 1: WhatsApp doğum günü mesajı nasıl kurulur?

Doğum günü, entegrasyonun en basit görünen ama veri tarafında en çok tökezleyen akışıdır; çünkü olay mağazadan değil takvimden gelir. Sırasıyla kurulan parçalar:

1. Veri toplama noktası. Doğum günü alanını üyelik formuna eklemek kayıt oranını düşürür. Daha iyi çalışan yol, ilk sipariş sonrası teşekkür ekranında veya hesap sayfasında istemek ve karşılığında ne olacağını yazmaktır. Gün ve ay yeterlidir; yıl bilgisi akış için gerekmez.
2. Veri doğrulama. Zorunlu alan yapıldığında rastgele tarihler girilir. Alanı isteğe bağlı bırakmak, veriyi az ama kullanılabilir tutar. Ayrıca aynı gün içinde toplu tarih girişleri varsa bunlar genellikle test veya hatalı kayıttır.
3. Tetikleme zamanı. Mesaj günün kendisinde gönderilebilir; ancak hediye veya kupon içeren kurgularda birkaç gün önce göndermek daha mantıklıdır, çünkü kişi o gün alışverişe değil kutlamaya odaklıdır. Geçerlilik süresini doğum gününden sonrasına uzatmak dönüşümü artırır.
4. İzin ve frekans kontrolü. Doğum günü mesajı pazarlama kategorisindedir; izin olmadan gönderilemez ve kişi başına aylık pazarlama bütçesinden düşer. Aynı gün sepet veya kampanya mesajı planlıysa öncelik davranışa bağlı akıştadır.
5. Veri yoksa ne olur? Kayıtların önemli bir bölümünde doğum günü bilgisi bulunmaz. Bu akış bu yüzden tek başına bir gelir kalemi değil, sadakat tarafını besleyen bir tamamlayıcıdır; modülün ayrıntılarına Doğum Günü Mesajları sayfasından bakabilirsiniz.

Örnek akış 2: ilk siparişi olmayan üye hangi veriyle ayırt edilir?

Bu akış teknik olarak diğerlerinden ayrışır, çünkü bir olayın gerçekleşmesiyle değil gerçekleşmemesiyle tetiklenir. Sistem, üyelik tarihinden itibaren tanımlı süre boyunca sipariş kaydı görmediğinde mesajı planlar. Doğru çalışması için üç veri parçası gerekir:

• Üyelik tarihi: Sayaç buradan başlar. Toplu müşteri aktarımı yapılan mağazalarda aktarım tarihinin üyelik tarihi olarak yazılmaması gerekir; aksi hâlde eski müşterilerin tamamı bir gecede "yeni üye" olur.
• Sipariş geçmişi: Yalnızca üyelik hesabına bağlı siparişler değil, aynı kişiye ait misafir siparişler de kontrol edilmelidir. Eşleştirme e-posta ve numara üzerinden kurulmazsa, alışveriş yapmış müşteriye ilk alışveriş teşviki gider.
• Sipariş durumu: İptal edilmiş veya ödemesi tamamlanmamış sipariş, satın alma sayılmaz ama bu kişiye gönderilecek mesajın dili de standart teşvik olmamalıdır.

Gönderim anında sipariş kontrolünün tekrarlanması bu akışta özellikle önemlidir; mesaj kuyruğa girdikten sonra sipariş gelmiş olabilir. Akışın pazarlama tarafını, karşılama diziyle birlikte yeni üye karşılama yazısında ele aldık; modül tarafı için İlk Alışveriş Teşviki sayfasına bakabilirsiniz.

Sipariş durumlarını kendi diline çevirin

Her altyapı sipariş ve kargo durumlarını farklı adlandırır; aynı altyapıda bile kargo firması değiştiğinde durum kodları değişir. Modülün bunları doğrudan kullanması, her yeni firmada akışın yeniden yazılmasını gerektirir. Bunun yerine arada bir eşleme katmanı tutulur: gelen kod ne olursa olsun, sistem içinde sabit bir durum adına çevrilir ve mesaj bu sabit ada bağlanır.

Bu katmanın ikinci faydası, mesaj hak etmeyen hareketleri filtrelemektir. Kargo firmalarından gelen aktarma ve transfer merkezi kayıtları müşteri için bir eylem üretmez; eşleme tablosunda bunları "sessiz" olarak işaretlemek, bildirim yorgunluğunu kaynağında keser.

Test: neyi doğrulamadan yayına alınmaz?

Entegrasyon testinin amacı mesajın gitmesini görmek değil, gitmemesi gereken durumları doğrulamaktır. Yayına almadan önce test edilecekler:

1. Test siparişi verildiğinde olay ne kadar sürede düşüyor?
2. Aynı olay iki kez gönderildiğinde ikinci mesaj engelleniyor mu?
3. Sipariş iptal edildiğinde bekleyen mesajlar iptal oluyor mu?
4. İzin geri çekildiğinde kuyruktaki pazarlama mesajları duruyor mu?
5. Farklı biçimlerde yazılmış aynı numara tek kayıtta birleşiyor mu?
6. Sessiz saatte tetiklenen olay ertesi sabaha erteleniyor mu?
7. Şablon değişkenleri boş geldiğinde mesaj eksik metinle gitmiyor, değil mi?

Son madde küçük görünür ama en sık rastlanan hatalardan biridir: kargo takip numarası gelmediğinde şablonun boş değişkenle gönderilmesi, müşteriye yarım bir mesaj ulaştırır. Değişken boşsa mesaj hiç gönderilmemeli veya alternatif şablon kullanılmalıdır. Kargo tarafındaki olay eşlemesini kargo bildirimi yazısında ayrıntılı çıkardık.

Bakım: entegrasyonu sessizce bozan dört şey

• Yetki ve anahtar yenilemeleri. Süresi dolan bir erişim anahtarı, akışı hata mesajı bile üretmeden durdurabilir.
• Tema veya sayfa değişikliği. Site içi olaya bağlı akışlar, sayfa yapısı değiştiğinde kopar. Bu yüzden kritik olayları tema yerine sunucu tarafına bağlamak daha dayanıklıdır.
• Altyapı sürüm güncellemeleri. API alanlarının adı veya davranışı değişebilir; özellikle sipariş durum kodlarında görülür.
• Kargo firması değişikliği. Durum kodları firmadan firmaya farklıdır; eşleme güncellenmezse bildirimler yanlış aşamada gider.

Bu dördü de tek bir önlemle yakalanabilir: belirli bir süre olay gelmediğinde uyarı üreten basit bir izleme. Otomasyonun sessizce durması, yanlış mesaj göndermesinden daha uzun süre fark edilmeden kalır.

Özet

WhatsApp entegrasyonu bir mesajlaşma işi değil, veri işidir. Olayın ne kadar hızlı geldiği, müşterinin hangi anahtarla tanındığı ve iznin nerede saklandığı; mesaj metninden çok daha fazla belirleyicidir. Modüller mağaza yazılımının dışında çalıştığı için altyapı değişikliği kurguyu sıfırlamaz, ancak her altyapıda olay kaynağı farklıdır ve bağlantı yeniden kurulur. Doğum günü akışı verinin nereden toplandığına, ilk alışveriş teşviki ise sipariş geçmişinin ne kadar doğru okunduğuna bağlıdır. İkisinde de kurulumun asıl işi, mesajı göndermek değil yanlış mesajı engellemektir.