Running Prebid.js and Amazon TAM together

Amazon TAM (Transparent Ad Marketplace) is Amazon's server-side header bidding product. From the page's point of view it looks like a second, independent wrapper: you call apstag.fetchBids(), it returns bids, and you set them as targeting. It brings Amazon demand plus a set of SSPs that transact through Amazon.

Because it is genuinely separate from Prebid, publishers frequently want both. Done well this is free incremental competition. Done badly it doubles your ad latency.

The mistake: chaining them

The naive integration runs Prebid, waits for it to finish, then runs TAM, waits for that, then calls the ad server. Two 1,500 ms timeouts in sequence is a 3-second worst case before a single ad request leaves the browser. On mobile that is catastrophic for viewability, and it will show up in your Core Web Vitals.

The fix: one timeout, one gate

Start both at the same moment. Give them a single shared deadline. Then gate the ad server call on a small counter that fires when both have reported back, or when the deadline hits, whichever happens first.

// Both auctions start together and share one deadline.
var pending = 2;
var sent = false;

function requestAds() {
  if (sent) return;
  sent = true;
  googletag.cmd.push(function () {
    pbjs.setTargetingForGPTAsync();   // Prebid targeting
    apstag.setDisplayBids();          // TAM targeting
    googletag.pubads().refresh();
  });
}

function done() {
  if (--pending === 0) requestAds();
}

// One hard deadline for the whole auction, not one per system.
setTimeout(requestAds, TIMEOUT_MS);

pbjs.requestBids({ timeout: TIMEOUT_MS, bidsBackHandler: done });
apstag.fetchBids({ slots: slots, timeout: TIMEOUT_MS }, done);

The sent flag matters more than it looks. Without it, a bidder that answers just after the timeout fires can trigger a second ad server call, and you get duplicate requests, discrepancies against your ad server reporting, and occasionally two creatives fighting over one slot.

Ordering the targeting calls

Set both sets of targeting before the refresh, and set them on the same slots. If you call setTargetingForGPTAsync() after refresh(), the targeting arrives too late and your header bidding line items never match — the classic symptom is bids appearing in the wrapper's debug output while the ad server reports zero header bidding revenue.

How ssm.codes handles it

The v7 engine runs Prebid and TAM as parallel adapters under one unified timeout, defaulting to 1,500 ms, with the gate and the duplicate-request guard built in. The adaptive mode then tunes that single deadline to the device: shortened by up to 20% on fast connections, extended by 20% on 3G, and bidding skipped entirely on 2G or on devices reporting 1 GB of memory or less, where the auction would cost more in abandonment than it could earn.

Related questions