Başvuru incelemesi: durumlar, süreler ve itirazlar

Bir başvuru zamanında ulaşsa bile haftalarca anlaşılır bir karar bekleyebilir. Yayıncı bekleme durumunu, reklamveren kuyruğu görür; operasyon ekibi ise belirli bir olayı incelemek yerine yazışmaları arar. Önce her başvuruyu kimin, hangi koşullara göre, ne zamana kadar inceleyeceğini ve kararını nasıl açıklayacağını belirleyin.

Bu rehber, reklamverenlerin ve operasyon ekiplerinin alınmış başvuruları incelemesini düzenlemeye yardımcı olur. İlgili bölgesel gereklilikleri kontrol ettikten sonra izin verilen ürünlerde kullanın. Aşağıdaki süreler, kodlar ve sayılar eğitim amaçlıdır; AffiliateCore koşulları değildir. Örnek sıradan bir dijital hizmetle ilgilidir ve katalogda böyle bir teklifin bulunduğunu göstermez.

1. Kararın neyi kapsadığını tanımlayın

Üç soruyu ayırın: Olay gerçekleşti mi, kararlaştırılan koşulları sağlıyor mu ve finansal hesaplaşma tamamlandı mı? Postback alınması bir mesajın alındığını gösterir; başvurunun niteliğini tek başına doğrulamaz. Onaylanmış dönüşüm de paranın hemen çekilebilir olduğu anlamına gelmez. Bekletme süresi ve finansal işlemler ayrıca değerlendirilir.

Başlamadan önce olayı, zorunlu özellikleri, izin verilen kaynakları, tekrarlanan başvuru kurallarını, gözlem aralığını ve koşul sürümünü yazın. Öğretici yazılım demosu örneğinde olay, ürün seçilerek gönderilmiş bir form olabilir. Trafik geldikten sonra bir ay içinde satın alma sessizce yeni kabul koşuluna dönüştürülemez. Ödeme başka bir olaya bağlıysa bunu önceden tanımlayın.

Sonuç, yürürlük tarihi bulunan tek sayfalık bir kural belgesi olmalıdır. İtiraz halinde başvuruya uygulanan koşulları yeniden belirleyebilmek için eski sürümleri saklayın. Değişiklikleri gelecekteki olaylar için kararlaştırın; önceden kabul edilmiş sonuçları azaltmak için kullanmayın.

2. Her aşamanın sorumlusunu belirleyin

Bir kişi kuyruğu karşılar, gerektiğinde teknik sorumlu kanıtları inceler ve yetkili taraf sonucu kaydeder. Küçük ekiplerde roller birleşebilir; ancak itirazı mümkünse ilk kararı vermeyen biri incelemelidir. İzin dönemleri için yedek ve gecikmeler için başvuru kişisi belirleyin.

Öğretici akış: alındı → eşleştirildi → koşullar incelendi → gerekçeli karar → bildirim → yeni kanıt varsa yeniden inceleme. Eksik bilgi, sorumlusu ve son tarihi olan bir bilgi talebi oluşturur. Bu bir ekip çalışma şemasıdır; AffiliateCore içinde hazır otomasyon gösterimi değildir.

Kurallar hazır olduğunda AffiliateCore reklamveren kaydı oluşturabilir, gerekli bilgileri tamamlayabilir ve kendi teklifinizi hazırlarken bunları kullanabilirsiniz. Kayıt, ürünün kabul edildiğini veya yayına hazır olduğunu tek başına göstermez.

3. Çalışma aşamaları ile durumları eşleştirin

Kontrol edilen AffiliateCore reklamveren dönüşüm listesinde görüntüleme, durum filtresi, olay türü, harici kimlik, olay tutarı ve para birimi, reklamveren borçlandırması, ret nedeni, teklif ve olay zamanı bulunur. Bu liste reklamverene dönüşümleri serbestçe düzenleme veya silme yetkisi vermez.

Disputed ifadesi otomatik itiraz formu, geri sayım veya ayrı bir itiraz ekranının bulunduğunu kanıtlamaz. Katılımcılara açık eksiksiz bir itiraz süreci doğrulanmadı. Burada önerilen dosya kaydını ve süreleri ekibinizin kararlaştırdığı çalışma aracında tutun. Sistem durumlarını yetkili taraf değiştirsin. İş ortağına bulunmayan bir düğme vaat etmeyin.

4. Sürelerin başlangıcını belirleyin

“Hızlı inceleriz” belirsizdir. “Alındıktan sonraki iş gününe kadar ilk değerlendirme yapılır; eksik bilgiler ve yeni tarih bildirilir” uygulanabilir bir kuraldır. Öğretici bir pilotta normal karar için iki iş günü, gecikmeyi üst sorumluya iletmek için bir gün daha ayrılabilir. Gerçek süreleri iş yükü, tatiller, bölge ve hedef olayın gözlemlenebileceği zamana göre kararlaştırın.

Olay zamanı, alınma zamanı ve karar son tarihini ayrı kaydedin. Süreçte tek bir saat dilimi belirtin; zaman bilgisi paylaşırken UTC farkını ekleyin. Geç ulaşan olay otomatik olarak yayıncının ihlali değildir. Önce gecikme nedenini ve geçerli kuralı belirleyin.

Kanıt beklemek başvurunun yaşını sessizce sıfırlamamalıdır. İlk süreyi, uzatma gerekçesini, sorumluyu ve yeni tarihi koruyun. Sürenin dolması, kararlaştırılıp uygulanmış bir mekanizma yoksa otomatik ret veya alacak kaydı değil, üst sorumluya iletim anlamına gelir.

5. Yeterli ve sınırlı kanıt toplayın

İnceleme için kaynak olay kimliği, varsa platform dönüşüm kimliği, tıklamayla ilişki, teklif, zaman, kural sürümü ve kanıt referansı gerekir. Kullanıcı kimliği olay kimliğinin yerini tutmaz: aynı kişi birden fazla izin verilen eylem gerçekleştirebilir.

Karar kaydına eski ve yeni durum, inceleyen kişi, tarih, gerekçe ve önceki karara bağlantı ekleyin. Aynı mesajın tekrar teslimi yeni başvuru değildir. Ortak IP veya benzer adres de tek başına kopya ya da sahtekârlık kanıtı değildir. Olay kimliğini ve önceden kararlaştırılmış koşulları inceleyin.

Parolaları, postback sırlarını, tam kimlik belgelerini veya gereksiz ziyaretçi iletişim bilgilerini iş ortağına göndermeyin. Nedeni açıklamaya yetecek gizlenmiş bir kayıt veya erişimi sınırlandırılmış referans kullanın. Genel kayıt ve koruma önerileri OWASP Logging Cheat Sheet belgesindedir; buradaki başvuru inceleme süreci editoryal bir çalışma şablonudur.

6. Ret nedenini bilgi talebinden ayırın

Aşağıdaki öğretici kodlar açıklamasız “kötü trafik” ifadesini önler. AffiliateCore içinde hazır bir neden sözlüğü değildir.

EVENT_DUPLICATE — Aynı olay yeniden kaydedilmiştir. Eklenecek kanıt: İlk olay ve eşleşme ölçütü.

TERMS_MISMATCH — Geçerli belirli bir koşul sağlanmamıştır. Eklenecek kanıt: Koşul maddesi, sürüm ve doğrulanabilir bulgu.

EVENT_NOT_MET — Kararlaştırılan hedef eylem tamamlanmamıştır. Eklenecek kanıt: Gözlem aralığı sonunda kaynak durumu.

NEEDS_EVIDENCE — Karar için bilgi yetersizdir. Eklenecek kanıt: Açık talep, alıcı ve yanıt süresi.

Son satır bir çalışma görevidir, nihai ret nedeni değildir. Sahtekârlık sinyalleri de yorumlanmalıdır. Kanıt sizin sistem arızanız nedeniyle alınamıyorsa olayı ve inceleme tarihini kaydedin. Belirsizliği iş ortağına yöneltilmiş suçlamaya dönüştürmeyin.

7. Öğretici örnek: kuyruğu doğru raporlayın

Varsayımsal dijital hizmet, yinelenen teslimler çıkarıldıktan sonra bir haftada 100 benzersiz başvuru almıştır. Rapor anında 60 onaylı, 20 doğrulanmış gerekçeyle reddedilmiş, 20 kararsızdır. Tamamlanan inceleme sayısı 80'dir. Karara bağlananlar içinde onay oranı 60 / 80 = %75; tüm alınanlar içinde 60 / 100 = %60'tır. Bunlar farklı ölçütlerdir; paydayı belirtin.

Bekleyen 20 başvurunun sekizi gecikmiştir. Açık kuyruktaki gecikme payı 8 / 20 = %40'tır. Raporu kapatmak için bekleyenleri reddedilmiş saymayın. Önce sekiz gecikmenin sorumlusunu belirleyin, ardından diğerlerinin yaşını ve bekleme nedenini inceleyin.

Yirmi reddin 12'si tekrarlanan mesajlarla açıklanıyorsa kohort tanımını kontrol edin. Bu örnekte tekrarlanan teslimler zaten çıkarılmıştı; böyle bir açıklama başlangıç verisinin düzeltilmesini gerektirir. Hesap yalnızca yüze tamamlanmamalı, sayılan birimle de uyuşmalıdır.

Uygulama: kendi teklifiniz için kişisel veri içermeyen böyle bir tablo hazırlayın. Reklamveren hesabındaki mevcut dönüşüm durumlarıyla karşılaştırın; farkları sorumlu operatöre ayrı bir liste olarak iletin. Tabloyu denemek için sahte ücretli olay üretmeyin.

8. Öğretici örnek: itirazlı kararı yeniden inceleyin

L-041, L-019'un kopyası olarak reddedilmiştir. İş ortağı iki farklı olay kimliği sunar. İnceleyen kişi geçerli koşulları bulur: tekrar başvuru yalnızca başka bir ürün için kabul edilmektedir. Ardından kaynaktaki ürün ve zaman karşılaştırılır. Farklı kimlik tek başına iş ortağının haklılığını; aynı IP de ret kararının doğruluğunu kanıtlamaz.

Farklı ve uygun bir olay doğrulanırsa yetkili taraf sonucu mevcut prosedürle düzeltir. İlk kararı, yeni kanıtları, yeniden inceleme tarihini ve gerekçeyi saklayın. Finansal etkiyi ayrı kontrol edin. Postback tekrar gönderimi “eksik alacağı eklemek” için kullanılmamalıdır.

Karar değişmezse yalnızca “reddedildi” demek yerine kuralı ve bulguyu açıklayın. Kanıt hâlâ yetersizse sonraki adımı ve tarihi belirtin. İç sürenin dolması nedeniyle dosyayı kapatmak gerekçeli bir kararın yerini tutmaz.

9. İnceleme çalışmasını ölçün

Her hafta belirli bir andaki açık kuyruk, gecikme sayısı, ilk karara kadar geçen sürenin medyanı ve 90. yüzdelik değeri, gerekçeli karar payı ve yeniden inceleme sonuçlarına bakın. Karar süresini tamamlanan kayıtlar üzerinden hesaplayın; açık kayıtların yaşını ayrıca gösterin. Aksi takdirde uzun süredir çözülmeyen dosyalar hız ölçütünden kaybolur.

Değiştirilen ilk kararların oranını bütün başvurulara değil, sonuçlandırılmış itirazlara göre hesaplayın. Üç yeniden inceleme bir kaynak hakkında güçlü sonuca yetmez. Aynı dönemleri, koşul sürümlerini ve yeterince olgun kohortları karşılaştırın. Ret artışı olay tanımındaki değişikliği veya işlem hatasını gösterebilir; trafiği değerlendirmeden önce nedeni araştırın.

10. Hazırlık kontrolü ve sonraki adım

Pilottan önce olay ve koşul sürümü, kuyruk sorumlusu ve yedeği, sürenin başlangıcı, gerekçelerin kanıtları, bilgi talebi ile ret ayrımı, itiraz sorumlusu, korunan karar geçmişi ve açık/kararlı başvuruların ayrı raporlandığını kontrol edin.

Üç öğretici kartla masa başı prova yapın: normal başvuru, tekrarlanan mesaj ve yeni kanıtlı itiraz. Hazırlık ölçütü, inceleyen kişinin her kart için kuralı, sonraki adımı, sorumluyu ve süreyi söyleyebilmesidir. Söyleyemiyorsa rastgele durumlar eklemek yerine başlamadan süreci netleştirin.

Teklifin anlaşılır sunumu ve rapor farkları rehberlerini kullanabilirsiniz. Buradaki amaç her başvuru için yeniden üretilebilir karar vermektir; ilişkilendirme kurulumu veya kabul oranı garantisi değildir.

AffiliateCore'a reklamveren olarak kaydolun, zorunlu bilgileri tamamlayın ve inceleme koşulları kararlaştırılmış kendi teklifinizi hazırlayın. Uygunluk, gerekli kontroller ve moderasyon ayrı aşamalardır. Teklif oluşturmak yayınlanma veya trafik garantisi vermez. Süreci ekibinizde saklayın ve ilk testten önce platformla mevcut iletişim yöntemini doğrulayın.