1. Overview

PubScale is a developer-focused monetization platform operated within the GreedyGame ecosystem. Its product suite includes AdX, Immersive Ads, GROW, PLUG, and Offerwall. For publishers specifically interested in rewarded actions, the Offerwall product is the part that deserves the most attention.

The basic proposition is straightforward: instead of monetizing every user exclusively through banners, interstitials, rewarded video, or in-app purchases, a publisher can give users a menu of optional tasks. Users complete qualifying actions such as app installs, registrations, leads, engagements, or other advertiser-defined goals and receive virtual currency or another in-platform reward. The publisher earns revenue from those completed actions.

PubScale currently markets 5,000+ personalized offers, coverage across 50+ countries, more than 10 million gamers in its pool, and thousands of integrated apps. It also promotes CPE campaigns designed specifically around gaming engagement.

What makes PubScale interesting is not simply the number of offers. The more important question for a publisher is whether the network can fit into the product's economics and technical stack without creating reward disputes or unnecessary engineering work.

That is where the picture becomes more nuanced.

The documentation is surprisingly useful for developers. There is an SDK, Web integration, an Offer API, iframe support, tracking parameters, S2S callbacks, sandbox testing, and multiple platform options. At the same time, independent feedback is mixed, particularly around tracking and user reward experiences. Trustpilot currently shows a 3.3 rating from 35 reviews, with a notably polarized distribution between positive and negative ratings.

My overall view: PubScale is technically credible enough to test seriously, but it should be evaluated with real traffic before becoming a core monetization dependency.

2. Who is it for?

PubScale is primarily suitable for publishers whose users already have a reason to earn or spend virtual currency.

That includes:

1. Mobile game developers
2. Reward apps
3. GPT and get-paid-to platforms
4. Loyalty applications
5. Consumer utilities
6. Finance and engagement apps
7. Community platforms
8. Websites with a points or rewards economy
9. Apps trying to monetize non-paying users

It is especially attractive when the product already has a wallet, points system, coins, credits, gems, or another virtual reward mechanism.

The model is much less compelling for a traditional content website that simply wants display advertising revenue. An offerwall works when users are willing to actively opt in and complete an action.

That distinction matters. PubScale is not really a replacement for normal display advertising. It is an additional monetization layer.

For a deeper explanation of the economics behind reward-based platforms, see the HansalDev article on the real economics behind a successful GPT platform and the site’s broader Offerwalls category.

3. Supported platforms

PubScale's Offerwall documentation explicitly lists:

1. Android
2. iOS
3. Unity
4. React Native
5. Web

The official documentation describes platform-specific integrations as well as Web integration and API-based implementation.

This is a strong point for developers maintaining the same reward economy across multiple environments.

For example, a publisher could maintain:

1. Native Android Offerwall
2. Native iOS Offerwall
3. Unity integration for a game
4. Web Offerwall for the accompanying website
5. API integration for a custom frontend

That flexibility is considerably more useful than an offerwall that only gives you a hosted page.

4. Website support

Yes. PubScale supports websites through its Web Offerwall.

The official documentation provides several options:

1. iframe
2. Direct link
3. JavaScript launch

The Web implementation requires an App ID and a unique user ID, and PubScale's current documentation also recommends passing advertising identifiers where applicable to improve tracking accuracy and fraud prevention.

This makes PubScale relevant to websites running:

1. GPT systems
2. Reward portals
3. Loyalty programs
4. Community platforms
5. Web games
6. Points-based memberships

The important technical detail is that the website should have a persistent internal user identity. The user ID passed to PubScale becomes part of the reward attribution chain.

For publishers building their own reward infrastructure, HansalDev's guide on creating an Offerwall website covers many of the same architectural concepts, including S2S callbacks, wallet accounting and reward verification.

5. App support

PubScale is strongly oriented toward apps.

Its official Offerwall SDK documentation includes Android and iOS integrations, while React Native support is also documented.

The Android ecosystem is particularly well covered, while iOS can be integrated through a URL-based Offerwall approach and the documented SDK flow.

For mobile publishers, the main attraction is that an offerwall can monetize users who do not purchase premium currency.

Instead of asking:

“How do we get non-paying users to buy?”

the product can ask:

“How do we generate value from users who are willing to engage but will not pay?”

That is exactly where offerwalls can outperform traditional monetization.

6. Game support

Gaming is one of PubScale's strongest use cases.

PubScale markets its Offerwall specifically for games and promotes CPE campaigns based on meaningful player actions such as level completion and other engagement milestones. Its gaming pages emphasize retention, ARPDAU and incremental revenue from non-paying players.

The company also documents Unity integration and specifically positions Offerwall alongside rewarded and immersive advertising for games.

For a game with a strong in-game economy, this can be more valuable than simply placing another banner.

The best scenario is a free-to-play game where users periodically need:

1. Coins
2. Gems
3. Energy
4. Extra lives
5. Boosters
6. Premium access
7. Progress acceleration

The offerwall becomes an optional “earn your way forward” mechanism.

7. Integration methods

PubScale offers several integration paths, and this is one of the most attractive aspects of the platform.

Current documentation shows:

1. Native SDK integration
2. Web integration
3. iframe
4. Direct links
5. JavaScript launch
6. API integration

For developers who want complete control over the user experience, the API is particularly important because it allows offers to be fetched and displayed inside a custom UI.

This means PubScale is not limited to one standardized Offerwall design.

That is valuable for serious products where the reward marketplace needs to feel like part of the platform rather than an external advertisement.

8. API availability

Yes, PubScale has an Offer API.

The API returns offers for the publisher's application, including information such as:

1. Offer type
2. App
3. Landing page
4. payout information
5. category
6. goals
7. tracking URL
8. GEO targeting
9. operating system
10. conversion metrics

The API can also be filtered by offer type, platform and country. PubScale documents offer types such as CPI, CPR, CPL, CPC, CPE, CPA, APK install and APK registration.

The API endpoint currently documented is:

https://api-ow.pubscale.com/v1/offer/api

PubScale says offer inventory is cached and refreshed every five minutes, which is an important implementation detail for publishers building their own offer catalog.

There is one catch: API integration requires pre-approval from the PubScale team.

That is reasonable for a custom integration, but it means the API should not be treated as a completely self-service, instant-access feature.

9. iFrame availability

Yes.

PubScale officially supports an iframe implementation for Web Offerwall integration. The documented implementation uses an Offerwall URL containing the application ID and user ID.

This is probably the fastest option for a website that wants to get an Offerwall online without building a custom frontend.

The advantage is speed.

The disadvantage is control.

An iframe gives you less control over the offer presentation, filtering logic, layout and surrounding user experience than the API approach.

For a new GPT site, iframe integration is usually the sensible starting point. After product-market fit and meaningful traffic, a custom API-driven experience can be considered.

10. SDK availability

PubScale provides SDK-related integrations for:

1. Android
2. iOS
3. Unity
4. React Native

Its documentation describes the SDK as an incremental monetization tool designed around users completing tasks in exchange for in-app currency.

Unity support is especially relevant because many Offerwall competitors focus heavily on standard mobile app development and treat games as a secondary case.

PubScale does not make that mistake.

For developers using Unity, the SDK includes a plugin-based setup and initialization around a unique user identifier.

11. Postback system

PubScale supports a Server-to-Server callback system, and this is one of the most important features for any publisher operating real rewards.

When a user completes an offer, PubScale can send a callback to the publisher's server containing data such as:

1. user_id
2. reward value
3. transaction token
4. signature

The documented callback is an HTTP GET request. PubScale also documents retries when a successful HTTP response is not returned.

This means the publisher does not have to rely purely on a client-side “reward completed” event.

That is critical.

A serious reward system should always make the server the authority for crediting currency.

The transaction token should also be treated as an idempotency key so duplicate callbacks do not create duplicate rewards.

This is exactly the type of implementation detail covered in HansalDev's Offerwall SDK integration guide.

12. Tracking

Tracking is handled through tracking URLs and user identifiers.

The Offer API returns a trk_url, which publishers are expected to use when a user interacts with an offer. PubScale supports parameters including:

1. user_id
2. GAID
3. IDFA
4. custom parameters c1 through c5

Those values can then be associated with the callback and used for attribution and internal reporting.

Technically, that is a sensible setup.

However, tracking quality is also where independent feedback becomes important.

Several recent Trustpilot reviews specifically complain about missing or delayed tracking, failed reward attribution, and difficult offer completion experiences. These are individual experiences rather than proof of a systematic platform-wide failure, but the repetition is enough to justify testing before making PubScale your only offerwall provider.

My recommendation is simple: never deploy an offerwall without monitoring callback success rate, reward reversals, conversion rate and complaint rate.

13. Attribution window

PubScale's current public Offerwall documentation does not clearly publish one universal attribution window that applies across all offers.

That is actually normal for performance advertising.

Different advertisers and campaigns can have different attribution rules. Some actions may require immediate installation attribution, while others depend on later milestones.

Because the public API exposes goals and tracking information rather than one single network-wide window, publishers should not assume a standard seven-day, fourteen-day or thirty-day rule.

For each important offer category, confirm:

1. Click-to-install attribution
2. Re-engagement rules
3. Goal completion time
4. Conversion validation period
5. Reversal rules

This is an area where asking the account manager for campaign-level documentation is better than relying on assumptions.

14. Offer types

PubScale has a broad mix of performance models.

The current API documentation explicitly includes:

1. CPI — Cost Per Install
2. CPR — Cost Per Registration
3. CPL — Cost Per Lead
4. CPC — Cost Per Click
5. CPE — Cost Per Engagement
6. CPA — Cost Per Action
7. APK Install
8. APK Registration

The API also categorizes inventory into areas such as Gaming, Finance and Survey.

For gaming publishers, CPE and multi-step offers are particularly interesting because they can turn an offerwall into a deeper engagement product rather than just an install marketplace.

15. GEO coverage

PubScale currently markets Offerwall coverage across 50+ countries.

The API also exposes GEO targeting with included and excluded countries, and publishers can filter offers by ISO Alpha-2 country codes.

This is important because offer inventory is highly dependent on GEO.

A network may have thousands of offers globally but a much smaller selection for:

1. Egypt
2. India
3. Brazil
4. Indonesia
5. Philippines
6. smaller European markets

Tier-1 traffic generally remains the most valuable for advertisers, and PubScale itself highlights its ability to reach premium global traffic and Tier-1 users through gaming inventory.

So “50+ countries” should not be interpreted as “equal inventory everywhere.”

16. Survey inventory

Survey inventory is part of PubScale's broader offer ecosystem.

The official API categorizes offers under SURVEY, confirming that survey-based opportunities are represented in the inventory.

However, publishers should distinguish between a network that contains survey offers and a specialist survey monetization platform.

A survey-first provider may have deeper profiling, qualification controls and survey-specific analytics.

PubScale's strength is broader monetization across offers, gaming and action-based campaigns.

For a GPT site, that diversity can be useful because users do not all want to complete surveys.

17. Gaming inventory

Gaming is one of PubScale's standout inventory categories.

PubScale promotes gaming CPE campaigns in which users can be rewarded for actions such as:

1. Reaching levels
2. Completing milestones
3. Collecting resources
4. Performing defined in-game actions

The platform currently markets more than 1,000 active multi-reward CPE campaigns and a pool of more than 10 million gamers.

For a rewards platform, this matters because game offers often create longer user sessions and higher-value conversions than simple install campaigns.

The downside is that multi-step game offers are also harder to track reliably. If the attribution pipeline fails after a user spends several hours completing milestones, the user experience can deteriorate quickly.

18. Fraud prevention

Fraud prevention is built into the platform.

PubScale describes fraud detection and prevention as part of its Offerwall offering and also exposes mechanisms that allow publishers to verify callback signatures. Its documentation recommends identifiers such as GAID and IDFA to improve tracking accuracy and fraud prevention.

The S2S signature is particularly useful because publishers can validate that a callback was generated using the expected secret.

That said, no offerwall's fraud system should be treated as perfect.

The publisher still needs its own controls:

1. Duplicate transaction prevention
2. Rate limiting
3. Account risk scoring
4. VPN/proxy detection where appropriate
5. Abnormal reward velocity detection
6. Wallet audit logs
7. Withdrawal risk checks

Fraud prevention should exist at both network and publisher levels.

19. Reporting

PubScale provides reporting and analytics functionality around offers, and the API documentation exposes global performance metrics such as conversion rate and earnings per click.

For a publisher, the most useful metrics are not simply revenue.

Track:

1. Offerwall impressions
2. Offerwall open rate
3. Click-through rate
4. Conversion rate
5. Revenue per active user
6. Revenue per Offerwall user
7. Reward cost
8. Margin
9. Reversal rate
10. Callback failure rate
11. Support complaints
12. ARPDAU

PubScale also promotes analytics and optimization for advertisers and publishers, particularly around CPE campaigns.

The publisher should still maintain its own database-level reporting because the commercial dashboard and your reward ledger have different purposes.

20. Reward flexibility

PubScale supports reward-based monetization where users receive in-app currency or other publisher-defined value.

The platform also provides a Promotions feature that lets publishers increase the base reward by a configurable percentage for a limited period. PubScale documents promotion periods of one to seven days and allows country targeting.

This is a practical feature.

For example, a GPT site could run:

“Earn 20% more on selected offers this weekend.”

The important financial detail is that the promotional bonus comes out of the publisher's margin, not the advertiser's payout.

That means promotions should be treated as a conversion optimization tool, not free money.

21. Payout model

For the user-facing Offerwall model, PubScale essentially operates on performance-based monetization.

The advertiser pays for a defined action. PubScale tracks that action and the publisher earns revenue from the resulting conversion.

This is fundamentally different from traditional CPM advertising.

The commercial model is therefore closer to:

Advertiser action → PubScale validates conversion → Publisher receives revenue → Publisher rewards user

PubScale's public Offerwall materials promote performance-oriented models such as CPE, while the API exposes CPI, CPA, CPL, CPC, CPR and other offer types.

Do not confuse this with PubScale's separate AdX agreements, which can contain different commercial and payment terms. Public terms for other PubScale/GreedyGame services include revenue-sharing and wire-transfer thresholds, but those terms should not automatically be treated as Offerwall payout terms.

22. Payment methods

This is one of the areas where PubScale's public Offerwall documentation is less transparent than its technical documentation.

There is no clearly published universal Offerwall payout table showing:

1. Minimum withdrawal
2. Exact payout methods
3. Standard payout day
4. Standard payment currency
5. Country-specific payment availability

Those terms can depend on the publisher relationship and product.

That is not necessarily a red flag, but it means you should obtain the actual commercial terms before sending serious volume.

Publishers should specifically confirm:

1. Payment method available in their country
2. Minimum payout threshold
3. Net payment period
4. Hold/reversal policy
5. Tax documentation
6. Currency conversion fees

This is particularly important for small publishers, because a technically excellent offerwall can still be a poor choice if the payment threshold or settlement terms do not fit the business.

23. Approval requirements

PubScale uses an approval process for Offerwall integrations.

Its current documentation states that when an app is created and an integration type is selected, the app enters a pending approval state. The manual review can take up to 72 hours, while integration and sandbox testing can continue during the approval process.

The API requires additional pre-approval.

Web Offerwall integration also requires pre-approval according to the documentation.

The good part is that PubScale provides a sandbox environment for testing before going live.

That is exactly what a publisher should use.

24. Minimum traffic

I could not find a clearly published universal minimum traffic requirement for PubScale Offerwall publishers in the current official documentation.

That matters because some monetization networks publish hard thresholds while others assess publishers individually.

The practical interpretation is:

1. Do not assume zero traffic is guaranteed approval.
2. Do not assume a specific DAU requirement unless PubScale confirms it.
3. Ask whether your current traffic source and GEO mix are acceptable.
4. If you're building a new GPT site, be prepared for manual review.

A platform can reject or restrict a publisher because of traffic quality even when raw traffic volume looks sufficient.

Traffic quality matters more than vanity numbers.

25. Publisher support

PubScale emphasizes developer support and its documentation includes a substantial technical knowledge base.

Its Offerwall documentation covers:

1. Platform setup
2. SDKs
3. API
4. Web
5. Sandbox
6. S2S callbacks
7. Promotions
8. FAQs

PubScale also lists support contact channels in its developer materials.

External reviews provide a mixed picture.

Some reviewers describe helpful onboarding and responsive support, while other reviewers report dissatisfaction with tracking or reward disputes. Trustpilot currently shows both strong positive and very negative recent reviews.

The takeaway is not “support is bad” or “support is great.”

It is this:

Support appears to be highly dependent on the particular problem and publisher experience, so test it before committing major traffic.

26. Strengths

Strong technical flexibility

The combination of SDK, Web, iframe, API, direct links and S2S callbacks is a serious advantage for developers.

Strong gaming orientation

PubScale clearly understands mobile gaming economics and promotes CPE and multi-reward campaigns rather than treating Offerwall as a generic survey product.

Broad offer categories

The API supports multiple performance models and categories, giving publishers more options than a survey-only provider.

Custom UI potential

API access allows publishers to build their own Offerwall presentation instead of permanently relying on a hosted interface.

Sandbox testing

The ability to test the callback and reward lifecycle before production is valuable, especially for custom implementations.

27. Weaknesses

Public commercial information is incomplete

Payment methods, payout thresholds and universal traffic requirements are not presented as clearly as the technical documentation.

Tracking deserves close monitoring

Independent reviewers have reported tracking and reward-crediting problems. These reports are subjective, but they are too relevant to ignore.

Inventory depends heavily on GEO

“50+ countries” does not mean equal offer depth in every country. Inventory will vary.

API and Web access involve approval

Developers who want a completely self-service API experience may find the approval process inconvenient.

Offerwall economics still depend on your user behavior

Having 5,000+ offers does not automatically create revenue. Your users need to open the Offerwall, click, complete offers and trust the reward process.

28. Best use case

The strongest PubScale use case is:

A mobile game, GPT platform, or rewards application with an existing active user base and an internal points/coins system.

For games, PubScale can sit beside:

1. Rewarded video
2. Interstitials
3. In-app purchases
4. Subscription revenue

For GPT platforms, it can sit beside:

1. Surveys
2. Cashback
3. Referrals
4. Other offerwalls
5. Affiliate offers

This “multi-source” approach is better than depending on one provider.

For example, a serious GPT platform can expose several offerwalls and automatically prioritize them based on:

1. GEO
2. EPC
3. Conversion rate
4. User history
5. Offer availability
6. Margin
7. Fraud risk

HansalDev's Offerwall builder guide and GPT economics content are useful complementary resources for designing this type of architecture.

29. Who should avoid it

PubScale is probably not the first choice for:

1. A tiny site with almost no active users
2. A publisher with no reward mechanism
3. A content site looking for simple passive ad revenue
4. A business that requires fully transparent public payout terms before integration
5. A publisher unwilling to monitor tracking
6. A project that depends on one network exclusively
7. A product with extremely strict user-support expectations but no internal reward-dispute process

I would also avoid launching a high-value reward system on PubScale without first testing callback reliability and several real offers in your main traffic GEOs.

30. Alternatives

There is no single “best” alternative because the right choice depends on your traffic and business model.

AdGem

AdGem is particularly interesting for publishers who want extensive technical control. Its current documentation provides Web Offerwall, iOS SDK, Android SDK, Unity SDK, REST Offer API and a GraphQL-based Prism option.

BitLabs

BitLabs is worth considering when surveys are a major part of the business. It offers surveys, games, offers, cashback-related earning opportunities and multiple SDK/API integration methods.

AdGate Media

AdGate is a long-established option to compare against for traditional Offerwall and rewarded-offer use cases. It is especially worth benchmarking when deciding between several general-purpose offerwall providers.

Torox

Torox is another option for publishers looking at broader performance-offer inventory and global monetization.

Tapjoy

Tapjoy remains relevant for mobile game publishers and is worth comparing when gaming monetization and rewarded engagement are the central priorities.

The best practical strategy is not choosing a winner on paper.

It is running the same traffic mix through two or three providers and comparing:

Revenue per 1,000 active users + conversion rate + reward success rate + user complaints + payment reliability.

A provider that has the largest theoretical offer count can still lose badly on real-world revenue.

31. Final rating

PubScale Rating: 8.2/10

Final verdict

PubScale is a serious Offerwall platform, particularly for mobile games, rewards apps and GPT-style products.

Its strongest advantage is the combination of commercial inventory and technical flexibility. The platform supports native app integrations, Web, iframe, API access, S2S postbacks and custom reward workflows. That is enough to build something far more sophisticated than simply embedding a generic third-party Offerwall.

The gaming side is another clear positive. PubScale actively markets CPE campaigns and multi-reward engagement, which fits free-to-play game economics especially well.

The main reason I would not rate it closer to 9/10 is uncertainty around the parts publishers ultimately care about most: real conversion consistency, tracking reliability, support quality and commercial settlement terms.

The independent feedback is mixed enough that a responsible publisher should not rely on marketing claims alone. Trustpilot's current review profile is particularly polarized, and several recent reviewers have raised tracking or reward-crediting concerns. That does not prove the platform is unreliable across the board, but it absolutely justifies a controlled test before sending significant production traffic.

My recommended approach is therefore simple:

Integrate PubScale, run it alongside at least one competing offerwall, and compare the actual numbers.

Measure revenue per active user rather than headline payout rates. Measure successful callbacks rather than the number of visible offers. Measure user complaints rather than dashboard activity alone.

That is the real PubScale review.

For a publisher with a proper rewards economy, PubScale is worth testing.

For a publisher looking for a completely transparent, plug-and-play network with every commercial term publicly documented, there are still some unanswered questions.

Final score: 8.2/10 — strong technology, strong gaming positioning, useful inventory, but test tracking and commercial performance before making it your primary monetization partner.

Useful resources

1. PubScale official website
2. PubScale Offerwall
3. PubScale Offerwall documentation
4. PubScale Offer API documentation
5. PubScale Web Offerwall documentation
6. PubScale S2S callback documentation
7. PubScale on Trustpilot
8. HansalDev Offerwalls & GPT resources
9. HansalDev case studies

Sources reviewed: PubScale's official product pages and developer documentation, PubScale/GreedyGame legal and support materials, Google Play's PubScale demo listing, Trustpilot publisher/user feedback, and current competitor documentation from AdGem and BitLabs.