Ad Server Trafficking in Google Ad Manager and Kevel

Most trafficking problems that reach us are taxonomy problems that were three years old before anyone noticed. One property portal we rebuilt was carrying four hundred and twelve key-values in Google Ad Manager, of which around thirty were targeted by a live line item and the rest travelled in every ad request. Cutting that set is not housekeeping. It is what makes the next twelve months of targeting decisions possible at all. Two different builds: If you are buying, the work sits in Google Ad Manager or Campaign Manager 360 as your own ad server, and the goal is a placement and creative structure that matches how you plan, so the delivery report answers a planning question instead of needing a pivot table. If you are selling, which is most of our portal and marketplace work, the split matters more. Standard display and sponsorship inventory belongs in Google Ad Manager. Sponsored listings inside your own search results do not. Those are a decision made inside your product, at your latency budget, against your own inventory data, and that is Kevel's job. We build both and we are explicit about the boundary, because pushing native listing promotion into GAM is how portals end up with a revenue product they cannot change without raising an ad ops ticket. What we set up in Google Ad Manager: An ad unit hierarchy that survives a site redesign, which means it follows page type and position rather than current navigation. Priority discipline: sponsorship at 4 reserved for what is genuinely dated and exclusive, standard between 6 and 10 doing the real work, price priority at 12 for programmatic, house at 16 filling. Competitive exclusions and roadblocks defined by category rather than by advertiser name. Frequency capping set at the line rather than the creative so it survives a creative swap. And a key-value list short enough for a new hire to read in one sitting. What we set up in Kevel: The flight and priority model, decision API integration against a latency budget agreed with your engineers, usually a p95 under eighty milliseconds including your own inventory lookup. Custom fields mirroring your listing schema so a campaign can target the same attributes your search already does. Pacing rules that fail toward under-delivery rather than toward burning a sponsor's month in four days, because the first is a conversation and the second is a refund. Verification before handover: We do not call a build finished on a screenshot. Discrepancy between your ad server and a buyer's is measured on live traffic for a fortnight, and we expect it under five percent for display. If it is not, we find out why before you invoice anyone. Every line type gets a test campaign that we run and then read ourselves. What we will not do: On-call ad operations. Same-day campaign changes. Holding the console after handover. We build the system, train the two or three people who will run it, write the runbook in your own naming conventions, and leave. If you need an operations team, hire one, and we will help you write the job description honestly. We also do not build the commercial model. What a sponsored listing should cost, how inventory is packaged and what it should yield are questions for your revenue team. We will tell you what the ad server can and cannot support, and stop there. Who this is not for: Anyone who needs the build finished this month around a live campaign calendar. A taxonomy change touches every active line item, and the safe path is a parallel build with a dated cutover. That takes longer than a rush and costs considerably less than a rollback.