Production rollout
Cheggout integrations issue things of value, so a bad rollout costs money rather than just availability. Phase it.
Phasing
Phase 1 — internal users only. Real production credentials, real campaigns, staff accounts. Verify the whole journey end to end including a real redemption at a merchant, which is the one thing UAT cannot prove.
Phase 2 — a small cohort. One to five percent of eligible traffic. Long enough to see real device diversity, real network conditions and the tail of your error distribution.
Phase 3 — widen. Twenty-five, then fifty percent. Watch whether error rates hold steady as volume grows; a rate limit or a capacity boundary shows up here.
Phase 4 — full traffic.
Hold each phase long enough to see a full daily cycle. Reward and deals traffic is usually very peaked, and a problem that only appears at peak will not show in an hour.
Put the Cheggout call behind a feature flag in your own system so you can widen or roll back without a deploy. Do not rely on Cheggout-side configuration for your rollout control.
What to monitor
Health
| Metric | Watch for |
|---|---|
| Error rate per endpoint | Any step change after a phase widens |
| Latency, p50 and p95 | Degradation as volume grows |
| Timeout rate | Especially on reveal, where retries are unsafe |
| Auth failure rate | A spike means a credential or config problem, not user behaviour |
| Signature failure rate | Should be zero. Anything above zero is a defect. |
Business
| Metric | Watch for |
|---|---|
| Card issuance rate | A drop means eligibility or trigger configuration changed |
| Reveal rate | Users receiving cards but not opening them is a UX problem |
| "No reward" proportion | Expected to be significant — but a sudden move means a campaign changed |
| Coupon delivery success rate | Failures here cost coins |
| Refund rate | Should be low and explainable |
Tracking
| Metric | Watch for |
|---|---|
| Impression fire rate versus items displayed | A gap means attribution is being lost |
| Click fire rate versus taps | Same |
Tracking fire rates deserve a dedicated dashboard. They are the easiest thing to break silently, and the failure is invisible in the user experience — everything looks fine while reporting and settlement quietly under-count.
Alerts worth having on day one
- Signature failures above zero
- Auth failure rate above your baseline
- Coupon delivery failure rate above threshold
- Refund rate above threshold
- Impression fire rate falling below display rate by more than a small margin
- Reveal timeout rate above threshold
Rollback
Know in advance what "roll back" means for each module, because reward issuance is not fully reversible.
| Module | Rolling back means |
|---|---|
| Advertisement | Stop requesting placements. Clean — nothing was issued. |
| Scratch cards | Stop issuing new cards. Cards already issued remain valid — keep the reveal path live so users who hold a card can still open it. |
| Deals | Stop offering purchases. Coupons already delivered remain valid. Ensure refunds still process. |
| Marketplace | Stop launching new sessions. Existing sessions expire naturally. |
Disabling issuance is safe. Disabling reveal or coupon retrieval strands users who already hold something of value. Roll back the entry point, keep the fulfilment path running.
Reconciliation
Run reconciliation from day one, not after the first dispute.
Daily, match your ledger against the platform:
- Every
extTransactionIdyou sent for card creation, and what came back. - Every reveal you recorded, cross-checked against reward history.
- Every coupon delivery, cross-checked against
getUserCoupons. - Every coin burn, matched to either a delivered coupon or a refund.
Investigate any burn without a coupon or refund, any reveal you have no reward for, and any
extTransactionId that appears twice.
extTransactionId is the join key for all of this — which is why it must be your real transaction
reference and must never be reused.
TBD No publisher-facing reporting or settlement API is published, so reconciliation depends on the read endpoints above and on reports agreed commercially with Cheggout. Tracked in Open items.
Capacity
TBD No rate limits, quotas or SLA are published. Before you widen beyond a small cohort:
- Share your expected peak request rate with Cheggout.
- Confirm whether any limits apply to your channel.
- Agree what happens if you exceed them.
Design defensively regardless: cache the catalogue, pre-fetch tokens, back off on transport failures, and keep the user journey working when a Cheggout call fails.
Post-launch
Week one — daily reconciliation, daily review of error and tracking dashboards, and a check that the "no reward" proportion matches what the campaign intends.
Ongoing — record the SDK build, widget build and document revision you are running, so that when behaviour changes you can tell what moved. See Versioning.