Yandex Metrica: CRM’den çevrimdışı dönüşüm aktarımı
Doğrulanmış CRM olaylarını hazırlayın; eşleşme, iptal ve maliyetleri iki ayrıntılı pilotla inceleyip durdurma ve büyütme kararını kanıta bağlayın.
CRM içinde tamamlanmış bir satış bulunurken web analizi yalnızca gönderilmiş bir form gösterebilir. Çevrimdışı olay aktarımı bu iki gözlemi birbirine bağlamaya yardımcı olur. Ancak dosyadaki her satır otomatik olarak eşleşmiş ziyaret, kârlı müşteri veya onaylanmış iş ortağı ödemesi değildir. Aranan sonuç denetlenebilir bir zincirdir: ne oldu, hangi zamanda oldu, hangi kimlik bilgisi kaydedildi ve işletme bu sonucu hangi kanıtla kabul etti?
Bu rehber Rusya pazarına yönelik kampanyalar yürüten reklamverenler içindir. Türkçe çeviri coğrafyayı değiştirmez ve başka ülkelerde hizmet erişimini doğrulamaz. Resmî kaynaklar 22 Ekim 2026 tarihinde kontrol edildi. Çalışma kartları, karar eşikleri ve iki örnek bizim editoryal yöntemimizdir. TRY tutarları bağımsız eğitim varsayımlarıdır; Rusya fiyatlarının kur karşılığı, sağlayıcı tarifesi veya gerçek müşteri başarısı olarak okunmamalıdır.
1. Doğrulanmış sonucun ne olduğunu yazın
Tek bir ürün, açılış sayfası ve müşteri kazanım dönemi seçerek başlayın. Satış sorumlusundan kabul edilen sonucu günlük dille anlatmasını isteyin. Telefonun çalışması uygun bir talep bulunduğunu kanıtlamaz; teklifin imzalanması da ödeme alındığını göstermez. Gerekli kanıtı, kontrol edecek kişiyi ve kaydın hangi aşamada dışa aktarılabileceğini yazın. İlk form gönderimini ayrı bir olay olarak tutun; satış ekibinin sonradan verdiği kararla aynı kabul etmeyin.
İlk örnekte nihai sonuç, iptal kontrolü tamamlandıktan sonra ödenmiş ve gerçekleştirilmiş servis ziyaretidir. İkinci örnekte talep uygunluğu ara aşamadır; ekonomik sonuç ise ödemesi alınmış uygulama işidir. Ara hedefin adı tahsil edilmiş gelir izlenimi vermemelidir. Bir raporda tek çizgi daha kolay anlatılıyor diye farklı iş aşamalarını birleştirmeyin. Daha sonra bu raporu okuyacak kişinin aynı tanımı anlayabilmesi gerekir.
İç olay kartında kayıt anahtarı, iş aşaması, kanıt referansı, gerçek zaman ve saat dilimi, kimlik türü ve değeri, hedef, isteğe bağlı tutar ve para birimi, iptal durumu, aktarım paketi ve kontrol eden kişi bulunur. Bu kart Metrica yükleme şeması değildir; sizin işletme belgenizdir. Müşteri belgeleri ve iç notlar analiz dosyasına kendiliğinden eklenmez. Her alan için niçin gerekli olduğu ve doğruluğundan kimin sorumlu olduğu açıklanmalıdır.
İş ortaklığı programı için AffiliateCore, kendi teklifinizi ve kabul koşullarını hazırlayacağınız ilk seçenek olabilir. Metrica bu akışta harici ölçüm aracı olarak kalır. Otomatik AffiliateCore-Metrica bağlantısı, garanti edilmiş eşleşme veya analitik hedef üzerinden ödeme onayı vaat etmiyoruz. Ürün ve kabul edilen olay netleştiğinde reklamveren profilinizi hazırlayın. Ürünün ve trafik kaynağının uygunluğu ayrıca kontrol edilir; hesap açmak her ürünün kabul edileceği anlamına gelmez.
2. Küçük ve incelenebilir bir paket oluşturun
Sorumlu kişinin doğru sayaca, seçilen CRM kayıtlarına ve siteyi yöneten geliştiriciye yetkili erişimi olmalıdır. Görev dağıtmadan önce hesabın gerçekten hangi işlemlere izin verdiğini kontrol edin. Gerekli olduğu doğrulanmamış rol adları uydurmayın. Parolalar ve erişim anahtarları çalışma tablosunda tutulmaz. Ayrı test ortamı varsa kullanın. Gerçek işletme üzerinde yapılan gözlemsel pilot, gerçek olayları izler; reklam sistemini beslemek için ücretli sahte dönüşümler üretmez.
Resmî API rehberi eşleştirme kimliği, Target ve DateTime ister; Price ile Currency isteğe bağlıdır. Seçilen aktarım yolunun tam şemasını kullanın. İç çalışma kartı bilinçli olarak daha geniştir ve olduğu gibi yüklenmemelidir. Yardım sayfalarında görülen farklı büyük ve küçük harf yazımlarının her entegrasyonda birbirinin yerine kabul edildiğini varsaymayın. Alan adları gerçek teknik sözleşmeyle karşılaştırılmalıdır.
İlk paket için tek bir kimlik yolu seçin. İlgili müşteri yolculuğunda gerçekten yakalanan değeri eksiksiz metin olarak saklayın. CRM fırsat numarası otomatik olarak analiz ziyaretçisi kimliği olmaz. Geliştiriciden izinli bir kontrol kaydı üzerinden yakalama ve saklama zincirini göstermesini isteyin. Değer yoksa kayıt istisna listesine gider. Başka müşterinin kimliğini kopyalamak doğru eşleşme sağlamaz; yalnızca yanlış ilişkiyi daha inandırıcı gösterir.
Üç satırlık bir eşleme kartı hazırlayın: CRM kanıtı → iş olayı; iş olayı → tam hedef kimliği; saklanan kimlik → belgelenmiş dosya sütunu. Sayaç referansı ile kontrol eden kişiyi ekleyin. Kartı başka bir şirketin ekran görüntüsüyle değil, gerçek hesapla karşılaştırın. Arayüz talimatları hedef oluşturma ve çevrimdışı veri yüklemeyi açıklar. Güncel belgeyi izleyin; doğrulanmamış düğmelerden oluşan bir tıklama sırası yazmayın.
Zaman bilgisini ayrı kontrol edin. Burada aktarımın başladığı an değil, kanıtlanmış iş olayının zamanı önemlidir. Kaynak saat dilimi belli olmalıdır. Dönüştürülen örnek bir değeri okunabilir tarihe geri çevirin ve CRM ile karşılaştırın. Milisaniye, belirsiz tarih biçimi veya tablo yuvarlaması makul görünen yanlış sonuç üretir. CSV dosyasını hücreleri elle birleştirerek değil, uygun bir dışa aktarım aracıyla oluşturun.
İçe aktarım özeti ziyaretleri tamamlama dönemini 21 gün olarak belirtir. Düzenli gönderim planlayın; ziyaret, olay ve işleme tarihlerini birlikte inceleyin. Bu, kapanıştan sonra 21 gün içinde gönderilen her satışın eşleşeceği garantisi değildir. Uzun görüşmeler için ayrı tasarım gerekir. Eski olayı yeni göstermek için tarih değiştirmek analizi düzeltmez; iş geçmişini yanlış anlatır.İlk kontrol yalnızca alanların boş olup olmadığına bakmamalıdır. Bütün kayıtlarda aynı kimlik varsa test formundan kalmış sabit bir değer olabilir. Onay zamanı denilen alan aslında talebin açıldığı zamanı taşıyor olabilir. Bu tür hatalar çoğu zaman tüm paketi etkiler. Teknik kontrolden geçmek için birkaç satırı değiştirmek yerine, veriyi üreten süreci düzeltin ve ardından yeni örnekleri baştan denetleyin.
Kullanılabilir dosya iskeleti
API yolu için aşağıdaki başlıkla başlayın. Her yer tutucuyu doğrulanmış değerle değiştirin; bu iskelet doğrudan yüklenmez. İlk senaryoda crm_service_net, ikincide ayrı crm_qualified hedefi üzerinde anlaşılabilir. Bunlar oluşturmanız için önerilen kimliklerdir, mevcut hedefler değildir. İç kayıt anahtarlarını asgari dosyaya eklemeyin. Uygunluk aşamasında gelir uydurmak yerine tutar alanlarını dışarıda bırakın. Göndermeden önce ikinci bir kişi tamamlanan dosyayı eşleme kartıyla karşılaştırsın.
ClientId,Target,DateTime
ClientId = <captured_identifier>Target = <configured_target>DateTime = <verified_unix_seconds>
3. Teslimatı, eşleşmeyi ve ticari kabulü ayırın
Göndermeden önce uygun kayıtları, dışlanan kayıtları ve benzersiz iç olay anahtarlarını sayın. Pakete bir referans verin ve gönderilen kopyayı sınırlı erişim altında değişmeden saklayın. Önerdiğimiz iç anahtar iş kaydı ile aşamayı birleştirir. Bu, kendi dışa aktarım sürecinizde tekrarları önleme yöntemidir; alıcı sistemin otomatik tekilleştirme garantisi olarak sunulmaz. İki ayrı gerçek olay ile yanlışlıkla yinelenen tek olay ayırt edilebilmelidir.
Gönderim yanıtını saklayın ve tekrar denemeden önce işleme durumunu açıklığa kavuşturun. Zaman aşımı bilinmeyen sonuç demektir; kesin ret anlamına gelmez. Önce ilk paketi karşılaştırın. Taşıma hataları, eşleşmeyen olaylar ve ticari iptaller ayrı listelerde tutulmalıdır çünkü çözüm yolları farklıdır. Teknik tekrar yeni bir satın alma yaratmamalı veya olay zamanını sessizce başka bir güne taşımamalıdır.
Kontrol tarihinde önemli bir uyarı bulunuyor: Yandex, raporlardaki eşleşme durumlarının yanlış görüntülenebileceğini ve güncel eşleşme oranının veri yükleme ayarlarından kontrol edilmesini söylüyor. Güncel yardım metnini dikkate alın. Etkilenmiş olabilecek rapordan tek başına kesin satır teşhisi çıkarmayın. Bulgular çelişiyorsa çelişkiyi kaydedin; eksik kanıt yerine tahmin ederek hata nedeni atamayın.
Çevrimdışı dönüşüm raporu eşleşme teşhisini belgeler. Bu bilgiyi paket kanıtlarıyla ve mevcut uyarıyı gözeterek kullanın. Kendi mutabakatınız CRM’de doğrulanan, gönderilen, işlenen ve eşleşen sonuçları ayrı göstermelidir. Eşleşmeyen gerçek satış gelirden silinmez. Buna karşılık, raporda hedef bulunması daha sonra yapılan müşteri iadesini ticari kayıtta geçersiz kılmaz.İptal için bu rehberin güvenli sınırı, iç ticari kayıtları düzeltmek ve ilk olayı güncel net gelir gibi değerlendirmemektir. Yeni bir sıradan çevrimdışı satırın önceki satırı sildiğini veya güncellediğini varsaymayın. Sipariş durumu değiştirmek gerekiyorsa ayrıca belgelenen CRM sipariş aktarım yolunu araştırın. Kimlik, güncelleme davranışı ve sınırlamalar uygulamadan önce doğrulanmalıdır; burada o yol için hazır entegrasyon sunulmuyor.
4. Eğitim senaryosu: tamamlanan teknik servis
Hayalî reklamveren izin verilen ekipman bakım hizmeti sunuyor. Pilot tek bölgeyi, tek sayfayı ve tamamlanmış bir müşteri kohortunu kapsıyor. Malzeme paketi hizmet açıklaması, uygunluk görüşmesi metni, eşleme kartı, aktarım tablosu ve iptal defterinden oluşuyor. Görüşmede ekipman, kapsama alanındaki adres ve iş kapsamına onay soruluyor. Her talebin mutlaka randevuya dönüşeceği söylenmiyor; uygun olmayan talep gerekçesiyle ayrılıyor.
Örnek iç kart şöyle: S-017; hizmet tamamlandı; makbuz sorumlu tarafından kontrol edildi; saat dilimiyle zaman kaydedildi; yakalanan kimlik mevcut; nihai hizmet hedefi; iptal incelemesi tamamlandı. Bu, doğrudan yüklenecek dosya satırı değildir. Eksik kart gerekçesiyle geri verilir. Geliştirici bir izinli yolculuğu baştan sona izler; ardından analist paketteki diğer uygun olayları serbest bırakır. Böylece ilk toplu işlemden önce yöntem anlaşılmış olur.
Kohortta 100 talep var. Yirmisi randevu öncesinde reddediliyor, 80’i planlamaya kabul ediliyor, 60’ı ödenmiş ve tamamlanmış ziyarete dönüşüyor. Bu 60 sonucun altısı nihai seçimden önce iptal veya iade ediliyor. Net 54 sonuç kalıyor. Kabul edilen diğer 20 talep gözlem döneminde ücretli hizmete dönüşmüyor ve ayrıca gösteriliyor. Son pakette 54 olay bulunuyor; varsayım olarak 48’i eşleşiyor, altısı inceleme sonrasında da ilişkilendirilemiyor.
Pilot maliyetleri 48.000 TRY reklam, 8.000 TRY sayfa ve içerik, 7.200 TRY kimlik uygulaması, 4.800 TRY aktarım ve kontrol, 4.000 TRY ayrılmış CRM gideri ve 8.000 TRY satış işlemesi. Toplam 80.000 TRY. Model tüm atanmış kazanım ve ölçüm giderlerini içeriyor. Değişken hizmet giderleri birim katkıda zaten düşülüyor. Vergi ve genel sabit giderler bu modelde yok; hesaplanan bakiye muhasebe net kârı olarak adlandırılmamalıdır.
Her net hizmetin varsayımsal geliri 7.200 TRY, değişken uygulama maliyetinden sonraki katkısı 2.400 TRY olsun. Gelir 54 × 7.200 = 388.800 TRY. Katkı 54 × 2.400 = 129.600 TRY. Pilot giderinden sonra 49.600 TRY kalır. Net sonuç başına tam maliyet 80.000 ÷ 54 = 1.481,48 TRY. Başabaş için en az 34 hizmet gerekir; çünkü 80.000 ÷ 2.400 = 33,33 sonucu yukarı yuvarlanır.
İptal oranı 6 ÷ 60 = %10, eşleşme kapsamı 48 ÷ 54 = %88,89. Paydalar farklıdır çünkü iki ayrı soru cevaplanır. Ticari değerlendirme kanıtlanmış 54 sonucu kullanır; kaynak karşılaştırması altı ilişkilendirilemeyen sonucu görünür tutar. Kimliği düzeltmek altı yeni müşteri yaratmaz. Bilinmeyen satışları reklam harcamasına orantılı dağıtmak da kanıt olmadan doğru değildir; zayıf bir kaynağı olduğundan iyi gösterebilir.
Önceden yazılan durdurma kuralları yanlış müşteri eşleşmesi, açıklanamayan tekrar, %15 üstünde iptal veya net sonuç başına 2.400 TRY üstünde tahminî maliyettir. Pozitif katkı veri bütünlüğü sorununu ortadan kaldırmaz. Bu örnekte kapsam seçilmiş %90 hedefinin altındadır; bu nedenle büyütme durur. İki karşılaştırılabilir olgun kohort kuralları sağladıktan sonra küçük bir bütçe artışı denenebilir; aynı maliyetlerin sonsuza dek korunacağı varsayılmaz.
5. Eğitim senaryosu: uzun B2B uygulaması
İkinci hayalî reklamveren şirketlere ekipman kurulumu satıyor. Gereken malzemeler ihtiyaç özeti, uygunluk ölçütleri, teklif sürümü, aşama geçmişi ve iptal kaydıdır. Uygunluk için ilgili ihtiyaç, erişilebilir karar sorumlusu ve gerçekçi uygulama kapsamı aranır. Bunlar işletmenin seçtiği ölçütlerdir; Yandex’in resmî kaliteli talep tanımı değildir. Başka bir çalışan kaydedilen kanıtlarla aynı kabul kararını yeniden değerlendirebilmelidir.
Altmış talebin on ikisi reddediliyor, 48’i uygun bulunuyor. Otuzuna teklif hazırlanıyor. On iki teklif gözlenen kohortta ödenmiş projeye dönüşüyor; ikisi iptal oluyor ve on net sonuç kalıyor. Diğer 18 teklif gerçek durumuna göre açık veya kaybedilmiş olarak tutuluyor. Kırk sekiz uygunluğu 48 satış diye anlatmayın. Ara sinyal ile nihai ticari sonuç farklı sütunlarda bulunmalı; satış ekibinin tek faaliyet sayısına alışmış olması bunu değiştirmez.
Uygunluk olayları zamanında gönderilirken geç kapanan satışlar CRM ticari defterinde tutuluyor. Bazı görüşmeler ziyaret tamamlama penceresini aşıyor. Satış tarihi geriye alınmıyor ve yapay yeni ziyaret oluşturulmuyor. Gerekirse ayrı sipariş aktarım yolu araştırılır; uygun değilse nihai satış atfının eksik kaldığı kabul edilir. Örnekte 48 uygunluk olayının 42’si eşleşiyor: %87,50. Bu, on net satışın eşleşme oranı değildir; farklı aşamanın ölçümüdür.
Giderler 72.000 TRY reklam, 12.000 TRY ihtiyaç özeti ve sayfa, 8.000 TRY kimlik ve aktarım kurulumu, 10.000 TRY uygunluk incelemesi, 6.000 TRY CRM payı ve 12.000 TRY teklif hazırlığıdır. Toplam 120.000 TRY. Korunan her proje 60.000 TRY gelir ve değişken uygulama giderinden sonra 16.000 TRY katkı verir. On proje 600.000 TRY gelir, 160.000 TRY katkı ve pilot sonrası 40.000 TRY bakiye üretir. Net sonuç maliyeti 12.000 TRY; başabaş sekiz projedir çünkü 120.000 ÷ 16.000 = 7,5.
İptal oranı 2 ÷ 12 = %16,67 olup önceden belirlenen %15 sınırını aşar. İki proje daha iptal edilirse sekiz proje, 128.000 TRY katkı ve yalnızca 8.000 TRY bakiye kalır. Yedi proje kaldığında 8.000 TRY açık oluşur. Sabit giderler hesaba katılmadan bile güvenlik payı küçüktür. Uygun talebin ucuz olması, sonraki teslimat istikrarsızken reklamı artırmaya gerekçe olamaz; iyi görünen ara metrik sonuca üstün tutulmaz.
Genişlemeyi durdurun; iptal nedenlerini teklif sürümleri ve kapsam vaatleriyle karşılaştırın. İzin verilen talep toplama ancak zaten onaylanan bütçe içinde devam eder. Yeni pilotta daha açık uygulama kontrol listesi gibi tek unsur değiştirilir; olay tanımları ve gözlem yaşı korunur. Ekonomik eşik ile iptal kuralını birlikte geçen olgun kohortlardan sonra büyütme yeniden denenir. Bu çerçeve gelecekte aynı performansı sağlayacağına dair bir garanti değildir.
İkinci pilotun iç kartı B-009; uygunluk tamamlandı; ihtiyaç belgesi incelendi; sorumlu kişi doğrulandı; gerçek zaman; yakalanan kimlik; crm_qualified; paket referansı şeklinde olabilir. Sonradan ödenen proje kendi kanıtını ve aşamasını alır. İki örnekte de iptal çalışması satış veya teklif emeğine dahildir; başka geri alınamayan uygulama gideri ve ödeme komisyonu olmadığı varsayılır. Gerçekte varsa katkı hesabından önce ekleyin. Kimlik erişimini sınırlandırın, saklama süresini ve veri işleme dayanağını belirleyin; kimlikler otomatik olarak anonim değildir.
6. Dosyayla birlikte kanıtlı karar teslim edin
Teslim paketi olay anlaşması, alan eşlemesi, sınırlı erişimli paket referansı, istisna sayıları, hesap tablosu ve yazılmış karar içerir. Eksik kimliklerden ve ticari iadelerden sorumlu kişileri ayrı belirtin. Bilinmeyen noktaları açıkça yazın. Güncel rapor uyarısı güvenilir teşhisi engelliyorsa büyütme duraklatılmış kalır. İkna edici bir açıklama, tekrar yapılabilir kontrolün yerine geçmez ve bilinmeyen sonucu olumlu sonuca dönüştürmez.
AffiliateCore teklifinde iş ortağı kabul metnini gerçekten doğruladığınız olayla uyumlu hâle getirin. Mevcut süreç üzerinden teklif hazırlamak veya incelemek için reklamveren hesabınızı açın. Site hedefleri ölçüme yardımcı olur; iş ortağı kabulü ve hesaplaşma üzerinde anlaşılmış koşullara ve kendi kontrollerine bağlıdır. Metrica üzerinden otomatik mali onay varsayılmaz.
Uygulama göreviniz önce on uygun CRM kartını hiçbir şey yüklemeden incelemektir. Kanıtı, kimliği, zamanı ve iptal geçmişini yeniden oluşturun. Her dışlamayı açıklayın, net sonuç maliyetini hesaplayın ve pilotun sürmesi ya da durması için tek cümlelik karar yazın. Ancak bundan sonra kontrollü paketi gönderin. İşleme tamamlandığında ve kohort olgunlaştığında mutabakatı tekrar yapın; bu kontroller farklı sorulara cevap verir.
Ek olarak kaynak kalitesi rehberini ve reklamdan CRM’ye yolculuk denetimini okuyabilirsiniz. Bunlar kaynak kıyaslama ve yolculuk hatalarına odaklanır. Buradaki çıktı ise iptalleri ayrı tutan kontrollü olay aktarımıdır; teknik açıdan başarılı bir yükleme gerçek ticari sonucun yerine geçmemelidir.