Son Güncelleme: Nisan 7, 2026 Sezar Fikson
Eğer satış hunisi hesaplamalarınız tutmuyorsa, matematiğe güvenin.
Bu hissi biliyorsunuz. Tıklamalar sağlıklı görünüyor, tıklama oranları (CTR) iyi, trafik kalitesi değişmedi, ancak kayıtlar ve ilk ziyaret edilen satışlar (FTD) aniden düşüyor veya mevsimselliğe, coğrafi dağılıma veya promosyon değişikliklerine uymayan şekillerde dalgalanıyor. Verilerde bir hile mi var yoksa izleme sisteminde bir sorun mu var? Suçlamada bulunmadan önce, adli muhasebecinin yapacağı gibi kanıt toplayın: tıklama-nakit zincirini yeniden oluşturun, bağımsız telemetri verilerini programın raporlarıyla karşılaştırın ve değerin nerede kaybolduğunu belirleyin.
At ŞİMDİBen bunu bir soruşturma gibi ele alıyorum. Suçlamıyoruz; ölçüyoruz. Sonra gerçekler konuşuyor.
"Tıraş"ın pratikte nasıl göründüğü (ve genellikle nasıl görünmediği)
"Tıraşlama", size ait olması gereken yönlendirmelerin, kayıtların veya gelir elde etme olaylarının sistematik olarak eksik bildirilmesidir.
En sık görülen erken belirtiler şunlardır: cihaz veya tarayıcı oranlarında ani bir sapma; bonus şartları değişmemesine rağmen FTD'lere dönüşmeyen kayıt artışları; belirli alt kimliklerde tetiklenmeyi durduran geri bildirimler; çerez pencerelerinin süresi dolması nedeniyle dönüşümlerin günler sonra içe aktarılması.
Aynı derecede yaygın olanlar: tamamen masum nedenler—Safari'nin ITP'sinin çerezleri temizlemesi, gece geç saatlerde yapılan para yatırma işlemlerinin yanlış atfedilmesine neden olan saat dilimi uyumsuzluğu, pikselleri devre dışı bırakan reklam engelleyiciler veya ortağınızın BI panosuna uygulanan basit bir raporlama filtresi. Sizin göreviniz kötü niyeti matematikten ayırmaktır.
Ayıyı kışkırtmadan önce bir "kanıt omurgası" oluşturun.
En az üç bağımsız sensör.
İlk olarak, her giden tıklamaya benzersiz bir click_id atayan ve kullanıcı aracısını, IP/ASN'yi, yönlendireni, zaman damgasını ve açılış URL'sini depolayan kendi sunucu günlükleriniz (veya hafif bir yönlendirme). İkinci olarak, açılış oturumlarını, kayıt düğmesi tıklamalarını ve çıkış yollarını izleyen gizliliğe saygılı bir analiz görünümü (örneğin, GA4 veya kendi kontrol paneliniz) - kişisel tanımlayıcı bilgiler yok, sadece olaylar.
Üçüncüsü, operatörün aynı click_id ile anahtarlanmış olarak uç noktanıza gönderdiği S2S geri gönderme işlemidir. Bu üçü bir araya geldiğinde, medyanızdan ödeme noktasına kadar kurcalamaya karşı dayanıklı bir veri zinciri elde edersiniz.
Tıklama-nakde dönüş zinciri: değerin sıklıkla kaybolduğu yer
Reklamınız → sayfanız → ortaklık bağlantısı (click_id ile) → operatörün açılış sayfası → kayıt → KYC → ilk para yatırma → ilk bahis.
Geri dönüşler meşru olabilir—KYC sürtünmesi, reddedilen ödeme, dolandırıcılık kontrolleri. Ancak bazıları meşru değildir: yönlendirmeler sırasında kaldırılan parametreler, bozuk postback'ler, GEO için çok kısa çerez pencereleri, yanlış eşlenmiş alt kimlikler veya orijinal yönlendirmeniz yerine son dokunuş dahili promosyonlarını sessizce tercih eden modeller.
Gerçekten kullanabileceğiniz basit bir nedensellik tablosu
| Semptom | Muhtemel sebep | Bunu hızlıca nasıl kanıtlayabilirsiniz? | Sonra ne yapacağız |
|---|---|---|---|
| Tıklamalar istikrarlı, açılış oturumları azaldı. | Bot veya spam filtrelerinin engellemesi | Sunucu yönlendirme günlüklerini analiz oturumlarıyla karşılaştırın. | Kendi tarafınızdaki bot eşiklerini düşürün; sunucu tarafı izleme ekleyin. |
| Safari/iOS'te kayıtlar sabit kalırken, FTD'ler düşüyor. | ITP veya çerez temizleme işlemi ilişkilendirmeyi devre dışı bırakır. | Tarayıcıya göre segmentasyon; Safari'ye özgü sapmayı arayın. | S2S izlemeye geçin; ilişkilendirme penceresini genişletin |
| Postback'ler belirli alt kimliklerde durur. | Operatör etiket yöneticisi güncellemesi kayıp makroları içeriyor | Bu click_id'ler için ham sunucu günlüklerini isteyin. | Makro eşlemeyi yeniden doğrulayın; günlük olarak bir QA alt kimliği gönderin. |
| FTD'ler aynı gün değil, ertesi gün hesaba katılır. | Saat dilimi/raporlama kesme saati uyuşmazlığı | UTC damgalarını iş ortağının yerel kesintileriyle karşılaştırın. | Hem postback hem de BI raporlarında UTC saat dilimine göre hizalama yapın. |
| Tüm göstergeler iyi, net gelir çöktü. | Bonus suistimali veya politika değişikliği | Oyuncu başına bonus ve net kazanç verilerini çekin. | Hedeflemeyi ayarlayın; şartları yeniden müzakere edin veya kötüye kullanım gruplarını sınırlayın. |
Tarayıcılar düşmanca davrandığında S2S piksellerden daha iyi performans gösterir.
Modern tarayıcılar üçüncü taraf çerezlerini pek sevmez.
Apple'ın Akıllı İzleme Önleme (ITP) özelliği, yıllardır siteler arası tanımlayıcıları hedef alıyor ve bu da özellikle Safari ve iOS yoğun trafikte piksel tabanlı ortaklık atıflarını sessizce baltalayabiliyor. Eğer işletmeniz hala ön uç piksellerine ve kısa çerezlere güveniyorsa, dönüşümleriniz hiç müdahale edilmemiş gibi görünecektir.
Apple'ın üçüncü taraf çerezlerini tamamen engelleme hakkındaki kendi yazısını okuyarak, bu sorunu tarayıcıda neden "düzeltemediğinizi" anlayabilirsiniz: https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/Pratik çözüm S2S'dir: Benzersiz bir click_id oluşturursunuz, operatör bunu kayıt sırasında sunucu tarafında saklar ve tüm para kazanma olayları, bu click_id'ye göre anahtarlanmış sunucu-sunucu geri bildirimleri aracılığıyla uç noktanıza gönderilir. Çerez yoksa sorun da yok.
Minimum uygulanabilir S2S sözleşmesi (onun olmadan savaşa girmeyin)
| Alan (makro) | Neden önemli | Denetim ipucu |
|---|---|---|
| tıklama_kimliği | Kayıtlarınızı onlarınkine ekler. | Alışılmadık kimlik numaraları (örneğin, NOWG-TS-1697041234) kullanarak arama motorlarına kod ekleyin, böylece gözden kaçmaları imkansız olsun. |
| olay | kayıt, FTD, para yatırma, bahis | İzin verilen değerleri zorunlu kıl; geçersiz değerleri reddet |
| miktar ve para birimi | Nakit onayı | Kendi tohum birikimlerinizle uzlaşın. |
| oyuncu_kimliği (karma) | Kişisel veriler hariç kohort analizi | Karma algoritması belgelenmediği sürece katılamazsınız. |
| ts (UTC) | Pencere hizalaması | Gelecek/geçmiş anlamsızlıklarını reddedin; ham dizeyi ve ayrıştırılmış zamanı saklayın. |
Honeytoken'lar, tohum hesapları ve filigran yerleştirmeleri - etik bir şekilde yapılıyor.
Her iş ortağımı, bonuslara hiç dokunmayan ve her zaman aynı süreci izleyen küçük bir QA kullanıcı grubuyla başlatıyorum. Kullanıcı adlarında filigranlar bulunuyor (örneğin, nowg_2025_11_23_1620) ve ilk para yatırma işlemlerini "imza tutarları" ile finanse ediyorum (17.13$, 19.87$, normal bir kasiyerin varsayılan olarak kullanmadığı tutarlar).
Bu tutarlar hem operatörün defterinde hem de benim defterimde birer işaret haline gelir. Eğer benim geri bildirimimde 16:27 UTC'de 17.13$ yatırıldığı yazıyorsa ve iş ortağı hiçbir şey göstermiyorsa—veya yerel gece yarısında 20$ yatırıldığını gösteriyorsa—ilgili mercilere bildirebileceğim net bir tutarsızlık var demektir. Bunu etik kurallara uygun şekilde yapın: promosyonları kötüye kullanmayın, QA aracılığıyla trafiği aklamayın, kimsenin kişisel bilgilerini paylaşmayın.
Su tesisatını test ediyorsunuz, evi soymaya çalışmıyorsunuz.
Tıraş sonrası tıraşı dakikalar içinde tespit eden huni matematiği
Tartışmaya girmeden önce, satış huninizi bir tamirci gibi ölçün. Rastgeleliği azaltmak için en az 2,000 tıklama içeren sakin bir 7 günlük zaman dilimi seçin. Şunları hesaplayın:
- Lander kullanım oranı = açılış sayfası oturumları ÷ giden tıklamalar
- Normal oran = kayıtlar ÷ açılış oturumları
- FTD oranı = FTD'ler ÷ kayıtlar
- FTD başına depozito = toplam mevduat ÷ FTD'ler
Şimdi bunu 90 günlük hareketli ortalamalarınızla karşılaştırın. Aradığınız şey şu: yapısal Gürültü değil, kırılmalar. Safari'de FTD oranı %40 düşerken Chrome'da sabit kalıyorsa, bu sizin metniniz değil, atıf hatasıdır.
FTD başına yapılan para yatırma işlemi sabit kalırken, FTD sayısı düşer ve kayıtlar aynı seviyede kalırsa, postback işlemleri azalıyor demektir. Küçük bir tablo oluşturun ve cihaz/tarayıcıya göre renklendirin; genellikle bu örüntü hemen göze çarpar.
Belgenize yapıştırabileceğiniz bir doğrulama şablonu.
| Bölüm | Lander kullanım oranı | Normal oran | FTD oranı | Delta ile 90 günlük karşılaştırma |
|---|---|---|---|---|
| Tüm trafik | 0.54 | 0.23 | 0.18 | −%22 FTD oranı |
| Safari/iOS | 0.52 | 0.24 | 0.09 | −%53 FTD oranı |
| Chrome/Android | 0.56 | 0.22 | 0.19 | +%2 FTD oranı |
iOS'ta ani bir yükseliş, Chrome'da ise istikrarlı bir yükseliş görüyorsanız, yaratıcı tartışmayı bırakın. İzleme sorununu düzeltin.
Saat dilimleri ve para birimleri: sessiz katiller
Mükemmel postback işlemlerinin "kaçırıldığını" gördüm çünkü operatör günü 00:00 CET'de sonlandırırken sizin BI'ınız UTC'yi varsayıyor. Gece yarısına yakın yapılan para yatırma işlemleri onların tarafında yarına kayıyor ve asla uzlaşmıyor. senin “Bugünkü” rapor. Para birimi için de aynı şey geçerli; eğer gösterge panelleriniz EUR cinsinden girdileri topluyorsa ancak bir iş ortağının API'si tutarlı bir döviz kuru olmadan USD döndürüyorsa, “kayıp dolarlarınız” sadece yuvarlama hayaletleridir. Veri sözleşmesinde her yerde UTC'yi şart koşun ve hem ham hem de normalleştirilmiş para birimi değerlerini o gün uygulanan kurla birlikte saklayın. Bunu yapmadığınız gün, altı saat boyunca hayaletlerin peşinden koşarak geçireceğiniz gündür.
Çerez pencereleri ve dahili son tıklama yamyamlığı
Bazı programlar sessizce son tıklama ilişkilendirmesini çalıştırır. Kendi İletişim noktaları: dahili bannerlar, canlı operasyon promosyonları, anlık bildirimler. Oyuncunuz öğlen saat 12:00'de bağlantınız üzerinden kayıt olur, para yatırmazsa ve daha sonra para yatırmadan önce saat 19:00'da bir anlık bildirim bannerına tıklarsa, para yatırma işlemi "şirket içi pazarlama"ya veya son çerezi kullanan bağlı kuruluşa (size değil) aktarılabilir.
Açıkça sorun: ilişkilendirme "ortaklık programına katılanların son tıklaması mı yoksa ortaklık programına katılanların ana şirkete göre önceliği mi" şeklinde olmalı?
O halde bunu kanıtla.
İki hücreli bir test yapın: Kullanıcının yolculuğunun ilk gününde dahili promosyonların olmadığı A hücresi, normal promosyonların olduğu B hücresi. Eğer aynı operatörde A hücresinin ilk tıklama oranı (FTD) sihirli bir şekilde daha yüksekse, dahili son tıklama oranı sizin yerinize geçmiştir.
GA4 ve model uyumsuzluğu: Deli değilsiniz, modeliniz sorunlu.
Universal Analytics'in son tıklama tabanlı analizinden GA4'ün veri odaklı ilişkilendirme modeline geçiş yaptıysanız, kendi analizlerinizde değişiklikler olabilir. hareket İş ortaklığı temas noktasından sonraki etkileşimlere doğru, bilinçli olarak kredi aktarımı sağlamak. Bu bir tıraşlama değil; bu bir model.
GA4'ün veri odaklı ilişkilendirme mekanizması hakkında bilgi edinmek için Google'ın belgelerini inceleyin: https://support.google.com/analytics/answer/11517529.
Denetimler için, modellenmiş paylar yerine deterministik birleştirmeleri (click_id) tercih edin. "Kimin ödeme alacağı" sorusuna cevap aradığınızda, modeller yorum niteliğindedir; click_id'ler ise gerçeği yansıtır.
Kötü tesisatları ortaya çıkaran (ve ilişkileri koparmadan) kontrollü bir A/B rotası.
Uygun trafiğinizin %10-20'sini, farklı bir postback uç noktası ve farklı bir bağlantı içeren ikinci, izole bir bağlantı üzerinden aynı operatöre yönlendirin. click_id Ad alanı (ön ekler yardımcı olur). Coğrafi konum, cihaz ve yerleşimi aynı tutun. Eğer A akışı 100 kayıt bildirirken B akışı birden fazla gün boyunca aynı kalitede sinyallerle 62 kayıt bildiriyorsa, sorun izleyicilerinizde değildir.
İki bağımsız veri kaynağıyla, operatörün kendi kayıtları varyansı "mevsimsellik" olarak geçiştiremez.
Savaş başlatmadan veri nasıl istenir?
İyi niyetli operatörler, ihtilaflı click_id'ler için ham kayıtları paylaşacaktır: kayıt zaman damgası, oyuncu karması, para yatırma toplamları ve durum kodlarıyla birlikte geri gönderme girişimleri. Tam olarak bunu isteyin; 10-20 spesifik click_id ve zamanını listeleyin, "bana her şeyi gönderin" demeyin.
Kendi kanıt paketinizi sağlayın: her click_id için sunucu günlüğünüz, analiz oturum kimliği, postback günlüğünüz (4xx/5xx yanıtları dahil) ve kapsam dahilinde olduğunu düşündüğünüz UTC zaman aralıkları.
Suçlayıcı sıfatlardan kaçının. Hassasiyet herkesi sakin tutar ve iş ortağının mühendislerinin gerçekten neyin bozuk olduğunu düzeltmesini kolaylaştırır.
Yanıtlar almanızı sağlayan, düzenli bir sorun çözme kontrol listesi.
| + | Bu, sorunun çözümünü nasıl ortaya çıkarıyor? |
|---|---|
| UTC damgalı 10-20 tartışmalı click_id | Mühendisler saniyeler içinde loglarda arama yapabilirler. |
| Yönlendirme kayıtlarınız (IP/UA/yönlendiren) | Tıklamanın gerçekten gerçekleştiğini kanıtlıyor. |
| Postback makbuzları (ham JSON + durum) | Karşı tarafın sunucunun deneme yapıp yapmadığını ve sizin ne yanıt verdiğinizi gösterir. |
| Her grup için bir ekran görüntüsü (tarayıcı/cihaz) | Görsel desen = hızlı empati |
| Talebiniz (“geri bildirimleri tekrar oynat” veya “makro eşlemesini düzelt”) | Mühendislerin somut bir eyleme ihtiyacı var. |
Tıraş etme ile varyansı birbirinden ayırt edin (temel istatistik, doktora gerekmez)
Küçük ölçekli programlar, örneklem büyüklüklerinin çok küçük olması nedeniyle düzensiz görünebilir.
İş ortağı başına günlük FTD (Full Time Date - İlk Gün Randevusu) sayınız 8-12 civarında seyrediyorsa, tek bir VIP müşterisinin davranışı net geliri veya FTD sayısını günden güne %20-30 oranında etkileyebilir. Çıkarım için haftalık pencereler kullanın ve basit bir oran testi hesaplayın: Bu haftanın FTD oranını son 8 haftalık ortalamayla karşılaştırın; %95 güven aralıkları çok az örtüşüyorsa, muhtemelen gerçek bir değişim söz konusudur.
Eğer bu değişiklik sadece Safari'de veya sadece belirli bir coğrafi bölgede mevcutsa, on vakadan dokuzunda bu bir teknik sorundur.
Trafiğin durdurulmasını haklı çıkaran uyarı işaretleri
Eğer bir ortak belirli konularda ham kayıtları paylaşmayı reddederse click_idsEğer atıf kuralları gizliyse veya ay ortasında haber verilmeksizin değişiyorsa, geri bildirimler hafta sonları rastgele duruyorsa, oyuncu bazında detay verilmeden ekstrelerde geç "manuel ayarlamalar" görünüyorsa veya BI'larında satır düzeyinde olayların dışa aktarımı yoksa, durun ve banka hesabınızı koruyun.
Saygın programlar sizinle birlikte araştırma yapacaktır. Paket yakalama yerine halkla ilişkiler jargonuna başvurursanız, harcamalarınızı başka yere yönlendirin.
Bir noktayı kanıtlamak için kanunu çiğnemeyin.
İhtiyaç duymadığınız kişisel bilgileri asla toplamayın veya saklamayın, oyuncuları hassas hesap sayfalarının ekran görüntülerini paylaşmaya zorlamayın ve kullanıcılara kumarhanenin şartlar ve koşullarını atlatarak "zorla" dönüşüm yapmaları talimatı vermeyin.
Kalite kontrol kullanıcılarınızı gerçek trafikten ayrı tutun ve asla hak etmediğiniz bonuslara dokunmayın. Bir denetim yapıyorsunuz, tuzak değil.
Takip sistemi düzeltildi ancak para hala kayıp.
Bazen tesisat sorunsuz çalışır, sorun finansal katmandadır. Sözleşmenize rağmen uygulanan negatif devirlere, spor kayıpları altında kumarhane gelirlerini yutan paket ürünlere veya uygulanan geri ödeme kesintilerine dikkat edin. gelecek Aylar boyunca belgeleme yapılmadı. Oyuncu segmentine göre uzlaştırma şelalesini isteyin:
Para yatırma → Para çekme → Bonuslar → Net kazanç → Ücretler/vergiler → Payınız.
Eğer bu mümkün değilse, "muhasebeniz" hislerden ibarettir. Karşı çıkın.
Kısa bir kişisel not (ve süreç konusunda neden bu kadar inatçı olduğum)
Yıllar önce, orta seviye bir programın iOS ağırlıklı dönüşümlerimizi haftalarca "kaybettiğini" izledik. Ortaklık ekibi her şeyin yolunda olduğunu iddia etti. Tablolarımız ise bunun aksini gösteriyordu—Safari FTD oranı yarıya inmişti;
Chrome'da herhangi bir sorun yaşanmadı. Her iki tarayıcıda da 17.13 $ ve 19.87 $ tutarında imza depozitoları oluşturduk, geri bildirimleri topladık ve ham günlükleri talep ettik. click_id.
Sorun 48 saat sonra çözüldü: Etiket yöneticisindeki bir değişiklik, belirli bir iOS açılış sayfası şablonundaki sorgu parametrelerini kaldırmıştı. Ortada bir sorun yoktu, sadece kanıt ve somut bir talep vardı.
O zamandan beri, sunucu günlükleri, analiz olay kimlikleri ve ham postback'ler gibi temel veriler olmadan sorunu tırmandırmayı reddediyorum. Sayılar sizin koruyucunuz olduğunda daha rahat uyursunuz.
“Güven ama doğrula” yaklaşımına pragmatik bir yol
S2S'yi mümkün olan her yerde çalıştırın. Her giden tıklamaya benzersiz bir click_id damgası vurun. Kendi loglarınızı saklayın. UTC'ye göre hizalayın. Olay sözlüğünü kabul edin ve ona bağlı kalın. Açıkça görünen QA kullanıcılarını filigran depolamalarıyla besleyin. Suçlamayı yapmadan önce sonuçları tarayıcı/cihaz ve coğrafi bölgeye göre segmentlere ayırın. Çıkarım için tek günler yerine haftalık pencereler kullanın.
Veriler bir sorun olduğunu gösteriyorsa, ayrıntıları belirterek durumu üst mercilere iletin ve yeniden oynatma/uzlaştırma isteyin; ders vermeye çalışmayın.
Kurulum sürecini kısaltmak isterseniz, NOWG'de basit, denenmiş ve test edilmiş şablonlar oluşturdum: tıklama kimliği oluşturucu, doğrulama ve tekrar oynatma özellikli, yapıştır ve çalıştır şeklinde bir geri bildirim alıcısı ve geliriniz "gizemli bir şekilde" düşmeden önce ITP kaynaklı ani artışları görmenizi sağlayan, Safari ve Chrome'u renk kodlarıyla gösteren bir dönüşüm hunisi matematik panosu. Ücretsiz araçları çalıştırın, iş ortağı makrolarınızı ekleyin ve programın size doğru şekilde ödeme yapıp yapmadığını veya istatistiklerinizin sessizce manipüle edilip edilmediğini önümüzdeki hafta öğreneceksiniz.
