Home/Offers/Media, Gaming & Sports/Audience Intelligence API

Media, Gaming & Sports

Audience Intelligence API

You almost certainly know how many people watched. Knowing which audiences those were, and what they are moving towards, usually takes a quarterly agency deck.

Publishers
Streaming platforms
Media agencies
Podcast networks
Broadcast research teams

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Media businesses measure volume well and composition badly. Dashboards report plays, uniques and completion, and then somebody asks which audience is growing and the answer arrives six weeks later as a slide. The data to answer it faster is already in the logs; what is missing is a segmentation layer that anyone can query.

Panel research fills the gap and has real weaknesses: small samples, slow refresh, and categories designed for television advertising rather than for the way your catalogue is actually organised. It is also expensive enough that most teams buy it once a quarter and treat the findings as fact for three months.

The honest version of this is built on first-party behaviour with aggregation thresholds applied from the start. Interests inferred from what people actually consume, segments defined and redefined by your own analysts, trend detection that distinguishes a genuine shift from a scheduling artefact. Done properly it is a reporting and planning tool, not a targeting database.

Who buys this

Publishers, Streaming platforms, Media agencies, Podcast networks, Broadcast research teams

Category: Media, Gaming & Sports

What the API returns

What comes back

Interest profiles at segment level, never individual, with cohort sizes attached
Consumption trends by topic, format, daypart and device
Segment definitions your analysts can create, version and share
Overlap analysis between segments, including unexpected intersections
Emerging-interest detection with the sample size that produced it
Churn-risk composition by segment rather than by single account
Content-to-audience affinity scores for commissioning and scheduling
Suppression flags wherever a cohort falls below the publishable threshold

Endpoints

Method	Path	Returns
POST	/v1/segments	Define or update a segment from behavioural criteria
GET	/v1/segments/{id}/profile	Interest and consumption profile for a segment
GET	/v1/trends	Rising and falling interests across the audience
POST	/v1/overlap	Overlap and distinctiveness between two or more segments
GET	/v1/content/{id}/audience	Which segments consumed a given item
POST	/v1/events	Ingest consumption events on a schedule or as a stream

Request and response

illustrative

Request

{
  "segment_id": "seg_latenight_docs",
  "period": { "from": "2026-07-01", "to": "2026-10-15" },
  "compare_to": "all_audience",
  "min_cohort": 500
}

Response

{
  "segment_id": "seg_latenight_docs",
  "cohort_size": 41820,
  "publishable": true,
  "period": { "from": "2026-07-01", "to": "2026-10-15" },
  "interests": [
    { "topic": "true_crime_documentary", "index_vs_all": 2.41, "share": 0.28 },
    { "topic": "political_history",       "index_vs_all": 1.86, "share": 0.14 },
    { "topic": "long_form_interview",     "index_vs_all": 1.52, "share": 0.11 }
  ],
  "consumption": {
    "median_session_minutes": 68,
    "peak_daypart": "22:00-00:00",
    "device_mix": { "tv": 0.52, "mobile": 0.31, "desktop": 0.17 },
    "completion_rate": 0.61
  },
  "trend": {
    "direction": "growing",
    "change_vs_prior_period": 0.093,
    "driver": "political_history up 21% within segment"
  },
  "overlap": [
    { "segment_id": "seg_weekend_bingers", "jaccard": 0.18 }
  ]
}

Where the data comes from

Your consumption logs	Plays, completions, searches and session timing — first-party behaviour is the backbone of the whole service
Your catalogue taxonomy	Topics, formats and genres as your organisation actually defines them, not a generic industry tree
Subscription and account metadata	Plan, tenure and region, used for segmentation; sensitive attributes are excluded by design rather than by policy note
Declared preferences	Onboarding choices and follows, where users gave them for this purpose
Licensed panel or industry data	Optional, for calibration against external measurement — almost always licensed for internal analysis only, so it informs rather than appears in output
Editorial and schedule metadata	Publication times, promotion slots and campaign periods, so a scheduling effect is not reported as an audience shift

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Interest inference from consumption sequences rather than single items, since one documentary does not make a documentary viewer
Topic modelling over your own catalogue text, so the taxonomy matches the business instead of a licensed vocabulary
Indexing against the full audience so a segment's distinctiveness is visible, not just its volume
Minimum cohort thresholds enforced in the query layer, with suppression reported rather than silently applied
Differencing checks so overlapping segment queries cannot be combined to isolate small groups or individuals
Trend detection with seasonality and schedule adjustment, because most apparent shifts are promotion artefacts
Stability testing: segments are re-derived on rolling windows to show whether a finding holds or was a one-period accident
Monitoring for ingestion gaps, which look exactly like audience decline on a dashboard

What it changes for the business

Faster planning cycles

Commissioning and scheduling questions get answered the same day instead of in the next research cycle.

Sharper commissioning input

Affinity scores show which audience an idea would actually serve, with the cohort size attached.

Lower research spend

First-party segmentation reduces how much external panel data has to be bought and re-bought.

Consistent definitions

One versioned segment library, so two teams stop reporting different numbers for the same audience.

How it fits into your product

How it embeds

REST queries from your BI tools, with results shaped for direct use in dashboards
Segment definitions stored and versioned, so a chart from last quarter can be reproduced
Scheduled exports into your warehouse for joins with revenue and subscription data
Deployment inside your own environment, which is the normal arrangement for first-party audience data
Role-based access so cohort-level detail is available to analysts and summaries to wider teams
Webhooks on material trend changes for planning and editorial alerts

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 12 weeks

Discovery and data review

Weeks 1–2

We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.

Architecture and prototype

Weeks 3–4

You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.

Production build

Weeks 5–10

Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.

Integration and handover

Weeks 11–12

We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Is this a targeting or ad-tech product?

No, and we would scope it away from that explicitly. It reports on audiences at cohort level with suppression thresholds; it does not emit individual-level profiles for advertising activation. If individual targeting is what you need, that is a different build with a different consent and legal basis, and it should not be smuggled in under a research tool.

How small can a segment be before it stops being reported?

That threshold is yours to set with your privacy team, and we build to it. The default we would propose is a few hundred accounts, plus differencing protection so a small group cannot be isolated by subtracting two larger queries from each other.

Do you infer sensitive characteristics?

No. The model works on consumption of your own catalogue. Inferring health, religion, sexuality, politics or ethnicity from viewing behaviour is both legally hazardous and frequently wrong, and we would decline to build it.

Can it be calibrated against industry panel figures?

Where you licence that data, yes — as a calibration input. Most panel licences permit internal analysis but not redistribution, so panel-derived numbers would not appear in API output you expose to clients or partners.

Will the trends be reliable in a small audience?

Less so, and the response says as much. With a modest audience, weekly trend detection mostly measures noise and scheduling. We would report on longer windows and attach sample sizes rather than produce a confident-looking line nobody should act on.

All Media, Gaming & Sports offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers