Every SDK Becomes a China Decision.

An SDK, or software development kit, is packaged code that adds a service: analytics, login, payments, advertising, crash reporting, customer support, chat, voice, anti-cheat, attribution, cloud saves, or something else the game team does not want to build alone. Integration may take an afternoon; the operating relationship can last for years.

For a China route, each SDK can affect availability, latency, entity responsibility, personal-information processing, cross-border data, consent and disclosure, minor protection, account design, platform review, customer support, and the ability to patch or exit. SDKs remain useful. “We already use it globally” simply leaves the China-specific work unanswered.

Data and platform obligations depend on the entities, players, route, fields, purposes, scale, and current law. Use qualified review for the actual system.

Define the service before comparing vendors

Write the player or operating need before naming a product.

“We need analytics” is still too broad. Do you need to know whether new players reach the first meaningful decision? Diagnose a purchase funnel? Balance an economy? Detect fraud? Attribute a campaign? Each purpose needs different events and different precision.

“We need login” can mean a local platform identity, a portable studio account, cross-device saves, age/identity state, social features, or entitlement. One SDK rarely solves all those needs without adding its own assumptions.

For each service, ask:

• What breaks for the player if we remove it?
• What decision becomes impossible for the team?
• Could the platform or operator already provide the necessary function?
• Does the service have to run before the main menu?
• Can a regional adapter implement the same interface with a different provider?

Delete any analytics event that has no named decision or owner.

Build the SDK register

Inventory code, not memories. Search package manifests, native plugins, engine assets, build scripts, platform settings, server dependencies, web views, tag managers, and partner libraries. An SDK removed from the UI may still initialise in a binary.

Give every integration a record:

Field	What to record
Service and purpose	The precise player or business need
Builds and routes	Global PC, mainland PC, mobile, test, backend, website, or another surface
Vendor and contracting entity	Who supplies it and who signed the terms
Data fields	Collected, inferred, linked, uploaded, and returned data
Subjects	Player, child/minor, employee, creator, support requester, device, or account
Trigger	App start, consent, account creation, purchase, session, crash, or manual action
Endpoints and storage	Domains, regions, subprocessors, and backups
Retention and deletion	Default, configured, export, deletion, and contract end
Access	Studio, operator, vendor, partner, and role permissions
Failure behavior	Timeout, blocked endpoint, bad response, revoked key, or expired certificate
Update owner	Who reviews release notes, tests, and deploys changes
Evidence	Terms, data agreement, diagram, test, platform response, and review date

Unknown is an acceptable temporary value if it has an owner and deadline. “Probably anonymous” is not. Device identifiers, IP addresses, account IDs, voice, chat, support records, and behavioural profiles deserve explicit classification rather than intuition.

Draw a data flow a new teammate can follow

Use boxes for the client, game server, platform, local operator, studio systems, and each vendor. Draw arrows for data. Label each arrow with fields, purpose, trigger, encryption in transit, destination, and responsible entity.

Then tell one player story: they install, launch, choose privacy settings, create or link an account, play, purchase, crash, contact support, request access or deletion, and stop playing. Follow the data through every step.

The story catches gaps a legal inventory can miss. A crash report may include an account token. A support screenshot may contain chat names. An attribution library may start before the consent screen. A “local” login can call an overseas fraud endpoint. A deletion request may remove the player profile but leave identifiers in analytics and backups.

Broader consent cannot repair these gaps. Change the architecture where possible.

Remove data before choosing a transfer mechanism

Data minimisation means collecting data that is necessary for a clear purpose, at a granularity and duration proportionate to that purpose. It is engineering work.

For onboarding, a small studio may need event order and failure state, not a permanent cross-game identity. For crash diagnosis, it may need build, device class, stack, and recent system state—not chat contents. For campaign learning, aggregate channel results may be enough without matching every player across services.

Delete default events the vendor enables but nobody uses. Shorten retention where the decision window is short. Separate production and test data. Limit dashboard roles. Mask or avoid free text. Do not send the same identifier to every vendor simply because correlation is convenient.

Cross-border requirements and thresholds matter where applicable, but a smaller unnecessary dataset is easier to secure, explain, honour, and eventually delete regardless of mechanism.

Put a narrow studio-owned interface around each service

Create a narrow internal interface for each category: analytics, identity, crash, support, payments, or voice. The game calls the interface; a route-specific adapter calls the provider. Not every service can be swapped cheaply, but the seam makes assumptions visible.

The analytics interface can define an approved event schema and reject arbitrary properties. The identity interface can separate player identity from platform authentication and eligibility state. The support interface can remove sensitive diagnostics unless the player chooses to attach them. The crash interface can operate without making the title unplayable when upload fails.

Keep remote configuration controlled. A vendor dashboard should not silently turn on new collection, ads, or social features in a build whose route was reviewed under different behaviour. Log configuration changes and restrict permissions.

Design timeout and outage behavior first

Test each SDK with its domains blocked, response delayed, credentials invalid, payload malformed, rate limit reached, certificate rejected, and service disabled. Observe startup time, main-thread stalls, memory, battery, save integrity, and player messaging.

Classify dependencies:

• Critical: the game cannot lawfully or technically provide the service without it. Failure needs a clear, supported unavailable state.
• Important: a feature is degraded, but the core game remains usable. The UI should explain the limitation.
• Optional: telemetry or convenience can queue, drop, or retry without blocking play.

An optional analytics endpoint should never hold the main menu hostage. A required identity decision should not fail open because the vendor timed out. Those policies belong to product and route owners, not whichever exception path the SDK ships by default.

Put partner SDKs on the product dependency list

A publishing partner may require local login, payment, anti-addiction, channel, analytics, or support SDKs. Request documentation, test credentials, supported engine and OS versions, update history, data details, endpoint requirements, security contact, and a deprecation policy.

Record who integrates, who certifies, who handles platform feedback, and who pays for future updates. Test the SDK against the studio’s build pipeline, crash tools, anti-cheat, code stripping, patch system, privacy flow, and performance budgets.

“Required by the partner” may be accurate for the selected route, but it cannot end the inquiry. Ask the partner to explain the service, scope, evidence, and failure behavior.

Rehearse player data-rights requests

Players need a discoverable way to understand data use and exercise applicable rights. Support agents need a verified procedure that does not expose one player’s data to another. The studio and local operator need to know who receives the request, authenticates it, searches every relevant system, responds, and records completion.

Practice with a fictional test account. Ask for access, correction, export where applicable, and deletion. Confirm what remains in backups or legally retained records and how that is explained. Do not use real player data for the drill.

If the team cannot find a test account across its vendors, it does not yet have operational control of the data map.

Require a build that can survive provider exit

For every SDK, know how to revoke keys, stop collection, export necessary records, delete data under the contract, replace the service, remove native code, update disclosures, and ship a build that still loads existing saves and accounts.

Some integrations create durable identity or purchase dependencies that cannot be casually removed. Surface that fact before the contract is signed. Ask what happens if the mainland partner changes, the provider stops supporting your engine, or the global and local branches merge later.

Choose the SDK whose purpose, data, failure behavior, ownership, update path, and exit fit the route you can operate. A successful demo proves only the first integration.