<div class="bg-warning">

</div>

Only one question remained... how would we distribute it? The ad tech market has always been so competitive on revenue and profit, and there were other companies selling their proprietary solutions at a premium price. However, at AppNexus, our ultimate goal has always been to make the Internet a better place. We believe header bidding is on the right track, and the best way to help publishers is to teach them everything we learned, including the code we wrote, the challenges that early adopters have faced, and the efficient ad ops setting we were experimenting with. We also do not believe our solution can fit all, or is the best yet - publishers are smart and they know their pages the most.

And - gulp! - we sent our baby out into the world.

And the power of open source started kicking in. On GitHub, publishers started posting comments, fixing bugs, and contributing code, big chunks of code! For example, our first version of [Prebid.js](https://github.com/prebid/Prebid.js) didn't have a popular header bidding partner implemented. Within a week, we received 3 versions of it, submitted by 3 different publishers!

We also want to make [Prebid.js](https://github.com/prebid/Prebid.js) excel on mobile pages, and we have a good plan for that. For the remainder of the year, we're going to invest heavily in those efforts so that publishers can enjoy faster page load, higher viewability rate, and much more efficient header bidding integrations.

This week, we're pleased to announce the formation of

independent organization dedicated to open source tools that drive

publisher monetization.

We sat down with

[Michael Richardson](https://www.linkedin.com/in/mtrichardson/) to

answer a few questions about why

being launched as an independent entity and what it means for

publishers and vendors. Michael is a Product Line Manager at

[AppNexus](https://www.appnexus.com) and Chairman of

* TOC

{:toc}

to keep driving header bidding adoption and effectiveness.

That's why we're launching

coalition to champion open-source header bidding and its ongoing

will act as an independent voice on how publishers should interact

with programmatic, help ensure that header bidding remains fair and

transparent across all parties affiliated with Prebid, and continue to

Suffice to say, we are ready to cross over the 1.0 milestone :rocket:. A great part about us working on the Prebid 1.0 journey is that we ended up delivering many of the original ideas already, instead of waiting for the big release. So, some of these features are already inside Prebid.js today.

- Universal adunit type support for Native, Video and banner.

- Faster performance due to cutting out of additional JS libraries and simplified adapter code.

- Better support for single page applications/sites (concurrency).

- Better size mapping and responsive site support.

**If you have a Demand Adapter that works with Prebid.js - we need your help to work with Prebid 1.0!**

- Once you update your adapter to work with the base adapter in 1.0 - you will be able to integrate with more ad formats easier such as Native and Video.

- We have broken down the parts of what an adapter does into separate functions - this will make it easier to integrate and test your adapter.

Prebid 1.0 Documentation:

As always, we love PRs. Thanks for contributing.

As a publisher, you can look forward to the following improvements when adopting Prebid.js 1.0:

- Faster performance due to using fewer JS libraries and simplifying adapter code

- Module integrations that support things like:

- [*Multiple currencies*]({{site.baseurl}}/dev-docs/modules/currency.html)

- [*User syncing*]({{site.baseurl}}/dev-docs/publisher-api-reference.html#setConfig-Configure-User-Syncing)

- [*Simplified config APIs*]({{site.baseurl}}/dev-docs/publisher-api-reference.html#module_pbjs.setConfig)

- Better support for single page applications/sites (concurrency)

For more information, see:

title: Setting up Prebid.js with Smart Ad Server

head_title: Setting up Prebid.js with Smart Ad Server

description: Setting up Prebid.js with Smart Ad Server

hide: false

sidebarType: 3

Proceed as follows:

- Select the relevant **Bidder Adapter(s)**, an **Analytics Adapter** (optional) and **Module(s)** (optional).

- Download the code.

- Consult the [Bidders' Params]({{site.baseurl}}/dev-docs/bidders.html) to get help for filling the parameters.

}

},

renderer: {

render: function(bid) {

ANOutstreamVideo.renderAd({

targetId: bid.adUnitCode,

| Attribute | Type | Description | Example Value |

|-----------+------------------+--------------------------------------------------------------------+-----------------------------|

| `method` | String | Which HTTP method should be used. | `POST` |

| `data` | String or Object | Data to be sent in the POST request. Objects will be sent as JSON. | |

Here's a sample block of code returning a ServerRequest object:

| `creativeId` | Required | A bidder-specific unique code that supports tracing the ad creative back to the source. | `"123abc"` |

| `netRevenue` | Required | Boolean defining whether the bid is Net or Gross. The value `true` is Net. Bidders responding with Gross-price bids should set this to false. | `false` |

| `currency` | Required | 3-letter ISO 4217 code defining the currency of the bid. | `"EUR"` |

| `vastXml` | Either this or `vastUrl` required for video | XML for VAST document to be cached for later retrieval. | `<VAST version="3.0">...` |

| `dealId` | Optional | Deal ID | `"123abc"` |

Appnexus Adapter uses above explained approach. You can refer [here](https://github.com/prebid/Prebid.js/blob/master/modules/appnexusBidAdapter.js)

If the demand partner is going to use Prebid API for this process, their adapter will need to include the `getMappingFileInfo` function in their spec file. Prebid core will use the information returned from the function to preload the mapping file in local storage and update on the specified refresh cycle.