The ability to look at the Web Companion and see quickly the vendor tags that were sent from the page is nice. Our QA team has to rely on the browser Net panels however, to validate the tag's parm values for each vendor. It seems if the web companion could display the tag parms sent - in addition to just the name of the tag and the Status column, that would help streamline QA and make the tool more valuable for us.
Allowing visibility to the tag parm values from the Web Companion would also help validation in Internet Explorer versions that lack a usable console/traffic inspector.
Any plans to extend the Companion like this?
Yes - we inspect the UDO from the Data tab tool also. But, I was thinking more along the lines of which specific values were passed for each of the individual vendors. So, say for the MediaMath tag, sent "OK", . . . we could then expand that and see which parms and values were sent for it e.g.
s7:Hunting & Fishing:Hunting Footwear
s9:Hunting & Fishing
. . . without having to move away from the page to a console or Network browser debugger tab, then filtering for tag names, etc. I think this would really speed up tag validation - for initial setup and for QA.
I could see how that would help for sure. I find that even using something like Charles Proxy is quicker compared to chrome or FF console validation. You don't have sift through as many images because it keeps the calls in a tree view and UI stays static as you load\re-load the pages but sometimes those apps can be buggy. Just a thought.
Good conversation so far. The idea is definitely something we have tossed around, but when we try to determine how to handle this it's a bit more complex.
For a tag such as MediaMath this solution would work well because Tealium is building the call to be made and also firing the image request.
However, tags such as Google Analytics, SiteCatalyst and Criteo have a library that handles building the call and firing the appropriate request - so Tealium is only declaring data and triggering the tag's function so their library can manage making the request. We would not be aware of the call that was made, so that is one issue we run up against.
Also, tags vary in the way that data is sent. Some vendors use the standard query string parameter ? followed by an &. Some use semicolon delimited data though there are several other designs. We would have to build into the tool the ability look at the tag level and ensure we know the expected results to parse. This is quite cumbersome and ideally not the best approach.
I am a firm user in logging tools because not only does it tell you the data sent, it also informs users with call status (404, 200, 302), response scripts (are other tags being piggybacked?), header response, and more.
Hopefully this helps, let me know if you have any follow up questions.