t1k:marketing:monetization:bytebrew

Field	Value
Module	`monetization`
Version	`1.16.9`
Effort	`high`
Tools	—

How to invoke

/t1k:marketing:monetization:bytebrew

ByteBrew

ByteBrew is a free, all-in-one game analytics and monetization platform (IAP and ad revenue). Its reporting surface is the ALE Metrics API (ALE = Analyze · Live · Engage), a public REST API that exposes ad-revenue, IAP, retention, and engagement data for pulling into dashboards and scheduled reports.

This skill documents the ALE Metrics reporting API only — not the separate Push API, and not the in-game SDK.

When to Use

Pulling ByteBrew ad-monetization data (revenue, impressions, eCPM, fill rate) into a dashboard
Reporting the IAP-vs-ad-revenue revenue split for a title or studio
Building retention cohort tables (Dn / Wn / Mn) from ByteBrew data
Reporting DAU / users / sessions / playtime engagement KPIs
Wiring a scheduled (cron) pull from ByteBrew with token auto-refresh

Overview

ByteBrew markets the analytics/operate suite as free. The ALE Metrics API is the official, public, ungated reporting REST API.
Data is daily-aggregated; sub-daily polling adds no value.
The API exposes product-analytics + monetization. It is not a campaign/cost/attribution API — there is no cost or campaign-spend endpoint here, so ROAS/UA-cost dashboards are not served by ByteBrew’s ALE API (this skill is scoped to the monetization module accordingly).
Paths are unversioned (no /v1/); treat the surface as “current” and re-verify before a production build.

Official docs: https://docs.bytebrew.io/services/ale · https://docs.bytebrew.io/startup/home

Authentication

ByteBrew’s ALE Metrics API uses a token-exchange flow, not stateless API keys.

POST https://ale.bytebrew.io/auth/generatetoken with JSON body:

{ "email": "<admin-email>", "apiKey": "<studio-api-key>" }

Response: { "token": "<bearer-string>" }. The token expires after exactly 1 hour.
Every subsequent reporting GET sends header Authorization: Bearer <token>.

Credentials needed:

Studio API key — found on the ByteBrew dashboard under Studio Settings. Only an account with the Admin role can view or generate it; non-admins cannot.
Admin-role account email registered on ByteBrew.
Game ID(s) for per-title filtering (optional but typical for dashboards).

Data Partner variant — externally-connected studios use POST https://ale.bytebrew.io/auth/datapartner/generatetoken (same body shape). The resulting token is scoped to your Data Partner role on the external app only.

Docs: https://docs.bytebrew.io/services/ale

Do not conflate this with ByteBrew’s separate Push API (https://docs.bytebrew.io/pushdashboard/api), which uses stateless email + apikey HTTP headers on every request. The two auth models are distinct.

Base URLs & Mobile-vs-Web Split

Base	Use
`https://ale.bytebrew.io/auth/generatetoken`	Token exchange (studio)
`https://ale.bytebrew.io/auth/datapartner/generatetoken`	Token exchange (data partner)
`https://ale.bytebrew.io/api/gamedata/analytics/`	Mobile games analytics
`https://ale.bytebrew.io/api/webgamedata/analytics/`	Web games analytics
`https://ale.bytebrew.io/api/gamedata/abtests` (and `/api/webgamedata/abtests`)	AB test enumeration

Most monetization endpoints are mobile-only — there is no /webgamedata equivalent for monetizationrevenue, monetizationadsdata, monetizationpurchasedata, purchasingusersdata, or the *retained series.

Revenue & Monetization Reporting

All paths below are under /api/gamedata/analytics/ and require startDate (YYYY-MM-DD).

Endpoint	Purpose	Key response fields
`monetizationadsdata`	Core ad-monetization report — the primary IAA/ad-revenue surface (mobile only)	`revenue`, `impressions`, `ecpm`, `fillRate` + breakdown dims
`monetizationrevenue`	Total revenue split into IAP vs ad revenue — top-line KPI card (mobile only)	nested `{ data: { purchaseData[], monetizationData[] } }` (see Gotchas)
`monetizationpurchasedata`	IAP detail — purchase count + revenue, breakable by item/category (mobile only)	`Purchases`, `Revenue` + dims

Common filters across these: endDate, gameId, abtests, country, platform.

Docs: https://docs.bytebrew.io/dashboard/monetizationrevenuereports · https://docs.bytebrew.io/dashboard/monetization

Retention & Engagement

Endpoint	Purpose	Key params / fields
`retention`	Cohort retention curve (Dn / Wn / Mn)	`scaleType` (`Days\|Weeks\|Months`), `scaledAmount`; rows: `created_date`, `day_0..day_n`
`userdata` / `dau`	Active users / installs over time	field `Users` (`/userdata`) or `DAU` (`/dau`)
`sessions` / `sessionlength` / `playtime`	Engagement KPIs	field `Sessions` / `SessionTime` / `Playtime`

Docs: https://docs.bytebrew.io/dashboard/retention

Breakdown Dimensions & Filters Reference

Shared query params (availability varies per endpoint — see tables above):

Param	Notes
`startDate`	Required, `YYYY-MM-DD`
`endDate`	Optional end of range
`gameId`	Array on most endpoints (empty = all games); a single required ID on `customeventdata` / `eventbreakdowndata`
`country` / `platform`	Geo / OS filters
`abtests`	Populate from the AB Tests List endpoint (`filterKeys[]`)
`breakdown`	Per-endpoint enum — see each table

AB Tests List (GET /api/gamedata/abtests, optional gameId) returns rows gameID, abName, abKey, filterKeys[]. Use this to discover valid values for the abtests filter on the reporting endpoints.

Common Dashboard Recipes

Ad revenue by network — monetizationadsdata with breakdown=Network; chart revenue / ecpm per network.
eCPM trend — monetizationadsdata with breakdown=Date; plot ecpm over the range.
IAP-vs-ads mix — monetizationrevenue; purchaseData[].Revenue = IAP, monetizationData[].Revenue = ad revenue; render as a split/stacked card.
Dn retention table — retention with scaleType=Days, scaledAmount=7; render day_0..day_7 as a cohort heatmap keyed on created_date.

Gotchas

Token expiry — 1 hour exactly. Re-mint before/at expiry; build refresh into any scheduled/cron pull so long-running jobs do not 401 mid-run.
API key is Admin-only. It is retrievable only by an Admin-role account under Studio Settings; non-admins cannot generate it.
Most monetization endpoints are mobile-only. monetizationrevenue, monetizationadsdata, monetizationpurchasedata, purchasingusersdata, and the *retained series have no /webgamedata equivalent.
Two distinct auth models. ALE Metrics API uses the Bearer token from /auth/generatetoken; the separate Push API uses stateless email + apikey HTTP headers. Do not mix them.
monetizationrevenue returns a nested shape — { data: { purchaseData[], monetizationData[] } } where purchaseData = IAP and monetizationData = ad revenue. This differs from the flat row shape of the other endpoints.
startDate is required, YYYY-MM-DD. gameId is an array (empty = all games) on most endpoints, but a single required ID on customeventdata / eventbreakdowndata.
Retention constraints. breakdown cannot use the Date dimension; scaledAmount has scale-specific ranges (Days 7-365, Weeks 4-52, Months 2-18).
No documented rate limits. Assume conservative server-side throttling; add client-side backoff. Do not hammer the 1-hour token-mint endpoint, and do not poll reporting endpoints more often than the daily data granularity.
Name collision. There is a same-named open-source bytebrew.ai agent project that is unrelated to this analytics platform — ignore it.
Retention numeric format is unverified. Docs show day_0..day_7 but do not state whether values are absolute users or fractions/percentages — verify against a live response before computing percentages.

References

ALE Metrics API: https://docs.bytebrew.io/services/ale
Getting started: https://docs.bytebrew.io/startup/home
Monetization revenue reports: https://docs.bytebrew.io/dashboard/monetizationrevenuereports
Retention dashboard: https://docs.bytebrew.io/dashboard/retention
Monetization dashboard: https://docs.bytebrew.io/dashboard/monetization
Push API (separate product — distinct auth): https://docs.bytebrew.io/pushdashboard/api