Fire pixels from Impression nodes and other trackers

[vladimirpodmogilnyi]

If there is a pixel in the Impression node it's not fired at the time of impression.
I was told it was done to not trigger billing. It's confusing as almost all other main testers in the industry fire pixels by default.
I'd propose to have it maybe as a switcher on the panel (similar to “Enable audio”)

[vladimirpodmogilnyi]

Yep, it's just to properly test VAST tags via the tool and make sure that not only JS tags are fired (from VPAID or OM nodes of the VAST xml) but also image pixels.

[timdp]

@vladimirpodmogilnyi Definitely good feedback! Allow me to weigh in as the original author here. 😎

I want to start by stating that I definitely appreciate the importance of tracking, and that I think the tester should be clear about its behavior. My primary goal would be for the user to unambiguously find out which tracking events fired, and currently, I agree that that's not always clear.

The reason why I (deliberately) didn't put in the actual tracking logic (for any event, including impression) is because I put more value into the fact that the event happened than into the pixel representing that event. Put differently: my assumption has always been that you want to know that the impression event happened without having to open up your browser's development tools. (Moreover, you may not want to incur additional billing, but realistically, the effect of a single impression will usually be negligible.)

As an initial implementation, we released the tester with a logging tab that clearly tells you (among many other things) when every VAST event happened. Additionally, the VAST tab give you counts for every event. The same applies for VPAID and OMID.

Where I think things can be improved is in communicating to the user which pixels would have fired in a non-testing environment. Particularly with VAST chains that contain one or more wrappers, it's far less trivial to figure that out from the overview at the bottom of the VAST tab. Hence, I'm absolutely in favor of adding log events that log something like:

[VAST] Event "firstQuartile" triggered tracking URL: https://example.com/tracking/q1

Additionally, now that VAST 4.1 is out, we should start replacing macros as well, but that's a different story.

Where I think it could be useful to indeed also track the actual URL would be for debugging whether that URL is valid. In particular, the user may want to know whether each tracker returned an HTTP 2xx response, what the latency was, etc. All that information can be accessed by the tester rather than the browser's dev tools, so for me, that's all the more reason to discourage people from firing up the latter. However, I do think this behavior should be opt-in, although I could be convinced of the opposite. 🙂

---

P.S. @amitshetty I'm not sure how you arrived at SIVIC as the subject. Perhaps you're confusing the repositories?

[vladimirpodmogilnyi]

Hey @timdp, thanks for the detailed feedback, very useful and now I fully understand your motivation not to fire pixels.
Agree that the behavior should be opt-in, so the user can choose the preferable output option: the VAST tab with log details or the browser's dev tool calls and console.

Adding VAST events with corresponding triggered tracking URLs to the VAST tab looks very useful. And you predicted my concern - for VAST 4.1 macros (and for earlier VAST versions if macros are backported) we are interested in the pixel firing not just to get an HTTP call but to see how the player processes pixel's URLs and replace macros in it, how it looks and what values format is there.

[amitshetty]

P.S. @amitshetty I'm not sure how you arrived at SIVIC as the subject. Perhaps you're confusing the repositories?

Exactly what happened :)

[timdp]

Thanks to @MerlierR, as of 5a3a334, the tester now logs the trackers that would be fired. 🎉

We're working to further improve the experience.