Sign in with your email and password.
Enter the email you sign in with and we'll send a reset link. It works once and expires in 60 minutes.
Choose a password of at least 12 characters. The link you arrived on works once — after this you sign in with your email.
Daily revenue across your view · billing basis — the financial ledger where a partner publishes one, analytics elsewhere
Share of revenue by source
Partners by revenue (consolidated across servers)
Last 7 days vs the 7 days before
CTV vs In-App — Internal: -ia tag suffix · XeWorks/Smarthub: _CTV_/_IA_ tokens
Pixalate vs DoubleVerify — Internal: -p/-dv tag suffix · XeWorks/Smarthub: _DV_ token, else Pixalate
Revenue split by format, broken down by verification vendor
Revenue split by channel. oRTB endpoints carry a vnd marker in the demand name; everything else is a VAST tag.
Highest-revenue oRTB line items in the selected range
Highest-revenue VAST line items in the selected range
Highest-revenue line items in the selected range
Revenue is the financial-ledger (billing) figure for XeWorks. Internal and SmartHub have no financial ledger and stay analytics-sourced.
Pick dimensions and metrics, drag to reorder columns, click a header to sort.
Exact matches only — no partial matching, so com.hulu.plus
will not pull in com.hulu.plus.roku.
Uses every filter above plus the date range. Demand takes a comma list — prequel, castify.
Consolidated across servers, tags & partners
Last 7 days vs the 7 days before
CTV vs In-App — bundle-tracked revenue only (XeWorks + Smarthub)
What the partner's own API says against our internal numbers, one row per feed tag per day with a TOTAL line for each day. API sources are pulled server-side; file sources (weekly emails) are pasted below and carry a file badge. Days a partner has not reported show as not reported — never as zero.
For partners who email a weekly report instead of exposing an API. Paste the rows exactly as they come — dates like 7/19/2026, numbers with commas and $ are handled. The last number on each line is treated as the amount and the one before it as impressions.
The date order is only used when the paste is ambiguous — if any date in it has a
part over 12 (like 7/19), that proves the order and this dropdown is ignored.
YYYY-MM-DD is never ambiguous. A paste containing both orders is refused rather than
half mis-dated.
Every XeWorks demand EP and internal feed with its full URL, shown as-is and a copy button.
Find a tag by anything you know about it — name, tag ID, partner, URL, or a marker like oRTB, CTV, InApp, DV, P.
The $ columns answer "is it making money": last 3 days, last 7 days, lifetime, and the date it was last active.
A bidder replying 404/204 to our GET is normal and means alive — it wants a bid POST, which we never send. Only DNS failure, refused or timeout counts as unreachable, and that means from our server: bidders may allowlist IPs.
Paste the XeWorks demand export — demandId, demandName, url (tab or comma separated; a header row is ignored). Re-importing updates existing rows by demandId, so it is safe to paste the whole list again after a change.
Your impressions against what Pixalate scanned, for the date range in the top bar. Every percentage is calculated from Pixalate's exact ad counts, not from its rounded % columns. A bundle Pixalate never scanned shows as unmeasured — that is not the same as clean.
Paste bundle IDs — one per line, or comma separated. Mixed Apple numeric IDs and Android package names are fine. Leave empty to go back to every bundle in range.
report_facts) and is the
only grain with an app/bundle breakdown. Financial is their billing
ledger (report_financial_facts) and is what XeWorks tell us to bill from:
“analytics can lose events”. A gap is normally a reporting incident on
the analytics side, not money that appeared or vanished. Financial data exists for
XeWorks only today — on any other server a financial figure of $0 means
absent, not zero revenue.
Pulls analytics, bundles and financials for today and yesterday. An automatic check runs every 10 minutes and only imports when XeWorks' numbers actually change, so this button is for when you do not want to wait.
Both numbers side by side for the date range in the top bar, with the difference highlighted. An emulated full outer join — a demand that exists in only one of the two grains is shown, not hidden.
| Name | View | First seen | Last active | Active days | Exports | Signed in from | |
|---|---|---|---|---|---|---|---|
| Loading… | |||||||
| Name | View | Status | Last sign-in | ||
|---|---|---|---|---|---|
| Loading… | |||||
Which partners a login is allowed to see. This controls visibility only — it deletes no data, changes no revenue, and every change is reversible. Your own view is never editable here, and a view with full access is not listed as editable because a partner list has no effect on it.
bb- tags (included there since
2026-08-10). Supply, demand and bundle totals are three different populations — no two
of them are additive.
Our own bb- feeds as XeWorks measures them, with cost and profit — which the Internal export below has never carried. Each tag is resolved to its Internal feed from the feed id inside the tag name.
Every bb- feed with data in the date range in the top bar. Fill rate and eCPM are calculated from the stored impression, bid and revenue counts, never from a stored ratio.
Measured against the newest day of supply data we hold, not against today and not against the date range in the top bar — a feed should not be reported dead because an export is a day old or because you picked a short range. Every feed is tested against all four meanings of “non-performing” at once and carries the reasons it was flagged, so you can see which definition produced a row.
Every tag whose first day of data falls inside the watch window — so a newly launched tag or oRTB endpoint stays visible while it beds in, then drops off by itself. Tags in their first few days are badged NEW.
Tags whose Internal comment field says monitor — the manual "look after this one" flag. Uses the date range and filters in the top bar.
Your winning tag earns on a set of apps. Which of them is a weaker tag not getting — and what is that worth at the weaker tag's own size? Bundles > Compare answers presence; this answers mix, in money. Revenue here is bundle-grain attribution, never billing.
Each server reports differently, so this surface reshapes per server and states plainly what the selected one cannot answer.
Movement in bundle attribution. Analytics remains the revenue truth — these $ figures rank urgency, they are not billing.
Requests, impressions and revenue per XeWorks endpoint, with eCPM and fill rate derived. Read the whitelist-size bands first — a single endpoint is not a population, and reading one row as one produced a wrong conclusion once already.
Traffic vs whitelist per demand endpoint — attributed bundles outside the whitelist, and whitelist entries with no observed traffic.
Scans every Index ID / Feed ID / Tag across the selected server(s) and date range (top bar) and lists any tag whose total revenue over that range is below the threshold — so you can pause them on the individual servers.
Figures on this tab are analytics-basis (the operational ledger). Billing revenue lives on Overview / Reports / Custom builder.
A tag is classified from its own name. These carry no _CTV_, _IA_ or _InApp_ token, so nothing in the data says which they are — set them here and every report follows. Anything set below can be changed or cleared.