Skip to content
Newv6.18.0Generated values for buyer deliveries, a safer Google Sheet connection, and a post log filter step that explains itself.Read the changelog
Analytics & margin

Volume is easy to see. Margin is the hard part.

Datahubb holds revenue, cost and profit on every lead, buyer, campaign and source — and updates them as leads settle rather than at the end of the month. Here is exactly how that number is put together.

Start Free Trial
Book a Demo
Revenue − cost, per lead
Hourly, not nightly
Pending never counted as revenue
Analytics view showing revenue, cost and margin broken down by campaign, buyer and source
How margin is computed

A number you can take apart

Margin is a subtraction, and the whole value of it is being able to see both sides. Revenue is what the buyer actually paid for a sold lead — the bid that won, or the payout rule that overrode it. Cost is what you owe the supplier or traffic source for that same lead. The difference is carried on the lead itself, then rolled up wherever you look at it.

  • Every settled lead increments a counter on the current hour’s bucket for its buyer, supplier and campaign — leads, accepted, rejected, revenue, payout
  • Nothing waits for a nightly batch: the same write that books the sale moves the margin
  • CPA leads awaiting confirmation add nothing until the postback lands, and a returned lead reverses the revenue it booked
  • Storing the hour, not the lead, is why a year-to-date range still loads
Margin · 14:00–15:00this hour
Revenue
38 sold · buyer price
+$1,482.00
Source payout
cost owed to suppliers
−$610.00
Returned
1 clawback · revenue reversed
−$44.00
Pending (CPA)
awaiting confirmation — not revenue yet
$0.00
Margin this hour+$828.00

Each settled lead increments the current hour’s counters — buyer, supplier, campaign.

Reporting

Profit visibility, not just volume

Lead counts tell you the machine is running. Margin tells you whether it is worth running. Every view here resolves back to the second question.

Both sides of the subtraction

Revenue is what the buyer paid. Cost is what you owe the supplier or traffic source for that same lead. Margin is held per lead and rolled up per buyer, campaign, supplier and source — so profit is a column, not a spreadsheet you build later.

Four buckets, never blurred

Sold, pending, rejected, returned. A CPA lead pending confirmation is not revenue, and a clawback is not the same thing as a CPA decline. Keeping them apart is the difference between a return rate you can act on and one that is quietly wrong.

EPC that says which EPC

Blended EPC answers “what did the traffic I bought earn?”. Offer-side EPC answers “what did this surface earn?”. They are different numbers and the dashboard labels which one you are looking at instead of averaging them into a third.

Rejections, with a cause

Every rejected lead grouped by what stopped it — a filter, a duplicate, a validation rule, the buyer’s own verdict, or a cap that was already full — with the buyer’s raw response one click away in the ping and post log.

Long ranges stay fast

Stats are pre-aggregated into hourly buckets per entity, so a year-to-date view reads a few thousand rows instead of scanning every lead you have ever taken.

Slice it, then keep the slice

Filter by campaign — several at once — buyer, supplier, traffic source, date range and timezone. Export the exact view, and save the column set as a preset so next week’s report is one click.

The four buckets

Sold, pending, rejected, returned

Most reporting mistakes in lead distribution are one of these four being quietly counted as another. A CPA lead that has not been confirmed is not revenue. A CPA lead the buyer declined never was. A sold lead clawed back is a real reversal and belongs in a different column entirely. Datahubb keeps them apart at the source, so the acceptance rate and the return rate mean what they say.

  • Sold — realised revenue, the only bucket that feeds the margin line
  • Pending — a CPA lead awaiting the buyer’s confirmation postback
  • Rejected — declined, never realised
  • Returned — sold, then clawed back, and the revenue reversed
Datahubb dashboard showing posted, accepted and rejected lead counts with profit and trend charts
How it gets used

From a KPI card to the buyer’s own words

The reporting surfaces are laid out as one path: notice it on the dashboard, narrow it in analytics, then prove it in the raw delivery log.

Open the dashboard: today’s posted, accepted, rejected and profit, against the trailing average
Roll several campaigns into one view, then click a campaign to drill into its buyers, suppliers and traffic sources
Sort that campaign’s buyers by rejections, then jump to the ping and post log and read the buyer’s own response
Switch the timezone to the buyer’s, so “today” means their day and not yours
Export the filtered view, and save the columns as a preset for the Monday report
FAQ

Frequently asked questions

Margin is not assembled by a nightly job. As each lead settles, the same write that records the sale increments counters on the current hour’s bucket for that buyer, supplier and campaign: leads, accepted, rejected, revenue, payout. So the numbers move while traffic is running. The honest caveat is that the hour is the grain those rollups are stored at, and rejection rows are written on an async queue — so a freshly rejected lead can land in the breakdown a little behind the event itself.

The payout owed on that lead to the supplier or traffic source that sent it. If a source-side payout filter overrode that cost, the lead timeline says so explicitly with a “Source Filter” chip and an annotation under the amount — because a margin that silently changed underneath you is worse than no margin at all. There is a separate, distinct flag for a buyer-side payout override, and the two are never merged.

Because it should not have. A CPA lead sits in the PENDING bucket and books nothing until the buyer’s confirmation postback arrives — that is the point at which revenue is real. If pending leads are still pending after the buyer’s confirmation window, the usual cause is a postback that is not being sent or is pointed at the wrong URL, not a reporting bug.

Almost always the query. A returned flag on a sale covers two different events: a sold lead clawed back, and a CPA lead declined before it ever became revenue. Only the first is a return. If you aggregate on the flag rather than on the explicit returned status, every CPA decline inflates your return rate — it is the single most common mistake made against this data.

They count different events on purpose. Rejection analytics counts every filter, schedule and cap event at the delivery level — one lead can generate several. Campaign analytics counts the lead. A gap between them is expected, and no toggle makes them agree.

Not inside Datahubb — there is no drag-and-drop dashboard builder, and pretending otherwise would waste your evaluation. What you get is the filtered views, the breakdowns by buyer, supplier, traffic source and campaign, and a CSV export of any of them with saved column presets. If you want a bespoke BI layer, the lead, sale and rejection tables are yours to query directly.

Whichever one you ask for. Timezone is passed with the request rather than baked into your account, so you can read the same window in your own timezone or in your buyer’s — which matters when you are arguing about a delivery schedule or a daily cap that resets on their clock, not yours.

Know your margin while the traffic is still running.

Start your 14-day trial. Full platform access. Card required, no charge if you cancel during the trial.

Start Free Trial
Book a Demo