Edge
- Persistent HTTP connections to each exchange
- Fast request parsing and validation
- Timeouts set below the exchange's tmax
- Load shedding when traffic spikes
Adtech and Martech Development
Adtech and martech software development
Ad tech has to answer a bid request in milliseconds and count every impression the same way your partners do, while martech has to keep customer data and consent in step across a dozen tools. Agnotic Technologies builds bidders, ad servers, publisher monetization code and marketing integrations to the published specifications.
OpenRTB 2.6ads.txt and sellers.jsonMarketing automationConsent and opt-outs
Trusted by global innovators
Ad tech and martech
What is adtech and martech software development?
Adtech and martech software development is building the systems that buy, sell and serve digital ads, and the systems that run marketing campaigns and customer data, to the industry's published specifications. Agnotic Technologies builds bidders, ad servers, publisher monetization code, campaign tools and marketing automation integrations for ad tech companies, publishers and marketing teams.
Ad tech and martech share data but solve different problems. Ad tech is about speed and agreement: answering auctions within the exchange's time limit and counting impressions the way partners will bill them. Martech is about consistency: one customer, one consent status and one set of numbers across many tools.
Audience and viewing analytics for media companies are covered on our media and entertainment analytics page. This page is about the systems that run the auction, the ad and the campaign.
Decision table
Which ad tech or martech product are you building?
The product type decides the standards, the latency budget and the hardest engineering problem. Pick the row that matches your product before anything else.
| Product type | Who runs it | What it does | Interfaces it must speak | Hardest engineering problem |
|---|---|---|---|---|
| DSP or bidder | Agencies, advertisers and buying platforms | Evaluates bid requests and bids on impressions for campaigns | OpenRTB bid request and response, win and billing notices | Answering within tmax while pacing budgets across many servers |
| SSP or ad exchange | Publishers, app developers and sell-side platforms | Runs the auction and sends bid requests to many buyers | OpenRTB, SupplyChain object, sellers.json | Fan-out to buyers, timeouts and fair, auditable auctions |
| Ad server | Publishers and advertisers | Decides which ad shows in a slot and records delivery | Tags, VAST for video, impression and click tracking | Delivery counts that match partners' numbers |
| Publisher monetization stack | Publishers and app developers | Header bidding wrapper, ad slots, floors and consent handling on the page or in the app | ads.txt, app-ads.txt, OpenRTB, consent signals | Revenue without slowing the page or app |
| Marketing automation integration | Marketing and revenue operations teams | Moves leads, events and consent between CRM, email, ads and the data warehouse | Vendor REST APIs, webhooks, bulk exports | Duplicates, sync loops and opt-outs that must reach every tool |
| Campaign and creative management | Agencies and in-house marketing teams | Plans campaigns, routes creative for approval and pushes it to ad platforms | Ad platform APIs, asset storage, approval workflows | Keeping versions, approvals and live ads in step |
Many products combine two rows, such as a publisher stack with its own ad server. We scope each row separately so each one has its own tests.
The auction
What happens in one OpenRTB auction?
Every bidder and exchange we build is tested against this sequence, including the paths where nothing wins.
The exchange builds the bid request
A request ID, one or more impressions, the site or app, device and user objects, the supply chain and the privacy signals, sent with a tmax.
The bidder decides within tmax
Targeting, budget, pacing and frequency checks run against data already in memory, because a database call at this point costs the auction.
Bid or no bid
The bidder returns a bid response with a price and markup or win notice, or an empty response with HTTP 204.
The exchange picks a winner
The winning bidder's nurl is called. A win is not yet a delivered or billable ad.
The ad renders and becomes billable
When the exchange's billing rule is met, the burl billing notice is called. This is the event finance should count.
Logs are reconciled
Bids, wins, billing notices and impressions are joined by request and bid ID, so every gap with a partner's report can be traced.
Bidder architecture
How is a bidder built to answer in time?
Four layers, each with its own latency budget and its own tests.
Decision
- Campaign and line item index held in memory
- Targeting, floors and deal checks
- Budget pacing and frequency caps
- Bid price from rules or a model
Data
- Audience segments in a low-latency store
- Consent status checked before any user data is used
- Campaign changes pushed to every server
- Supply path rules from ads.txt and sellers.json
Logging and reporting
- Every request, bid, win and billing notice streamed
- Joins on request ID and bid ID
- Spend and delivery reports per campaign
- Discrepancy reports against partner statements
Failure points
Where do ad tech and martech builds fail?
The problems we design against from the first sprint.
Challenge
The bidder answers after the exchange's tmax, so bids are silently dropped.
Agnotic approach
Latency is measured at the edge per exchange, with an internal timeout set below tmax and load tests at peak traffic.
Challenge
A campaign overspends because budget updates reach servers late.
Agnotic approach
Pacing runs on short intervals with a spend buffer, and every server reads the same budget state.
Challenge
Wins are counted as revenue, so reports never match invoices.
Agnotic approach
Reports count billing notices, not win notices, and keep both so the difference is visible.
Challenge
Inventory is bought through sellers the publisher never authorized.
Agnotic approach
Supply paths are checked against ads.txt, app-ads.txt and sellers.json files that are refreshed on a schedule.
Challenge
A contact opts out of email in one tool but keeps receiving campaigns from another.
Agnotic approach
Opt-outs are written to one consent record and pushed to every connected tool, with a check that each one applied it.
Challenge
Two marketing tools update each other in a loop and create duplicates.
Agnotic approach
Each field has one owning system, sync jobs carry a source marker, and records match on a stable key.
Martech connections
Which systems does a martech integration connect?
The systems we connect most often. Each field has one owning system, agreed before any sync is built.
Customer records
- CRM accounts, contacts and leads
- Customer data platform profiles
- Ecommerce customers and orders
Campaigns
- Marketing automation and email platforms
- Ad platforms and audience uploads
- Landing pages and forms
Consent
- Consent management platforms
- Email opt-out and preference centres
- Privacy request handling
Measurement
- Web and app analytics
- Data warehouse and BI tools
- Attribution and conversion APIs
Privacy and consent
Which privacy rules shape the build?
Your legal team decides how each rule applies. We build the signals and controls into the data flow.
01
Privacy signals in bid requests
Example: A request carries consent strings or a regulation flag in its privacy objects
Approach: The bidder reads the signal before using any user data and logs which signal each decision used.
02
Email opt-outs
Example: A contact unsubscribes from marketing email
Approach: The opt-out link works with nothing more than the email address and preferences, and the opt-out reaches every sending tool.
03
Children's audiences
Example: An app or site directed to children under 13
Approach: Requests flagged for children are excluded from audience targeting and third-party data by default.
04
Partner data terms
Example: A contract limits how an audience segment may be used or how long it is kept
Approach: Contract terms become rules in the data model: which campaigns may use a segment and when it expires.
Components we build for ad tech and martech teams
Components we design and build, from a single integration to a full product.
Bidders and DSP components
OpenRTB bidders, campaign and line item management, budget pacing and frequency capping.
Exchange and SSP components
Auction logic, buyer connections, floors and SupplyChain handling for sell-side platforms.
Ad servers and decisioning
Ad selection, delivery tracking and reporting for publishers and advertisers.
Supply path checks
Crawlers and validators for ads.txt, app-ads.txt and sellers.json files.
Marketing automation integrations
Two-way sync of leads, events and consent between CRM, email, ad platforms and your warehouse.
Campaign and creative tools
Campaign planning, creative approval workflows and publishing to ad platforms through their APIs.
Who it is for
Teams we build ad tech and martech for
Teams that need the engineering behind their ads and campaigns, not another subscription.
Ad tech companies
Bidders, exchanges and ad servers that need more engineering capacity or a performance rebuild.
Publishers and app developers
Monetization code, header bidding and supply path files kept current.
Retailers with their own ad network
Sponsored product and on-site ad placements served from the retailer's own data.
Marketing and revenue operations teams
Integrations that keep CRM, email, ad platforms and the warehouse in step.
Adtech and martech startups
First releases built to the published specifications, so partner integrations do not need rework later.
Scope and cost
What drives the cost of adtech and martech development?
We do not publish prices. These factors set the scope, which we confirm on the scoping call.
Product type
Which rows of the decision table you are building, and whether they share code.
Traffic and latency
Requests per second at peak and the time each exchange allows for a response.
Partners
How many exchanges, ad platforms or marketing tools must be connected and certified.
Reporting
Which reports must reconcile with partners and finance, and how quickly.
Consent and privacy
Which signals must be read, stored and passed on, and to which tools.
Existing code
Whether we build new, extend your platform or replace a component in place.
Engagement
From one partner connection to scale
From the product type to a component running against real partners.
1.
Scoping call
We agree the product type, the partners and the numbers that must match.
Scope2.
Specification review
We map your partners' versions of OpenRTB, VAST or each marketing API, including their extensions.
Specs3.
Fixed-scope first release
One partner connection end to end, load tested and reconciled against their reports.
Build4.
Scale and support
More partners, more traffic and on-call support, or a hand-over to your engineers.
ScaleSpecifications
Specifications we build to
The public specifications and rules behind auctions, supply paths and email consent.
OpenRTB 2.6ads.txtsellers.jsonIAB VAST16 CFR 316
Facts and sources
Which specifications shape ad tech and martech builds?
Short facts the work is designed around, each linked to its primary source.
In OpenRTB 2.6, tmax is the maximum time in milliseconds the exchange allows for bids to be received, including internet latency, and a valid call that returns no content, such as an empty bid response that signals no bid, should return HTTP 204.
Source: IAB Tech Lab, OpenRTB 2.6 specification, sections 2.1 and 3.2.1OpenRTB 2.6 defines nurl as the win notice URL the exchange calls if a bid wins, which is not necessarily a delivered, viewed or billable ad, and burl as the billing notice URL called when a winning bid becomes billable under the exchange's business policy.
Source: IAB Tech Lab, OpenRTB 2.6 specification, section 4.2.3ads.txt stands for Authorized Digital Sellers: a method publishers and distributors use to publicly declare the companies they authorize to sell their digital inventory. app-ads.txt extends it to apps distributed through mobile and connected TV app stores.
Source: IAB Tech Lab, ads.txt and app-ads.txtsellers.json lets buyers discover the entities that are direct sellers of, or intermediaries in, the selling of digital advertising, and the OpenRTB SupplyChain object lets buyers see all parties who are selling or reselling a given bid request.
Source: IAB Tech Lab, sellers.jsonUnder the CAN-SPAM Rule, a sender may not require a recipient to pay a fee, give any information other than an email address and opt-out preferences, or take any step other than replying to an email or visiting a single web page in order to opt out.
Source: 16 CFR 316.5 (eCFR)
Frequently Asked Questions
We do not publish a price. Cost follows the product type, peak traffic and latency, the number of partners, the reports that must reconcile, the consent signals involved and whether we build new or extend your platform. You get a written proposal after the scoping call.
It depends on the partners and traffic involved, so we agree a fixed first release on the scoping call. That release connects one partner end to end, so you see real auctions and reconciled numbers before more partners are added.
A self-serve DSP is usually the right start for running campaigns. Building your own bidder pays off when your bidding logic, your data or your margin is the product, and a platform's controls or fees get in the way.
Yes. We work through each platform's published APIs, webhooks and bulk exports, and we agree which system owns each field before building any sync, so the tools you already pay for stay in place.
We log every request, bid, win notice, billing notice and impression with its IDs, count billable events the way the partner does, and produce a discrepancy report that traces each gap to a cause.
Consent and opt-outs live in one record that every connected tool reads from or is updated by. Each sync checks that the target tool applied the change, and failures are alerted rather than silently retried.
Yes. A common first release is a bidder connected to one exchange with basic campaign controls, or one two-way integration between your CRM and your marketing automation platform, with reconciliation built in from the start.