Connect a game to the production ad service
Use the production workspace at app.nativegameads.com for approved game integrations. Create your account, verify your email and set up your developer workspace. Billing and payouts remain disabled.
Register your surface
Follow the developer walkthrough to register your own game, describe its permitted advertising area, upload real scene evidence and publish the placement. Both the developer and advertiser approve the same artwork version; the advertiser controls campaign launch.
Open Connect game, register your adapter's build and surface identifiers, and enable the reviewed placement. Choose Download game configuration. Give this public JSON file to your integration team. It identifies one game, placement, rendering method and connection revision. It contains no account password or private upload permission.
Integrate the Unity SDK
While signed in to your developer workspace, download Unity SDK 0.5.0-preview.1. The download page refreshes your sign-in before requesting the file. In Unity 6000 or later, open Window → Package Management → Package Manager, choose Install package from tarball, and select the downloaded file. Import Native Delivery Check from the package's Samples for a validation scene. The package includes version-matched integration notes in Documentation~/NativeDelivery.md. This is a prerelease with billing disabled; validate your own renderer and target devices before release.
The archive's SHA-256 is ea49317156b67cc874750e2f28b2f21a3f1f48d3e4ad7d7746a75c1466ac7386.
Use the SDK's Native Delivery Check sample and its NativeDelivery integration notes as a reference. The reusable runtime consists of NativeAdDelivery, NativeAdRecording, and NativeAdUploadRecovery. The optional sample controls belong only in a validation build; the runtime does not add game menus or test buttons.
- Load the downloaded JSON as a TextAsset and validate it as a NativeDeploymentConfiguration. Use the exact HTTPS origin supplied by your workspace.
- Configure NativeAdUploadRecovery once with that configuration and your application's explicit ad-only upload permission. It processes only the SDK's ad archive directories.
- Begin NativeAdDelivery when your game permits advertising. Wait for Ready and available recording capacity before drawing the supplied creative.
- Begin NativeAdRecording only when your renderer actually presents that creative. Submit the actual on-screen rectangle, viewport, known covering rectangles, active state and composition certainty through its Measurement component. Do not substitute the nominal texture dimensions for its displayed size.
- On Invalidated, remove the ad immediately and close its recording. Close when the surface leaves view permanently, the session ends, or your game pauses. The SDK also stops presentation and closes capture on app pause or focus loss. Start a fresh delivery after returning; do not silently reuse an expired assignment.
The current production adapter supports an opaque rectangular overlay whose rendering and occlusion your integration controls. Arbitrary world-space surfaces need their own validated measurement adapter. Importing the package alone does not connect your renderer.
Recover interrupted uploads
The initial upload grant lasts four hours. The SDK saves a separate permission bound to exactly one recording, allowing automatic upload-grant renewal for up to thirty days from authorization. Renewal can finish that recording even after a campaign pauses; it cannot authorize new presentation, select new artwork or enable billing.
If the app closes, reopen it with the same deployment configuration and explicit ad-only upload permission. The recovery component finishes preparing interrupted queues, renews permission and retries the same evidence. Keep that component available during the archive's recovery period when changing deployment identifiers. Do not copy queues between games or environments.
Local evidence is removed only after a final matching server receipt or the saved permission's thirty-day deadline. Detailed server evidence has its own thirty-day period, starting with the first accepted upload chunk. Campaign reports remain after evidence expires. The report retains measured totals and completion status, while explaining that expired observations cannot be replayed again.
Verify your integration
| Check | Expected behavior |
|---|
| No approved campaign | The ordinary ad-free surface remains; no local measurement recording is created. |
| Clear, small and fully covered ad | Measurements reflect the rendered view; fully covered and undersized views add no qualified time. |
| App switch or pause | Presentation stops and the recording closes; background time adds no exposure. |
| Connection loss | Delivery falls back when validation fails; closed evidence remains saved for retry. |
| Restart during capture or upload | Recovery preserves committed evidence and the original recording identity; an incomplete tail is marked accurately. |
| Upload permission expires | Automatic renewal is bound to the saved recording; no manual pilot code is needed. |
| Campaign pause or connection revocation | New presentation stops. Already authorized saved evidence can still finish uploading. |
| Final receipt | One matching report is available to the developer and advertiser; retries do not duplicate it. |
Server replay checks the arithmetic and structure of submitted observations. Public deployment identifiers are not app attestation, and these checks do not establish human attention or protect against a malicious modified client. Measurement results are not billing approval.
Keep internal tests separate
The pilot uses a different hostname and data store. Its pairing codes, sample campaigns and internal diagnostic pages are not production onboarding requirements. Test-only campaigns cannot be selected by the production delivery service. A test-game result validates only the behavior exercised; each real integration still needs its own rendering and device checks.