Channel Publisher FAQ

This document is for channel publishers, app channels, web channels, and integrators using the Android SDK. It covers common questions about integration, debugging, launch, tracking, data, and settlement.

1. Documents and Integration Methods

1.1 Should I choose OpenAPI-V4 or the Android SDK?

If the channel needs custom UI, cross-platform reuse, server-side aggregation, multi-slot requests, or fine-grained control over caching and rendering, use Game Slot OpenAPI-V4 Integration Guide.

If the channel is an Android app and wants to quickly integrate standard game slot components, use Game Slot Android SDK Guide. The SDK encapsulates initialization, game slot loading, component rendering, click-to-open behavior, and exposure tracking.

1.2 Can new projects still use the legacy merchant platform OpenAPI?

New projects should use OpenAPI-V4 or the Android SDK. The legacy merchant platform OpenAPI will be discontinued in the future.

1.3 Can the game slot API and Android SDK be used together?

Yes, but it is not recommended to mix two integration methods for the same display position. A common approach is:

• Use the Android SDK for standard native Android pages.

• Use OpenAPI-V4 for Web, WebView, mini programs, or custom UI pages.

• If both integration methods appear on the same page, make sure game slot IDs, exposure tracking, and click tracking are not counted twice.

2. Credentials and Environments

2.1 What are client_id, api_key, secret_key, and slot_id?

client_id is the unique identifier for a channel or merchant. api_key and secret_key are API signing secrets. slot_id identifies a specific game slot. They are usually assigned by MiniGame and isolated between test and production environments.

2.2 Can test and production parameters be mixed?

No. Test environment URLs, credentials, and game slot IDs are only for development and debugging. Before production launch, switch to production parameters and confirm that the package, server configuration, cache configuration, and operation backend configuration have all been switched accordingly.

2.3 Can api_key secret_key be placed on the client side?

For OpenAPI-V4, game slot requests use api_key to sign requests and are called directly from the client. If the app is reverse engineered, key leakage is possible. If needed, reduce risk through a key rotation mechanism.

secret_key is used for S2S server-to-server communication and must never be placed on the client side. If it is leaked, reduce risk promptly through a key rotation mechanism.

Android SDK initialization parameters should be configured according to the SDK document and business allocation method. Production parameters should not appear in public documents, logs, or locations readable by normal users.

2.4 What usually causes signature failures?

Common causes include:

• The request method, path, timestamp, or request body used for signing does not match the actual request.

• Request body serialization changes field order, null handling, or encoding.

• The timestamp is outside the allowed window.

• The wrong environment's client_id or secret_key is used.

• A proxy, gateway, or client SDK modifies the request body.

Start by fixing one request body and printing the raw signing string, request path, timestamp, and request body digest on the server, then compare each item with the signing rules in the document.

3. Game Slot Requests

3.1 Can one request retrieve multiple game slots?

OpenAPI-V4 supports retrieving multiple game slots in one request. This is suitable for pages with multiple positions such as home pages, detail pages, and recommendation sections, reducing network round trips. The number of game slots per request must follow the API document limit; split the request if the limit is exceeded.

3.2 What if the API succeeds but a game slot has no games?

Possible reasons include:

• slot_id is not configured or the configuration has not taken effect.

• No playable content is available for the current country, language, screen orientation, or device conditions.

• Game slot strategy, operation rules, or inventory constraints return no result.

• Missing request parameters prevent the recommendation service from matching suitable content.

Recommended handling:

• Confirm that the slot_id belongs to the current client_id.

• Provide context such as language, country, device type, and screen orientation.

• Record request_id and provide it to MiniGame support for diagnosis.

• Prepare an empty-state fallback on the frontend to avoid layout errors.

3.3 Can the game list be cached?

Short-term caching is allowed, but note:

• Do not cache for too long, or recommendation freshness and operation strategy updates may be affected.

• Tracking URLs in the response have an expiration time; using expired URLs causes tracking failures.

• When serving cached results, exposure, viewability, and click events must still be triggered according to actual user behavior.

• Do not reuse a full response containing personalized recommendation results and tracking parameters across users.

3.4 Can game links be manually composed or modified?

Not recommended. Game links in the response usually already contain required parameters. If the channel needs to append its own parameters, first confirm that MiniGame parameters, signatures, attribution, and jump logic will not be broken. A safer approach is to use an agreed extension field or channel configuration.

3.5 How should API timeout or service errors be handled?

Use fallback strategies:

• Set a reasonable request timeout to avoid blocking the main page flow.

• Retry transient failures with a limited number of attempts and intervals that avoid concentrated traffic spikes.

• Use the last short-term cached content or show an empty state.

• Log status code, business error code, request_id, request latency, and channel-side user environment.

4. Event Tracking

4.1 When should exposure, viewability, and click tracking be triggered?

Exposure tracking should be triggered when a game card enters the visible viewport. Viewability tracking should be triggered after the card remains continuously visible for the specified time. Click tracking should be triggered when the user clicks the game card or button.

The OpenAPI-V4 response returns the corresponding trackers URL, and the client can request it according to actual behavior. Android SDK components usually include built-in exposure and click tracking, so integrators do not need to report them again.

4.2 Does a tracking URL need to be signed?

A single tracking URL is already pre-signed. The client does not need to sign it again and should not modify URL parameters. Request it directly.

If using the batch tracking API, sign the request according to the API document.

4.3 Does tracking failure affect opening the game?

It should not. Tracking failures should be handled silently and must not block opening the game, page display, or user operations. However, the channel should keep necessary logs for later diagnosis of exposure, click, and revenue anomalies.

4.4 Can the same game be reported for exposure multiple times?

Avoid reporting the same event type repeatedly for the same imp_id. Deduplicate locally by imp_id and event type. After page refresh or a new game slot request, a new tracking context is generated and the new response should be used.

4.5 What if unsent tracking events remain when the page closes?

For Web or WebView scenarios, use lightweight browser send mechanisms before page unload. For Android SDK scenarios, follow the SDK's cache and scheduled reporting mechanism. In all cases, tracking failures should not block the user from leaving the page.

5. Android SDK

5.1 Where should SDK initialization be placed?

Initialize as early as possible in Application or the first Activity that hosts a game slot, so the environment, channel credentials, and user identifier are ready before loading any slot.

5.2 How should the SDK environment be configured?

Use the test environment during development and debugging, and use the production environment for release builds. Pay special attention to build types, channel packages, gray releases, and online packages so they do not accidentally use test parameters.

5.3 If the SDK already handles exposures and clicks, should the channel report again?

Standard SDK components usually handle component exposure, click reporting, and opening the game. The channel should not call OpenAPI-V4 tracking URLs again for the same SDK component; otherwise, data may be duplicated or metric definitions may diverge.

6. Data and Settlement

6.1 Why do channel-side exposure or click counts differ from the MiniGame backend?

Common reasons include:

• The channel counts card render events, while MiniGame counts valid exposures or valid clicks.

• Tracking URLs are not triggered, triggered repeatedly, expired, or blocked.

• Page cache, preload, or virtual list reuse causes different local metric definitions.

• User network errors, app backgrounding, or page closure causes some events to be lost.

• Time zone, data delay, filtering rules, or anti-fraud rules differ.

Unify the metric definition first, then use request_id, imp_id, time range, channel-side user identifier, and game slot ID for sample-level diagnosis.

6.2 Why is revenue data delayed?

Revenue data usually needs to go through ad platform or payment platform callbacks, cleaning, attribution, anti-fraud, and settlement processing. Therefore, it may lag behind real-time exposure and click data. Final settlement follows the agreed settlement cycle and backend metric definition.

6.3 How should a user failure to open a game be diagnosed?

Collect the following information:

• Channel, app version, OS version, device model, and network type.

• client_id, slot_id, request_id, and imp_id.

• Game ID, game link, click time, and error screenshot.

• WebView kernel version, whether jumps are intercepted, and whether third-party pages or popups are disabled.

• SDK callback logs or API response logs.

7. Launch and Operations

7.1 What must be checked before launch?

Confirm at least:

• Production environment URL, credentials, and game slot IDs are configured correctly.

• Test environment parameters have been removed from production packages and production server configuration.

• Game slot request, display, exposure, viewability, click, and game opening flows are verified.

• Empty results, API failures, timeouts, network disconnects, and page closure all have fallback behavior.

• Dashboards or logs can locate request_id, slot_id, and user environment.

• Business, operation, technical support, and settlement definitions are aligned.

7.2 What information should be provided when reporting production issues?

Provide the following information together:

• Issue time and time zone.

• Channel name, client_id, and slot_id.

• request_id, imp_id, API response status code, and business error code.

• User device, app version, network environment, region, and language.

• Reproduction steps, screenshots, log snippets, and impact scope.

The more complete the information, the easier it is to determine whether the issue is caused by parameter configuration, channel implementation, network environment, content strategy, or server-side errors.

7.3 Can game slot style, game count, or recommendation strategy be adjusted?

Yes. Game slot style, game count, recommendation strategy, country or language filtering, and operation ranking usually need to be adjusted based on the channel scenario and cooperation configuration. API parameters are controlled by the channel, while backend strategy or game slot configuration changes require contacting the MiniGame account manager.