You may require the ability to send ad requests to Ad Manager from third-party or proprietary servers, dynamic ad stitchers or server-side insertion providers. Complete the following to send server-side ad requests to Ad Manager and accurately report on impressions, clicks, and attributed conversions.
1. Share integrations instructions with server-side technology partner
In order for Ad Manager to authenticate server-side calls from third-party servers (for example, dynamic ad insertion providers or server-side stitchers), they need to connect to Ad Manager servers using an SSL certificate that is issued by Ad Manager.
Instruct your server-side technology partner to complete the steps detailed on this page.
Campaign Manager 360 with server-side ad requests also requires the installation of an SSL certificate. Your server-side technology partner must follow the Campaign Manager 360 integration instructions if video creatives will be requested via server-side calls.
2. Generate a server-side ad tag
Publishers leveraging third-party servers to send ad requests to Ad Manager are responsible for generating a video tag in the either of the following two ways:
In the Ad Manager interface
Learn how to generate a video tag from Ad Manager
Manually construct the video ad tag URL
See the required and optional URL parameters supported on VAST video ad tags and the additional requirements for recording views, conversions, and clicks.
Server-side ad tag URLs referencing
/gampad/live/ads must use
serverside.doubleclick.net (instead of
pubads.g.doubleclick.net). You may need to manually modify your ad tag URLs to meet this requirement.
3. Generate a server-side ad request
Once the ad tag has been generated, the technology partner responsible for sending the server-side ad request to Ad Manager must:
Pass the server-side stitching source as a value of the
ssssparameter in the Ad Manager request.
Video stitching technology vendors using server-to-server integrations with Google are given this value from Google and are able to provide it to you. You can reach out to your Google account manager with any questions about the value to set to this parameter.
Dynamically pass the IP address from the client device using either the
X-Forwarded-Forheader or as a value of the
ipparameter in the Ad Manager request. Only pass the value using one of these methods, not both.
Failure to pass the client device's full IP address in one of these two methods properly may cause ad serving and delivery issues.
- Pass the the full HTTP headers from the client device/environment, including:
User-Agent: This should be the entire, unmodified string reported by the user's browser. For mobile devices, the publisher must send the user agent that the mobile platform uses for WebViews or the native mobile web browser (for example, the Mobile Safari user agent in the case of iOS).
User agent strings generated by the mobile platform's URL connection classes (for instance, "Dalvik" on Android or "CFNetwork" on iOS) are not valid.
Accept-Encoding: This should be set to
gzip,deflatefor Ad Manager to compress responses. This is requirement because uncompressed responses are 20 times larger.
The only header that should not be forwarded in the server-side ad request is the cookie header.
Additional requirements for recording views, conversions, and clicks
It is highly recommended that all views and conversions be sent from the client rather than the server. Publishers should send impressions and conversion pings from the client. In limited cases, publishers may be granted the ability to record views, conversions and clicks from the server.
If your technical setup requires you to send view, conversions and clicks from the server, you must include
ipe=ssb on initial ad requests sent from the server-side environment.
Other recommended best practices to ensure Ad Manager is able to process ad requests and conversions from server-side measured implementations:
- Send all view, conversion and click events in the order the event took place. For instance, do not send the click event before the impression event since it would not be possible for a user to click on an event before the impression is fired and the ad is rendered.
- Don't send events in batch. Instead, send events at the moment that the event is registered.
This traffic is only valid for reservation demand and will not be MRC accredited, unless otherwise specified under the conditions of a Beta agreement.