Paano Mag-setup ng Postback para sa CPAlead.com Offerwall: Isang Simpleng Gabay

Awtor: CPAlead

Na-update Friday, September 20, 2024 at 8:34 AM CDT

Paano Mag-setup ng Postback para sa CPAlead.com Offerwall: Isang Simpleng Gabay

Ang pagse-set up ng postback ang pinaka-maaasahang paraan para awtomatikong gantimpalaan ang mga user kapag nakumpleto nila ang mga offer sa iyong CPAlead Offerwall. Sa halip na manu-manong i-check ang mga conversion, nagpapadala ang CPAlead ng server-to-server request sa iyong endpoint sa tuwing may nalilikhang kwalipikadong lead.

Ang pinakaligtas na setup ay simple: ipasa ang sarili mong user o transaction reference sa {subid}, i-store ang {lead_id} para hindi madoble ang credit kapag may retries, at magbigay ng reward mula sa {payout}. Sa karamihan ng kaso, iyon lang ang kailangan mo para makapagsimula.

Ano Talaga ang Ginagawa ng Publisher Postback

Kapag nag-click ang isang user sa iyong CPAlead tracking URL at nakumpleto ang isang offer, maaaring tawagin ng CPAlead ang iyong server gamit ang conversion data. Nagbibigay ito sa iyong app, website, o game ng kakayahang gantimpalaan ang user nang awtomatiko nang walang kailangang manu-manong mag-review ng mga conversion.

Awtomatikong gantimpalaan ang mga user: mag-credit ng points, balance, coins, o premium access sa sandaling maitala ang conversion.
Panatilihin ang sarili mong ledger: i-store ang bawat conversion sa sarili mong database para sa finance, support, at analytics.
Iwasan ang dobleng reward: gamitin ang natatanging {lead_id} ng CPAlead para ligtas na i-ignore ang mga retry.
Subaybayan ang mas mayamang context: isama ang mga opsyonal na value tulad ng country, IP, device IDs, o dagdag na subid kung kailangan ng workflow mo ang mga ito.

Hakbang 1: Ipasa ang Sarili Mong Reference sa Offerwall URL

Bago mo isipin ang postback URL, tiyaking ang orihinal na CPAlead tracking URL ay may sarili mong identifier sa subid. Maaaring ito ay user ID, username, wallet ID, session key, o anumang internal reference na ginagamit mo para malaman kung aling user ang dapat gantimpalaan.

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

Kung kailangan mo ng dagdag na context, maaari ka ring magpasa ng subid2 at subid3. Halimbawa, ginagamit ng ilang publisher ang subid para sa user ID, subid2 para sa app placement, at subid3 para sa campaign o A/B test label.

Hakbang 2: Magsimula sa Malinis at Maaasahang Postback URL

Maraming postback setup ang pumapalya dahil masyadong malawak ang simula. Panatilihing maliit at maaasahan ang iyong unang bersyon. Ito ay isang matibay na starting pattern para sa karamihan ng CPAlead publishers:

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

Ang bersyong ito ay nagbibigay sa iyo ng mga field na talagang kailangan ng karamihan sa publishers: kung sino ang gagantimpalaan, aling lead ang nag-convert, aling offer ang nag-convert, magkano ang bayad nito, at isang shared secret para beripikahin ang request.

Hakbang 3: Unawain ang Inirerekomendang Macros

{subid}: sarili mong user ID o transaction reference. Sinasabi nito sa iyong system kung sino ang dapat makatanggap ng reward.
{lead_id}: natatanging conversion ID ng CPAlead. Ito ang pinakamainam na field para sa duplicate protection at retry safety.
{campaign_id}: ang CPAlead offer o campaign ID.
{campaign_name}: ang CPAlead offer o campaign name.
{payout}: ang payout amount para sa conversion. Karamihan sa publishers ay dapat itong gamitin bilang reward input.
{password}: ang iyong naka-save na postback secret, na dapat i-validate ng iyong endpoint bago i-credit ang user.

Kasama sa mga opsyonal na macro ang {subid2}, {subid3}, {country_iso}, {ip_address}, {idfa}, {gaid}, at {gateway_id}. Sinusuportahan din ng CPAlead ang mga compatibility alias tulad ng {offer_id}, {offer_name}, {transaction_id}, {amount}, {ip}, at {country_code} kung inaasahan ng umiiral mong endpoint ang mga pangalang iyon.

Isang mahalagang tandaan: huwag buuin ang iyong unang integration sa paligid ng {virtual_currency}. Sa standard publisher postback flow ng CPAlead, karaniwan ay 0 ang value na iyon. Kung kailangan mo ng points o in-app currency, mas mainam na kalkulahin ito mula sa {payout} sa loob ng sarili mong system.

Hakbang 4: I-secure nang Tama ang Endpoint

Magdagdag ng postback password sa iyong CPAlead dashboard at isama ang {password} sa URL. Sa iyong server, i-verify ito bago mo gantimpalaan ang user. Isa itong simple at epektibong paraan para tanggihan ang mga hindi awtorisadong request.

Kung ang iyong server ay tumatanggap lang ng mga aprubadong IP, i-whitelist ang relay IP na ipinapakita sa loob ng iyong CPAlead postback dashboard. Iyon ang outbound IP na ginagamit ng CPAlead para sa publisher postbacks. Kung laktawan mo ang IP whitelisting, mas nagiging mahalaga ang password validation.

Dapat ding magbalik ang iyong endpoint ng mabilis na HTTP 2xx response kapag naproseso na ang conversion. Ang mabagal na response o mga response na hindi 2xx ay maaaring magdulot ng retries at postback errors.

Hakbang 5: Subukan ang Postback Bago Magpadala ng Tunay na Traffic

Pagkatapos mong i-save ang iyong postback URL, gamitin ang Postback Testing page sa iyong CPAlead dashboard. Ang maayos na test ay magpapatunay ng apat na bagay:

Nakararating ang request sa iyong server. Kung hindi, i-check ang firewall rules, SSL, IP whitelisting, o ang format ng iyong URL.
HTTP 2xx ang response. Dapat mabilis na magbalik ng success ang iyong endpoint matapos iproseso ang request.
Tama ang user mapping mo. Kumpirmahin na ang {subid} ay tumutugma sa tamang user o wallet sa iyong system.
Gumagana ang duplicate protection. Kung ang parehong {lead_id} ay ipinadala ulit, dapat itong i-ignore ng iyong endpoint sa halip na doblehin ang reward sa user.

Pagkatapos mag-test, suriin ang Postback Logs page sa iyong CPAlead dashboard. Ito ang pinakamabilis na paraan para makumpirma ang destination URL, response code, at anumang delivery errors na kailangang ayusin.

Halimbawang PHP Script

Nasa ibaba ang mas ligtas na starter example kaysa basta pag-update ng balance mula sa {subid} at {payout}. Dina-validate nito ang password, natatanging ini-store ang {lead_id} para sa retry safety, at gumagamit ng prepared statements sa halip na raw SQL.

<?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';

Kung gumagamit ka ng points system sa halip na cash balance, i-convert ang {payout} sa sarili mong points ratio bago i-update ang user. Halimbawa, kung ang app mo ay gumagamit ng 100 points kada $1.00 na kinita, kalkulahin ang conversion na iyon sa loob ng sarili mong code sa halip na umasa sa hiwalay na macro.

Paano Kung Hindi Mo Gusto ang Awtomatikong Crediting?

Sinusuportahan din ng CPAlead ang mas simpleng fallback approach para sa ilang publishers: maaari mong hilingin sa visitor ang isang email o subID at manu-manong i-review ang mga completion. Maaari itong gumana para sa napakaliit na proyekto, pero mas mabagal ito, mas madaling magkamali sa pag-credit, at mas mahirap i-scale. Kung gusto mo ng maaasahang user rewards, mas mabuti ang automated postback crediting.

Mga Panghuling Tip

Palaging ipasa ang sarili mong user reference sa {subid}.
Palaging i-store at i-dedupe gamit ang {lead_id}.
Gamitin ang {payout} bilang pangunahing reward input.
I-validate ang {password} bago mag-credit.
I-test ang URL at suriin ang Postback Logs bago magpadala ng totoong traffic.

Kung susundin mo ang pattern na iyon, magiging mas madali pangasiwaan ang iyong CPAlead Offerwall postback setup, mas madaling i-debug, at mas mababa ang posibilidad na makapag-doble ng credit sa mga user o mawalan ng conversions.

Napansin mo ba ang isang pagkakamali o isang aspeto ng post na ito na nangangailangan ng pagwawasto? Mangyaring ibigay ang link ng post at makipag-ugnayan sa amin. Pinahahalagahan namin ang iyong feedback at agarang aayusin ang isyu.