Server-side implementation guide

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.

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.

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 ssss parameter in the Ad Manager request.

  The value of the ssss parameter is case sensitive. If the publisher is given the value of examplesource, then passing ssss=examplesource is correct, while ssss=ExampleSource is not correct.
  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-For header or as a value of the ip parameter 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,deflate for Ad Manager to compress responses. This is requirement because uncompressed responses are 20 times larger.

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.