CrakRevenue postback URL issues with server-side tracking?

Hello Iman Balogun,

"the postback URL isn't firing consistently, particularly when i'm trying to pass custom subid parameters for more granular conversion tracking."

I completely understand how frustrating inconsistent postback firing can be, especially when you're trying to nail down precise conversion tracking with custom `subid` parameters. I've debugged similar issues countless times when integrating with various affiliate networks, and CrakRevenue has its own nuances. Let's break down the common pitfalls and how to troubleshoot this effectively for server-side tracking:

1. Verify CrakRevenue's Exact Postback Structure and Tokens

First, double-check the precise postback URL and tokens CrakRevenue provides for that specific offer. While generally standard, some networks might use slightly different token names or URL formats.

• Standard CrakRevenue Postback Example:
  https://offers.crakrevenue.com/track_conversion.php?subid={subid}&payout={payout}&currency={currency}&offer_id={offer_id}
• Ensure you are using the correct tokens (`{subid}`, `{payout}`, etc.) provided in their offer details.

2. SubID Capture and Propagation

This is often where the issue lies. Your server-side logic needs to flawlessly capture the unique `subid` from the initial click URL and then dynamically insert it into the postback URL when a conversion occurs.

• Initial Click URL: Your tracking link should pass a unique identifier (often a `click_id` or your own generated `subid`) to CrakRevenue. Example: https://yourtracker.com/click?offer_id=XXX&subid={your_unique_click_id}. CrakRevenue then receives this `subid` and stores it.
• Server-Side Postback Trigger: When a conversion happens on your end, your server needs to retrieve that `your_unique_click_id` (which CrakRevenue will pass back to you as `{subid}` in their postback). You then use *that* value in your postback to CrakRevenue.
• Common Mistake: Trying to pass a *new* `subid` in the postback that wasn't originally passed to CrakRevenue during the click. The `subid` in the postback *must* be the one CrakRevenue previously recorded from the user's click.

3. URL Encoding

If your custom `subid` parameters contain special characters (e.g., spaces, `&`, `=`, `?`, `/`), they must be URL-encoded before being appended to the postback URL. Failure to do so can break the URL and prevent it from firing correctly. Most programming languages have built-in functions for URL encoding (e.g., `urlencode()` in PHP, `urllib.parse.quote()` in Python).

4. Server-Side Logging and Debugging

Implement robust logging on your server.

• Log every attempt to fire a CrakRevenue postback, including the full URL being called, the response received, and any errors.
• Check your server's outbound firewall rules. Is it possible traffic to CrakRevenue's domain is being blocked?
• Use tools like `curl` from your server's command line to manually test the postback URL with a known good `subid` to see the exact response.

5. Asynchronous Firing and Retries

If your postback is mission-critical, consider implementing an asynchronous firing mechanism (e.g., a queue system) and a retry logic for failed attempts. This ensures that even if CrakRevenue's server is temporarily unavailable, your conversion data isn't lost.

6. Tracking Platform (Tracker)

If you're managing multiple campaigns and complex affiliate marketing setups, using a dedicated tracking platform can significantly simplify postback management. Tools like Voluum, RedTrack, or Binom handle the `subid` capture, postback construction, and firing automatically, reducing the chances of human error. They also provide comprehensive reporting.

7. Test with a Clean Click ID

Generate a unique `subid` (e.g., `test_subid_20231026_1234`) and use it for a test click. Ensure this `subid` is passed correctly to CrakRevenue. Then, manually trigger a conversion that should fire the postback with that specific `subid`. Monitor your server logs and CrakRevenue's stats closely. Could you elaborate on how you are generating and storing the `subid` on your server before attempting to fire the postback?