Payment Events Review

This article reviews payment events and how they are being used.

In Real-Time Bidding (RTB), a "payment event" is the specific action or set of actions that lead to the advertiser being charged. This could be based on various metrics, depending on the specifics of the advertiser's campaign and the agreed-upon pricing model.

Here are a few examples of payment events:

1. Cost Per Mille (CPM): The advertiser is charged for every thousand impressions, or views, of their ad. In this case, the payment event would be the ad being displayed to a user.

2. Cost Per Click (CPC): The advertiser is charged each time a user clicks on their ad. Here, the payment event is the click.

3. Cost Per Action (CPA): The advertiser is charged when a user not only clicks on the ad, but also takes further action, such as making a purchase, signing up for a newsletter, or filling out a form. In this model, the payment event is the specific action that the user takes.

In an RTB auction, once the auction is won, the ad server sends back an ad response that includes a tracking pixel. This pixel is designed to fire when the payment event occurs, sending a signal back to the ad server to indicate that the event has taken place and the advertiser should be charged.

This "server call" or "pixel fire" indicates that the user has interacted with the ad in a meaningful way.

There are currently a few ways to track a billable event and they depend on the Media type of the response and the RTB version the advertiser and the publisher are supporting.

Pixels Types and when they are being used:

• Page Pixel -
  1. A page pixel will be fired when the advertiser script is being served to a page. It will not indicate that the script has been executed only that it has reached the page. This event can be used for troubleshooting in cases no other events have been fired. It will indicate that the script has reached a page and that could be a tech issue or any other issue that it was not executed. 
  2. When is being used -  will be sent in display activity (banner and native) in site and in-app activity.
• BURL event -
  1. In all media types and sources (site and app) OpenRTB versions 2.5 and onwards support the BURL (Billable URL) object. This BURL object is used to indicate the event of an advertiser being charged for an impression.
  2. When is being used - The BURL object will be sent in the response when the advertiser is sending it and supporting it in all media types and sources (Site and App).

• ADM Pixel -

  1. In the OpenRTB protocol, "ADM" stands for "Ad Markup". It's a field in the bid response where the actual content of the advertisement is sent if the bid is won.

     The Ad Markup could be an image, a piece of text, a video, or any other form of multimedia content. It could also be a reference to a content delivery system, or it could be a script that fetches the ad content. The exact content and format of the ADM field will depend on the specifics of the ad campaign and the inventory it's being served on.

     The ADM field is often accompanied by tracking pixels for monitoring the ad's performance. The purpose of an ADM pixel is to track certain user actions. It is embedded within the advertisement itself, and it "fires" (i.e., sends a request back to the server) when the ad is viewed or interacted with in a particular way.

  2. When is being used - The ADM pixel will be sent in a response in display activity (Banner and native), in site and In-app activity with the exception of MRAID response in In-app activity where it will be omitted and an MRAID pixel will be sent.
• MRAID Pixel -
  1. In ad tech, MRAID (Mobile Rich Media Ad Interface Definitions) is a standard created by the IAB (Interactive Advertising Bureau) for handling rich media ads in mobile applications.
     MRAID provides a set of standardized commands, which allow the ad content to perform actions like expand, resize, close, and others within the mobile application. This means that advertisers can design interactive, feature-rich ads without worrying about compatibility issues across different mobile platforms.
     In the context of an RTB (Real-Time Bidding) auction, a creative that complies with the MRAID standard might be part of the winning bid, particularly if the target inventory is in mobile applications. The ad server would then send back an ad response containing the MRAID-compliant creative.
  2. In order for an MRAID to run the incoming request of the publisher should be declared as MRAID compliant in the API attribute of the RTB request. The values of the API field indicate the specific frameworks that the ad slots support, such as VPAID (Video Player Ad Interface Definitions), MRAID (Mobile Rich Media Ad Interface Definitions), or ORMMA (Open Rich Media Mobile Advertising). These are standards used for interactive video or rich media ads.
  3. MRAID pixel is embedded in MRAID-compliant creatives to measure the performance of the ad. These pixels can track when the ad is loaded when it is viewed, when it is interacted with, and so on, allowing the advertiser to gather data about how users are responding to their ads. An impression derived from an MRAID ad will called MRAID impression.
  4. When is being used - An MRAID pixel will be sent in the ad response when the response is MRAID along with a Page pixel and BURL if supported by the protocol version. The ADM pixel will be omitted.