Publisher policy

01Scope

This policy applies to every publisher, app and placement monetizing through the Sky Boosts network, SDK, mediation or SSAI surfaces, and to anyone acting on a publisher's behalf. The terms of service carry the contractual layer; this document is the operational layer that enforcement runs on.

02Inventory requirements

• Published store presence. Every app monetizing on the network must be published on the stores it is onboarded for, under the developer identity the account declares.
• Maintained app-ads.txt. The developer domain must serve a correct, current file. Crawl monitoring alerts on drift; unremedied drift is an enforcement matter.
• Accurate store metadata. Store listing name, category and content rating must match the app that ships. Metadata theater is treated as misrepresentation.

03Prohibited traffic

• Bot and incentivized traffic, including installs or sessions driven by paid incentives to fake engagement.
• Forced engagement: interactions obtained by coercion, trickery or gate-keeping that the user did not genuinely choose.
• Simulated clicks and impressions: any mechanism that generates ad events without a corresponding human action.
• Layering, stacking or auto-refresh implementations that fabricate viewable impressions.
• Signal manipulation: modifying, fabricating or masking identifiers, application identities, bundle IDs, store URLs or content metadata in ad requests, or substituting one app's identity for another's. Requests must describe the app they come from, truthfully.

CTV authorization: for connected TV inventory, the application owner listed on the TV platform's store must be the party that authorizes every SSP and exchange selling that inventory, through the app-ads.txt chain described on the app-ads.txt page. Inventory offered by parties the application owner has not authorized is treated as unauthorized supply and filtered.

04Content restrictions

Apps whose primary content falls into categories prohibited for monetization cannot run on the network, including illegal content, malware distribution, and content that impersonates system or other applications. Where a category is age-restricted rather than prohibited, consent handling and demand eligibility follow the compliance rules; the contact desk confirms category status for edge cases before integration rather than after.

05Placement rules

Per format, placements must satisfy the rules in the format pages and the advertiser-facing commitments they encode:

• Rewarded: opt-in only, clearly labeled, real rewards granted, no forced loops. The offer must state the reward before the ad starts, and the app must grant it on completion.
• Interstitial: natural breaks only, never mid-action, close controls within the policy window, caps respected. Placement during loading screens must not extend load time to fit the ad.
• Banner and native: no layout shift after load, no overlap of app controls, native units visibly labeled. Reserved layout space must exist before the ad loads, so content never jumps.
• Offerwall: honest task descriptions, stated reward terms, no forced engagement. Pending reward states must be visible to the user until granted.
• CTV: pod limits and break spacing honored, competitive separation enforced, pause overlays cleared on resume. Break structure must match the VMAP plan agreed for the channel.

06Ad experience standards

Beyond per-format rules, inventory must meet the network's ad experience standards, which follow the principle that an ad is a guest in the product:

• Ad density. The share of session time and screen time occupied by advertising must stay proportionate to the product. Placement configurations that push density beyond what the content supports are treated as placement defects, whatever the format mix technically allows.
• Refresh behavior. Auto-refresh runs within the ranges published per format in the documentation, only while the unit is on screen, and never in a way that manufactures unviewable impressions.
• Positioning. Ads must not be placed where accidental interaction is the primary source of engagement: immediately adjacent to interactive controls, under system dialogs, or intercepting expected touch targets.
• Interruption budget. The combination of interstitials, capped formats and transition placements must respect a session-level interruption budget, not only per-format caps. Enforcement reads the combination, not each unit in isolation.

07Invalid traffic

Invalid traffic, IVT, is any traffic that does not come from a genuine human interacting with the product as designed. General invalid traffic, GIVT, covers known patterns: declared bots, datacenter ranges, malformed requests. Sophisticated invalid traffic, SIVT, covers coordinated behavior designed to evade detection and is scored from signals across the request lifecycle: timing distributions, session coherence, attribution consistency. Filtered traffic never monetizes and never appears in publisher revenue; publishers can see filtered volume per app in reporting. Inventory sourced through purchased installs, incentive networks that simulate engagement, or device farms is prohibited regardless of which partner produced it.

08Data passing rules

Publishers and their integrations must pass signals truthfully. Consent strings, device identifiers, location signals and content metadata must arrive as the platform produced them: modified, forged, downgraded or substituted signals are violations. Data beyond what the consent signals permit must not be attached to requests, and precise location or identifiers must never be passed for child-directed inventory. If your own vendors sit between your app and the SDK, their behavior is yours to police; the network reads what arrives at the auction.

09Inventory lifecycle

Apps are reviewed at onboarding and re-reviewed when material facts change: a new store listing, a change of developer domain, a category shift, or a metadata update that changes how the inventory is sold. Publishers are responsible for keeping store metadata accurate; metadata that misrepresents the app to demand is treated as misrepresentation. Apps delisted from their stores must be removed from live demand; monetizing a delisted app is a material violation.

10Enforcement ladder

1. Warning. First violations with fix paths receive written notice describing the specific finding and the fix.
2. Remediation. Continued or material violations pause affected placements or apps until the fix is verified.
3. Suspension. Traffic that endangers demand quality, or unremedied material violations, suspend the account's live demand.
4. Termination. Fraud, simulated traffic and misrepresentation terminate the account, with payment implications defined in the terms of service.

11Requirements by surface

12Appeals

Enforcement actions can be contested through the contact desk with the reference from the notice. Appeals are reviewed by a person who did not issue the action, and the outcome, including any reversal, is provided in writing. If an enforcement action paused your inventory, the pause is reassessed at the appeal outcome, not left running by default.

13Changes

Policy updates are communicated to account contacts before they take effect, with a transition window for changes that require code or placement work. The effective date is stated in every notice. Material changes are also logged on this page.