Role Description
The single technical owner of a Connected TV measurement platform is the person who decides how advertising exposure is matched to advertiser conversions and who is accountable for whether the resulting numbers are right. This is the only backend seat on the project. There is no backend peer, no second architect, and no one else to catch a modelling error before it reaches an advertiser.
The platform does not invent the measurement science. It comprises three third parties — an affiliate network supplying conversions, CTV buying platforms supplying exposure, and a specialist supplying the household match — behind one client-owned layer. The engineering value is in that layer: the contracts between the parties, the durable and replayable record of every event, the reconciliation that proves nothing was silently lost, and the auditable trail that explains why a given conversion was matched, left pending, or rejected.
Two things make the role harder than its component parts. The first is that every integration contract belongs to someone else, and each carries its own approval path — a plugin agreement, an information-security questionnaire, a penetration test, white-label terms. The second is that the measurement result taxonomy is the product. Matched, unmatched, pending, and rejected are commercial statements, not enum values, and getting their boundaries wrong produces confident numbers that are quietly false.
Full-time across the whole engagement, from the first validation conversation to production handover. The role leads a small delivery team — a frontend engineer, an SDET, and a DevOps engineer — while personally building the ingestion, orchestration, and measurement pipeline.
About the Project
Client: a UK audience-first programmatic media-activation partner that plans and runs advertising campaigns for brands and agencies on a managed-service basis, engaged through a delivery partner. Phase 1 is a controlled pilot with a small advertiser cohort, operated internally rather than sold as a product.
Product: a Connected TV Measurement Platform that comprises proven third-party engines behind one client-owned layer:
- Awin is the distribution spine and the source of advertiser conversions, captured through a client-branded MasterTag plugin.
- CTV buying platforms (DSPs such as Amazon DSP and DV360) supply campaign exposure data.
- Spoteffects performs the specialist household exposure-to-conversion match.
Client owns the layer between them: partner integration and advertiser provisioning, conversion capture and event ingestion, measurement orchestration, the durable event store, reconciliation, and the reporting API. This role designs and builds that layer.
Stack: Java backend services; ClickHouse for the reporting and aggregation layer, exposed through a REST API and a query DSL; MongoDB for operational and configuration state; React and TypeScript on the operations console, built by a separate frontend engineer against these APIs.
Position today: greenfield. Data contracts, event schemas, and the end-to-end flow across the three partners are a first-milestone deliverable, not an inheritance. The person in this role writes them.
Delivery: an approximately five-month phased pilot, run against a weekly delivery review, and gated by partner dependencies — Awin plugin agreement and information-security approval, one validated DSP exposure path, and the Spoteffects interface. Advertiser-facing access and productisation are later-phase decisions.
Key Responsibilities
Architecture and integration design
- Author the integration design specification: confirmed data contracts, event schemas, and the end-to-end data flow across the affiliate network, the DSP, and the household-match partner.
- Validate each partner interface in practice rather than on paper: conversion field shapes, exposure-data availability at the household level, and the match partner’s input and results interface.
- Produce the consent and data-flow assessment: controller, processor, and sub-processor roles, and the privacy design for the pilot.
- Map the partner onboarding critical path: plugin agreement, integration fee, information-security questionnaire, vulnerability scan, and penetration test — and feed it into the delivery schedule as dated dependencies.
Building the platform
- Build the Partner Integration Service and the advertiser activation, deactivation, and provisioning path.
- Deliver the client-branded MasterTag plugin and conversion capture against the affiliate sandbox.
- Build tracking and event ingestion with schema validation, deduplication, and a durable, replayable event store.
- Build the measurement orchestration and the match-partner adapter, and the pipeline behind them: Logger, FileX, Uploader, Aggregator, and Reporter.
- Implement reconciliation across partner boundaries and the Reporter API and query DSL that the console consumes.
Measurement correctness
- Define the boundaries of matched, unmatched, pending, and rejected outcomes, and make each one defensible to a commercial stakeholder.
- Guarantee that a genuine zero is distinguishable from a failed integration at the source, not just in the interface.
- Produce explainable, auditable measurement records for any reported figure, the trail that shows how it was reached.
Technical leadership
- Guard architectural boundaries and integration contracts as the parallel frontend, test, and infrastructure workstreams build against them.
- Set the API contracts the console depends on early enough that the frontend is not blocked, and co-own the query DSL with the engineer consuming it.
- Provide technical coordination across the three partner integrations, including direct technical dialogue with partner engineering teams.
- Carry the platform into production: monitoring, operational runbooks, exception workflows, and support handover.
Required Qualifications
Experience
- 8+ years building backend systems in production, with several years as the design authority on a system rather than a contributor to someone else’s.
- Has designed and personally built an event-processing pipeline end-to-end, including ingestion, validation, deduplication, durable storage, aggregation, and reporting, and not only maintained one that already existed.
- Has owned third-party integrations where the contract, the schema, and the release calendar belonged to the other party, and has negotiated a working interface out of that.
- Has led a small delivery team while remaining hands-on as the primary author of the hardest component.
- Production Java depth, and working command of a columnar analytics store, ClickHouse specifically, or a close equivalent carried into production.
- English: strong written and spoken, C1+ effectively. The role writes the specifications that other parties build against and speaks directly to partner engineering teams and client stakeholders.
Technical Acumen
- Event-driven architecture with durability and replay as first-class requirements, including the failure modes of at-least-once delivery, out-of-order arrival, and late data.
- Reconciliation design — proving that what entered the system, what was matched, and what was reported agree, and locating the discrepancy when they do not.
- Schema and contract design across organisational boundaries, including versioning and validation at the edge.
- Analytical data modelling for reporting at query-time performance, and exposing it through a REST API and a query DSL.
- Operational state and configuration modelling in a document store, alongside the analytical layer.
- Production readiness as a design input, not a final phase: monitoring, alerting, runbooks, and exception workflows.
Judgement & Soft Capabilities
- Treats a measurement result as a commercial claim. Will not ship a number they cannot explain the derivation of, and says so before it ships rather than after.
- Validates partner assumptions early and in practice, because a wrong assumption about a partner interface discovered in the third month is the single failure mode most likely to end the pilot.
- Holds an architectural boundary against schedule pressure and can explain to a commercial stakeholder what is being traded when it bends.
- Distinguishes pilot-grade from production-grade deliberately and states which one is being built rather than leaving it ambiguous.
- Leads a small team without becoming a bottleneck: unblocks the frontend with contracts, unblocks the SDET with testable boundaries, and still writes the pipeline.
- Raises a dependency risk with a named owner and a date, not as a general concern.
Domain Knowledge — required
Domain knowledge gates this role, but not the engagement-specific kind. The person who defines what counts as a matched conversion is defining what an advertiser is billed against, and a domain error there produces confident, wrong measurement that survives review because nothing looks broken. What must already be present is the adtech reasoning underneath that judgement. The specifics of this particular partner set are learnable in weeks by someone who holds it, and not learnable at all by someone who does not.
Required and portable across adtech platforms:
- Digital advertising measurement and attribution as a commercial mechanism: what an impression, an exposure, and a conversion each are, attribution windows, and how the payment model changes what the data has to prove.
- Identity and matching: deterministic versus probabilistic resolution, why a match is a confidence statement rather than a fact, and what unmatched and pending legitimately mean.
- Conversion tracking in practice: tags and pixels, deduplication across sources, late and amended conversions, and reconciliation against a partner’s own reported figures.
- The programmatic supply chain: what a DSP, an SSP , and a network each do, and what exposure data does and does not contain.
Depth in one of adtech, affiliate, performance marketing, or media measurement is expected. Breadth across all of them is not. The gap that matters is someone who has never had to defend a number to the party paying against it.
Nice to Have
- Direct experience with an affiliate or performance network’s integration surface, or with building a branded tag on a third-party’s tag-management platform.
- Prior work with a CTV or TV measurement provider, or with panel-based and household-graph data sources.
- Having taken a system through a client’s or partner’s information-security review, questionnaire, vulnerability scan, and penetration test.
- ClickHouse at reporting scale, including schema design for query-time aggregation.
- Experience white-labelling a third-party engine behind an owned product surface.
- Having handed a platform over to a client team to run, in anticipation of Phase 2.
Ideal Candidate Profile
You are the person who gets handed three partners, no contracts, and a promise someone has already made to an advertiser, and treats that as a normal Tuesday. You know the architecture is not the hard part here. The hard part is that three organisations each own a piece of the truth. None of them will change their interface for you, and the number at the end has to be defensible to whoever is paying against it.
You validate assumptions about other people’s systems early, because you have been burned by a partner interface that turned out to work differently in month three, and you would rather find that in week two. You map the approval path — the questionnaire, the scan, the agreement — before it becomes the thing holding up the launch, and you give every dependency a name and a date.
You care about reconciliation the way other engineers care about test coverage. You want to be able to point at any figure on a report and walk backwards through it to the raw event, and you are uncomfortable until you can. You know the difference between a genuine zero and a broken feed is not a display concern. It is decided in your pipeline, long before anyone sees a screen.
You lead by unblocking. The frontend engineer gets contracts from you before they are needed, the SDET gets boundaries worth testing, and you still write the ingestion and the matching orchestration yourself. You are the only person on this project who can tell whether the measurement is right, and you are comfortable with that being true.