Monetization & Analytics Services for Games

Monetization and Analytics

The game is live, DAU is growing, but money isn't coming in—or it is, but you can't figure out where it's coming from. This is the classic situation where monetization and analytics were bolted on "as needed" instead of designed upfront. Overhauling your purchase system and analytics events post-launch is painful and expensive. Let's cover what needs to be in place from day one.

IAP: Architecture of In-App Purchases

Technically, integrating Unity IAP looks simple: hook up the SDK, create a product catalog, handle purchase callbacks. In practice, this is where most problems hide—duplicate transactions, lost purchases, no server-side validation.

Client vs. Server Validation

Basic Unity IAP integration works like this: client initiates purchase, App Store or Google Play returns a receipt, client passes it to game logic and grants the item. The problem—clients can be hacked. Receipts can be forged or replayed.

The correct scheme for any meaningful purchase:

1. Client initiates purchase through Unity IAP
2. Store returns receipt to client
3. Client sends receipt to your backend
4. Backend validates receipt through Apple App Store API or Google Play Developer API
5. Only after successful validation does the backend grant item / credit currency
6. Backend stores transaction ID—to protect against replay attacks on the same receipt

Without server-side validation, your store is vulnerable to replay attacks. This is especially critical for soft currency and battle passes.

Product Types and Their Quirks

Subscriptions are the most complex. Apple and Google handle renewals, trials, and cancellations differently. You need server-side logic for S2S (Server-to-Server) notifications: Apple sends them through App Store Server Notifications, Google through Pub/Sub.

Purchase Restoration

On iOS, you must implement Restore Purchases—otherwise App Store will reject the app. On Android it's not required (Google handles it automatically), but recommended. Unity IAP provides IStoreController.RestoreTransactions().

Ad-Driven Monetization

For free-to-play without IAP or alongside IAP, advertising remains the primary revenue source for hypercasual and casual games.

Key SDKs:

• AdMob (Google) — standard for Android, works well on iOS. Rewarded video, interstitial, banner, app open ads.
• IronSource (Unity LevelPlay) — mediation. Instead of integrating one SDK directly, a mediator conducts real-time auctions between multiple ad networks and shows the ad with highest eCPM.
• AppLovin MAX — alternative mediator, often performs better in certain geographies.

Practical rule: if the game is serious, don't integrate a single ad SDK—integrate a mediator (IronSource or MAX) with AdMob, Meta Audience Network, and a couple of regional networks. The revenue difference can be 30-60% with the same traffic.

UX considerations: ad integration impacts retention. Rewarded video works well—players choose to watch for rewards. Interstitial between levels works worse with aggressive show frequency. Never show ads to new players in their first 24 hours—it kills Day 1 retention.

Analytics: Event Architecture

This goes deepest. Most teams plug in Firebase Analytics, add logEvent() in a few places—and call analytics done. A month after launch, they realize there's no data, or it's useless.

Designing Your Event Schema

Before writing code, define what questions analytics should answer. Typical questions:

• Where do players get stuck in onboarding?
• At which level do most players drop off?
• Which traffic sources deliver the best LTV?
• Which IAP offers convert best?

For each question—one specific event with needed parameters.

Example of bad event:

logEvent("level_complete")

Example of good event:

logEvent("level_complete", {
  level_id: "world_2_level_5",
  attempts: 3,
  time_spent_sec: 142,
  boosters_used: ["shield", "bomb"],
  session_id: "abc123",
  user_segment: "payer"
})

The difference is fundamental: the first says "level done," the second lets you build funnels, segment players, and correlate behavior with monetization.

Standard Event Categories

Progression:

• tutorial_step_complete — each onboarding step as separate event
• level_start, level_complete, level_fail
• chapter_unlock

Monetization:

• iap_initiated — player opened shop or tapped offer
• iap_complete — transaction finished (with revenue parameter)
• iap_fail — transaction canceled or declined
• ad_show_request, ad_show_complete, ad_reward_claimed

Engagement:

• session_start, session_end (with duration)
• feature_used — for new features, understand if players actually use them
• push_notification_open

Firebase Analytics vs. GameAnalytics vs. AppsFlyer

These are different tools solving different problems, and a mature project uses all three.

Firebase Analytics — behavioral analytics inside the game. BigQuery export, Audiences for segmentation, A/B tests via Remote Config. Free up to volume limits. Constraint: 500 unique event types per app, 25 parameters per event.

GameAnalytics — game-specialized. Built-in: progression, resources (currency gains/spends), design events, errors. Good free tier. Less flexible than Firebase for custom events, but simpler for game designers.

AppsFlyer — attribution. Answers "where did this player come from and how much did they spend." Integrates with ad platforms (Facebook Ads, Google UAC, TikTok Ads), calculates ROI per campaign, supports SKAdNetwork for iOS. Without attribution, you're spending UA budget blind.

Cloud Saves

Technically not monetization, but directly impacts retention and conversion: a player who loses progress switching devices likely won't return.

Options:

• Unity Cloud Save (UGS) — simple integration, key-value store, free up to volume
• PlayFab Player Data — more flexible, supports segmentation and conditional data access
• Firebase Firestore — for projects with complex data structures, real-time sync

Important: don't sync entire game state—sync only critical data: progression level, purchased items, settings. Store heavy data (replays, screenshots) separately.

What to Decide Before Monetization Development Starts

1. Monetization model — premium, freemium, subscription, ads-only, hybrid. Determines IAP and ad integration architecture
2. Backend for validation — you need a server to verify receipts. If you don't have one, add it to project scope
3. Analytics event schema — designed before coding. Event list is agreed with game designer and UA team
4. GDPR/COPPA — if your audience is under 13 or game targets EU, special consent handling for ads and analytics is required. Apple's ATT request impacts attribution