Measurement and approval specification
Development pilot reference reconciled on 5 November 2026. Receiver source revision c721c37eb83b011678b174edfb11221c32c9ac19; SDK reference revision aaa14c6a75d5978ee5d6809c783da9c3b814198e.
Measurement meanings
Native visible time sums adjacent known, ready, active endpoints with positive visibility and valid sampling gaps. Qualified intervals separately apply policy thresholds. Short qualifying fragments still add to total qualified time; only an uninterrupted qualifying streak can create the impression candidate. Native report durations are microseconds.
Browser visibility metrics version 2 uses milliseconds. observedVisibleMs sums adjacent known, foreground, non-idle, positively visible endpoints within the allowed gap. qualifiedVisibleMs equals legacy visibleMs. durationMs is the longest qualifying streak. Old receipts without observed time retain an unknown observed value. Inspected browser policy uses 50% visibility, 2% screen coverage, a one-second streak and a 250 ms maximum gap. Historical README values of 1.5%, two seconds and 260 ms are not the current inspected policy.
Focused browser tests check below-threshold visibility, screen coverage, unknown/inactive evidence, gaps, malformed fields and separate duration meanings. The prior SDK release test checks two interrupted half-second fragments yielding one qualified second and no impression candidate. These tests validate calculations, not human attention or authentic rendered pixels.
Creative and placement approval
Approval routes read the current asset, campaign and placement inside a transaction after the request body is parsed. Ownership, quality status, current campaign asset and placement review revision are checked. Advertiser and developer approvals are separate. A delayed approval cannot restore an approval that the other role withdrew. Changes to the asset or placement while a request is pending reject stale approval work.
Withdrawal requires the expected review identifier. It removes that side's approval, preserves the other approval and review history, and pauses the campaign. A conflicting newer review causes rejection. Runtime eligibility also checks active campaign status, required approvals, placement publication and disable state, game disable state, category compatibility and placement review revision, among other existing conditions.
Presentation permission is separate from permission to finish uploading previously opted-in evidence. The focused recovery test allows scoped recovery after withdrawal without renewing presentation or enrolling a different historical recording. This does not mean an expired presentation token can be reused.
Evidence scope
The verification summary maps these claims to local checks. Synthetic software approvals are not owner artwork approval. No current hosted approval state was changed or inspected. Pricing and payment calculations remain outside this specification update.
Phone storage, upload and deletion
This section covers native ad recordings, the build 44 Android retention test candidate and the hosted pilot receiver. Earlier phone builds do not acquire the new cleanup rule automatically. The offline Unity preview displays measurements in memory. Persistent game recording starts a separate local archive for an ad-bearing run.
| Copy | What it contains | When it is removed |
|---|
| Phone recording | Run metadata, campaign manifest, report, ordered measurement observations and optional ad-interaction evidence. A run can include a scoped installation identifier for repeat-ad frequency. | Build 44 enrolls new recordings for seven-day cleanup as described below. Upload and restart do not reset the deadline. Earlier, unenrolled recordings require separate handling. |
| Optional compressed copy | A second, verified representation of a completed local recording, created when selected. | Creating or using the copy keeps the original. Enrolled recordings share their deadline with compressed copies and preparation files. |
| Phone upload queue | Messages for one approved recording, its assignment and destination. Authorization for transport is supplied separately. | A matching receipt releases the corresponding queued message. Pending messages are also removed when their enrolled recording is cleaned up, even if upload has not completed. |
| Pilot receiver | Uploaded artifact chunks, receipts, a finalized archive of the selected files and a result calculated from those observations. | Newly enrolled deliveries expire thirty days after their first accepted chunk. Cleanup removes their active-store evidence and receipts, retaining a separate campaign report with totals, completion status, campaign/artwork references and verification status. Raw session/device identifiers and event streams are not retained in that summary. A minimal expiry marker prevents re-upload. |
| Backup | When the pilot backup worker runs, a snapshot can include the database and archived evidence held at that time. | The selected snapshot window is thirty days from snapshot creation. Enrolled snapshots are checked at worker startup and hourly, with recoverable Dropbox deletion after thirty days. Historical files require explicit enrollment. Provider permanent erasure remains unverified. |
Campaign reports do not have an automatic thirty-day expiry. The evidence deadline remains visible, and expired evidence cannot be rechecked. This change preserves reports still present at cleanup; it cannot recover results deleted by earlier cleanup. Retained reports are not inputs to new evidence-based commercial simulations; previously saved simulations keep their existing behavior. Explicit deletion requests must account for reports separately.
What leaves the phone
The normal recording path saves evidence locally. The QA upload path requires explicit opt-in and authorization for the selected recording. It can send the run, manifest, report, ordered evidence items and optional engagement file, together with identifiers linking the recording to its game, placement, campaign, artwork revision, delivery, session, policy and measurement method. This is enough for the receiver to check the observations behind a total. When engagement evidence is absent, interaction status is unknown.
The ad-only collection rule excludes ordinary game saves, scores, mission outcomes, personal identity and cross-app identifiers. Ad-free sessions must stay free of ad tracking records and installation-ID creation. Upload permission is scoped to the approved evidence. Historical phone recordings require their own eligible opt-in.
Retention periods and deletion requests
The hosted receiver enforces a thirty-day deadline for newly enrolled deliveries, including partial uploads, starting at the first accepted chunk. Retries and finalization do not extend it. Cleanup runs at startup, on API entry and hourly. Existing deliveries from before rollout remain outside this rule until separately reviewed. This applies to the active receiver store; external exports and backup copies require separate handling.
The build 44 phone candidate sets a seven-day deadline when a new recording closes. For an interrupted recording, recovery anchors the deadline to the last committed evidence, or its start time if no evidence was committed. Reopening does not extend a pinned deadline. Cleanup runs while the app is running, at startup, on resume and periodically. It waits while storage work or an upload is active and skips the current recording. A phone that is off or an app that is not running cannot perform cleanup at the deadline. Original recordings, compressed copies, preparation files, pending queues and associated diagnostics are in scope. Unenrolled historical recordings remain excluded.
Physical-phone checks on build 44 verified normal enrollment, interrupted-recording anchoring, unchanged deadlines after restart and removal of predated disposable recordings while controls remained. These are targeted checks, not seven days of elapsed-time observation. Controlled Unity Editor checks verified cleanup deferral when upload/storage work is marked active, and retry after a diagnostic-file failure with the component recreated. A physical-device test also verified that a malformed disposable diagnostic leaves cleanup markers for retry, and that repairing it and restarting completes cleanup while preserving controls. This does not establish automatic repair of corrupt diagnostics. A physical-device concurrency check used ten-second delayed local upload responses. Cleanup deferred on resume while a real test upload was active, then removed an expired disposable recording after upload completion. The uploaded original and unexpired/historical controls remained. This targeted test does not cover every upload failure or timing race.
Thirty days is the selected backup snapshot window, not a confirmed Dropbox erasure guarantee. The worker records newly verified snapshots and checks their age at startup and hourly, independently of whether the next backup succeeds. At the first successful check after thirty days, it rechecks file identity, revision and hash, requests recoverable deletion with a revision precondition, and verifies that the file is absent. Outages or a busy backup can delay a check. Failed or uncertain deletion remains visible in backup health; absence alone is not proof that our deletion succeeded. Changed, shared or restored files require review. Historical snapshots are not automatically enrolled; signing-key backups and other non-snapshot archives stay outside this rule. A disposable snapshot has been uploaded and restored successfully; checks around its thirty-day cutoff are scheduled for 5 December 2026.
The backup account uses Dropbox Basic, whose default deleted-file recovery period is another thirty days after deletion. A snapshot deleted at age thirty days may therefore remain recoverable until roughly age sixty days. Dropbox says final server removal normally happens within ninety days after the recovery window, with possible additional processing time. Permanent deletion starts a separate process and may be delayed; it is not proof of immediate physical erasure. Account-specific permanent deletion has not yet been tested, and provider-side exceptions remain unverified. See Dropbox's retention policy and deleted-file lifecycle.
A snapshot taken near the server's thirty-day recording deadline can extend a recording's lifetime further: roughly ninety days from first upload through Dropbox recoverability if both active thirty-day windows are enforced, plus provider deletion processing. Apply current expiry and deletion information before making a restored snapshot available.
For a deletion request, identify the recording or delivery and account for its phone originals, compressed copies, pending transfers, server evidence/results, exports and backups. Do not confirm complete erasure while any copy remains recoverable or its status is unknown. A deletion-request turnaround and verified backup-erasure procedure are still open. Withdrawing artwork approval stops presentation; it does not itself erase previously collected evidence.