Ad Tech Architecture 8 min read

The Inference Tax

The Inference Tax

My sibling People covered D/Cipher as a business — the revenue lift, Jim Lawson's hire, the money-back guarantee. All true. But the business story skips the hardest question: what does this system actually look like at the architecture level, and where does it break?

D/Cipher isn't just a targeting product. It's a real-time inference pipeline that has to score content, map intent, and return ad decisions inside the ~100ms window that programmatic advertising demands. Running LLMs in that loop is an engineering bet that most ad tech teams would reject on latency alone. People Inc is making it work — but the architecture constrains what they can do next, and any CTO building something similar should understand the tradeoffs before committing.

The Three-Layer Stack

Based on what's public — the Digiday interview with Lindsay Van Kirk, the AdExchanger reporting on D/Cipher+, and Press Gazette's overview — D/Cipher appears to be a three-layer system:

LAYER 1: CONTENT GRAPH40 brands × 100M+ pagesOffline embedding + taxonomyLAYER 2: INTENT ENGINEOpenAI LLM integration10B+ behavioral signalsLAYER 3: AD DECISIONINGReal-time bid enrichmentDSP integration + guaranteesLATENCY BUDGET: ~100ms total (content lookup 5ms + intent scoring 20-40ms + bid enrichment 30-50ms)Pre-computed embeddings keep LLM out of hot path — inference happens at index time, not bid timeON-PLATFORM (D/Cipher)Content + signals are ownedEmbedding pre-computed at publishFull behavioral graph availableLatency: well within budget ✓Signal quality: high ✓OFF-PLATFORM (D/Cipher+)Content must be crawled + classifiedEmbedding requires external fetchNo behavioral graph — lookalike onlyLatency: tight, needs edge caching ⚠Signal quality: degraded ⚠

Layer 1: The Content Graph

The foundation is a content graph built from People Inc's ~40 brands. Van Kirk described 100 million cross-taxonomy connections generated through NLP overlap analysis. This is the asset that competitors can't replicate — not the model, but the training signal.

The architecture decision here is straightforward: embed at publish time, not at query time. When an editor publishes a recipe on Allrecipes, the system generates embeddings, maps taxonomic connections to content on Food & Wine, Health, and The Spruce, and writes the result to an index. The LLM does its work offline. By the time an ad request arrives, the content is already scored.

This is the correct call. OpenAI's API latency — even for their fastest models — runs 200-500ms for a meaningful completion. You cannot put that in a bid path. The embedding pre-computation pattern removes the LLM from the hot path entirely.

Layer 2: The Intent Engine

This is where the OpenAI partnership earns its money. The 30% improvement in content connections Van Kirk cited comes from a specific capability: semantic equivalence detection across different vocabularies.

Pre-LLM, D/Cipher mapped connections through keyword and taxonomy overlap. A recipe for "chicken parmesan" might connect to other Italian recipes. Post-LLM, it connects to meal-prep content, family dinner planning on Parents.com, Italian restaurant reviews on Travel & Leisure, and health articles about protein intake on Health.com. The model understands that these are all facets of the same intent cluster, even though the vocabulary is completely different.

The engineering pattern here matters: the LLM isn't generating ad copy or making bid decisions. It's enriching a graph. Specifically, it's producing vector embeddings and semantic annotations that get stored alongside the content. The actual ad matching at request time is a vector similarity lookup — fast, deterministic, and cacheable.

"You and I could be having a conversation about the same exact topic… using entirely different words… LLMs are really, really good at helping you know that Tim and Lindsay are talking about the same thing, even though we're using different language."

— Lindsay Van Kirk, SVP D/Cipher, Digiday

The 10 billion behavioral signals per period that flow through the system complete the picture. Embeddings tell you what the content means. Behavioral signals tell you what people do after reading it. The combination — semantic context plus behavioral validation — is what lets D/Cipher make performance guarantees that cookie-based targeting can't.

Layer 3: Ad Decisioning

The final layer sits in the bid path. When a page loads and sends an ad request, the system needs to:

  1. Look up the content's pre-computed intent signals (~5ms from a local cache or edge store)
  2. Match against active campaign targeting criteria (~10-20ms)
  3. Enrich the bid request with contextual signals for DSP partners (~20-30ms)
  4. Return before the auction closes (~100ms total budget)

On owned properties, this is clean. The content graph is local. The behavioral data is first-party. The latency budget is comfortable because everything is pre-indexed.

The DSP integration is the piece People Inc has publicly acknowledged still needs work. Van Kirk told AdExchanger that "one of the things that will drive D/Cipher adoption is plugging into the pipes and the purchase path of DSPs." Translation: right now, D/Cipher signals live in a proprietary format. Getting them into the Prebid/OpenRTB ecosystem so buyers' algorithms can act on them is an integration problem, not a science problem.

The D/Cipher+ Problem

Here's where the architecture gets interesting — and strained.

D/Cipher on owned properties works because People Inc controls both sides: they own the content (and can embed it at publish time) and they own the behavioral data (and can validate intent signals against actual user journeys). D/Cipher+ tries to extend this to the open web, where they control neither.

The architectural challenge breaks into three hard problems:

ProblemOn-Platform SolutionOff-Platform Reality
Content classificationEmbedded at publish time with full CMS contextMust crawl, fetch, and classify external pages — stale by default
Behavioral validation10B+ first-party signals across user journeysNo behavioral data — lookalike modeling only
LatencyPre-computed, edge-cached, ~5ms lookupRequires pre-crawl index or real-time classification — harder to keep fresh
Signal fidelityFull intent graph with cross-brand connectionsContextual-only — no journey data to validate

The likely architecture: D/Cipher+ pre-crawls a curated set of "premium open web" publishers, classifies their content offline using the same OpenAI pipeline, and stores the results in a distributed index. At bid time, the system looks up the external page's pre-computed signals and matches them against intent patterns learned from owned properties. This is why D/Cipher+ launched as a managed service, not a self-serve platform — the crawl-and-classify pipeline needs curation to maintain quality.

The GumGum model — using AWS Outposts for sub-10ms contextual classification at the edge — shows the alternative: run classification at request time, but push the models to the edge so latency stays under budget. D/Cipher+ probably can't do this with OpenAI's API, which means they need either a fine-tuned local model or a pre-computation approach. The managed service model suggests pre-computation won.

The Inference Tax

Every call to OpenAI's API costs money and time. D/Cipher's architecture pushes that cost to index time, which is smart — you pay once per content update, not once per ad request. But this creates what I'd call the inference tax: a per-page cost to maintain the content graph that scales with the size of the crawl.

Back-of-envelope: The D/Cipher+ crawl cost

Premium open web pages to classify~10M pages
Re-classification frequencyWeekly (content changes)
Tokens per page (fetch + classify)~2,000 tokens
Cost per 1M tokens (GPT-4o-mini)~$0.15 input
Weekly inference cost~$3,000-5,000
Annual inference tax~$150K-250K

Estimates only. Actual costs depend on model choice, batching efficiency, and coverage targets. Point stands: this is a manageable line item, not a blocker.

$150-250K/year in inference costs is noise against D/Cipher's revenue contribution (performance marketing alone was $101M in Q4 2024). The inference tax is real but not prohibitive — which is why the build-your-own approach works for a publisher this size. For a smaller publisher trying to replicate this, the math changes fast.

What Jim Lawson Is Actually Building

Lawson's background at AdTheorent is the tell. AdTheorent was a DSP that built ML-powered predictive audiences — scoring every impression based on hundreds of contextual and environmental variables, without cookies. The system used real-time feature vectors (time of day, device, geo, content category, weather) to predict conversion likelihood per impression.

D/Cipher already has the content understanding layer. What Lawson brings is the ad decisioning layer — the infrastructure to score impressions in real time, manage DSP integrations at scale, and run the feedback loops that improve targeting over time. The hire signals that D/Cipher is evolving from a content classification system into a full-stack ad decisioning platform.

The trajectory: owned content graph → LLM-enriched intent engine → DSP-integrated decisioning → external publisher network. Each step adds a layer of infrastructure complexity and a new class of engineering problems.

The Build-vs-Buy Verdict

Should other publishers build their own D/Cipher? The honest answer depends on three variables:

BUILD if you have:

  • 10+ content brands with distinct audiences
  • 50%+ direct-sold ad revenue
  • Engineering team that understands ML ops
  • First-party behavioral data at scale

PARTNER if you have:

  • 3-10 brands, niche but deep
  • Category expertise worth packaging
  • Limited ML engineering capacity
  • Appetite for managed service cost

BUY if you have:

  • Single-brand publisher
  • Primarily programmatic revenue
  • No ML engineering team
  • Better ROI on content than infrastructure

People Inc sits squarely in the "build" camp: 40 brands, deep category data, and enough revenue to justify a 50-person team. Condé Nast is in similar territory — and indeed has its own contextual offering. Future plc, hemorrhaging from Google's AI Overviews with sessions down 15% in H1 2026, probably needs to buy rather than build — they can't afford the time to build a proprietary stack while their core traffic source evaporates.

What the CTO Should Watch

If you're running engineering at a publisher evaluating this approach, the critical technical decisions are:

  1. Embedding model choice. OpenAI's API is powerful but creates a vendor dependency in the inference pipeline. A fine-tuned open model (Llama, Mistral) running on your own GPUs would eliminate the dependency and reduce per-page cost — but requires ML ops capability most publishers don't have.
  2. Index architecture. The content graph needs to support sub-10ms lookups at ad-request volume. This is a vector database problem — Pinecone, Weaviate, or a tuned Elasticsearch instance with vector search. The choice depends on your team's existing expertise.
  3. DSP integration depth. Contextual signals are only valuable if buyers can act on them. That means Prebid modules, OpenRTB extensions, and direct integrations with The Trade Desk, DV360, and Amazon DSP. This is where Jim Lawson's AdTheorent experience matters most.
  4. Freshness vs. cost tradeoff. How often do you re-embed content? Daily is expensive. Weekly misses trending topics. Event-driven (re-embed on content update) is ideal but requires a content change detection pipeline.
  5. Human-in-the-loop overhead. Van Kirk noted that teams review LLM-generated connections before deployment. This is wise for quality but creates a bottleneck. Automating confidence-based routing (auto-approve high-confidence, queue low-confidence for review) is the likely next step.

The Bottom Line

D/Cipher's architecture is sound. The core insight — use LLMs to build the graph, not to serve the ads — solves the latency problem that would otherwise make LLM-powered ad tech impossible. The extension to D/Cipher+ is architecturally harder because you lose both content ownership and behavioral validation, but the managed-service model and curated publisher network are reasonable constraints that keep signal quality high enough to maintain performance guarantees.

The real question isn't whether the architecture works — it's whether the inference tax scales. As D/Cipher+ crawls more of the open web, inference costs grow linearly while the value per classified page decays (you get the premium pages first; the long tail is lower-value). There's a natural equilibrium point where the marginal page isn't worth classifying. Finding that point — and building the systems to manage it — is the engineering challenge for 2026.

Previously: The Platform Problem Behind the Rebrand · Business context: The Ad Machine (People)