Setting up tracking for sponsored listings

Use beacons to transmit accurate interaction information and determine revenue

To report back on performance to our advertisers, it’s essential to know when a sponsored listing has been viewed and clicked and when that ad click has led to conversion—whether that conversion is on an Expedia Group rate or a rate from a different inventory source. The Lodging Sponsored Listings API uses beacons to enable this tracking and ad performance reporting.

Tracking beacons are pieces of encrypted information that allow our system to correctly capture ad interaction events, attribute your bookings to the appropriate advertiser, and process ad revenue that comes from your site.

Tracking beacon details

Tracking beacons will be generated by our delivery API and will be attached to each response in the form of a URL. Tracking beacons will have unique information associated with each sponsored listing, so they can’t be reused, and they need to be triggered at the right time.

Note: All beacons contain a placeholder for the actual position in the sort order that you'll need to populate when the beacons are triggered.

Some beacons are required for our reporting, and others are helpful for your own strategic decision-making.

Click beacons

As their name implies, click beacons trigger when the user clicks the sponsored listing. They are a crucial part of sponsored listings, as they are the mechanism used for earning you revenue.

Best practices when implementing click beacons:

• Only set them on the parts of the listing card that would lead the user to open the property details page
• Right clicks should only trigger the click beacon on non-image elements of the lodging card

Render and view beacons

At a first glance, render and view might seem like the same datapoint, but they trigger at different times. Render beacons trigger as soon as the ad is rendered on the page, but view beacons only trigger when at least 50% of the ad's pixels are visible in the browser window for a continuous 1 second.

For example, consider the following scenario:

Your website receives a list of 10 properties and includes them in the page results. As the page loads, the browser will render all 10 property cards, whether they are actually in the viewport or not. The search results layout makes only the 2 at the top of the page actually visible to the user. If all properties had beacons, all 10 render beacons would be triggered, but only 2 view beacons would be. As the user scrolls down and the rest of the property cards become visible, the remainder of the view beacons would be triggered.

Combining both view and render beacons will surface more granular data and could be used to inform decisions around sponsored listing positioning. We recommend that you implement both view and render beacons, though only view and click beacons are required to adopt the Lodging Sponsored Listings API.

Both view and render beacons use the position parameter in the URL, which should be populated with the numerical position of the sponsored listing within the overall search results. Page placement is typically numbered from 1 (the first property card at the top of the page) downward. In pagination results, positions continue sequentially across pages—numbering does not restart on each new page.

Deduplication

Tracking beacon events are deduped based on the auction ID and property ID. If no new ad request is submitted for, say, a filtered search, then no new auction ID will be generated. If the same property is displayed and clicked in both default sort and filtered search, you will only earn revenue for 1 click.

Bot detection

Unless bot traffic is detected and suppressed, fraudulent ad events such as views and clicks can be generated. Because these are not valid events and advertisers should not be charged for them, they should be identified and filtered out.

We rely on you to prevent ads from being shown to known bots and to avoid firing ad tracking events from bot activity. Unexpected attacks can generate millions of dollars in fraudulent advertising revenue, which must ultimately be refunded to the advertiser.

To avoid fraudulent traffic, we have protective logic in place that automatically rejects events when certain conditions are not met.

Bot detection security guidelines for Lodging Sponsored Listings API:

• When pushing a call, send us the customer's real IP address. Events from the same IP address will be rejected if they exceed a predefined amount within one hour.
  Note: This is the only way customer IP is used, and strict data access policies ensure that customer IP data is not misused.
• Ensure that the user-agent and origin HTTP headers are set correctly. Incorrect or missing values may result in rejection from our bot filters or cross-origin resource sharing (CORS) issues.
• Before you go live, you must provide us with a list of all domains where sponsored listings will be displayed. You can use wildcards if needed. Any events fired from unrecognized domains will be automatically rejected.