Kampanya hâlâ yayındayken geçersiz reklam tıklamalarını engellemek

Reklamverenler her tıklama için ödeme yapar. Bu tıklamaların bir kısmı botlardan, VPN'lerden, proxy'lerden ve veri merkezlerinden gelir; haftalar sonra gelen bir rapor ise yalnızca kaybı belgeler. ClickFortify, mimarisini tek başıma tasarlayıp işlettiğim bağımsız bir proje. Görevi, geçersiz trafiği fark edip kampanya hâlâ harcama yaparken hariç tutmak.

Problemin yapısı

Neredeyse her tasarım kararını üç özellik belirliyor:

• Hiç durmaz. Tıklamalar saat dilimlerinin ötesinde, günün her saati kesintisiz gelir.
• Her reklamveren bir kiracıdır. Her birinin kendi hesapları, kuralları ve verileri vardır ve bunlar asla birbirine karışmamalıdır.
• Eylem başka bir yerde gerçekleşir. Kötü bir tıklamayı tespit etmek işin yalnızca yarısıdır. Hariç tutmanın, kotaları olan ve zaman zaman hata veren API'ler aracılığıyla reklamverenin Google Ads veya Meta reklam hesabına geri yazılması gerekir.

Bilinçli olarak olay güdümlü

Tıklamaları toplamak, puanlamak ve hariç tutmaları senkronize etmek çok farklı yük profillerine sahiptir. Toplama ani dalgalanmalar gösterir ve hızlı kalmalıdır. Puanlama CPU'ya bağlıdır. Senkronizasyon ise başkasının API'siyle sınırlıdır. Bunları tek bir süreçte toplamak, en yavaş parçanın hepsinin temposunu belirlemesine yol açardı.

Bu yüzden her sorumluluk, NATS üzerindeki olaylarla birbirine bağlanan ayrı bir servistir. Bir tıklama toplanır ve yayınlanır; puanlama servisi buna abone olur, karar verir ve kararı yayınlar; senkronizasyon servisi de hariç tutma gerektiren kararları alır. Her servis kendi başına ölçeklenir ve yavaş bir reklam platformu API'si asla toplamayı tıkamaz.

Bir tıklamayı puanlamak

Hiçbir sinyal tek başına bir tıklamanın geçersiz olduğunu kanıtlamaz; bu yüzden puanlama birkaç sinyali birleştirir: davranışsal sinyaller, cihaz parmak izi ve VPN, proxy ve veri merkezi trafiği için filtreleme. Puanlamayı toplamadan ayrı tutmak, kuralların ayakta kalması gereken kısma dokunmadan değiştirilebilmesini sağlar.

API'leri boğmadan geri yazmak

Geri yazma, ilginç şekillerde hata veren kısımdır. Hariç tutmalar Redis Bull iş kuyruklarından geçer; böylece her senkronizasyon geri çekilmeli (backoff) yeniden denemelere sahip olur ve ani bir karar patlaması, bir sıçrama yerine istikrarlı bir API çağrısı akışına dönüşür.

// Illustrative: one queued exclusion per tenant, platform and IP
await exclusions.add(
  'exclude-ip',
  {tenantId, platform, ip},
  {
    jobId: `${tenantId}:${platform}:${ip}`, // idempotent: the same IP is never queued twice
    attempts: 5,
    backoff: {type: 'exponential', delay: 30_000},
    removeOnComplete: true
  }
);

Sabit bir iş kimliği işlemi idempotent hâle getirir: aynı IP bir dakika içinde on kez işaretlense bile yalnızca bir kez senkronize edilir.

Kiracılık ve canlı bir geçiş

Her reklamverenin izole bir kiracı veritabanı olduğu için büyük değişiklikler tek seferlik riskli bir geçiş yerine kiracı kiracı planlanabilir. 500+ kiracı veritabanında neredeyse sıfır kesintiyle canlı ortam veritabanı geçişini bu şekilde gerçekleştirdim.

Aynı şeyi inşa eden birine söyleyeceklerim

1. Zor kısım olarak tespiti değil, reklam platformuna geri yazmayı görün.
2. Servisleri isimlere göre değil, yük profillerine göre ayırın.
3. Yeniden denemeye ihtiyaç duymadan önce her harici yan etkiyi idempotent hâle getirin.