Feature request: per-user revenue attribution (SSV callback or user dimension in Reporting API)

[ToRaNek]

Context

We operate a rewarded-ad-based app (Flutter, using CAS-Flutter) where users earn real money for watching ads. To prevent revenue spoofing from tampered clients, emulators, or GAID reset abuse, we need a trustworthy, server-authoritative source of per-user ad revenue.

Today, the only per-impression revenue data available comes from the SDK client side (AdContentInfo.revenue, revenuePrecision, revenueTotal, impressionDepth). A modified client can forge these values before sending them to our backend, and we have no way to verify them.

Filing this here because issues are disabled on CAS-API-Documentation. Feel free to move it.

The gap

The CAS Reporting API only exposes aggregated dimensions:

• filters: date, app, country, format, ad_source
• columns: impressions, observed_ecpm, est_earnings, dau, arpu

There is no user_id / user_pseudo_id dimension, and no server-to-server callback (unlike AdMob's Rewarded SSV, which signs impression events and POSTs them to an operator-specified URL).

This makes it structurally impossible to:

1. Verify that a given user actually watched an ad they claim to have watched.
2. Reconcile the revenue a user earned in-app with what CAS actually paid out.
3. Detect client-side tampering without resorting to indirect heuristics (eCPM plausibility bounds, impressionDepth monotonicity, device fingerprinting, etc.).

Request

One (or both) of the following would solve this:

Option A — Server-Side Verification for Rewarded ads

Same shape as AdMob's Rewarded SSV:

• Publisher configures a callback URL in the CAS dashboard.
• For every rewarded impression, CAS POSTs a signed payload containing at minimum: ad_unit, reward_item, reward_amount, user_id (passed through from the SDK via a setUserId() / customData field), timestamp, signature.
• Publisher verifies the signature server-side against a CAS-published public key.

Reference: https://developers.google.com/admob/android/ssv

Option B — user_pseudo_id dimension in the Reporting API

Let the SDK attach an opaque userPseudoId (hashed, GDPR-safe) to impressions, and expose it as a filter/column in POST /api/mediation/data. Publishers could then reconcile daily per-user revenue server-to-server.

Why this matters

Without this, every rewarded-ad publisher on CAS who pays out real money is forced to either trust the client blindly (and lose money to fraud) or build a brittle heuristic anti-fraud layer that still can't match the precision SSV would give.

Competing mediation platforms already offer SSV (AdMob, AppLovin MAX, IronSource LevelPlay). Adding it to CAS would close a significant gap for the rewarded-ad use case.

Happy to provide more details on our use case if useful.