Skip to content

Industry

Software engineering for Advertising

Adtech is two hard problems at once: engineering at brutal latency and scale, and rebuilding measurement after privacy changes broke the old tracking model. We do both, and we build consent-respecting, first-party systems rather than surveillance workarounds that will not survive the next platform change.

Why the domain matters

Advertising software spans a wide range. The tools an agency uses to plan and run campaigns, the ad-serving and bidding infrastructure that decides which creative loads in a fraction of a second, and the measurement and attribution systems that try to answer the oldest question in the industry: did the spend work. It is one of the few sectors where a genuinely demanding distributed-systems problem and a genuinely demanding regulatory problem sit on top of each other, and where getting one right does not excuse getting the other wrong.

The engineering at the sharp end is real. Real-time bidding gives you a budget of tens of milliseconds to receive a bid request, enrich it, score it, and respond: millions of times a second, every second, with the auction closing whether you answered or not. That is high-throughput, low-latency, cost-sensitive engineering where a slow tail is a lost impression and a lost impression is lost revenue. But most of the industry does not live at the exchange; most of it lives in campaign tooling, ad serving, tracking pixels and dashboards, and that is where the deeper change has landed.

The defining story in advertising right now is not scale, it is privacy upheaval. The slow deprecation of third-party cookies, Apple’s App Tracking Transparency and the retirement of the mobile advertising identifier, and the hard requirements of GDPR, the ePrivacy rules and PECR around consent have collectively broken the tracking and attribution model the industry ran on for two decades. We are honest about what that means: the old cross-site, identifier-based measurement is not coming back, and no amount of clever engineering makes fingerprinting or covert tracking a safe bet. What we build is privacy-compliant, first-party, consent-respecting measurement and campaign systems. The model the industry is moving to, not the one it is leaving.

The challenges in advertising

  • The tracking model the industry ran on has broken

    Third-party cookies, cross-site identifiers and the mobile ad ID underpinned most attribution and audience targeting. Cookie deprecation, Apple’s ATT and identifier retirement, and consent law have dismantled that foundation. The hard part is not adding a consent banner; it is that measurement built on those signals now under-reports, breaks silently, or stops working entirely, and the replacements are structurally different, not drop-in.

  • Consent is now load-bearing, not decorative

    Under GDPR, the ePrivacy rules and PECR, non-essential tracking needs valid consent before it fires, freely given, specific and revocable. That turns the consent signal into a control that every tag, pixel and measurement call has to respect at the moment it runs. Systems that collect the consent and then ignore it, or fire tags before it is granted, are both non-compliant and a genuine liability. Wiring consent through the whole stack is real engineering, not a banner.

  • RTB demands extreme latency and throughput

    For anyone touching the bidding path, the constraints are unforgiving: single- or low-double-digit millisecond response budgets, millions of requests per second, and an auction that does not wait. There is no room for a slow database call, a cold cache, or a garbage-collection pause on the hot path. This is tail-latency engineering (the p99 is what loses you inventory), and it has to be done at a cost per mille that keeps the economics viable.

  • Attribution was always harder than the dashboards admitted

    Last-click attribution was always a convenient fiction, and multi-touch models were always fragile. Privacy changes have made the underlying data sparser and noisier, so measurement now has to reason honestly about incomplete signals rather than pretend to a false precision. Building systems that are candid about uncertainty (modelled conversions, gaps, confidence), is harder and less comfortable than a dashboard that shows a tidy, over-confident number.

  • First-party data is the asset, and it is under-built

    As third-party signals fade, a brand’s own first-party data (its customers, its consented audiences, its own site and app behaviour), becomes the durable asset. But most organisations have that data scattered across tools, with no clean identity model, no consent lineage and no way to activate it. Turning it into something usable and compliant is a data-engineering and governance problem that has been deferred for years and can no longer be.

  • The platforms move the goalposts, repeatedly

    Google, Meta, Apple and the browser vendors change APIs, deprecate signals, and shift policy on their own timelines, and the whole ecosystem has to follow. A measurement approach that works today can be undermined by a browser release or a platform policy next quarter. Systems built rigidly around one platform’s current behaviour age badly; the work is to build for change rather than betting the architecture on signals someone else controls.

What we build for advertising

The systems this sector most often needs, built by engineers who understand the domain, not just the code.

  • Campaign management and planning tools

    The tooling agencies and in-house teams use to plan, launch, budget, traffic and report on campaigns across channels. We build the workflow, the approvals, the budget pacing and the reporting layer, and we integrate the platform APIs so that setting up and monitoring campaigns does not mean a dozen browser tabs and a manual spreadsheet reconciliation at the end of the month.

  • Ad serving and RTB infrastructure

    The low-latency path, ad servers, bidders, and the components that plug into exchanges, DSPs and SSPs. We build for the tail latency and throughput this demands: careful data-locality, in-memory decisioning, budget and frequency control that holds up under concurrency, and a cost model that survives contact with real query volumes. We are equally honest when a client does not need to build this at all.

  • Privacy-respecting attribution and measurement

    Measurement that works in a consented, first-party world: server-side event collection, the platform conversion APIs, modelled and aggregated measurement, and incrementality testing rather than a reliance on cross-site identifiers. We build systems that report honestly on what can and cannot be known, so decisions rest on defensible numbers instead of a precise-looking figure that quietly stopped being true.

  • Customer data and first-party data platforms

    The infrastructure that turns scattered first-party data into a governed, activatable asset, identity resolution on consented data, audience building, consent lineage, and clean feeds out to activation channels. This is as much a data-governance problem as an engineering one, and we build the consent and provenance in from the start rather than bolting it on when someone asks where an audience came from.

  • Creative management and dynamic optimisation

    Tooling for creative production, versioning and dynamic creative optimisation, assembling and serving the right creative variant per context without turning every render into a tracking event. We build the asset management, the templating and the decisioning, and we keep the personalisation on the right side of the consent line rather than treating every viewer as a data-collection opportunity.

  • Consent and preference infrastructure

    The plumbing that makes consent actually control behaviour, integrating a consent-management platform, propagating the consent signal through tags and server-side collection, honouring withdrawal, and keeping an auditable record of what was consented to and when. Done properly this is the backbone that lets everything else run compliantly; done as an afterthought it is the thing that fails an audit.

Where we help

  • Migrating measurement off third-party cookies

    A brand or agency whose attribution quietly degraded as cookies and identifiers fell away, needing measurement that will still work in a year. We move collection server-side, wire in the platform conversion APIs with consent gating, introduce modelled and incrementality-based measurement, and are explicit about the coverage gaps rather than papering over them with fabricated precision.

  • A bidder that holds its latency budget under load

    An RTB component that must answer within a tight millisecond window at high request rates without blowing the cost model. We profile the hot path, remove the synchronous calls that do not belong there, get the decisioning into memory, and design frequency and budget control that stays correct under heavy concurrency, because a correct bid that arrives after the auction closes is worth nothing.

  • Turning scattered first-party data into consented audiences

    An organisation with customer data spread across a CRM, its website, an email tool and a handful of platforms, and no compliant way to activate it. We build the identity and consent model, resolve the data into governed audiences, and create clean, auditable feeds to activation channels, so the first-party asset becomes usable without becoming a compliance problem.

  • Consent that genuinely flows through the stack

    A site or app where the banner is present but the tags fire regardless of what the user chose. We integrate the consent-management platform properly, gate every non-essential tag and server-side event on the actual consent state, honour withdrawal in real time, and keep the audit record, so consent stops being theatre and becomes the control the law requires it to be.

How we build for advertising

We start by asking what you are actually trying to measure and whether the signal to measure it still exists. A lot of adtech briefs assume a tracking capability that privacy changes have already removed. Before we design anything, we get honest about which signals are available under consent, which have gone, and what the realistic measurement approach is, because building on signals that are disappearing is building on sand.

We treat consent as an architectural constraint, not a feature at the edge. The consent signal has to reach every tag, every pixel and every server-side event, and it has to be respected at the moment each one runs. We design that flow first, so that compliant behaviour is the default path through the system rather than something layered on and easily bypassed.

On the latency-critical work, we let the numbers govern the design. RTB and ad serving live and die on the tail (the p99, not the average), so we profile relentlessly, keep the hot path free of synchronous I/O, push decisioning into memory, and watch the cost per query as closely as the latency. We are also willing to tell you when you do not need to build any of this and should be buying it instead.

We build measurement that is candid about uncertainty. A dashboard that shows a confident number the data cannot support is worse than one that shows a range and says why. We prefer modelled conversions with stated assumptions, incrementality testing where it is affordable, and clear labelling of what is measured versus estimated, because decisions made on false precision are still bad decisions.

We build for a moving platform landscape. Google, Apple, Meta and the browsers will keep changing what is possible, so we isolate those dependencies behind clean boundaries and avoid hard-coding the architecture around one vendor’s current behaviour. Because we operate what we build, we are the ones who feel it when a platform deprecates a signal, which is exactly why we design so that change is a contained update rather than a rebuild.

The regulatory landscape

Advertising technology sits squarely inside data-protection law, and the central instruments in the UK and EU are the GDPR, the ePrivacy rules and, in the UK, PECR. The practical upshot is that storing or reading information on a user’s device for non-essential purposes (the cookies and identifiers most tracking relies on), needs valid consent first. That consent has to be freely given, specific, informed and as easy to withdraw as to give, which rules out pre-ticked boxes, cookie walls in many cases, and tags that fire before the choice is made.

Consent is not a one-time banner interaction; it is a state that has to be honoured continuously. Every downstream system that processes personal data for advertising has to know the current consent state and act on it, and withdrawal has to actually stop the processing. This is where a lot of stacks fail: the banner is compliant, the plumbing behind it is not, and tags keep firing on data they no longer have permission to use.

The privacy changes driven by the platforms. Apple’s App Tracking Transparency and the retirement of the IDFA, browser restrictions on third-party cookies and fingerprinting: are not themselves law, but they interact with it. They reflect and reinforce the regulatory direction, and crucially they are enforced technically rather than negotiated. A workaround that tries to defeat them, such as fingerprinting to reconstruct an identifier, tends to be both against platform policy and legally exposed, which is why we do not build them.

Data-protection principles beyond consent apply throughout: purpose limitation, data minimisation, transparency about what is collected and why, and defined retention. Advertising data is personal data, and treating it as exhaust to be hoarded indefinitely is exactly the posture regulators are moving against. We design collection to be minimal and purposeful, with retention that can be justified rather than defended after the fact.

To be clear about our lane: we are the engineering partner, not your data-protection lawyers or your DPO. We build systems that implement consent, minimisation and retention as your privacy advisers define them, and that can be shown to behave correctly under scrutiny. The legal determination of what is lawful for your specific product, and your regulatory relationships, sit with people qualified to own them, and we will build to their requirements rather than improvise our own.

The adtech integration stack

The major advertising platforms. Google Ads and its measurement APIs, Meta’s marketing and Conversions API, and the equivalents from the other walled gardens: are where most campaigns run and most budget flows. Integrating them well means handling their authentication, their rate limits, their frequent API changes, and their server-side conversion endpoints, which are increasingly the compliant way to send measurement data with consent attached rather than relying on browser-side pixels.

The programmatic side brings DSPs, SSPs and ad exchanges, each with their own protocols, bid-request formats and latency expectations. Whether you are plugging a bidder into an exchange or pulling delivery data back out for reporting, these integrations carry the low-latency and high-volume characteristics of the ecosystem, and they have to be built to degrade gracefully rather than stall when a partner is slow or unavailable.

Customer data platforms and the wider first-party data stack are where activation increasingly starts. Integrating a CDP, a CRM, and the brand’s own site and app analytics means resolving identity on consented data, keeping provenance intact, and producing clean audience feeds outward, with the consent state travelling alongside the data rather than being lost at the first hop.

Analytics and measurement tools: from web and product analytics to server-side collection and the modelling layers on top, have to be wired in so that events are collected once, consistently, and under consent, then fanned out to the destinations that need them. Server-side tagging is often the right backbone here, because it gives you one controlled point where consent is enforced and data minimisation happens before anything leaves your boundary.

Underpinning all of it, the consent-management platform is the integration that makes the rest lawful. The CMP captures the choice; the value of it depends entirely on whether that choice actually reaches and governs every tag, pixel and server-side call downstream. We treat that propagation as core infrastructure, because a consent signal that is collected and then ignored is worse than useless. It is documented non-compliance.

Security and data protection for advertising software

The dominant risk in advertising software is not a dramatic breach so much as the quiet mishandling of personal data at scale. Adtech systems process enormous volumes of behavioural data, often about people who never knowingly interacted with you, and the first security question is therefore a data-minimisation one: are you collecting and retaining data you have no lawful basis or genuine need to hold. The cheapest data to protect is the data you never collected.

Consent enforcement is a security concern as much as a compliance one, because a system that fails to honour consent is leaking data it was not permitted to process. We treat the consent gate as a control to be tested like any other, verifying that non-essential collection genuinely does not fire without consent, that withdrawal takes effect, and that the enforcement cannot be trivially bypassed by a misconfigured tag.

The old tracking model’s fragility is itself a risk: teams under pressure to restore lost measurement are tempted toward fingerprinting, covert identifiers and other workarounds that are both against platform policy and legally exposed. We are blunt that we do not build these. They are technical debt of the worst kind. A capability that regulators and platforms are actively closing off, built on data you should not be joining in the first place.

Standard operational security applies with real force here given the data volumes: encryption in transit and at rest, least-privilege access to audience and behavioural data, tamper-evident logging of who accessed what, and disciplined key management. Retention has to be enforced by the system, not left to good intentions: advertising data that lingers indefinitely is a growing liability that a single request or audit can turn into a problem.

Because we operate what we build, the data-handling controls are not documents we hand over and forget. We live with the collection pipelines and the retention jobs, which is why we design them to minimise, to enforce consent, and to be auditable, so that when someone asks what data you hold, where it came from and on what basis, there is an honest answer ready rather than a reconstruction under pressure.

What changes

  • Measurement that survives the next platform change

    Attribution and reporting rebuilt on server-side, consented, first-party signals and honest modelling rather than the cross-site identifiers that are disappearing, so your numbers keep working through the next browser release or policy shift instead of quietly degrading.

  • Consent that actually governs the stack

    A consent signal that reaches and controls every tag, pixel and server-side event, with withdrawal honoured and an audit trail behind it. That turns compliance from a banner that hopes for the best into a control you can demonstrate when regulators or partners ask.

  • A first-party data asset you can actually use

    Scattered customer data resolved into governed, consented audiences with provenance intact and clean feeds to your activation channels, so as third-party signals fade, you are activating an asset you own rather than one you are renting from someone who keeps changing the terms.

What we build for advertising

From a first platform to modernising what you already run. The disciplines this sector draws on most.

How we deliver

  1. 01

    Discover

    We map the system, the constraints and the business it serves, including the parts nobody documented.

    Architecture brief

  2. 02

    Architect

    Decisions get made, written down and defended before a line of production code exists.

    Decision records

  3. 03

    Build

    Short cycles against working software. You see progress in the product, not in a status deck.

    Shipping increments

  4. 04

    Operate

    Monitoring, incident response and iteration. The system is alive, so the engagement is too.

    Runbooks & SLOs

Building something for advertising?

Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.

Technologies we work in

Chosen per problem, not per fashion. A selection of the stack we most often reach for.

Why teams in advertising choose us

  • Engineers who understand both the latency and the law

    Adtech punishes teams that are strong on one axis and weak on the other. Our people are senior engineers who understand tail-latency and high-throughput systems and take consent, minimisation and retention as real constraints, because a fast system that mishandles personal data is a liability, and a compliant one that misses the auction is worthless.

  • We build the model the industry is moving to

    We build privacy-compliant, first-party, consent-respecting measurement and campaign systems, not fingerprinting, not covert identifiers, not surveillance workarounds. Those are dead ends that platforms and regulators are actively closing, and we would rather build you something durable than something that fails at the next policy change.

  • Honest about what can and cannot be measured

    We will tell you plainly when a measurement approach depends on signals that are going away, when a confident dashboard number is not supported by the data, and when you should buy infrastructure rather than build it. We would rather give you a defensible range than an impressive figure that quietly stopped being true.

  • We operate what we build

    We do not ship a pipeline and walk away from it. We live with the collection, the retention jobs and the platform-API changes, which is exactly why we design for minimisation, consent enforcement and auditability from the start rather than leaving them as someone else’s problem.

Related sectors

Adjacent sectors we also know.

Common questions

Can you rebuild our attribution now that cookies and mobile IDs are going away?

Yes, and this is much of the work we do in this sector. We move measurement onto server-side collection with the platform conversion APIs, gate it on consent, and introduce modelled and incrementality-based measurement rather than a reliance on cross-site identifiers that are disappearing. We are honest that this does not perfectly reconstruct the old cookie-based precision (nothing does), so we build systems that report clearly on what is measured versus estimated, and where the gaps are, instead of showing a confident number the data no longer supports.

Will you build fingerprinting or a workaround to restore the tracking we lost?

No. Fingerprinting and covert identifier workarounds are both against the platforms’ policies and legally exposed under GDPR and PECR, and they are exactly the techniques regulators and browser vendors are actively shutting down. Building on them is technical debt with a countdown attached. We build privacy-compliant, first-party, consent-respecting measurement instead (the model the industry is moving to), because it is the only version of this that keeps working, and we would be doing you no favours by shipping something designed to fail at the next policy change.

Do we actually need to build our own RTB or ad-serving infrastructure?

Often not, and we will tell you honestly. Real-time bidding infrastructure is genuinely demanding: tight millisecond latency budgets, millions of requests a second, and a cost model that has to survive real volumes, and for many businesses the right move is to build on existing DSPs, SSPs and ad servers rather than replicate them. Where you do have a real reason to build on the bidding path, we are equipped for the tail-latency and throughput engineering it requires. But we would rather save you from building infrastructure you do not need than bill you to reinvent an exchange.

How do you make sure consent is actually respected across our stack?

We treat consent as an architectural constraint, not a banner at the edge. We integrate the consent-management platform and then propagate the consent state through every tag, pixel and server-side event so that non-essential collection genuinely does not fire without consent, withdrawal takes effect in real time, and there is an auditable record of what was consented to and when. We also test the consent gate as a control in its own right, because the common failure is a compliant-looking banner sitting on top of plumbing that fires regardless of what the user chose.

Will you handle our data-protection compliance and legal sign-off?

No, and we are deliberate about that boundary. We are engineers, not your data-protection lawyers or your DPO. We build systems that implement consent, data minimisation and retention as your privacy advisers define them, and that can be shown to behave correctly under audit. The legal determination of what is lawful for your specific product, and your relationships with regulators, sit with people qualified to own them. We will build to their requirements and flag where we think a design creates data-protection risk, but the sign-off is theirs, not ours.

Building for advertising?

Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if advertising is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.

  1. 01A senior engineer reads it. Not a form queue, and not an account manager.
  2. 02We reply either with questions or with a straight answer that we are not the right fit.
  3. 03If it looks like a fit, a technical call with the person who would actually run the delivery.
  4. 04Then scope, effort and risk in writing, before anyone signs anything.

Two fields required. We reply to real enquiries. No list, no sequence.