Inventory best practices

This guide is for supply-side partners, including publishers, SSPs, and exchanges that integrate with The Trade Desk's products. The Trade Desk platform provides tools that prioritize transparency, quality ad experiences, and high-integrity auctions. Follow these best practices to maximize bid eligibility, inventory quality, and auction integrity. To troubleshoot why bids are not placed, see the No-Bid reason codes reference.

Bid request formatting

Follow these guidelines when constructing bid requests:

• Adhere to our Standard Adapter object model reference.
• Include all required fields.
• Include recommended fields for better results.
• Set as low a floor as possible. A $0 floor is acceptable.

Setting a bid floor

We recommend setting the lowest floor possible. Bids below your floor never compete, which reduces demand and limits competition in your ad server.

Here's what you need to know about bid floors when working with The Trade Desk:

• We never bid below your set floor. So, raising it may reduce the number of bids you receive.
• A higher floor doesn't induce higher bidding.

Authorized digital sellers

Supply from digital sellers is authorized through the use of IAB transparency files, such as ads.txt, app-ads.txt, and sellers.json.

The following table shows which entity is responsible for implementing each IAB transparency file.

To ensure bids are being placed on your inventory, as an authorized digital seller, follow these guidelines:

• Do not block crawler access to the sellers.json, app-ads.txt, and ads.txt files, as The Trade Desk uses a crawler to verify them.
• Format the OWNERDOMAIN variable in ads.txt and app-ads.txt as ownerdomain=xyz.com. This represents the business domain of the company that owns the site or app and resolves in a browser without any redirects.
• If programmatic sales are handled by someone other than the owner, make sure the MANAGERDOMAIN variable is used. This can be specified by country but should be noted as such in the ads.txt file.
• Select an accurate seller type from the three options in the sellers.json specification: PUBLISHER, INTERMEDIARY, or BOTH.
• Your business domain must be consistent across all exchanges in the sellers.json files.
• The inventory for a site should use only one seller ID per exchange unless the media type is different.
• Each bid request must have a complete supply chain (schain) object that terminates with the publisher. Make sure the domain in each schain node matches the domain where the sellers.json file of the respective advertising system is hosted. See also ads.txt.

Streaming TV Inventory Sharing Arrangements

When multiple parties, such as a content owner and an app developer, share streaming TV ad rights, each party must list their authorized sellers in their own app-ads.txt file.

If you are a content owner whose content streams through a developer's app:

• List the seller IDs authorized to sell your inventory in your app-ads.txt file.
• Pass your business domain in the bid request using the app.inventorypartnerdomain field for qualifying impression opportunities that represent inventory from third-party developer apps. Do not populate this field for proprietary apps.
• Request the app developer to add your inventorypartnerdomain to their app-ads.txt file.

If you are an app developer hosting a content owner's stream:

• Maintain your own app-ads.txt file listing the seller IDs authorized to sell your share of the inventory.
• Add each content owner that has an inventory share as an inventorypartnerdomain entry in your app-ads.txt file.

The following diagram shows how a content owner and app developer within a shared arrangement for streaming TV inventory must each have their own app-ads.txt file.

IMPORTANT: For inventory-sharing arrangements, the app.inventorypartnerdomain field must be populated in the bid request and match the inventory partner domain declared in the content owner's app-ads.txt file.

When validating whether a seller is authorized to sell streaming TV inventory, The Trade Desk determines which app-ads.txt file to use based on the inventory owner. The Trade Desk validates the bid request depending on whether the app.inventorypartnerdomain field is present and does not assume the app developer and inventory owner are the same.

The following table shows how The Trade Desk validates the bid request.

Supply paths

To optimize supply paths, follow these best practices:

• Prioritize the most direct supply paths.
• Limit each supply path to one directly integrated exchange.
• Generate a single transaction ID across wrappers.
• Each seller ID must represent a single integration type, such as Amazon Transparent Ad Marketplace (TAM), or Prebid. For example, a publisher can use seller_id=1 for video through TAM and seller_id=2 for display through Prebid, but cannot use the same seller ID for both TAM and Prebid display inventory.
• Be sure to avoid using intermediaries like OB and Amazon Unified Ad Marketplace.

Global Placement ID

A global placement ID (GPID) is a consistent placement identifier that helps buyers identify a given ad placement on a page across different SSPs and header bidding integrations. GPIDs apply to display, video, and native channels in web and app environments.

To create valid GPIDs, the publisher should follow these guidelines:

• Make sure GPIDs are unique, consistent in syntax, informative, and actionable.
• GPIDs must not correlate with user behaviors, including user session data, time of visit, and user ID.
• GPIDs must meet granularity thresholds that prevent repeats per page while avoiding unnecessary cardinality and granularity.
• Do not include information already in another part of the bid request. For example, don't include the domain, ad format, seller, or mobile placement type.
• When constructing the GPID, do not edit or truncate elements of the ad unit path or ad element ID.

GPID construction

Construction depends on your ad server setup. There are two options: using Google Ad Manager (GAM), or using a non-GAM ad server.

If you're using GAM, follow these guidelines:

• Make sure the GPID consists of the ad unit path.
• If using only the ad unit path results in multiple placements on the same URL, make each placement unique by doing the following:
  1. Append the ad element ID to the GPID, separated by a # character. Example: /1111/homepage#div-leftnav.
  2. If placements are still repeated due to your ad server setup, append an integer at the end, again separated by #. For example, /1111/homepage#div-leftnav#2.

If you're using a non-GAM ad server, construct the GPID by concatenating ad server inventory identifiers that can uniquely identify a position on a given URL, separated by a # character.

Ad breaks

To monetize through ad breaks, you should focus on long-form video inventory and follow the OpenRTB 2.6 spec. An example of long-form video is professionally produced content that's longer than 15 minutes.

Here's what you need to know about ad breaks:

• Ad breaks must be monetized through ad pods. For details, see Dynamic Podded Bid Request Example.
• Each ad break must have a transaction ID.
• Do not fan out requests for long-form video ad breaks.
• Only one podded bid request is allowed per ad break. Exceptions require explicit approval from The Trade Desk team.

Transaction IDs

Each transaction ID corresponds to a single ad break, and is included in an ad pod request. When providing transaction IDs for an ad break, follow these guidelines:

• Generate the transaction ID in the ad-serving system closest to the publisher, such as the publisher’s server-side ad insertion (SSAI) system or ad server, so that the same ID can be broadcast globally to all demand sources.
• Each transaction ID must correspond to one logical ad break. For example, if an ad-serving system emits a request for a dynamic ad pod that includes deals through the pmp array, and a separate request for a deal with different signal transparency at a different price point, both requests must use the same transaction ID.
• Pass the same transaction ID to all demand wrappers or mediation layers.
• If any system in the supply chain emits multiple requests that correspond to the same logical ad break per authorized seller, use the same transaction ID in all of those requests.

Long-form video impressions

Use the imp.ext.tid field to specify transaction IDs for long-form video. Per-impression transaction IDs support multiple impression opportunities within a single bid request. For field details, see Impression Extensions object.

When using the impression extension for transaction IDs, follow these guidelines:

• Do not send the source.tid request-level transaction ID for podded requests. However, if the imp array contains only one item, or if all items in the imp array correspond to one logical ad break, the source.tid transaction ID is unambiguous and acceptable as a temporary solution until you can use the imp.ext.tid field.
• Do not reuse or regenerate transaction IDs at each wrapper level as this can cause deduplication failures and inaccurate impression tracking.
• If a party receives a request without a transaction ID, generate a transaction ID before passing the request further upstream, then set the imp.ext.tidt field to indicate the transaction type. For details, see Impression Extensions object.

TIP: Where possible, intermediaries, such as SSPs and exchanges, are recommended to pass through the transaction ID received from the publisher.

Ad experience

Ad density

Follow these best practices for ad density:

• Low ad loads are used.
• Ad refreshes occur only when the ad is in view with intervals of more than 30 seconds on web, and more than 10 seconds on mobile app.
• Only one video ad unit plays on a page at a time.
• Rewarded ad placements are declared in OpenRTB 2.6 field rwdd=1.
• Total content durations for in-stream and accompanying content video ad units are longer than ad durations.

Viewability

Follow these best practices for viewability:

• The Trade Desk prefers highly viewable placements.
• Ads are lazy loaded as they enter the viewport.

Page experience

Follow these best practices for page experience:

• Ads do not obscure, replace, or modify other ads or inventory.
• Ad placement does not disrupt user navigation.

NOTE: Content signals use IAB Content Taxonomy 2.2 or later. If you want to see how version 1.0 maps to version 2.2, see IAB content taxonomy mapping: Version 1.0 to 2.2.

Identity

For secure and transparent bid requests, be sure IDs and tokens conform to these best practices:

• Include browser-specific IDs in the user.buyeruid field, issued directly by the adsrvr.org domain or generated from a matching table based on a cookie sync with adsrvr.org. You may use TDID, but do not use UID2.
• Populate the device.ifa field with the raw Identifier for Advertising (IFA) and always include the device.ext.ifa_type value to declare the identifier type according to IAB guidance.
• Enhance security and transparency by including UID tokens in your bid requests.

TIP: For more implementation guidance and examples, see Implementing UIDs in bid requests.

Recommended RTB signals

While the following signals are not required, The Trade Desk considers them valuable and is more likely to bid when they're present. They are sorted by environment and channel, from broadest to most specific.

NOTE: The Trade Desk also prioritizes user identifiers like The Trade Desk ID (TDID), UID2, device ID (DAID), IP address, and RampID.

NOTE: To learn more about DOOH, see DOOH object.

Bid feedback

IMPORTANT: Send all bid feedback, including win, billable, and loss notifications, as soon as possible after the auction. Delays in bid feedback can cause billing discrepancies and inaccurate conversion attribution.

Here are some best practices for sending bid feedback after an auction:

• Trigger both a win notification and a separate billable notification for each impression. Win notifications confirm auction outcome, while billable notifications confirm that the impression was rendered and is eligible for billing. For implementation details, see Impression win notifications.
• Add loss reasons by populating the ${AUCTION_LOSS} macro in the LURL field using the standard loss reason codes.
• Populate the ${AUCTION_MIN_TO_WIN} macro with the minimum bid to win that auction.