Sohbetten sonra ne olduğunu kaydet
Bir reklamın çok sohbet başlatması, ne kadar iş getirdiğini açıklamaz. Aynı kişi farklı günlerde sorular sorabilir, siparişini başka kanaldan tamamlayabilir veya kararını erteleyebilir. Satış takibinin işi, bu hareketleri tek bir müşteri ihtiyacı etrafında düzenlemektir. Mesajların tamamını analitik rapora taşımadan da bu ilişki kurulabilir.
WhatsApp Business resmi ürün sayfası, Facebook ve Instagram reklamlarının WhatsApp işletme sohbetini açabildiğini açıklar. Buradaki rehber bu geçişten sonraki işletme kaydını ele alır. Belirli bir yazılımın tüm sohbetleri otomatik okuyabildiğini veya bütün satışları kendiliğinden reklama bağlayabildiğini varsaymaz.
İlk hedefin “hangi reklam kazandı?” sorusundan önce “bu talebin doğrulanmış sonucu ne?” sorusunu yanıtlamak olsun. Sağlam bir sonuç kaydı kurulduğunda kaynak karşılaştırması da daha anlamlı hale gelir. Kaynak ile sonuç farklı yerlerde tutuluyorsa aralarındaki ilişkiyi sorumlu kişiye bırakmadan yazılı kurala bağla.
Talep, kişi ve siparişi ayır
Kişi müşteriyi, talep belirli bir ihtiyacı, sipariş ise gerçekleşen ticari işlemi temsil eder. Aynı kişinin tekrar mesaj göndermesi yeni talep olmayabilir. Buna karşılık daha önce aldığı üründen bağımsız yeni bir hizmet istemesi ayrı talep oluşturabilir. Ayrımı işletmenin iş akışına göre belirle ve bütün ekipte aynı şekilde uygula.
Her talebe değişmeyen bir talep kimliği ver. Sipariş gerçekleştiğinde sipariş kimliğini bu kayda bağla. Bir talepten iki farklı sipariş doğabiliyorsa bire çok ilişkiyi koru; ilk sipariş numarasının üzerine ikinciyi yazma. Aynı sipariş birden fazla görüşmede geçiyorsa toplam satışta bir kez say.
Kişi eşleştirmesini yalnız isim benzerliğiyle yapma. Aynı isimli kişiler olabilir; aynı kişi farklı biçimde yazabilir. Yetkili operasyon kaydındaki güvenilir ilişkiyi kullan. Eşleşme belirsizse doğrulama bekliyor durumunu koru. Satış bulunamadığı için en yakın tarihli sohbeti rastgele seçmek, kanal sonuçlarını yanlış birleştirir.
Kaynak bilgisinin kanıtını sakla
Kaynak alanına yalnız “Instagram” yazmak, hangi reklam veya teklifin konuşmayı başlattığını göstermeyebilir. Kullanabildiğin yetkili sistem gerçekten kampanya veya reklam kimliği sağlıyorsa bu bilgiyi ilk talep kaydıyla ilişkilendir. Böyle bir veri yoksa kaynağı varmış gibi üretme. Önceden doldurulmuş mesajın içeriğini değiştirebilen kullanıcı olduğunu da hesaba kat.
Müşterinin “reklamını gördüm” demesi yararlı bir beyan olabilir; teknik olarak doğrulanmış kampanya kimliğiyle aynı kanıt değildir. Her kaynağın yanında kanıt türünü tut: doğrulanmış sistem kaydı, müşteri beyanı, ekip girişi veya bilinmiyor. Böylece raporda kesinliği farklı kayıtlar birbirine karışmaz.
| Kaynak durumu | Nasıl kaydedilir? | Ne iddia edilmez? |
|---|---|---|
| Kimlik yetkili kaynaktan geldi | Kaynak sistem ve mevcut kampanya kimliği | Reklamın tek neden olduğu |
| Müşteri kanalı söyledi | Kanal ve müşteri beyanı etiketi | Belirli reklamın teknik olarak doğrulandığı |
| Yalnız tahmin var | Doğrulanmadı; yorum ayrı alanda | Tahminin gerçek kaynak olduğu |
| Kaynak bilgisi yok | Bilinmiyor | Organik veya doğrudan olduğu |
Bir bağlantı kendi web sitenden geçiyorsa mevcut kampanya parametrelerini izinli ve gerekli kapsamda izleyebilirsin; bu durum sohbet içindeki satışın da otomatik bağlandığı anlamına gelmez. Web ziyareti, sohbet ve sipariş arasındaki bağlantının her parçasını ayrı doğrula. Kaynağı bilinmeyen satışları raporun dışında saklamak yerine sayısını göster.
Asgari kayıt tablosunu oluştur
Başlangıçta karmaşık bir sistem kurmak zorunda değilsin. Düzenli kullanılan bir iç tablo, belirsiz birden fazla rapordan daha işe yarar olabilir. Aşağıdaki alanları talep ve satış kayıt şablonuna uyarlayabilirsin. Kayıtların kim tarafından ve ne zaman güncellendiği de izlenebilir olsun.
| Alan | Varsayımsal örnek | Amacı |
|---|---|---|
| Talep kimliği | TAL-041 | Tek bir ihtiyacı izlemek |
| İlk temas zamanı | İşletmenin saat dilimiyle zaman damgası | Başlangıç grubunu kurmak |
| Kaynak ve kanıt türü | Kampanya A / doğrulanmış sistem kaydı | Kaynak bilgisinin dayanağını korumak |
| İlgili ürün veya hizmet | Paket A | Teklif ve marj farkını görmek |
| Uygunluk durumu | Uygun / bilgi bekleniyor / uygun değil | Talebin niteliğini ayırmak |
| Mevcut aşama | Teklif bekliyor | Operasyonun sonraki işini belirlemek |
| Sorumlu ve sonraki adım | Teklif gönderilecek | Talebin sahipsiz kalmasını önlemek |
| İlişkili sipariş kimliği | SIP-103 | Satışı gerçek kayıtla bağlamak |
| Tutar ve para birimi | Açıkça tanımlı net gelir / TRY | Aynı kapsamda ekonomik sonuç hesaplamak |
| İade veya iptal ilişkisi | IADE-017 / SIP-103 | Sonradan gelen düzeltmeyi korumak |
Serbest metin alanlarına bütün konuşmayı yapıştırmak yerine kısa durum kodları kullan. Özellikle talebin sonucu ve kayıp nedeni ayrı olsun. Satın almamış olmak, neden satın almadığını bildiğin anlamına gelmez. Birinin yanıt vermemesiyle fiyatı açıkça reddetmesi farklı durumlar olarak kalmalıdır.
Satış koşulunu ve ödemeyi netleştir
“Tamam, alıyorum” mesajını hangi koşulda satışa dönüştüreceğini belirle. İş modeline göre sipariş onayı, ödeme doğrulaması veya yetkili operasyon kaydı gerekebilir. Her işletmeye aynı koşulu dayatmak yerine kendi koşulunu açıkça tanımla. Sözlü kabul, sipariş, tahsilat ve hizmetin gerçekleşmesi için gerekiyorsa ayrı durumlar tut.
GA4 lead olayları referansı, ilk talep ve uygun talebi müşteriye dönüşme aşamasından ayırır. İç kaydında da aynı anlam ayrımını koru. Olay adlarını bir analitik sisteme göndermek, eksik satış kanıtını tamamlamaz; önce yetkili kaynağın doğrulaması gerekir.
Kaporalı işte iki ödeme hareketi bulunabilir. Varsayımsal toplam sipariş bedeli 1.200 TL ise 400 TL kapora ve 800 TL kalan ödeme birlikte 1.200 TL tahsilat yapar. Sipariş bedelini hem kaporada hem kalan ödemede tekrar kaydedersen 2.400 TL gibi hatalı gelir oluşabilir. Ödeme hareketiyle sipariş toplamının farklı alanlar olduğunu koru.
Varsayımsal bir sohbetin kayıt yolu
Aşağıdaki örnek gerçek müşteri verisi değildir. TAL-041 kimlikli talep Kampanya A kaydıyla açılmış olsun. Kişi ürün ve teslim koşulunu sorar; ihtiyacı uygun bulunur, teklif kabul edilir ve SIP-103 siparişi oluşur. Daha sonra aynı siparişe kısmi iade gelir.
| Hareket | Kayıt | Sayım kararı |
|---|---|---|
| İlk talep | TAL-041 oluşturuldu | Bir yeni talep |
| Aynı ihtiyaç için tekrar mesaj | TAL-041 güncellendi | Yeni talep değil |
| Uygunluk doğrulandı | Durum uygun oldu | Bir uygun talep |
| Sipariş koşulu karşılandı | SIP-103, toplam 1.200 TL | Bir satış kaydı |
| Kısmi iade | IADE-017, 200 TL, SIP-103'e bağlı | Aynı gelir tabanında net tutar 1.000 TL |
Sonradan gelen iade ilk satışın kaynak ilişkisini silmez; ekonomik sonucu düzeltir. İade günüyle satış günü farklı olabilir. İlk temas grubunu değerlendirirken düzeltmeyi ilgili siparişe götür; dönemsel nakit hareketini değerlendirirken iadenin gerçekleştiği zamanı da koru. Bunlar iki farklı rapor sorusudur.
Açık durumları ve olgun grupları izle
Talep geldiği gün satış gerçekleşmeyebilir. Açık kayıt için son güncelleme, sorumlu ve sonraki adımı tut. “Henüz değerlendirilmedi”, “teklif bekliyor”, “müşteriden yanıt bekleniyor” ve “sonuç doğrulanmadı” farklı bilgi eksiklerini anlatır. Bunları tek bir kayıp sütununda birleştirme.
Oranları ilk temas dönemine göre oluşturduğun ve yeterli takip süresini tamamlamış grupta hesapla. Varsayımsal olarak 40 tekil talebin 20'si uygun, bu 20 talebin sekizi doğrulanmış satış olsun. Uygunluk yüzde 50, uygundan satışa geçiş yüzde 40 ve toplam talep-satış geçişi yüzde 20'dir. Aynı grubun reklam harcaması 2.000 TL ise gözlenen satış CPA'sı 250 TL olur.
Bu oranlara yeni gelen, sonucu henüz belli olmayan talepleri kapanmış başarısızlık gibi ekleme. Sonuç beklenen grubun büyüklüğünü ayrı göster. Ayrıca hiç satış eşleşmesi bulunmayan kayıtla, satış olmadığı doğrulanan kayıt farklıdır. Kayıtlar tamamlandıkça sonucun değişebileceğini raporda belirt.
Kişisel veriyi operasyon ihtiyacıyla sınırla
Müşteriye hizmet vermek için kullanılan iletişim bilgisiyle reklam performansı raporunun ihtiyacı farklıdır. Google Analytics veri koruma rehberi telefon, e-posta ve benzeri kişisel bilgilerin analitik alanlarına veya kampanya parametrelerine taşınmaması gerektiğini açıklar. Ham sohbet metnini ölçüm olaylarına ekleme.
İç müşteri kaydında gereken bilgiyi erişimi sınırlı bir yerde tut; analitik tarafta karar için gereken durum, teknik kimlik ve toplu ölçüyü kullan. Telefonu yalnız farklı biçimde yazarak veya dönüştürerek güvenli hale geldiğini varsayma. Erişim, saklama ve izin akışını kullandığın sistemlerin gerçek veri yollarına göre tasarla.
Kanal atıflarını satış toplamıyla karıştırma
İşletme kaydında bir sipariş bulunurken farklı platform raporlarında aynı siparişle ilişkili sonuçlar görebilirsin. Kendi toplamını tekil sipariş kimliğinden üret. Google Analytics atıf dokümanı, modellerin müşteri yolundaki temaslara kredi dağıttığını belirtir. Bu rapor mantığını işletmenin gerçekleşmiş sipariş sayımından ayrı tut.
“Reklamla ilişkili satış” demek, o satışın reklam olmasaydı gerçekleşmeyeceğini kanıtlamaz. Bu rehberin kayıt düzeni o nedensel soruyu çözmez. Sağladığı şey hangi talebin hangi sonuçla ilişkili olduğunu izlenebilir kılmaktır. Bütçe kararı verirken bu sınırı ve kaynağı bilinmeyen kayıtların payını birlikte değerlendir.
Kayıt düzenini ekiple dene
Bir ekip arkadaşından aynı örnek talebi işlemesini iste: yeni ihtiyaç açsın, tekrar mesajı güncellesin, siparişi ilişkilendirsin ve kısmi iadeyi eklesin. Beklenen sonuç bir talep, bir sipariş ve düzeltilmiş tek net gelir olmalı. İki kişi aynı kaydı ayrı açıyorsa birleştirme ve sorumluluk kuralını düzelt.
Sonra sınırlı bir gerçek iş akışında kayıtların eksiksiz tutulup tutulmadığını kontrol et. Aracın karmaşıklığından önce kullanım disiplinine bak. Ölçüm planıyla alanların teknik karşılığını belirle; aşamalardan biri sürekli tıkanıyorsa mesaj var, satış yok rehberini kullan. Katkı hesabını da başabaş maliyet aracıyla aynı gelir tabanında yap.
