How do I validate a Flashtalking VAST tag?

Open the live servedby.flashtalking.com URL in the VAST tester, follow the chain to the inline response, and validate that XML. Flashtalking's methodology counts a video impression only after the creative has buffered and begun to play.

Why does the tag say AdSystem FT if the brand is Innovid?

Flashtalking's description of methodology says the external brand is moving to Innovid after Mediaocean's acquisition, while the measurement procedures stay in place. Live responses can still identify the ad system as FT.

Which VAST versions does Flashtalking publish?

The public sources used for this guide do not list a VAST version matrix or a wrapper-depth cap. Validate the resolved response.

Flashtalking VAST validator guide

Short answer: Flashtalking is a third-party ad server. Live tags are commonly served from servedby.flashtalking.com and name the ad system FT. Validate the resolved XML. A video impression, in Flashtalking's own methodology, is counted after the creative has buffered and started, which is a later event than the first request.

Need a Flashtalking VAST validator?

Start with the live tag URL. Resolve the chain, then validate the XML the player executes.

Test a live Flashtalking tag →Validate resolved XML →

Quick reference

Role	Third-party ad server
Common host	servedby.flashtalking.com
Ad system name	FT
Video impression	After post-buffer and video start
Public version matrix	Not published in the sources for this guide

FT on the tag, Innovid on the brand

Flashtalking's description of methodology says Mediaocean's acquisition of the Innovid ad server is a brand change: the external name is moving to Innovid, and the measurement procedures in that document stay in effect. The same note says MRC accreditation remains for the legacy Flashtalking service. A tag can therefore still carry <AdSystem>FT</AdSystem> while the company talks about itself as Innovid. Use the Innovid guide for the Innovid ad-server path, and keep validating whichever hostname the trafficker actually exported.

Request is not the impression

The methodology splits the first hit from the counted impression. After the video tag fires, Flashtalking tracks the request as ads requested, using a count-on-download method. The impression for a VAST-served video is counted once the creative has post-buffered and begun to play. They provision the player to fire an ad-rendered pixel after the player declares video start. If the publisher inhibits the impression event, or the video never starts, only the request is tracked.

That split is why a tag that parses cleanly can still miss delivery. Validate the media file and the impression URL in the resolved inline, then confirm the player fires the impression after start rather than on the initial request alone.

Click macros on the VAST tag

Yahoo's identity documentation for a Flashtalking ad server describes a VAST-specific click setup: put a custom parameter such as ft_c1 on the VAST tag, then point the click suffix at that parameter instead of leaving a ${CC} macro unsubstituted. New tag generation, in the same note, is the place to see which variables the video settings already populate. An unsubstituted click macro is a trafficking defect the validator can see in the XML even when the media file itself is fine.

Pre-flight checklist

The live Flashtalking URL resolves to inline XML.
The resolved response passes the validator.
Media and impression URLs are present and use HTTPS.
The impression is the post-start pixel, and the request pixel is not the only event.
Click suffixes do not still contain an unsubstituted custom macro.