When an ad event pipeline drops events at peak, put a yearly price on the gap first. Then compare fixing it, a managed service and a rebuild against that price.
If your ad event pipeline loses impressions and clicks at peak traffic, there are three ways out. You can fix the parts that leak, move the servers that carry and store the events, often Kafka and ClickHouse, to a managed service, or rebuild the pipeline with an outside firm. The route also decides who you hire. A fix needs engineers who work inside your team, while a rebuild needs a firm that can deliver a whole pipeline and hand it over. Before choosing, put a yearly price on the gap between your attribution reports and your bidder logs. Then compare each route on cost, on the control you keep and on how soon the numbers you bill on are right again.
The short answer: first work out what the gap between your reports and your bidder logs costs you in a year. For each route, add its cost over the next twelve months to what the gap keeps costing until that route closes it, and compare only the routes that can remove the losses you actually found. A managed service also brings a bill that grows with traffic and an upgrade calendar the provider sets, and a rebuild leaves you only as much control as its contract gives you.
Read next
Most of the cost shows up in invoices, so start with them. Take one month and put three counts side by side: the impressions you billed advertisers for, the impressions each exchange billed you for, and the wins your bidder logged.
The exchange decides what you pay for. OpenRTB 2.6, the IAB Tech Lab standard that exchanges and bidders use to trade ads in real time, says the exchange sends a billing notice “when a winning bid becomes billable based on exchange-specific business policy”. Each exchange bills you by its own policy and from its own records, while your advertisers are billed from your reports. Each impression your pipeline loses was paid for and never billed. One counted twice is billed twice, and you pay it back as a credit when the advertiser's own count disagrees.
Take round numbers, not anyone's real data. A platform buys 500 million impressions a month and resells them to advertisers at $2 per thousand. If it loses 3 percent of the impression events, 15 million impressions go unbilled, which comes to $30,000 a month or $360,000 a year before duplicates and credits.
Two more costs are harder to price. One is the hours your people spend each month explaining differences to advertisers and exchanges. The other is bids set on incomplete data. Note both next to the total.
The yearly total is roughly the most a route should cost. A route that costs more than the gap it removes needs another reason, such as traffic growth the current pipeline cannot carry.
Split the gap before you price the routes. The article on reports that do not match bidder logs describes the recount, which matches each win in your bidder logs to an impression in your reports by its auction ID, the ID each exchange stamps on an auction. The recount shows how much of the gap is lost events and how much comes from the two sides counting by different rules. Different rules are fixed by agreeing on one set of rules and applying it in whatever pipeline you run. A managed service or a new pipeline does not change the counting rules.
A fix and a rebuild are paid for mostly as projects. A managed service adds a bill every month for as long as you use it.
Fixing in place costs engineering time, from your own engineers or from outside engineers working inside your team. There is no new subscription. Plan a second round of fixes, since the first busy period after the fixes often shows the next part that cannot keep up.
A managed service bills every month, and part of the bill is priced per gigabyte of events, so it follows your traffic. Your engineers still run everything outside the provider's servers. Amazon MSK Serverless is one option of AWS's managed service for Kafka, the queue that holds events between collection and the database. Its pricing page, read on 14 October 2026, lists an hourly rate for each cluster, meaning each separate installation of the service, and for each partition, a slice of the queue. It adds a fee for every gigabyte written into the queue and every gigabyte read out of it, plus a rate for storage. So every extra program that reads the same events, such as a daily recount against your bidder logs, adds to the bill.
Price the managed route at the traffic you expect in your busiest month next year, and check that traffic against the provider's limits. An MSK Serverless cluster, for one, slows down writes above 200 megabytes per second, according to its quota page read on 14 October 2026.
Most of the money for a rebuild goes on the project itself. Add the months when the old and new pipelines run side by side, and your own people's hours for reviewing and accepting the work. After the handover someone has to run the new pipeline, and the contract should name who. Ask every firm to price the same scope in writing, parallel running included, so you can set the quotes next to each other item by item.
A managed service takes part of the control away, starting with your calendar. Under the MSK version support policy, a cluster still on a Kafka version after its end-of-support date “is auto-upgraded to the recommended Kafka version”. The policy adds that “You will not receive any notification before the upgrade.” Plan your own upgrades before those dates, or accept the provider's timing. Leaving later is a migration of its own. The data is copied into systems you run elsewhere, and every program that writes or reads it is switched over.
A fix in place keeps full control of the pipeline with you. Whoever made the fixes knows how they work, so if some of them are contractors, ask for a written note on each fix before they leave.
With a rebuild, your control is whatever the contract gives you. The contract should say that the code belongs to your company and is kept in your company's accounts from the start of the work. The design documents should arrive with the code, together with runbooks, the written instructions for handling each alert. Your engineers should also start answering the new pipeline's alerts while the outside firm is still on the project.
A fix in place can be checked at the next peak, by comparing hourly counts at each step of the pipeline before and after. A move to a managed service takes longer, because data is copied, every program that writes or reads events is switched over, and both systems run side by side until their counts agree. Leaks outside the provider's servers still need fixing, for example in the collector, the program that receives events from browsers and apps. A rebuild takes longest. Both pipelines run on the same events for at least one full billing period before the reports you bill on move over, as the article on reports that do not match bidder logs explains.
Four answers decide most of the choice. The first three come from records you already keep, and the fourth may need a test.
Side by side, the three routes look like this.
To compare the routes, add up for each one its cost over the next twelve months and the monthly price of the gap times the months until that route closes it. Compare the totals only among routes that can remove the losses you actually found. A managed database will not help if events are lost before they reach it. A rebuild will not help if the gap comes from the two sides ending the day at different hours.
Often the cheapest plan mixes the three routes, in a set order. Agree on counting rules first, since they apply whatever runs underneath. Fix the leaks you can point to next. Decide about servers and design last, once a few weeks of clean hourly counts show what is left.
A rebuild does not have to mean running your own servers. A new pipeline can sit on a managed queue and a managed analytics database, and some providers also run the loader, the step that writes events from the queue into the database. ClickHouse Cloud, the hosted version of the ClickHouse database, offers ClickPipes for this. Its documentation calls ClickPipes “a managed integration platform” and lists Kafka and AWS MSK among its sources. The outside firm then builds what is specific to your platform, such as the counting rules and the daily recount against your bidder logs, plus the collector and a loader wherever no managed option fits.
Whatever route a firm proposes, its proposal should be checkable against your own data. Ask for the checks that fit the route.
amBrain builds event analytics pipelines for ad tech: collection, processing and reporting of impression and click events. In AdTech it also works on DSP development, real-time bidding platforms, and ad exchange engineering, and RTBBidder is a demand-side platform amBrain built for a client.
amBrain diagnoses slow systems in trading and ad tech: the running platform is measured end to end and the report names where the time goes.
amBrain has been building software since 2019. It works in three formats: full delivery, a dedicated team, or engineers embedded in your team. Its line on ownership is “The client keeps full ownership of the product and the code, except our reusable components.”
Nothing here describes a client's pipeline. Amazon MSK, Kafka, ClickHouse and ClickPipes are named as common examples, and amBrain does not claim to have used them or to have moved a pipeline to a managed service. The article gives no amBrain prices or timelines, and the dollar figures above are an invented example.
If you talk to amBrain, start with the yearly price of your gap and the hourly counts from your busiest day.
Bring your current architecture and the failure mode that worries you, and we will go through it together in half an hour.