While the development and implementation may vary depending on the content management system (CMS), this article provides an overview of the integration process with Vistar. You must first decide on the integration type, which then determines how you will work with Vistar’s Ad Serving API. When your team feels confident with the development work, tests are conducted with Vistar’s team to certify that your integration is strong and meets quality standards.
Additionally, Vistar created an account for your organization in the ad platform. To learn more, see Use the staging environment for testing.
To get started, follow these steps for Vistar’s integration process:
Decide on which integration type best suits your organization. This dictates which documentation you need to view and how Vistar can help with your development.
Note: If you are integrating with Vistar using the agent, Ayuda HTML5, or Broadsign web redirect, you can review the respective documentation and then proceed to Step 3. Begin the testing phase with Vistar.
You can send ad requests and proof of plays (PoPs) to the ad server using the Ad Serving API during development for testing purposes. Vistar provides the required API credentials that you need in order to authenticate and make calls to the API. You can retrieve these credentials when you receive access to the ad platform (see API credentials for details).
The following describes the life cycle of a single ad request to Vistar’s ad server using our Ad Serving API:
- Ad request is sent—The CMS makes a request to the Ad Serving API. This request should be close to the time of impression, though it is not required.
- Ad response is received—The Ad Serving API responds to the CMS with one or more advertisements (also referred to as leased advertisements) for each display area requested. The asset URLs (and all other data) returned are promised to be immutable. Signage providers are free to refer to such fields as the asset URL whenever and however often they like.
Additionally, you can use the Creative Caching endpoint to request for and cache creative assets in advance.
The ad response contains an advertisement for each display area requested. Note that a valid ad request can return an empty response. This can occur when there is no qualifying ad to be returned based on your campaign targeting parameters.
Each advertisement contains aproof_of_play_urlparameter that should be fetched after the advertisement is shown. This is a unique URL and after the URL is fetched, it cannot be fetched again. This is further described in Ad Serving API. - Proof of play (PoP) is sent—When a screen displays a leased advertisement, it sends a response to the Ad Serving API, at its discretion, recording the play. If you hit the URL at a different time than the ad was played, you can append that display time to the query string (as described further in Ad Serving API). The PoP is expected to be hit within 15 minutes of the play time. The unique PoP URL is in the advertisement response.
Vistar conducts a series of three tests that take place (over a period of time specified in your statement of work) to help ensure a strong integration. These three tests are outlined in the following articles:
Note: The testing process may vary depending on your integration type with Vistar. Refer to your statement of work (SOW) or contact Vistar if you have any specific questions regarding the integration tests.
After the tests are successfully completed, your production account and network are ready to be activated by Vistar. Vistar will coordinate training with your team to walk through the ad platform.