Real-time Bidding: Mengapa Penawar Tertinggi Bisa Kalah

Real-time bidding (RTB) adalah metode penjualan impresi iklan satu per satu melalui lelang yang berjalan setiap kali peluang muncul. Pembeli menawar sebelum batas waktu khusus permintaan, dan penjual memilih pemenang yang memenuhi syarat berdasarkan aturan lelangnya sendiri.
Advertising and Paid Media Above the Line (ATL)Ad BannerAd Agency
Real-time Bidding: Mengapa Penawar Tertinggi Bisa Kalah - Arfadia

Real-time Bidding, Defined

Real-time bidding (RTB) is a method of selling advertising one impression opportunity at a time through an automated auction. Buyers bid before a deadline, and the seller picks an eligible winner under its own rules. OpenRTB is a protocol for those messages, not RTB itself.

RTB is not limited to websites. The opportunity can come from a web page, an app, a connected TV stream, or a digital out-of-home display. The OpenRTB 2.6 specification defines RTB as bidding for individual impressions in real time, and it describes an exchange as a service that runs an auction among bidders for each impression.

RTB Is Not a Synonym for Programmatic

Programmatic advertising is the wider category. It also includes negotiated deals without competitive bidding. RTB is one mode inside it. Confusing these terms hides why a negotiated deal does not compete on price.

Search advertising adds another source of confusion. Paid search also runs auctions, but a search engine marketing program buys placements against a query inside one platform's own ranking system. Do not copy auction assumptions between these channels.

RTB and OpenRTB Are Different Things

RTB is the method. OpenRTB is a standard. IAB Tech Lab's OpenRTB overview presents the protocol as a shared way for buyers and sellers to communicate, and the specification itself says its intent is to make integration easier rather than to regulate exactly how each business operates.

That distinction shapes everything below. The protocol tells you which signals can travel. It does not tell you who wins.


One Ad Opportunity, Checkpoint by Checkpoint

Follow a single opportunity and ask, at each step, what could stop a bid. One pattern repeats. Eligibility comes before price.

RTB decision checkpoints Where a bid can be stopped before the final ad call 1 Bid request Seller sends it to bidders 2 Bid before deadline Deadline is per request, network latency counts too 3 Eligibility filters Bids can be rejected here Filtered out Bid exits before auction 4 Auction selection Eligible bids compete 5 Final ad decision Publisher ad server may make the final call Winning the auction is not always the final word

The Bid Request Sets the Terms

A transaction begins when a seller, usually an ad exchange or supply-side platform, sends a bid request to bidders. Under OpenRTB only two attributes are technically required: a request ID and at least one impression object. Recommended and optional objects supply context such as the site, app, device, and regulatory signals. A request with only required fields says little about what is for sale.

A request can carry restrictions. It can list blocked advertiser categories, blocked advertiser domains, and allowed or blocked buyer seats. Each impression can carry a floor price, expressed as a CPM, plus a currency. A bidder that ignores these terms is not really competing.

The Deadline Includes the Network

The OpenRTB field tmax sets the maximum time, in milliseconds, that the exchange allows for bids to be received, and the specification says that window includes internet latency. There is no universal number. The request-specific deadline matters more than a timing figure repeated in explainers.

A late response cannot be counted on.

No-Bid Is a Valid Answer

Bidders do not have to respond with a price. OpenRTB treats an empty response as one valid way to decline. A buyer might have no matching campaign or value the opportunity below its floor. A no-bid is not automatically a failure.

Eligibility Filters Run Before Price

Bids that arrive in time still have to pass the seller's checks. A malformed response, a creative the platform has not approved, a category the publisher blocked, or a price below the floor can remove a bid before any price comparison happens.

The Auction and the Final Selection

Only then does the auction run. The OpenRTB specification says responses are evaluated under the prevailing auction rules and a winner is selected, and it leaves those rules to each exchange. OpenRTB includes a field that records whether the final sale decision belongs to the exchange or to an upstream source such as a header bidding setup or a publisher ad server.


Why the Highest Bid Can Lose

"Highest bid wins" is a handy shortcut and a poor diagnostic. These are two documented platform implementations, not campaign performance cases or evidence of commercial uplift.

Google's Bid Filtering Rules

Google's bid filtering guide for Authorized Buyers lists reasons a bid response can be filtered before it competes. They include invalid responses, disapproved creatives or landing pages, publisher exclusions such as blocked categories or vendors, and bids priced below the applicable floor. Raising a bid cannot repair a creative that failed review. These rules are authoritative for Google's platform, not a universal standard.

Microsoft's Auction Overview

Microsoft's auction overview for bidders describes a related set of conditions. The winner is the highest eligible bid with an approved creative, so approval is part of eligibility rather than a step that happens later. Microsoft describes the auction as first price, with exceptions for inventory ultimately decided by a third-party ad server. It also explains that when a publisher uses an upstream ad server, the winning bid is passed along for that server's decision, which means a win inside Microsoft's auction is not a guarantee that the ad will finally serve.

Read together, the two documents make the same point. A bid must first be allowed to compete. Price matters only after that.


First Price, Second Price, Floors, and Deals

The Auction Type Is Declared, Not Assumed

OpenRTB gives each request an auction type field. A value of 1 means first price, 2 means "second price plus," and exchanges may define their own types using values of 500 and above. The default is 2 when the field is absent. That protocol default does not establish which model an exchange runs today.

In a first price auction, the winner pays what it bid. In a second price design, the clearing price is tied to competing bids rather than the winner's own offer, and the exact formula belongs to the platform. Do not assume a universal fixed increment.

Floors Are a Gate, Not a Price

A floor is the minimum bid the seller will accept, expressed as a CPM. Clearing it does not mean winning. It only means the bid may proceed. Deals can carry floors of their own, and OpenRTB lets a deal override the request's auction type, including a setting in which the floor value is the agreed deal price.

Deals Change Who Competes

A deal ID signals that specific terms apply to a specific buyer or group of buyers. It does not prove the inventory is guaranteed. The seller's configuration decides which seats may use it.


Header Bidding, PMP, and Programmatic Guaranteed Compared

Several neighboring terms share plumbing with RTB. The differences come down to three questions: who may bid, how the price is set, and whether volume is committed.

RTB Open Auction vs Deal Types Compared

ApproachBuyer AccessPrice SettingVolume Commitment
RTB Open AuctionEligible buyers per seller rulesCompetitive auction, platform rulesNo advance agreement
Private AuctionInvited buyers onlyInvited buyers still competeNot specified
Preferred DealSpecific buyer, take or passNegotiated priceNo, non-reserved inventory
Programmatic GuaranteedReserved for one buyerNegotiated price, set in advanceYes, negotiated volume
Header BiddingSeveral demand partnersNo pricing rule of its ownNot specified
Sources: Google Ad Manager Help and Prebid.org, cited in the surrounding text.

Header Bidding

Header bidding, explained in Prebid's introduction to header bidding, is a publisher-side technique that requests bids from several demand partners before the publisher's ad server makes its final decision. In a Prebid setup, the results reach the ad server as ad server key-value pairs that describe the bid, such as its price bucket and bidder. Header bidding collects bids. It is not another name for RTB, and it does not define a pricing rule on its own.

Private Auctions and Preferred Deals

Google Ad Manager's transaction types documentation draws a useful line here. A Private Auction restricts bidding to invited buyers, but those buyers still compete with each other, so a Private Auction can still be real-time bidding. A Preferred Deal works differently. Google's Preferred Deals and Programmatic Guaranteed guide describes it as non-reserved inventory offered at a negotiated price that the buyer may take or pass, with no competitive auction involved.

Programmatic Guaranteed

Programmatic Guaranteed reserves inventory for a buyer at a negotiated price and volume. The commercial terms are agreed in advance rather than discovered through competitive bidding. Calling it RTB misreads the commercial agreement.


Winning Is Not Billing, Rendering, or Results

An auction win is one event. Billing, rendering, viewability, and business impact are separate events, and each one needs its own count.

A win is not an outcome Five separate measurement boundaries, not one funnel Auction win Proves only that a bid won Win alone does not prove: ? Billable event Defined by platform policy Timing follows each platform's billing rules ? Rendered ad Ad creative was rendered Separate from being seen ? Measured viewability Depends on measurement Not implied by a render ? Business outcome What the business wanted Needs its own evidence Check each one separately, order can vary by platform

OpenRTB Separates the Win from the Bill

The specification provides a win notice that tells a bidder it won, a separate billing notice that indicates spend should actually be applied, and a loss notice that can explain why a bid did not win. The billing notice exists because exchanges apply different billing policies, for example billing on delivery to a device or on viewability, and those policies sit outside the specification. Rendering and billing do not follow one fixed order across platforms, and no buyer should assume that every platform bills only on viewable impressions.

Keep the Measurement Bases Separate

A clean diagnosis names each event and the base it is measured against:

  • Bid participation: bids returned divided by requests received, with no-bids and timeouts reported separately.
  • Wins: wins divided by eligible bids, not by all requests.
  • Billable events: events that met the platform's billing policy, counted under that platform's own definition.
  • Rendered impressions: creatives that actually displayed, which can differ from wins.
  • Measured viewable impressions: viewable impressions divided by measurable impressions, not by all wins.

None of these ratios should be assumed to move one to one. Investigate gaps against creative delivery, upstream ad server decisions, and measurement coverage. Always state the denominator.

Incremental Results Need Their Own Test

Business outcomes sit outside the auction entirely. Attributed conversions show which conversions an attribution model credited to ads, and that is not the same as proof that the ads caused them. A controlled test with a suitable holdout can help assess incremental lift. An auction report cannot answer that question.


Privacy Signals and Supply-Chain Files Have Limits

Consent Signals Travel, They Don't Decide

OpenRTB can carry regulatory flags and consent strings, including GDPR and COPPA indicators, a US privacy string, and a GPP string. The specification is explicit that each implementer remains responsible for complying with applicable law. A signal in a bid request records what was communicated. It does not establish a lawful basis.

For the United Kingdom, the Information Commissioner's Office guidance on storage and access in online advertising says consent is required when storage or access technologies are used for advertising purposes, and it does not treat contextual advertising as automatically exempt when those technologies are involved. That guidance covers the UK only.

ads.txt, sellers.json, and SupplyChain

Three IAB Tech Lab tools address who is selling. Through ads.txt authorized seller files, publishers declare which companies may sell their inventory. Through sellers.json and the SupplyChain object, exchanges disclose the identities of their sellers and intermediaries, and the SupplyChain object lists the parties that sold or resold a specific bid request. Together they make the declared selling path checkable.

They stop there. These tools do not prove that an impression reached a human, was viewable, appeared in a brand-safe context, or was handled lawfully. A complete chain describes the declared path only, so separate checks for invalid traffic and ad fraud are still needed.


A Practical Checklist for Buyers and Publishers

For Buyers

  • Read the auction type each exchange declares instead of assuming first or second price.
  • Check the tmax values you receive and measure your own response time against them.
  • Get creatives approved before launch, since a bid with an unapproved creative may never compete.
  • Report requests, bids, eligible bids, wins, billable events, renders, and viewable impressions as separate counts.
  • Judge RTB inside a broader internet marketing plan, so auction metrics are weighed against business goals rather than read in isolation.

For Publishers

  • Keep ads.txt current and confirm that the sellers listed there match the relevant sellers.json entries.
  • Know which system makes the final decision: the exchange, a header bidding wrapper, or your ad server.
  • Reconcile billed impressions with rendered impressions using each platform's own definitions.

Real-time bidding is one way to buy display and video inventory, and many teams run it next to other paid channels. Paid placements on social platforms are covered by Arfadia social media ads work, and companies selling to other businesses can look at B2B marketing programs for how paid media fits a longer buying cycle. Organic demand also affects how paid traffic performs, which is where search engine optimization comes in. The checklist above still applies to any buying route.


Frequently Asked Questions

What is real-time bidding (RTB)?

Real-time bidding (RTB) is a method of selling individual ad impressions through an auction run as each opportunity occurs. Buyers bid before a request-specific deadline, and the seller selects an eligible winner under its own auction rules.

Is RTB the same as programmatic advertising?

No. Programmatic advertising covers all automated buying and selling, including Preferred Deals and Programmatic Guaranteed, which use negotiated prices instead of competitive bidding. RTB is the auction-based part of programmatic, which includes open auctions and private auctions.

Does the highest bid always win?

No. A bid must arrive before the deadline, pass the seller's checks on format, creative approval, publisher restrictions, floors, and deal terms, and then win under the exchange's auction rules. An upstream ad server may still decide last.

What is the difference between first price and second price auctions?

In a first price auction, the winner pays what it bid. In a second price design, the clearing price is tied to competing bids under a formula the platform defines. OpenRTB supports both and lets exchanges define their own auction types, so the reliable answer comes from each platform's documentation.

How is header bidding different from RTB?

Header bidding is a publisher-side technique that collects bids from several demand partners before the ad server makes its final decision. It gathers and passes bids, and it does not set a pricing rule of its own.

Does winning an RTB auction mean the ad was viewable?

No. Winning, billing, rendering, and viewability are separate events. A win can fail to render, a rendered ad may not be measurable, and a measurable ad may not meet a viewability threshold.


References and Related Terms


References

  1. IAB Tech Lab, OpenRTB standard overview. https://iabtechlab.com/standards/openrtb/
  2. IAB Tech Lab, OpenRTB 2.6 specification (GitHub). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md
  3. IAB Tech Lab, ads.txt (Authorized Digital Sellers) page. https://iabtechlab.com/ads-txt/
  4. IAB Tech Lab, sellers.json and SupplyChain page. https://iabtechlab.com/sellers-json/
  5. Google for Developers, Authorized Buyers bid filtering guide. https://developers.google.com/authorized-buyers/rtb/response-guide/bid-filtering
  6. Google Ad Manager Help, transaction types. https://support.google.com/admanager/answer/2805834?hl=en
  7. Google Ad Manager Help, Preferred Deals and Programmatic Guaranteed. https://support.google.com/admanager/answer/7637485?hl=en
  8. Microsoft Learn, Xandr bidders auction overview. https://learn.microsoft.com/en-us/xandr/bidders/auction-overview
  9. Prebid.org, introduction to header bidding. https://docs.prebid.org/overview/intro-to-header-bidding.html
  10. Prebid.org, ad server key values. https://docs.prebid.org/features/adServerKvps.html
  11. Information Commissioner's Office (UK), storage and access rules in online advertising. https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/how-do-the-rules-apply-to-online-advertising

Related Terms

  • Ad Exchange
  • Header Bidding
  • Ad Impression
  • Ad Fraud
We use cookies

We use cookies to enhance your browsing experience, analyze traffic, and personalize content. See our Privacy Policy for details.

Cookie Settings
PT Arfadia Digital Indonesia

We use cookies to ensure the website runs optimally and to help us understand how you use our services. You can choose which categories to allow. Read our Privacy Policy.

Necessary Cookies Always Active

Required for basic website functionality. Cannot be disabled.

Analytics Cookies

Help us understand how visitors interact with the website. Data used anonymously.

Marketing Cookies

Used to display relevant ads and measure campaign effectiveness.

Functional Cookies

Enables live chat, social media integrations, and language preferences.

Preferences saved