Adludo documentation · Development pilot

Adludo developer guide

For the reusable production connection and automatic upload recovery, see Connect a game to the production ad service. Internal pilot pairing procedures remain separate.

New to the platform? Follow the visual developer onboarding guide.

For the technical team connecting its own game to Adludo. The SDK is a preview, so validate your rendering method, lifecycle and target devices before relying on campaign delivery or measurement.

Start with the local preview

Follow the package’s supported Unity version and compatibility requirements. The retained SDK release and later internal test builds can have different capabilities even when they share a version label; use the exact package identified in the installation instructions.

Follow the verified tarball installation instructions for the retained preview.2 release. Import Quick Start: Local Preview, select Tools → Game Ad Marketplace → Open Local Preview, then press Play with the Game view focused. Leave Config Path empty for offline use. Move the pointer over and away from the creative, then pause and resume to inspect qualification. The sample is ephemeral: it does not save session history or send network requests. Use ConfigureRecording for persistent local evidence. The retained release and later internal test sources share a version label but differ in capabilities. The installation page identifies the exact package; use the compatibility reference for later pilot behavior.

Integrate the measurement method deliberately

The overlay method relies on an owned final composition: creative and viewport rectangles share coordinates, and later covering elements must be represented. Visible fraction uses the full creative area as its denominator; screen fraction uses viewport area. Unknown composition must remain unknown. A conservative depth-quad method is also documented for controlled scenes: a possible foreground intersection marks composition unknown rather than claiming a precise occlusion percentage. Neither method establishes general arbitrary-scene GPU visibility. Shape capture has local methods but is outside the documented native upload subset. E05

Connect readiness, frame observations, focus, pause, disable and close boundaries. Missing observations must not earn an invented tail of exposure. Preserve the method and policy identifiers with every recording so a receiver can interpret the evidence under the correct rules. A new engine or rendering pipeline needs its own adapter validation.

Understand recorded time

Native visible time accumulates valid sampled intervals whose endpoints are known, ready, active and have positive visible fraction. Qualified time applies the policy's visibility, screen-share and other qualification checks. The tracker requires both endpoints to qualify and the interval to remain within the maximum sampling gap. The first observation earns no time. Pauses, unknown evidence and invalid gaps break continuity. E04

Cumulative qualified time can contain separate short fragments. Continuous qualified time describes an uninterrupted streak. An impression candidate records satisfaction of the policy's streak condition for a delivery; it is not a payment decision. The SDK demo documents 50% visibility, 2% screen area, one continuous second and a maximum 250 ms gap as developmental settings. Read the recording's actual policy rather than applying these defaults to every report. Sampling and replay do not establish what pixels a human actually saw.

Browser receipts use a separate versioned definition. In version 2, observedVisibleMs, qualifiedVisibleMs and durationMs respectively describe observed visible intervals, the qualified total and the longest qualified streak. Older visibleMs is the qualified total; missing observed time remains unknown. Do not mix browser milliseconds with native microseconds or reinterpret historical receipts. E08

Follow the data and authorization boundaries

A matched receipt releases the queued message. The original phone recording, optional compressed copy, finalized server archive and backup each have their own lifecycle. Detailed server recording evidence expires 30 days after its first accepted upload chunk. Campaign reports are retained separately and remain visible, with a notice that expired evidence cannot be rechecked. Device copies, historical recordings and backups have separate lifecycles. Phone storage, upload, retention and deletion.

The intended flow is approved creative and placement → local observations and saved report → explicit authorized upload queue → durable receiver receipt → canonical replay result. A receipt acknowledges storage; the replay result separately establishes whether the submitted recording passed its checks. E06

The standing collection rule permits ad-measurement identifiers, exposure evidence, actual ad interactions and measurement lifecycle/error state. It excludes general gameplay outcomes, scores, unrelated activity, personal identity and cross-app identifiers. Ad-free sessions must not create tracking records or an installation identifier. Ordinary game saves remain separate. Local capture is the default; documented QA upload requires explicit opt-in and scoped authorization. These are implementation requirements, not a comprehensive privacy certification. Production retention, deletion, consent and age handling remain review gaps. E07

Upload and recover saved evidence

Two upload contracts are implemented. The common contract is adludo-native-upload-v1; the approved pilot adapter selects adludo-native-upload-pilot-v1 for its pilot receiver. Both bind the upload to assignment, game, placement, campaign, creative revision/hash, delivery, exposure, session, policy and method. Both accept owned-opaque-overlay-v1 and owned-depth-quad-conservative-v1 under ages-preview-v1. Shape methods v1–v4 remain local only. See the compatibility table for separate sender and receiver limits and finalization behavior. E05

Validate the archive before staging and preserve originals when unsupported or rejected. Limits apply together; a recording below one limit can still exceed another. Local capture capacity is not a promise of upload eligibility.

Preserve the exact original queued message bytes. The approved worker may bundle messages and gzip the HTTP body; receipt hashes still identify the original individual messages. Delete each message only after its matching receipt is validated. Network failures and selected transient responses receive bounded retries. Rejection or mismatched receipts retain evidence. Credentials remain outside queue files, recordings and logs. Transport sequence reservations may have gaps; canonical evidence has separate continuity rules. E06

Recovery discovers explicitly registered queues for the expected receiver. It does not scan and upload arbitrary recording history. The adapter supplies valid authorization and prevents duplicate active workers. Recovery capabilities depend on the exact package. Check the compatibility reference before using compressed-copy recovery; preserve acknowledged progress and the original pending message bytes. A valid unexpired grant may be used; recovery after restart requires fresh scoped authorization. Never clear app data or uninstall as a recovery technique when recordings must be retained. E01, E02, E06

Verify your first pilot recording

Use your own game and its validated integration. The offline preview does not connect a new game automatically.

  1. Confirm the game and placement identifiers in your developer workspace. Map them to the actual surface your adapter controls. Both companies must approve the same artwork version and the advertiser must launch the campaign.
  2. Implement and validate the runtime assignment and artwork path for your rendering method. Check eligibility and fallback behavior when an assignment is unavailable or approval is withdrawn.
  3. Connect recording lifecycle events to your game’s actual session boundaries, foreground state and visibility observations. Configure the authorized receiver and explicit ad-only upload consent. Keep credentials out of recordings and saved configurations.
  4. Run a controlled session on a target device. Verify the intended artwork, close the session through your game’s flow, and inspect the adapter’s upload status. Preserve pending evidence if delivery fails.
  5. Open Results in the owning workspace. Match the game, placement, campaign and artwork version. Check completion status and measured totals. Upload acknowledgement is separate from successful server verification.
  6. Exercise interruptions, retries and withdrawal in your integration. Confirm that retries preserve one report for the same recording and that incomplete sessions are identified accurately.

Detailed recording evidence expires after thirty days from its first accepted upload chunk; campaign reports remain available after cleanup. Once evidence is gone it cannot be replayed or rechecked. Previously deleted reports cannot be reconstructed by this change.

Interpret verification and troubleshoot

State or symptomMeaning and next action
Preview stays at zeroFocus the Game view, resume, uncover the creative and check its size; then inspect policy and known-composition state.
NeedsAuthorizationPreserve the queue and obtain fresh permission through the approved recovery flow.
NeedsPreparationStaging was incomplete; explicit preparation is required before recovery.
RetryingA transient delivery problem is being retried; retain the saved bytes.
Rejected or FaultedPreserve evidence and inspect a sanitized diagnostic. Do not convert the failure into zero measured time.
StoredQueue receipts matched; inspect the receiver's separate canonical result.
Interrupted recordingCommitted evidence may be recoverable, but an uncommitted tail can be missing. Do not call it complete.
Qualified time below visible timeExposure can be visible while failing size, visibility or continuity thresholds. Keep both values.

Server replay recalculates results from submitted observations and checks their structure. It does not authenticate client pixels or human attention. Source matching and a signed APK identify the tested package but do not establish a byte-reproducible rebuild or independent certification. E03, E04, E06

Maintain compatibility and evidence

Keep app build, SDK package, wire schema, measurement method and measurement policy versions separate. Use the exact package and its release instructions to reproduce integration checks. Link future release claims to focused checks in the same register. E03

Before extending these results to another integration, validate its rendering, target devices and operational policies.

Example of separate qualifying fragments

Illustrative native result under a one-second continuous threshold: two qualifying half-second fragments separated by an interruption total one qualified second, but produce no impression candidate. If there are no other visible intervals, visible time is also one second. Additional visible intervals below the size or visibility thresholds can increase visible time without increasing qualified time. This is an explanation of the accounting rule, not a campaign result. E04

For current policy values and approval rules, see the maintained measurement and approval specification and verification summary.