CPAlead.com آفر وال کے لیے پوسٹ بیک سیٹ اپ کرنے کا آسان طریقہ

مصنف: CPAlead

اپ ڈیٹ کیا گیا Friday, September 20, 2024 at 8:34 AM CDT

CPAlead.com آفر وال کے لیے پوسٹ بیک سیٹ اپ کرنے کا آسان طریقہ

CPAlead Offerwall میں offers مکمل کرنے پر صارفین کو خودکار طور پر انعام دینے کا سب سے قابلِ اعتماد طریقہ postback سیٹ اپ کرنا ہے۔ conversions کو دستی طور پر چیک کرنے کے بجائے، CPAlead ہر بار جب کوئی qualifying lead بنتا ہے تو آپ کے endpoint پر server-to-server request بھیجتا ہے۔

سب سے محفوظ سیٹ اپ سادہ ہے: {subid} میں اپنا user یا transaction reference پاس کریں، {lead_id} محفوظ کریں تاکہ retries ایک ہی conversion کو دو بار credit نہ کریں، اور {payout} سے reward دیں۔ زیادہ تر cases میں launch کرنے کے لیے یہی کافی ہوتا ہے۔

Publisher Postback دراصل کیا کرتا ہے

جب کوئی user آپ کے CPAlead tracking URL پر کلک کرتا ہے اور offer مکمل کرتا ہے، تو CPAlead conversion data کے ساتھ آپ کے server کو call کر سکتا ہے۔ اس سے آپ کی app, website, یا game user کو خودکار طور پر reward کر سکتی ہے، بغیر اس کے کہ کسی کو conversions ہاتھ سے review کرنے کی ضرورت ہو۔

صارفین کو خودکار طور پر reward کریں: جیسے ہی conversion record ہو، points، balance، coins، یا premium access credit کریں۔
اپنا ledger برقرار رکھیں: finance، support، اور analytics کے لیے ہر conversion اپنی database میں محفوظ کریں۔
Duplicate rewards سے بچیں: retries کو محفوظ طریقے سے ignore کرنے کے لیے CPAlead کے unique {lead_id} کا استعمال کریں۔
زیادہ مفصل context track کریں: اگر آپ کے workflow کو ضرورت ہو تو country، IP، device IDs، یا extra subids جیسی optional values شامل کریں۔

Step 1: Offerwall URL میں اپنی Reference پاس کریں

Postback URL کی فکر کرنے سے پہلے، یقینی بنائیں کہ اصل CPAlead tracking URL میں subid کے اندر آپ کا اپنا identifier موجود ہو۔ یہ user ID، username، wallet ID، session key، یا کوئی بھی internal reference ہو سکتا ہے جس سے آپ جان سکیں کہ کس user کو reward ملنا چاہیے۔

https://your-tracking-domain/view.php?id=1234&pub=1234&subid=USER_123

اگر آپ کو اضافی context چاہیے، تو آپ subid2 اور subid3 بھی پاس کر سکتے ہیں۔ مثال کے طور پر، کچھ publishers subid کو user ID کے لیے، subid2 کو app placement کے لیے، اور subid3 کو campaign یا A/B test label کے لیے استعمال کرتے ہیں۔

Step 2: ایک صاف اور قابلِ اعتماد Postback URL سے شروع کریں

بہت سے postback setups اس لیے ناکام ہو جاتے ہیں کیونکہ وہ بہت زیادہ وسیع شروع ہوتے ہیں۔ اپنی پہلی version چھوٹی اور قابلِ اعتماد رکھیں۔ یہ زیادہ تر CPAlead publishers کے لیے ایک مضبوط starting pattern ہے:

https://example.com/postback/cpalead.php?subid={subid}&lead_id={lead_id}&campaign_id={campaign_id}&campaign_name={campaign_name}&payout={payout}&password={password}

یہ version آپ کو وہ fields دیتا ہے جن کی واقعی زیادہ تر publishers کو ضرورت ہوتی ہے: کس کو reward کرنا ہے، کون سا lead convert ہوا، کون سا offer convert ہوا، اس نے کتنے پیسے دیے، اور request کی توثیق کے لیے ایک shared secret۔

Step 3: Recommended Macros کو سمجھیں

{subid}: آپ کا اپنا user ID یا transaction reference۔ یہ آپ کے system کو بتاتا ہے کہ reward کس کو ملنا چاہیے۔
{lead_id}: CPAlead کا unique conversion ID۔ یہ duplicate protection اور retry safety کے لیے بہترین field ہے۔
{campaign_id}: CPAlead offer یا campaign ID۔
{campaign_name}: CPAlead offer یا campaign کا نام۔
{payout}: conversion کی payout amount۔ زیادہ تر publishers کو reward input کے طور پر یہی استعمال کرنا چاہیے۔
{password}: آپ کا محفوظ postback secret، جسے credit دینے سے پہلے آپ کے endpoint کو validate کرنا چاہیے۔

Optional macros میں {subid2}, {subid3}, {country_iso}, {ip_address}, {idfa}, {gaid}, اور {gateway_id} شامل ہیں۔ CPAlead compatibility aliases بھی support کرتا ہے جیسے {offer_id}, {offer_name}, {transaction_id}, {amount}, {ip}, اور {country_code} اگر آپ کا existing endpoint ان names کی توقع کرتا ہو۔

ایک اہم نوٹ: اپنی پہلی integration کو {virtual_currency} کے گرد نہ بنائیں۔ CPAlead کے standard publisher postback flow میں، وہ value عموماً 0 ہوتی ہے۔ اگر آپ کو points یا in-app currency کی ضرورت ہے، تو بہتر ہے کہ انہیں اپنے system کے اندر {payout} سے calculate کریں۔

Step 4: Endpoint کو درست طریقے سے Secure کریں

اپنے CPAlead dashboard میں postback password شامل کریں اور URL میں {password} استعمال کریں۔ اپنے server پر، user کو reward کرنے سے پہلے اسے verify کریں۔ یہ unauthorized requests کو reject کرنے کا سادہ اور مؤثر طریقہ ہے۔

اگر آپ کا server صرف approved IPs قبول کرتا ہے، تو اپنے CPAlead postback dashboard کے اندر دکھائی گئی relay IP کو whitelist کریں۔ یہی outbound IP CPAlead publisher postbacks کے لیے استعمال کرتا ہے۔ اگر آپ IP whitelisting چھوڑ دیں، تو password validation اور بھی زیادہ اہم ہو جاتی ہے۔

آپ کے endpoint کو conversion process ہونے کے بعد ایک تیز HTTP 2xx response بھی واپس کرنا چاہیے۔ سست responses یا non-2xx responses retries اور postback errors کا سبب بن سکتے ہیں۔

Step 5: Real Traffic بھیجنے سے پہلے Postback Test کریں

اپنا postback URL save کرنے کے بعد، اپنے CPAlead dashboard میں Postback Testing page استعمال کریں۔ ایک اچھا test چار چیزوں کی تصدیق کرتا ہے:

Request آپ کے server تک پہنچتی ہے۔ اگر ایسا نہیں ہوتا تو firewall rules، SSL، IP whitelisting، یا اپنے URL format کو چیک کریں۔
Response HTTP 2xx ہے۔ Request process کرنے کے بعد آپ کے endpoint کو فوراً success واپس کرنا چاہیے۔
آپ کی user mapping درست ہے۔ تصدیق کریں کہ {subid} آپ کے system میں درست user یا wallet سے map ہوتا ہے۔
Duplicate protection کام کرتی ہے۔ اگر وہی {lead_id} دوبارہ بھیجا جائے، تو آپ کے endpoint کو user کو دو بار reward کرنے کے بجائے اسے ignore کرنا چاہیے۔

Testing کے بعد، اپنے CPAlead dashboard میں Postback Logs page دیکھیں۔ destination URL، response code، اور کسی بھی delivery error کی تصدیق کرنے کا یہ سب سے تیز طریقہ ہے جنہیں ٹھیک کرنے کی ضرورت ہو۔

Example PHP Script

نیچے دیا گیا مثال صرف {subid} اور {payout} سے balance update کرنے سے زیادہ محفوظ starter example ہے۔ یہ password validate کرتا ہے، retry safety کے لیے {lead_id} کو منفرد طور پر store کرتا ہے، اور raw SQL کے بجائے prepared statements استعمال کرتا ہے۔

<?php

declare(strict_types=1);

const POSTBACK_PASSWORD = 'replace_with_your_secret';

$subid = trim((string) ($_GET['subid'] ?? ''));
$leadId = (int) ($_GET['lead_id'] ?? 0);
$campaignId = (int) ($_GET['campaign_id'] ?? 0);
$payout = (float) ($_GET['payout'] ?? 0);
$password = (string) ($_GET['password'] ?? '');

if (POSTBACK_PASSWORD !== '' && !hash_equals(POSTBACK_PASSWORD, $password)) {
    http_response_code(403);
    exit('Invalid postback password.');
}

if ($subid === '' || $leadId <= 0) {
    http_response_code(400);
    exit('Missing subid or lead_id.');
}

$pdo = new PDO('mysql:host=127.0.0.1;dbname=your_database;charset=utf8mb4', 'user', 'pass', [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
]);

$pdo->beginTransaction();

try {
    $insert = $pdo->prepare(
        'INSERT INTO cpalead_postbacks (lead_id, user_id, campaign_id, payout, created_at)
         VALUES (:lead_id, :user_id, :campaign_id, :payout, NOW())'
    );
    $insert->execute([
        ':lead_id' => $leadId,
        ':user_id' => $subid,
        ':campaign_id' => $campaignId,
        ':payout' => $payout,
    ]);
} catch (PDOException $e) {
    if (($e->errorInfo[1] ?? null) === 1062) {
        $pdo->rollBack();
        http_response_code(200);
        exit('Duplicate lead ignored.');
    }

    $pdo->rollBack();
    throw $e;
}

$credit = $pdo->prepare('UPDATE users SET balance = balance + :amount WHERE id = :user_id');
$credit->execute([
    ':amount' => $payout,
    ':user_id' => $subid,
]);

if ($credit->rowCount() !== 1) {
    $pdo->rollBack();
    http_response_code(404);
    exit('User not found.');
}

$pdo->commit();
http_response_code(200);
echo 'OK';

اگر آپ cash balance کے بجائے points system استعمال کرتے ہیں، تو user کو update کرنے سے پہلے {payout} کو اپنے points ratio میں convert کریں۔ مثال کے طور پر، اگر آپ کی app $1.00 earned پر 100 points استعمال کرتی ہے، تو یہ conversion اپنے code کے اندر calculate کریں، کسی الگ macro پر انحصار کرنے کے بجائے۔

اگر آپ خودکار Crediting نہیں چاہتے تو کیا ہوگا؟

CPAlead کچھ publishers کے لیے ایک سادہ fallback approach بھی support کرتا ہے: آپ visitor سے email یا subID درج کرنے کو کہہ سکتے ہیں اور completions کو دستی طور پر review کر سکتے ہیں۔ یہ بہت چھوٹے projects کے لیے کام کر سکتا ہے، لیکن یہ سست ہے، غلط credit ہونے کا امکان زیادہ ہے، اور scale کرنا بہت مشکل ہے۔ اگر آپ قابلِ اعتماد user rewards چاہتے ہیں، تو automated postback crediting بہتر option ہے۔

آخری مشورے

ہمیشہ {subid} میں اپنی user reference پاس کریں۔
ہمیشہ {lead_id} پر store اور dedupe کریں۔
{payout} کو بنیادی reward input کے طور پر استعمال کریں۔
Credit دینے سے پہلے {password} validate کریں۔
Real traffic بھیجنے سے پہلے URL test کریں اور Postback Logs review کریں۔

اگر آپ اس pattern پر عمل کریں، تو آپ کا CPAlead Offerwall postback setup بہت آسانی سے maintain ہوگا، debug کرنا آسان ہوگا، اور users کو double-credit کرنے یا conversions کھو دینے کا امکان بھی بہت کم ہوگا۔

کیا آپ نے اس پوسٹ میں کوئی غلطی یا ایسی چیز نوٹ کی ہے جس کی درستگی کی ضرورت ہے؟ براہ کرم پوسٹ کا لنک فراہم کریں اور ہمیں رابطہ کریں. ہم آپ کی رائے کی قدر کرتے ہیں اور مسئلے کو جلدی حل کریں گے.