مہم کے دوران ہی غلط اشتہاری کلکس کو روکنا

مشتہرین ہر کلک کی قیمت ادا کرتے ہیں۔ ان میں سے کچھ کلکس بوٹس، VPNs، پراکسیز اور ڈیٹا سینٹرز سے آتے ہیں، اور ہفتوں بعد آنے والی رپورٹ صرف نقصان کا ریکارڈ بنتی ہے۔ ClickFortify ایک آزاد پروجیکٹ ہے جس کا آرکیٹیکچر میں خود بناتا اور اکیلے چلاتا ہوں۔ اس کا کام غلط ٹریفک کو پہچاننا اور اسے مہم کا بجٹ خرچ ہوتے ہوئے ہی خارج کرنا ہے۔

مسئلے کی نوعیت

تین خصوصیات تقریباً ہر ڈیزائن فیصلے کی بنیاد ہیں:

• یہ کبھی نہیں رکتا۔ کلکس مختلف ٹائم زونز سے، دن رات، مسلسل آتے رہتے ہیں۔
• ہر مشتہر ایک ٹیننٹ ہے۔ ہر ایک کے اپنے اکاؤنٹس، قواعد اور ڈیٹا ہیں، اور انہیں کبھی ایک دوسرے میں نہیں ملنا چاہیے۔
• اصل کارروائی کہیں اور ہوتی ہے۔ خراب کلک کی نشاندہی آدھا کام ہے۔ اخراج کو مشتہر کے Google Ads یا Meta اشتہاری اکاؤنٹ میں ان کی APIs کے ذریعے واپس لکھنا ہوتا ہے، جن کے کوٹے ہوتے ہیں اور جو کبھی کبھار ناکام بھی ہو جاتی ہیں۔

جان بوجھ کر ایونٹ ڈرِون

کلکس جمع کرنے، انہیں اسکور کرنے اور اخراج کو سنک کرنے کے لوڈ پروفائل بہت مختلف ہیں۔ کلکس جمع کرنے میں اچانک اضافہ ہوتا ہے اور اسے تیز رہنا چاہیے۔ اسکورنگ CPU پر منحصر ہے۔ سنک کسی اور کی API سے محدود ہے۔ انہیں ایک ہی پروسیس میں رکھنے کا مطلب ہوتا کہ سب سے سست حصہ سب کی رفتار طے کرے۔

اس لیے ہر ذمہ داری اپنی الگ سروس ہے، جو NATS پر ایونٹس کے ذریعے جڑی ہے۔ ایک کلک جمع ہو کر شائع کیا جاتا ہے؛ اسکورنگ اسے سبسکرائب کرتی ہے، فیصلہ کرتی ہے اور فیصلہ شائع کرتی ہے؛ سنک ان فیصلوں کو اٹھاتا ہے جن کے لیے اخراج درکار ہو۔ ہر سروس اپنے طور پر اسکیل ہوتی ہے، اور سست ایڈ پلیٹ فارم API کبھی کلکس جمع کرنے کے عمل کو نہیں روکتی۔

ایک کلک کو اسکور کرنا

کوئی ایک اشارہ یہ ثابت نہیں کرتا کہ کلک غلط ہے، اس لیے اسکورنگ کئی اشاروں کو یکجا کرتی ہے: رویّے کے اشارے، ڈیوائس فنگر پرنٹنگ، اور VPN، پراکسی اور ڈیٹا سینٹر ٹریفک کی فلٹرنگ۔ اسکورنگ کو کلکس جمع کرنے سے الگ رکھنے کا مطلب ہے کہ قواعد اس حصے کو چھوئے بغیر بدلے جا سکتے ہیں جسے ہر وقت چلتے رہنا ہے۔

APIs پر بوجھ ڈالے بغیر واپس لکھنا

واپس لکھنے کا عمل وہ حصہ ہے جو دلچسپ طریقوں سے ناکام ہوتا ہے۔ اخراج Redis Bull جاب کیوز سے گزرتے ہیں تاکہ ہر سنک کو بیک آف کے ساتھ ری ٹرائی ملے، اور فیصلوں کا اچانک ریلا API کالز کے اچانک اضافے کے بجائے ایک متوازن بہاؤ میں بدل جائے۔

// 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
  }
);

ایک مستحکم جاب id اس عمل کو idempotent بنا دیتی ہے: اگر ایک ہی IP ایک منٹ میں دس بار نشان زد ہو، تو وہ صرف ایک بار سنک ہوتا ہے۔

ٹیننسی، اور ایک لائیو مائیگریشن

چونکہ ہر مشتہر کا ایک الگ تھلگ ٹیننٹ ڈیٹا بیس ہے، اس لیے بڑی تبدیلیوں کی منصوبہ بندی ایک خطرناک یکبارگی تبدیلی کے بجائے ٹیننٹ بہ ٹیننٹ کی جا سکتی ہے۔ اسی طرح میں نے 500+ ٹیننٹ ڈیٹا بیسز میں تقریباً صفر ڈاؤن ٹائم کے ساتھ لائیو پروڈکشن ڈیٹا بیس مائیگریشن کی۔

یہی چیز بنانے والے کو میرا مشورہ

1. ایڈ پلیٹ فارم میں واپس لکھنے کو مشکل حصہ سمجھیں، نشاندہی کو نہیں۔
2. سروسز کو لوڈ پروفائل کے لحاظ سے الگ کریں، اسم کے لحاظ سے نہیں۔
3. ہر بیرونی اثر کو ری ٹرائی کی ضرورت پڑنے سے پہلے ہی idempotent بنائیں۔