Services and platforms

Mobile traffic buying platform

The DSP brings together the spend and results of mobile traffic buying, so advertisers and agencies can evaluate campaigns without compiling reports by hand

UvicornPostgreSQL 16ClickHouseRedis 7Kafka / RedpandaREST / OpenAPIDocker / Docker Compose
Mobile traffic buying platform

Project at a glance

Problem

Data on mobile traffic buying had to be pulled from different ad accounts, reconciled with tracking data and copied into spreadsheets for client reports. The goal was to bring campaigns, spend, conversions and balances into one dashboard for mobile app advertisers and agencies. The platform is built around a division of labor: the media buyer runs the buying, while the client monitors results and exports reports. Agencies needed a structure with sub-accounts, and the finance team needed shared accounting of spend, charges and balances.

What we did
  • APIs for access, campaigns and billing
  • APIs for analytics, notifications and audit
  • Postback intake and processing
  • Conversion attribution with data storage
What the client wanted
  • Bring together data on campaigns, spend and conversions
  • Give clients access to buying results and report exports
  • Link spend, charges and balances in one accounting system

Want the same for your business? Tell us about your task — we’ll propose a solution and estimate the timeline.

A dashboard for advertisers and agencies

We designed a model of companies and sub-accounts with different access rights. It covers two scenarios: an advertiser buys traffic for its own apps, or an agency buys traffic for several clients. Financial accounting is tied to the company.

The client’s role covers viewing results and exporting data. Campaign setup is assigned to the buying team: we described offer selection, targeting, budgets, creatives and moderation. The media buyer manages the buying in external ad accounts.

Spend and results in one place

The integration scheme sets a single source of data on traffic and spend. We implemented conversion data intake and linking to campaigns — the basis for comparing costs with buying results.

The analytics design provides for handling late-arriving data and assessing traffic quality by retention, signs of fraud and spending anomalies. Report granularity depends on what data the source provides.

Finance at the company level

We designed financial accounting with a company balance, top-up confirmation and a transaction ledger. Spend, charges and balances are linked in one model, so the finance team can reconcile them without separate spreadsheets.

The model includes commissions and limits. The internal commission and margin are kept separate from the data available to the client.

Technical details

Technical details

We built backend APIs for access, campaigns, billing, analytics, notifications and audit. Postbacks are processed through an event queue: after attribution, the data is saved to PostgreSQL.

The backend runs locally and in Docker. For working with the API, we prepared a Postman collection and Swagger pages.

Target audience

  • Mobile app advertisers
  • User acquisition teams and media buyers
  • Agencies with sub-clients
  • Finance teams

What users need

Job to be done — from situation to outcome

Situation

To understand how traffic buying for my app was performing, I had to pull data from different ad accounts, reconcile it with tracking data and build a report in a spreadsheet.

Need

I want to know where the ad budget goes and what results the media buyers deliver, without compiling reports myself.

Outcome

I get an overall picture of buying spend and results and can export the data for analysis on my own.

What’s inside

1

APIs for access, campaigns and billing

2

APIs for analytics, notifications and audit

3

Postback intake and processing

4

Conversion attribution with data storage

5

Model of companies, sub-accounts and role-based access

6

Financial model with a balance and a transaction ledger

How we worked

1

Describing buying and client reporting scenarios

2

Designing accounts, financial accounting and integrations

3

Developing backend APIs

4

Implementing postback processing and attribution

5

Preparing the runtime environment and API documentation

Need a similar project?

Tell us about your task — we’ll estimate the scope, timeline and cost and propose a solution.