Sektör Eki 21, 2026

Yandex Direct: Başvuru var, satış yok — CRM’ye kadar denetim

Reklam, açılış sayfası ve başvuru işleme arasındaki hatayı bulun: Rusya için iki öğretici senaryo, şablonlar ve kontrollü pilotu tekrarlama koşulları.

A
AffiliateCore
52 görüntülenme
Yandex Direct: Başvuru var, satış yok — CRM’ye kadar denetim

Yandex Direct başvuru getiriyor ama satış ekibi sipariş alamıyorsa, “hedef kitleyi değiştirin” önerisi erken bir teşhistir. Bir kişi aynı gün servis sözü görebilir, farklı bir hizmeti anlatan sayfaya gelebilir, telefonunu bırakabilir ve temsilciden bambaşka koşullar duyabilir. Araçların her biri çalışıyor görünür: reklam gösterilir, form gönderilir, CRM kayıt oluşturur. Ancak bütün yol birbiriyle tutarlı değildir.

Bu denetimin çıktısı somut bir hata kaydıdır: sözün veya işlemin hangi geçişte kaybolduğu, bunu neyin kanıtladığı, kimin düzelteceği ve hangi tekrar testinin düzeltmeyi doğrulayacağı. Bu, Rusya pazarıyla çalışan reklamveren için hazırlanmış bir rehberdir; genel Metrica raporları veya istatistik uzlaştırma anlatımı değildir. Bütün çevirilerde pazar Rusya olarak kalır. Resmî kaynaklar 25 Ekim 2026 tarihinde kontrol edildi. Şablonlar, eşikler ve iki senaryo editoryal yöntemimizdir; Yandex şartları değildir.

Tam olarak neyin çalışmadığını tanımlayın

Tek bir bileşim seçin: reklam grubu, hizmet, şehir, açılış sayfası ve iletişim yolu. İlk incelemede amacı anlaşılabilen arama başvuruları kullanışlıdır. Bunları Yandex reklam ağı trafiğinden, mevcut müşterilerden ve başka hizmetlerden ayırın; bağlamları farklıdır. Teklif koşullarının değişmediği tamamlanmış bir dönem seçin ve gözlemin bitiş tarihini kaydedin. Hâlâ devam eden uzun bir satış süreci ret anlamına gelmez.

Reklamlara ve hedef URL’lere erişim, Direct ve Metrica raporları, formu test edebilen geliştirici, anonimleştirilmiş CRM geçmişi ve sorumlu satış yöneticisi gerekir. Reklamın, sayfanın ilk bölümünün, formun ve ilk konuşma metninin sürümlerini saklayın. Çalışma saatlerini, gerçek hizmet alanını, ürün veya teknisyen uygunluğunu da toplayın. Sürüm geçmişi yoksa bugünkü sayfa, ziyaretçinin dün ne gördüğünü kanıtlamaz; bu sınırlamayı açıkça yazın.

Dört düzey tanımlayın. Olay, analitik sisteminin sinyalidir. Başvuru, işletmeye gerçekten ulaşmış kayıttır. Kabul edilmiş başvuru, geldiği anda geçerli koşulları karşılar ve işlenebilir. Korunan satış, örnekteki iptal gözlem süresinden sonra tamamlanmış ve ödenmiş sipariştir. Sonradan satın almaktan vazgeçmek, kabul edilmiş başvuruyu kendiliğinden geçersiz yapmaz. Yayıncı ödemesini ayrıca kararlaştırılmış olay belirler.

Ayrıca bir iş ortaklığı kanalı hazırlıyorsanız, AffiliateCore’a reklamveren olarak kaydolun ve doğrulanmış açılış sayfasıyla teklif açıklamanızı hazırlayın. Platformumuz ad, açıklama ve hedef URL içeren teklif taslaklarını destekler. Ürünün ve kaynağın uygunluğu ayrıca incelenir. Direct denetimi kendi reklam araçlarınızda ve CRM’nizde yapılır; burada bu zincirin hazır senkronizasyonunu vaat etmiyoruz.

Beş geçişi kanıtlarıyla inceleyin

1. Arama sorgusu → reklamın sözü

Direct’in resmî arama sorguları raporu, gösterimleri tetikleyen sorguları gösterir. Erişilebilir sorguyu hizmet, şehir, süre ve sınırlamalarla karşılaştırın. Sorgunun yerine hedefleme anahtar kelimesini koymayın. Kişisel eşleştirme kanıtlanmadıkça belirli bir sorguyu belirli müşteriye atamayın; erişebildiğiniz segment düzeyinde çalışın.

Üç sütun hazırlayın: ziyaretçinin beklentisi, reklamın sözü ve işletmenin gerçekten sunabildiği şey. “Bugün onarım”, “bugün sizi arayacağız” demek değildir. İlgisiz sorgu hedeflemenin incelenmesini gerektirir; ilgili sorguya verilen yerine getirilemez söz ise teklifin düzeltilmesini gerektirir. İkisi de temsilcinin başvuruyu reddetmesiyle sonuçlansa bile farklı hatalardır.

2. Reklam → açılış sayfası

Canlı reklamınıza tekrar tekrar tıklamak yerine kaydedilmiş hedef adresini doğrudan açın. Bilgisayar ve mobil tarayıcıyı, ana hedefi ve ek bağlantıları, formu ve telefonu kontrol edin. İlk bölümdeki koşulları reklamla karşılaştırın: önemli bir istisna ilk kez telefon görüşmesinde ortaya çıkmamalıdır. Tarih, sürüm, cihaz ve beklenen test sonucunu yazın.

Yandex, yclid içeren URL’lerin çalışmasını kontrol etmeyi ve bunların yol açtığı site hatalarını düzeltmeyi önerir: Direct ve Metrica belgeleri. Yönlendirmelerden sonraki son adresi ve hizmet bağlamının korunmasını da inceleyin. Etiket kaybı ölçümü araştırma nedenidir, tek başına satış kaybının kanıtı değildir.

3. Form → alınmış başvuru

Form hedefi başarısız bir denemeyi de sayabilir; bu durum Metrica yardımında açıklanır. Boş formu, geçersiz numarayı, geçerli gönderimi ve ikinci tıklamayı ayrı ayrı test edin. Görünen yanıtı, işletmenin alımını ve CRM kaydını yazın. Teşekkür mesajı, kaydetme onayının yerine geçmez.

Metrica, reachGoal ile hedef olaylarını destekler: resmî açıklama. Önerimiz, geliştiricinin istenen olayı yalnızca tıklamaya değil, başvurunun doğrulanmış kaydına bağlamasıdır. Bu, sitenizde yapılacak bir düzenlemedir; tek kutucukla evrensel çözüm değildir. Test kayıtlarını işaretleyin ve ticari sonuçlardan çıkarın.

Yandex, yeni sayaç kodunda _ym_debug=2 parametresini ve hata ayıklama panelini hedef kontrolünde anlatır. Düzeltmenin kanıtı hem doğru olay hem işletme tarafındaki kayıttır. Telefon, e-posta veya görüşme metnini teşhis URL’lerine ya da açık denetim belgesine koymayın.

4. İletişim → sorumlu çalışan

Telefon tıklaması görüşme yapıldığını kanıtlamaz. Arama verilerinin Metrica’ya aktarılması ayrı çağrı takibi gerektirir: resmî yardım. Böyle bir sistem yoksa mevcut telefon kaydını kullanın ve belirli reklam ziyaretiyle bağlantıyı bilinmiyor olarak bırakın. Formlarda alınma, atama ve ilk anlamlı yanıt zamanını inceleyin.

Vardiya sonunda, normal temsilci yokken veya az istenen bir hizmet seçildiğinde kimin devraldığını kontrol edin. Ortak sohbette bildirim olması, sorumlu atanması değildir. Birkaç kaydı izleyin: çalışan vaat edilen koşulları, istenen hizmeti ve tercih edilen iletişim biçimini görüyor mu? Müşterinin yanıt vermemesi, telefonun sahte olduğunu veya trafiğin kötü olduğunu göstermez.

5. Yanıt → teklif → sonuç

İlk konuşmayı reklamla karşılaştırın. Vaat edilen işlem sunuldu mu, anlaşmadan önce fiyat açıklandı mı, sonraki adım belirlendi mi? Her kayıp satış için kanıtlanabilir neden seçin: uygun saat yok, farklı hizmet, uygun olmayan teklif, müşterinin vazgeçmesi veya bilinmiyor. Bilinmeyeni kolayca “niteliksiz” etiketiyle değiştirmeyin.

İzleme şablonu: iç ID; zaman ve saat dilimi; reklam grubu; sözün sürümü; açılış sayfası; iletişim yolu; alım kanıtı; sorumlu; ilk yanıt zamanı; sonraki adım; sonuç; neden; erişilebilir kanıt bağlantısı; bilinmeyen alanlar. İletişim bilgilerini erişimi kısıtlı normal sistemde tutun. Geliştiriciye görev vermek için çoğunlukla teknik ID ve tekrarlanabilir koşullar yeterlidir.

Skillfactory kamuya açık örneği: nitelikli başvuru ne demektir?

Yandex’in Skillfactory örneği (20 Şubat 2024), tekrarları dışlayan CRM doğrulamasını anlatır. Nitelikli başvurular ödenmiş satış değildir; sağlayıcının bu anlatımını burada bağımsız olarak doğrulamadık. Yandex.

Denetimdeki uygulama önerimiz, kaydın alınması ile işleme kabul edilmesi arasındaki sınırı incelemektir. Sonuçlara bakmadan önce nitelik kuralını yazın; aksi halde başarısız satış sonradan kötü başvuru diye yeniden sınıflandırılabilir. İlk başvuruyu, inceleyen kişinin kararını ve sonraki sipariş sonucunu bağlayan, erişimi kısıtlı kanıt zinciri isteyin. Bu zincir yoksa satışları, iptalleri ve nedensel iyileşmeyi doğrulanmamış bırakın. Bu bizim test önerimizdir; Skillfactory’nin iç sürecinin yeniden kurulması veya güncel ayarlarının açıklaması değildir. Tarihsel entegrasyon ayarlarını güncel belgelere bakmadan hesabınıza kopyalamayın.

Öğretici senaryo 1: bugün yapılamayan acil onarım

Kazan’daki hayalî beyaz eşya servisi bugün ziyaret sözü veriyor. Sayfa onarım başvurusu istiyor, ancak ilk uygun randevu birkaç gün sonra. Tek arama grubu ve hizmet inceleniyor. Başvuru toplama yedi gün, gözlem başlangıçtan itibaren 21. güne kadar sürüyor; örnekte bütün kayıtlar o tarihte kapanmış. Bunlar gerçek müşteri sonuçları veya herkes için önerilen süreler değildir.

Önce: “Teknisyen bugün” reklamı, uygunluğu doğrulamayan ilk bölüm, telefon formu ve “bugün yer yok” yanıtı. Sonra: “Randevulu onarım — uygun zamanı sorun” reklamı, bununla uyumlu sayfa, “Randevu uygunluğunu öğren” formu ve “Randevu istediniz; bölgenizi, arızayı ve en yakın uygun zamanı kontrol edelim” yanıtı. Aciliyet ancak gerçekten sağlanabiliyorsa vaat edilir.

Test, reklamın mobil hedef adresinden başlar. Çalışan hatalı ve geçerli gönderimleri, ardından tam bir çalışma kaydını, istenen hizmeti ve atanmış temsilciyi kontrol eder. Vardiya sonu başvurusu ayrıca denenir. Başarı, bağlamı kaydedilmiş kayıt ve anlaşılır sonraki adımdır. Test başvuruları ücretli sonuç sayılmaz ve ticari gruba eklenmez.

Öğretici kayıtlarda aynı onarım için tekrarları, farklı hizmet isteklerini, iletişim kurulamayanları ve kabul edilmiş başvuruları ayırın. Tekrarı geçmişini silmeden ilk kayda bağlayın. Sunulan randevuyu kabul etmeyen müşteri yine de geçerli bir başvuru yapmış olabilir. Tamamlanmış sipariş ile sonraki iptalini ayrı kaydedin; satış başarısız oldu diye kabul edilmiş başvuru geçmişten silinmemelidir.

Kanıt, saklanan bugün hizmet sözü ve uygun randevu olmadığını gösteren izinli nottur. Nedeni düşen dönüşüm grafiğinden çıkarmayın. Başka nedenle vazgeçen müşteriyi aynı gruba koymayın. Sözü ve randevu görüşmesini düzeltin; ardından çalışma formuyla atanmış çalışanın ilk talebi görüp görmediğini kontrol edin.

Yerine getirilemeyen söz veya kaybolan geçerli form varsa etkilenen yolu duraklatın. Düzeltmeden sonra bilgisayar ve telefonda, vardiya sonu devri dahil aynı yolu tekrarlayın. Sınırlı pilota ancak söz, alım ve sorumluluk kontrolleri geçtiğinde ve ekip sunulan randevuları karşılayabildiğinde devam edin. Açık siparişleri kararlaştırılan gözlem bitişine kadar açık tutun. Teknik başarı satış artışını kanıtlamaz.

Öğretici senaryo 2: paket teklifi istenirken tek ürün satılması

Yekaterinburg’daki hayalî ofis ekipmanı tedarikçisi küçük ofisler için paket talepleri alıyor. Reklam ve sayfa, çalışma noktası sayısına göre fiyat teklifi vaat ediyor. Form telefon ve sayıyı saklıyor, fakat temsilci bağlamsız bildirim alıp tek cihaz satmaya başlıyor. Teknik teslimat çalışıyor; müşterinin görevinin satış ekibine aktarımı bozuluyor.

Bildirim şablonu: “Paket teklifi talebi; ID; çalışma noktası sayısı; kategori; sayfa sürümü; tercih edilen iletişim; sorumlu; sonraki işlem”. İlk yanıt: “Belirttiğiniz çalışma noktası sayısı için ekipman istediniz. İçeriği ve kısıtları netleştirip teklifin gönderileceği zamanı kararlaştıralım”. Müşterinin vermediği bilgiler tahmin edilmez, bilinmiyor olarak işaretlenir.

Testte farklı kategorilerden iki geçerli talep ve bir tekrar gönderimi bulunur. Temsilci ilk talebi görmeli, doğru kaydı açmalı ve sonraki adımı atamalıdır. Tekrar, şirket kurallarına göre önceki kayda bağlanır. Alanların nasıl taşınacağını CRM sorumlusu seçer; belirli bağlantı aracı varsayılmaz. Atama değişikliği, sayfa metni değişikliğinden ayrı test edilir.

Tekrarlanan teklif talebi, sunulmayan ürün, iletişim kurulamaması ve kabul edilmiş paket talebi için ayrı öğretici kayıtlar oluşturun. Kabul edilmiş talep sonradan kaybedilebilir veya iptal edilebilir; bu onu geçersiz yapmaz. İlk nitelik kararını koruyup ticari sonucu ekleyin. Kaybı eksik bağlama bağlamadan önce ilk yanıtı inceleyin; diğer nedenler ayırt edilebilir kalmalıdır.

Yönetici önce form metnini, kayıt içeriğini ve ilk teklifi karşılaştırır. Çalışma noktası sayısı CRM’de var ama kullanılmadıysa sorun işlemededir. Daha saklanan başvuruda bile yoksa form sorumlusu araştırmalıdır. Bu ayrım düzeltmeyi belirler: eğitim ve sorumluluk ataması ya da alan aktarımının onarılması.

Çalışan zorunlu bağlamı göremiyor veya kimse devri üstlenmiyorsa etkilenen yolu duraklatın. Düzeltmeden sonra farklı kategorileri, tekrarı ve yedek atamasını test edin. Çalışan ilk görevi anlatabiliyor ve vaat edilen sonraki adımı kaydedebiliyorsa devam edin. Pilotu ancak teklif hazırlama kapasitesi varsa ve çözülmemiş aktarım hatası kalmadıysa genişletin. Teklif ile tamamlanmış siparişi ayrı tutun.

Ayrı bir iş ortaklığı teklifi için AffiliateCore reklamveren hesabına giriş yapın ve hesabınızda oluşturma açıksa doğrulanmış açıklama ile URL’yi taslağınıza taşıyın. Kabul koşullarını önce çalışma brifinde yazın. CRM, Direct ve yanıt süreleri sizin operasyonel sorumluluğunuzdadır. Örnek siparişler, platformun otomatik desteklediği ücretlendirilebilir olaylar olarak sunulmaz.

Kopyalanabilir CRM devir çalışma formu

Aşağıdaki formu erişimi kısıtlı bir çalışma belgesine kopyalayın. Test zamanını form sorumlusu ve satış yöneticisiyle kararlaştırın. Bu belge dışında tutulan izinli test iletişim bilgilerini kullanın ve her testi işaretleyin. Önce devir koşullarını doldurun, ardından testleri uygulayıp kişisel verileri çıkarılmış alım kanıtını veya kayıt referansını ekleyin. Varsa test ortamını kullanın. Aktarım hatasını orada canlandırın ya da mevcut izinli olay kaydını inceleyin; kanıt üretmek için çalışan entegrasyonu bozmayın. Test başvuruları ücretli dönüşüm veya ticari optimizasyon hedefini eğiten sinyal olmamalıdır. Form editoryal bir belgedir, AffiliateCore entegrasyonu değildir.

Çalışma formunu metin dosyası olarak indir

CRM DEVİR FORMU — ÇALIŞMA KOPYASI
Kapsam: Rusya / Yandex Direct; dil, kullanılabilirlik kanıtı değildir.
İsim, iletişim bilgisi, parola veya görüşme dökümü eklemeyin.

BOŞ DEVİR ANLAŞMASI
Yol / hizmet / açılış sayfası sürümü: ____
Reklam sözü / izinli istisnalar: ____
Test ortamı / izinli test zamanı: ____
Denetim referansı / alınma zamanı ve saat dilimi: ____
Alım kanıtı / CRM kayıt referansı: ____
Zorunlu bağlam / gözlenen değerler: ____
Sorumlu / yedek sorumlu / sonraki işlem / son tarih: ____
Nitelik kuralı ve sürümü: ____
Karar: kabul / ret / tekrar / bilinmiyor: ____
Neden / kanıt / inceleyen / karar zamanı: ____
Tekrar kuralı / ilk kayıt referansı: ____
Sipariş: açık / kaybedildi / tamamlandı / iptal: ____
Sonuç kanıtı / gözlem bitişi: ____
Bilinmeyenler / araştıracak kişi: ____
Hata / düzeltme sürümü / tekrar testi kanıtı: ____
Karar: geçti / kaldı / durdur; karar sorumlusu: ____

DOLDURULMUŞ ÖĞRETİCİ ÖRNEK — KURGUDUR, MÜŞTERİ SONUCU DEĞİLDİR
Yol: ofis ekipmanı paketi; açılış sayfası B.
Referans: TEST-B; zaman: kararlaştırılan test aralığı, Europe/Moscow.
Söz: çalışma noktaları için bütün paketi görüşmek.
Zorunlu bağlam: paket kategorisi; tercih edilen yanıt kanalı.
Alım kanıtı: TEST-RECEIPT-B; CRM referansı: TEST-CRM-B.
Gözlem: kategori kayıtta var, çalışan bildiriminde yok.
Sorumlu: satış testi lideri; yedek: vardiya lideri.
Karar: kabul edilmiş test başvurusu; satış değil.
Neden: istenen hizmet sunuluyor, alınma doğrulandı.
Sonraki işlem: tam kaydı açıp istenen paketi doğrulamak.
Sipariş: açık; tamamlanma veya iptal kanıtı yok.
Bilinmeyen: diğer bildirim yollarında kategori kayboluyor mu?
Hata sorumlusu: CRM yöneticisi; düzeltme: bildirim C.
Tekrar: atanmış çalışan yeni sürümde kategoriyi görüyor.
Karar: düzeltme öncesi kaldı; yalnızca kanıtlı tekrar sonrasında geçti.

TEST BAŞVURULARI — BEKLENEN SONUÇLAR
GEÇERLİ: sunulan hizmet için izinli başvuru gönderin.
Alım, bağlı CRM kaydı, bağlam, sorumlu ve sonraki işlem beklenir.
GEÇERSİZ: zorunlu alanı boş bırakın.
Görünür doğrulama uyarısı beklenir; kabul edilmiş ticari başvuru oluşmaz.
TEKRAR: aynı izinli talebi yeniden gönderin.
İlk kayda belgeli bağ beklenir; ikinci kabul edilmiş sonuç oluşmaz.
FARKLI İŞ: aynı test kişisi, farklı meşru talep.
Otomatik silme değil, tekrar kuralına göre inceleme beklenir.
RET: teklif dışında kalan hizmeti isteyin.
Koşul sürümüne bağlı neden beklenir; alınma kanıtı korunur.
YANIT YOK: iletişimsiz izinli test örneğini inceleyin.
Bilinmiyor/iletişim kurulamadı beklenir; uydurma dolandırıcılık etiketi değil.
VARDİYA SONU: yedek sorumluya kararlaştırılan devri test edin.
Sorumlu rol, süre ve devralma onayı beklenir.
AKTARIM HATASI: test ortamında güvenli biçimde canlandırın.
Sahte başarı olmaması, kurtarılabilir kanıt ve sorumlu beklenir.

KABUL KONTROL LİSTESİ
[ ] Söz, işletmenin gerçekten sunabileceği hizmetle uyumlu.
[ ] Alınma, analitik olayından ayrı kanıtlanmış.
[ ] Bağlam, sorumlu ve sonraki işlem korunmuş.
[ ] Tekrar ve ret kararlarının nedeni ve kanıtı var.
[ ] Bilinmeyen ve açık sonuçlar görünür kalıyor.
[ ] Testler ticari sonuçlardan çıkarılmış.
[ ] Tekrar kanıtı düzeltilmiş sürüme ait.
GEÇTİ: uygulanabilir her test beklenen sonucu veriyor.
KALDI: farkı kaydedin, düzeltmeyi atayın; genişletmeyin.
DURDUR: geçerli talep kaybı, yanlış söz veya sorumlu yok; etkilenen yolu duraklatın.
YENİDEN BAŞLAT: düzeltme, tekrar testi ve satış yöneticisinin onayı kaydedilmiş.

Düzeltmeyi ve yeni pilot kararını kaydedin

Hata kartı: geçiş; beklenen işlem; gerçek sonuç; kanıt; bilinen etki; bilinmeyenler; düzeltme sorumlusu; değişiklik sürümü; tekrar testi; trafiği açma kararı. Örnek: “Sayfadan işleme: uygunluk kontrolü vaat ediliyor, temsilci kontrolsüz ziyaret sözü veriyor; konuşmayı düzelt ve izinli üç test talebini incele”. Test sayısını gösterişli rapora göre değil, risk ve yol çeşitliliğine göre belirleyin.

Sonucu anlamak istiyorsanız hedef kitleyi, fiyatı, formu ve satış ekibini aynı anda değiştirmeyin. Önce kanıtlanmış hatayı giderin, sonra karşılaştırılabilir sınırlı pilot yapın. İki dönemi karşılaştırmak tek başına nedensellik kanıtlamaz; talep, mevsim ve kapasite değişebilir. Tekrarlanabilir düzeltmeyi, nedeni henüz kanıtlanmamış satış artışından ayrı raporlayın.

Çalışma: tek bir yol seçip ret ve iptaller dahil on anonimleştirilmiş başvuruyu sözden sonuca kadar izleyin. Şablonu doldurun, bir hatayı yeniden üretin, sorumlu ve tekrar testi sınırı belirleyin. Devam etmeden önce sözlerin tutarlılığını, alımı, bağlamı, sahipliği, sonraki adımı, olgun sonuçları, iptalleri ve her kararın kanıtını kontrol edin. Kanıt yetersizse kesin bir bilinmeyen ve onu araştırma yöntemi de değerli çıktıdır.

İlgili görevler için Metrica kaynak analizi, istatistik farkları ve CRM’ye güvenilir aktarım yazılarına bakın. Buradaki son belge farklıdır: belirli bir yolda kanıtlanmış kırılma ve yeniden başlatmak için doğrulanabilir koşullar.