Role Description

A senior data scientist who also engineers on a delivery team building an outcome-optimisation and scoring platform for an independent SSP. The role builds, evaluates, and operates models across three families: a real-time curation model, look-alike modelling with segment augmentation, and contextual segmentation. Python is the delivery language.

The two data scientists on the team are peers. Ownership of the three model families is split between them at kickoff, so this role must be credible on all three, including the latency-bound one. Model choice is not the hardest part of the work. Conversion labels arrive hours to weeks after exposure, advertiser data can be pooled only as far as each advertiser permits, and the finished system transfers to a client team with no data scientists.

An AdTech background on the programmatic supply side is required. Depth in CTV, audio, or social is an advantage rather than a gate.

About the Project

Client: an independent supply-side platform with curation, identity, and managed-service products, engaged directly. The first use case is outcome-driven campaigns for financial-services advertisers, who pay for real-world outcomes, account openings and deposits, rather than CPM or CTR.

Product: a scoring and optimisation platform that runs on the client’s infrastructure in two planes. The central plane on Google Cloud holds the data and feature foundation, model training, MLOps and experimentation, and control and reporting. The edge plane is a portable scoring container deployed inside third-party SSP runtimes.

Channels in scope: the initial production release covers one agreed channel set. Rollout follows the client’s priority order: CTV first, then web and app video, display, audio, native, and DOOH. Social is a priority for segment creation and optimisation rather than for campaign optimisation.

Modelling: three model families defined by the client. The curation model uses gradient-boosted trees on tabular features, and scores bid requests in real time. The look-alike and contextual models run in batch. Gradient-boosted trees are the baseline elsewhere, but not a constraint. The approach for the batch families is selected against the data in Phase 1 and signed off with the architecture in Phase 2.

Facts that shape the role

Only the curation model is latency-bound. Its budget is under 5 ms total round trip at p99+, and model execution is only a subset of that. The look-alike and contextual models are not real-time.
Two execution modes run at the same time. Dynamic mode scores inside third-party SSP auctions. Static mode is batch and human-governed. It produces outputs no more than once a day, which the client activates through its curation and audience tools.
Two feedback clocks. Bidstream data returns within two to three hours and drives fast adaptation. Deterministic conversions return in hours to weeks, and up to six months for one industry feed, and drive learning, calibration, and evaluation.
Advertiser data must not be commingled. The design is a general baseline model plus isolated client-specific instances, with isolation enforced in datasets, pipelines, model artefacts, and scoring instances.
Data rights are runtime configuration. Each advertiser’s position is discovered at onboarding, after the system is live, so a new policy must not require re-engineering.
Pooled historical training across advertisers is largely unavailable, so cold start is a design problem from day one.
Initial volume is around 10,000 QPS per campaign. All eligible traffic is scored, but logging is sampled within what each SSP permits to leave its environment.
The client standardises input fields across SSPs, so the models see a consistent request schema.
All datasets are delivered in Google Cloud, from roughly a dozen sources. Establishing schemas, join keys, historical coverage, and label latency is the first phase of work.
The client has no in-house data scientists. The models, the tuning practice, and the runbooks transfer to its engineering team at the end.

Key Responsibilities

Model development (primary)

Build and own models in the families assigned at kickoff, and be able to take over any of the three.
Develop the curation model: gradient-boosted trees on request-time features, sized and exported to run inside the 5 ms budget alongside feature lookup, routing, and policy evaluation.
Develop look-alike modelling and segment augmentation, subject to the agreed first-release scope: audiences seeded from confirmed converters, segment add, drop, and merge, and support for both the existing performance look-alike logic and the new behavioural logic.
Develop contextual segmentation: segments over publisher, domain, placement, format, and geography that over-index against the target outcome.
Implement multi-objective, constrained decisions, with operator-configurable weights and hard constraints held separately from predictions.

Delayed labels and data isolation

Design the two-clock objective: proxy targets from bidstream signals for fast adaptation, calibrated against deterministic outcomes as they arrive.
Handle cold start and sparse data where pooled training is not permitted.
Model intra-day, weekly, and quarterly seasonality, and monitor for concept drift.
Train the general baseline and isolated client-specific instances from pipelines that read each advertiser’s data-rights policy at runtime.
Automate the decision to move a campaign from the general baseline to its client-specific model.

MLOps and evaluation

Build reproducible training and evaluation pipelines, with model and feature versioning, a registry, and approval states.
Promote models through offline validation, shadow, canary, and champion/challenger, with rollback to the previous champion.
Measure outcome lift against control groups using the client’s existing traffic-splitting capability.
Produce the Alpha: a model scored on a held-out historical window, side by side with the operator’s own baseline on the agreed KPI, plus input to the latency feasibility benchmark for the scoring path.
Define retraining triggers and drift and guardrail monitoring with the DevOps / Infrastructure Engineer.

Collaboration and handover

Work with the data engineers on feature pipelines, point-in-time correctness, and leakage prevention.
Present modelling decisions at phase gates to the client’s product and engineering leadership.
Write code and documentation the client’s engineers can maintain. AI-assisted tooling is used under human review, with every change owned by a named engineer. [XENOSS DATA POINT: AI-usage policy]
Prepare the model and tuning handover for a team that will operate the models without data scientists.
Raise data gaps, label problems, and dependency risks early to the Solution Architect / Tech Lead

Required Qualifications

Experience

6+ years building machine-learning models that reached production, from feature design through deployment and monitoring.
At least one model deployed in a real-time bidding path, DSP or SSP side, against a measured latency budget.
Evaluated models against a control group, holdout, A/B, or champion/challenger, and reported the lift to a non-technical audience.
Delivered on a fixed-timeline, phase-gated engagement with an external client.
English: strong written and spoken, C1+ effectively. The role presents to the client’s technical leadership.

Technical Acumen

Python — production code that is packaged, tested, and reviewable, not only notebooks.
Gradient-boosted trees — XGBoost, LightGBM, or CatBoost on tabular data, including calibration and trading tree depth and count against inference latency.
Learning from incomplete labels — positive-unlabelled learning, conversion-lag modelling, and proxy objectives.
Segmentation methods — embeddings, similarity search, clustering, and over-indexing analysis.
Experimentation — holdout design and statistical power at low conversion rates.
MLOps — registry, versioning, shadow and canary rollout, drift monitoring, and automated retraining.
SQL and cloud data platforms — BigQuery and Google Cloud preferred; AWS or Azure acceptable.

Domain Knowledge — required

Programmatic auction mechanics — bid requests and responses, floors, deals, win and impression events, and where supply-side decisions sit in the auction.
Outcome measurement — attribution windows, conversion lag, deterministic and probabilistic matching, and why auction metrics are only proxies for outcomes.
Identity fundamentals — hashed email, IP, cookies, UID2, and the privacy limits on joining them. The requirement is the underlying reasoning. The client’s own products and data feeds are ramp-up.

Judgement & Soft Capabilities

Names the technique. Says gradient-boosted trees or positive-unlabelled learning, not a generic “AI”.
States plainly what has and has not been proven, including in front of the client.
Holds a modelling position with technically senior client stakeholders, and revises it when shown to be wrong.
Treats data-isolation rules as hard constraints rather than preferences.
Builds for the team that inherits the work, not for the person who wrote it.

Not Required

Deep learning research or novel architectures. The real-time path uses gradient-boosted trees because deep models cannot meet the latency budget.
LLM application or agent development. Agentic surfaces are outside this engagement.
Dashboard or front-end work. The client builds its own reporting on the feeds provided.

Nice to Have

Single-digit-millisecond model inference in production at 100k+ QPS.
Campaign or audience optimisation in CTV, audio, or social.
Outcome data from financial services or another regulated vertical.
Supply-side curation or deal-level optimisation.
Constrained or multi-objective optimisation — scalarised objectives, Pareto trade-offs.
Handing models over to a team without data scientists.

Ideal Candidate Profile

A senior data scientist from programmatic adtech who ships models rather than prototypes — someone whose work has made decisions on live traffic, not only produced analysis about it.

They write production Python and think about a model as far as its serving path. When a latency budget is quoted, they ask what feature lookup costs before they ask about model accuracy. They are equally at home on the batch side, where the question is what an audience or context segment should contain rather than how fast it can be scored.

They reason carefully about labels. Delayed conversions, proxy targets, and positives with no reliable negatives are familiar problems rather than surprises, because every model family on this project runs into at least one of them.

They respect data boundaries. Advertiser isolation is a constraint on the design, not a compliance note, and they build it into pipelines and model artefacts rather than trusting policy alone.

They are credible in front of a technical client. The client’s leadership has its own machine-learning background. They explain modelling choices in precise terms, say what has not been proven yet, and document their work so the client’s engineers can run it after they leave.