Player ID Stability: Why Postback Matching Decides Reward Reliability
Player ID Stability: The Foundation of Reliable Rewards
Every offerwall conversion must match a real user in your database. The link between them is the player ID – and instability there is the #1 cause of lost credits.
When a user completes an offer, the offerwall platform fires a postback to your server containing the reward value and the player ID you passed when the user opened the offerwall. Your backend uses that player ID to find the user in your database and credit their balance. If the player ID in the postback does not match any user in your database, the reward is lost – the user completed the work but never gets paid. This silent failure is the single most common integration issue publishers face, and it almost always traces back to an unstable player ID.
Why IDs Break
Random session IDs, device IDs that change, or email-based IDs that users change – all break the postback match. The result: completed offers that never credit.
Consider what happens with each unstable ID type. A random session ID is regenerated on every app launch, so the user who completed the offer has session ID ABC123, but by the time the postback arrives hours later, the user has launched the app again and now has session ID XYZ789. The postback looks for ABC123, finds nothing, and the reward vanishes. Device IDs (like IDFV on iOS) can change when the user reinstalls the app or resets advertising settings, breaking the link between past completions and the current session. Email-based IDs seem stable until a user changes their email, logs in with a different provider, or plays as a guest – at which point the same physical user has two different IDs, and rewards split across both accounts. Each of these failures is invisible to the user until they notice their balance is wrong, at which point trust is already damaged.
The Stable ID Rule
Use your internal user ID from your backend user table. It never changes across sessions, devices, or reinstallations – postbacks always match.
The solution is straightforward: use the primary key from your user table as the player ID. This ID is assigned once when the user first registers or creates an account, and it never changes. Whether the user launches the app on a new device, reinstalls after a phone upgrade, or clears their cache, the backend user ID remains the same. When you pass this ID to the offerwall SDK at launch, it travels through the entire conversion flow and returns in the postback. Your backend joins the postback to the user table by primary key – the most reliable lookup in any database. If your app supports guest users who later register, use a guest ID that gets merged into the permanent account ID upon registration, and update the mapping so old postbacks still find the right user.
Implementation
Pass the stable ID to PerkoxOfferwall.create(…) at launch. Configure postbacks with {player_id} placeholder. Your backend joins postbacks to users by ID.
The implementation is three steps. First, when initializing the offerwall SDK, pass your internal user ID as the player ID parameter. On Android, this looks like PerkoxOfferwall.create(context, “your_user_id_here”). On iOS, the same parameter goes into the initialization call. On Unity, Flutter, or React Native, the bridge passes the ID through to the native layer. Second, configure your postback URL in the Perkox dashboard to include the {player_id} macro, which gets replaced with the ID you passed at launch. Third, on your backend, parse the incoming postback, extract the player_id field, and query your user table to credit the reward. Test the full flow end-to-end with a real offer completion before going live – a five-minute test catches ID mismatches that would otherwise lose rewards for weeks.
Why This Matters
Lost credits are not just lost revenue – they are lost trust. When a user spends twenty minutes completing a survey and never receives their reward, they do not blame the advertiser or the offerwall platform. They blame your app. They leave a negative review, they tell their friends, and they never open the offerwall again. The cost of one lost credit is not just the reward value – it is the lifetime value of a user who could have been a repeat offerwall customer. Getting the player ID right from day one is the cheapest insurance policy you can buy for your monetization stack.
Frequently Asked Questions
What breaks postback matching?
Unstable IDs – random, device-based, or changeable identifiers.
What is a stable ID?
Your internal user ID from your database.
How does Perkox use the ID?
It travels through the SDK and postbacks to match rewards to users.
Key Takeaway
Use your backend user table primary key as the player ID passed to the offerwall SDK. Never use session IDs, device IDs, or email-based identifiers that can change. Test the full postback flow with a real offer completion before launch to confirm rewards credit correctly.
Start Monetizing with Perkox
Register as a Perkox publisher and integrate the rewarded monetization SDK. Read the documentation
Perkox provides rewarded monetization infrastructure – SDKs, tracking, analytics, and reward validation – for mobile apps and games across Android, iOS, Unity, Flutter, and React Native.