Back homeIndustry

AdTech

Budget and frequency state maintained from the impression stream itself, so the counts that decide spend are current in the engine.

The problem

Where the usual stack breaks

01
Ad serving runs on one of the tightest budgets in software: the bid path has very little time to look up audience and budget state, and it runs constantly. Frequency capping and budget pacing depend on counts that are right, and a drifting impression count is money spent wrong.
02
The standard stack caches audience and budget state in one system and counts impressions in another, reconciled after the fact. The bid path reads a snapshot that predates the current request.
03
You want per-campaign and per-user counters maintained from the impression stream itself, keyed lookups for the bid path, and attribution joins in the same engine.

Where NYXDB fits

Use-case journeys

Bid-path state

Keyed audience and budget lookups next to the counters that maintain them.

HTAP & operational analytics

Impression & frequency caps

Caps read counters that the impression stream itself keeps current.

Fraud & risk

Attribution pipelines

Join impressions to campaign data with LOOKUP JOIN, in the engine.

Observability & logs

Architecture

How NYXDB fits AdTech

Impressions land in one table; grouped transformations keep spend and frequency per campaign and user in keyed tables; an ASOF LEFT JOIN or LOOKUP JOIN attaches campaign data to each event for attribution.

01
Bid-path lookup
Audience and budget state is one keyed read away, by primary key or POSTINGS index, in UPSERT tables.
02
Count
Spend per campaign stays current, maintained by a grouped fold over the impression table.
03
Frequency cap
The count the cap reads is maintained by a fold keyed by (campaign, user).
04
Attribute
Each event is stamped with the campaign data current at processing time, by a LOOKUP JOIN transformation.

In practice

Representative query

The examples use the same two tables on every page. See the SQL reference for full syntax.

Activity per balance, kept current by a transformation

CREATE TRANSFORMATION balance_activity INTO balances ATTRIBUTE GROUP activity AS
SELECT
  chain_id,
  recipient AS address,
  token,
  COUNT(*) AS transfer_count,
  MAX(transferred_at) AS last_transfer_at,
  MAX(_index) AS activity_index
FROM transfers
GROUP BY chain_id, recipient, token;

Capabilities

What you get out of the box

Keyed lookups

Primary-key reads and POSTINGS indexes on the bid path.

Maintained counters

COUNT / SUM maintained by transformations.

Durable before ack

Each impression write is persisted before acknowledgement.

Attribution joins

Attach campaign data to each event in a transformation, with LOOKUP JOIN or ASOF LEFT JOIN.

Learn more

Tables

Keyed counters.

Transformations

Folds and joins.

Joins

LOOKUP JOIN and ASOF LEFT JOIN.

Counters that follow the impression stream

Explore HTAP & operational analytics or run a node.

Get startedRead the docs