Cloud Save & Achievement Integration: No Data Loss

A player cleared 40 levels on iPhone, moved the game to iPad – progress reset. According to several mobile studios, losing progress on reinstall is among the top 3 reasons for negative reviews and player churn (about 28% of users abandon after such an incident). iCloud or Google Play Games Services solve this – but correct integration requires more than calling a single method. We offer professional integration of cloud saves and achievements with data integrity guarantees and robust architecture that won't fail across thousands of devices.

Hidden Production Pitfalls

Save Merge Conflicts

A user played offline on two devices. When both come online – you get two incompatible progress snapshots. Apple Game Center and Google Play Games don't resolve conflicts for you: they return both snapshots and wait for the client to pick the winner. According to statistics, about 30% of users face such conflicts when actively using multiple devices. Without a properly implemented conflict resolution with a clear UI ("Your progress on this device: 43 levels / In the cloud: 38 levels – which to keep?") the user will lose data – and this is a major source of negative reviews.

Snapshot Size and Write Frequency

Google Play Saved Games limits each snapshot to 3 MB, and total saves per account to 10 MB (default). If a save includes inventory data with thousands of entries – you need to serialize only the delta or optimize the format. Frequent autosaves (after every action) create a write queue that, under poor connectivity, builds up and causes GooglePlayGames.SavedGame.ISavedGameClient timeouts. In practice, this leads to intermittent sync and player frustration.

Apple iCloud Keychain vs CloudKit

For simple games, NSUbiquitousKeyValueStore is enough – it syncs up to 1 MB of key-value pairs. For complex progress you need CloudKit with CKContainer and CKRecord. Unity has no native CloudKit binding – integrating requires writing an Objective-C/Swift plugin or using a third-party solution like CloudSave from Unity Gaming Services. We've built such plugins for projects with over a million users – we can share that experience.

How to Properly Handle Save Conflicts

Algorithm: on load, compare updatedAt of local and cloud snapshots. If they differ, save both locally and show a selection screen. After selection, write the winner to cloud. For automatic resolution you can use last-write-wins, but it's risky with offline sessions – progress is lost while the player is disconnected. The best approach is manual resolution with a UI that gives the player control. According to our data, this reduces data loss complaints by 4x.

Why Size Limits Matter

Exceeding limits causes CloudSaveValidationException errors and blocks writes. Recommended: serialize only changed fields and compress data. In Unity Cloud Save, max document size is 1 MB – for larger volumes split into multiple documents. We use binary serialization with protobuf to save space – it reduces snapshot size by 40-60% compared to JSON.

Unity Gaming Services Cloud Save

For cross-platform projects (iOS + Android + PC) the optimal path is Unity Cloud Save from package com.unity.services.cloudsave. It stores JSON documents up to 1 MB, works via Unity Authentication (anonymous accounts or federated identity), and supports server-side validation via Cloud Code.

Key point: CloudSaveService.Instance.Data.Player.SaveAsync() is asynchronous, throws CloudSaveValidationException on quota exceed and CloudSaveException on network errors. Handling these exceptions in production is mandatory – without it, a lost connection during save breaks the local cache without diagnostic.

Architecture: local save (PlayerPrefs or a custom JSON file in Application.persistentDataPath) + cloud save as a mirror with a version tag. On load – compare updatedAt from cloud snapshot metadata with local timestamp. If mismatch – initiate conflict resolution flow.

Cloud Platform Comparison

Achievements

Google Play Games Achievements and Apple Game Center Achievements – different APIs, different limits, different unlock logic. Proper abstraction: IAchievementService with methods Unlock(achievementId), Increment(achievementId, steps), Report(achievementId, percent) – platform-specific implementation hidden behind the interface.

Important: incremental achievements in Google Play require setting totalSteps in Play Console upfront. If steps change (e.g., achievement "kill 100 enemies" reworked to "kill 50") – you cannot change total steps without resetting all existing users' progress. This is an architectural decision to make before release. We help design achievements to avoid such issues.

For Game Center on iOS – handle GKLocalPlayer.localPlayer.authenticateHandler with branching for: authentication succeeded, user declined, Game Center unavailable. The last scenario is often ignored – but it occurs for users with restrictive Family Sharing settings. In our implementation we always provide a fallback to local save when cloud sync is unavailable.

What's Included

1. Audit of current save and achievement architecture.
2. Selection of optimal provider (iCloud, Google Play, Unity Cloud Save).
3. Implementation of conflict resolution UI and exception handling.
4. Testing on real devices with simulated network errors.
5. Documentation for maintenance and extension.

Timelines

Pricing is determined individually after an audit of your game's architecture and sync requirements. Contact us for a consultation and preliminary estimate – we'll discuss your project and find the best solution. Get a guarantee of quality integration backed by our expertise.

Monetization and Analytics

The game is live, DAU is growing, but revenue isn't — or it comes in but you don't know from where. We often see this picture: monetization and analytics are stitched in after the fact, without a system. Rewriting purchases and events after release is expensive and time-consuming. Our task is to design these layers so that they start generating money from day one, rather than turning into technical debt.

IAP: Architecture of In-App Purchases

Integrating Unity IAP seems trivial: SDK, product catalog, callback. In practice, most projects break here — duplicate transactions, lost purchases, vulnerability to hacking.

Client-side vs. Server-side Validation

The basic scheme with a client-side receipt works until it is cracked. A hacker spoofs the store's response and gets the item for free. The correct solution is to send the receipt to your backend for verification via Apple App Store API or Google Play Developer API. Only then grant the item and save the transaction_id. Without server-side validation, any soft currency or battle pass is a target for replay attacks. Fixing this gap typically saves 15–25% of lost IAP revenue.

Product Types

Subscriptions are the most complex type. Apple and Google handle renewal, trial, and cancellations differently. You need a backend that processes Server-to-Server notifications (App Store Server Notifications, Google Pub/Sub). Without this, half of your subscriptions will be lost — processing these notifications correctly cuts subscription revenue leakage by up to 40%.

Purchase Restoration

On iOS, without IStoreController.RestoreTransactions(), the store won't approve. On Android, restoration is optional but increases trust. Unity IAP does this with one method, but you need to test on a real device with TestFlight.

How does ad monetization work?

In hyper-casual and casual games, ads are the main source of revenue. Key SDKs:

• AdMob — basic, stable, but eCPM below average ($0.02–$0.08 in many regions).
• IronSource (Unity LevelPlay) — mediator, conducts real-time auctions between networks.
• AppLovin MAX — alternative, often wins on eCPM in the US and Europe ($0.10–$0.15).

The rule of thumb: use a mediator (IronSource or MAX) with AdMob, Meta Audience Network, and a couple of regional networks. Direct integration of a single SDK yields 30–60% less revenue for the same traffic — proven on 20+ projects. Using a mediator increases revenue by 30–60% compared to direct integration.

Retention impact of ad frequency

Rewarded video is the most lenient format: the player decides whether to watch the ad for a reward. Interstitials between levels cut retention if shown more than once every 3–4 transitions. New players should not see ads in the first 24 hours — this reduces Day 1 retention by 15–25%. Optimizing ad placement can increase ad revenue by 20–40% without harming retention.

What is the architecture of analytics events?

This goes deeper. Most teams connect Firebase Analytics, scatter logEvent() calls, and think analytics is ready. A month later, they find the data missing or useless because the event schema wasn't thought through.

How to Design the Event Schema?

Before writing code, define what questions the analytics should answer. Typical questions are: where players get stuck in the tutorial, at which level churn peaks, which traffic sources yield the best LTV, and which IAP offers convert better. For each question, a specific event with parameters is needed.

Example of a bad event:

logEvent("level_complete");

Example of a 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 first one only says 'level completed'. The second allows building funnels, segmenting players, and correlating behavior with revenue. Games using proper event schema see LTV increase of 15–25% within the first month.

Standard Event Categories

Progress: tutorial_step_complete (separate for each onboarding step), level_start, level_complete, level_fail, chapter_unlock.

Monetization: iap_initiated (opened store or tapped offer), iap_complete (with revenue), iap_fail, ad_show_request, ad_show_complete, ad_reward_claimed.

Engagement: session_start/session_end (with duration), feature_used, push_notification_open.

Firebase Analytics vs. GameAnalytics vs. AppsFlyer

In a typical project, all three are used. Without AppsFlyer, you're spending your UA budget blindly — it tracks SKAdNetwork, calculates campaign ROI, and integrates with Facebook Ads and Google UAC.

Cloud Saves

A player who loses progress when changing devices has a 70% chance of not returning. Options:

• Unity Cloud Save (UGS) — fast, key-value, free up to limit.
• PlayFab Player Data — more flexible, segmentation, conditional access.
• Firebase Firestore — for complex data, real-time synchronization.

Synchronize only critical data: level, purchased items, settings. Heavy files (replays, screenshots) store separately.

What does the work include?

After signing the contract, we follow a structured process:

1. Conduct an audit of the current monetization and analytics scheme (if the game is already live) or design from scratch.
2. Develop IAP architecture with server-side validation and subscription support, including S2S notification handling.
3. Integrate ad mediator (IronSource/MAX) and configure the auction with multiple networks to maximize eCPM.
4. Design the analytics event schema and connect Firebase + GameAnalytics + AppsFlyer for full funnel visibility.
5. Implement cloud saves and purchase restoration (iOS restore, Android fallback).
6. Provide documentation on events and instructions for game designers, plus a testing guide.
7. Offer 2 weeks of free support after release to catch issues early.

Why Work with Us

We have been setting up monetization in mobile games for over 7 years. Experience — 30+ projects, from hyper-casual to MMORPG. We developed an event standard that increased payment conversion by 20% for one client within a month of implementation. We guarantee data transparency — you always see which events are firing and how much they bring. Get a free audit of your monetization scheme — reach out via our contact form.

Estimated Timelines

• IAP + server-side validation: 5 to 10 business days.
• Ad monetization with mediator: 3 to 7 days.
• Full cycle (analytics + IAP + ads): 2 to 4 weeks. Cost is calculated individually — request an estimate via email.

Frequent pitfalls to avoid

• Lack of server-side validation — vulnerability to hacking (fix saves 15–25% lost revenue).
• Events without parameters — data useless; no way to segment or calculate LTV.
• Showing ads in the first 24 hours — kills Day 1 retention by 15–25%.
• Direct integration of a single ad SDK — lose 30–60% of potential ad revenue.

Order a consultation — we will analyze your project and propose a plan. Contact us through the feedback form.