Advertisement

The advertisement module fills placements in your UI with Cheggout's merchandising: rotating offer banners and a row of store icons. You own the pixels; Cheggout owns the decision about what goes in them, and can change it at any time without you shipping a release.

This is the lowest-commitment module in the platform. There is no session to manage, no reward to persist, no idempotency key. There is one thing you must get right, and it is tracking.

The product

Two ad formats, both delivered as SDK method calls.

Format	What it is	Typical placement
Banners	Full-width creative images, optionally auto-rotating	Home screen hero, feed slots
Stores	Merchant icons with names and discount details	A "top brands" row

Both are addressed by placementId — a slot identifier that tells Cheggout where in your product the ad will appear, so it can serve something appropriate.

What the publisher is responsible for

The module works only if you do all five of these. Missing any one produces an integration that looks fine in a demo and fails commercially.

Responsibility	Detail
Load placements	Fetch banners on home screen visit; fetch stores on each launch
Call impression	Whenever a creative is displayed, pass its href to the SDK's impression method
Call click	When the user taps, open the Cheggout SDK and pass the href in the payload
Pass user context	virtualId is mandatory except in PreLogin; languageCode is always required
Pass placement ids	The placementId for the slot you are filling
Handle callbacks	Both fetch methods are asynchronous and deliver their result to a callback

Rendering without tracking is not an integration

Impression and click are the entire commercial substance of this module. A banner that renders and never reports has no attribution, produces no revenue, and makes the campaign look dead in Cheggout's reporting — which leads to it being paused. See Tracking.

Architecture

The SDK sits in two roles here. It supplies the fetch methods, and it is the tracking and destination layer — you hand it the opaque href string and it handles parsing, firing and opening the destination.

The ad lifecycle

Two details in that sequence are easy to miss:

Rendering and impression are separate steps. Fetching a creative is not seeing it. Fire the impression when the creative is actually on screen.

Clicking means launching the SDK. For most banners, handling a click is not opening a URL yourself — it is opening the Cheggout SDK and passing the href through the payload, so the SDK resolves the destination and records the click. The exception is bankLink = 1, where the banner belongs to you and the SDK is not involved at all. See Banners.

What you need before starting

Prerequisite	Where it comes from
Channel name and credentials	Cheggout onboarding
The Android or iOS SDK integrated	See Marketplace overview for setup
Your placementId values	Cheggout — there is no self-service registry
A stable virtualId per logged-in user	Your identity system
A languageCode	Two-character ISO code

Reporting

TBD

There are no publisher-facing reporting APIs for the advertisement module. You cannot currently query impressions, clicks, click-through rate, fill rate or revenue programmatically. Reporting is delivered out of band by your Cheggout contact.

The practical consequence: a tracking bug can run for weeks undetected, because there is nothing to reconcile against. Until reporting APIs exist:

• Instrument your own counters — creatives fetched, creatives rendered, impressions fired, clicks fired — per placementId.
• Compare your counters against the numbers Cheggout reports to you, on a regular cadence.
• Investigate any material divergence as a tracking bug, not a reporting discrepancy.

What is missing, specifically: an impressions and clicks reporting endpoint, a fill-rate and no-fill metric, revenue and settlement reporting, and per-placement breakdowns. Tracked in Open Items.

Headless availability

TBD The banner and store contracts are documented as SDK method calls, not as HTTP endpoints. A headless HTTP contract — request path, auth mechanism, response envelope — is not published. If you need server-side ad delivery, confirm availability with Cheggout before planning it. The request and response field shapes documented on the banners and stores pages are stable and useful either way. See also Banners and stores.

Next

• Placements — the slot model, placementId, and pre-login behaviour.
• Banners — the full banner integration with code.
• Stores — the store row integration with code.
• Tracking — the impression and click contract and a checklist.