In our reporting, there are a few reports that will provide information as to where your player is embedded. These websites/domains listed are not only important information for your analysis but are also key pieces of information in which the player needs to accurately make advertisement requests to its configured Ad Vendors (Ad Campaigns). Without the proper location of the player's embedded website the Ad Vendors will not know where the demand request is coming from and will not be able to identify how they should fill the inventory.
Our platform offers two very common "flavors" of player embed code, known in the platform as a "player tag". These two very common tags are:
1. Standard Tag
2. Static Tag
While the core of how these tags load in the player is VERY similar there are some very important differences that can make or break how the domain/website is delivered to reporting. This will also heavily affect how the player relays its requests to your Ad Vendors. Lets look at each tag as well as separately talk about how the player parameter (player macro) of "url" affects the results of the domain/website.
The standard tag is designed for use in what the industry calls "owned and operated" websites or O&O. The reason why we say its designed for such a use case is because in an O&O scenario you are often "by hand" placing the player's tag into a web page or CMS - or - are handing the player's tag to a publishing partner for them to do so. In this scenario you know exactly where this player is going to live and in most cases know exactly the type of inventory your website or publishing partner is providing.
What about the standard tag makes it standard? There are really two key things as a "default":
1. The standard tag will dynamically fire its "player impression" tracker as a part of its "player code".
This means that the timing of the player being rendered within the web page does not necessarily fit the exact time of what an Ad Exchange or Media Exchange would consider "an impression". It is very close, but very different. Why do we do this? The main reason is that generally in an O&O use case scenario you as the owner of the player are NOT paying for impressions of your player on the publishing site. Rather a common monetization strategy is that of a revenue share from the players advertising or, in some cases, there isn't a monetization strategy. Therefore; we do not need to try and meet the definition that Ad Exchanges/Media Exchanges use as an "Impression".
2. The standard tag will dynamically figure out the domain/website it lives on.
You do not need to tell the player anything about where it exists, rather it figures it out via its "player code". This means that it will in almost every case, report the ACTUAL web page in which it was loaded in. Your reports within the platform will be accurate and the ad vendors configured to be requested by the player will also get accurate domains/websites in their ad requests as a result.
There is one key feature of the player tag which is universal to ALL player tags which is the capability to add in player parameters also known as "player macros". These "player macros" require a bit of technical understanding of how web services and systems make use of "macros" to fully understand; however, some basic knowledge can help clear up quite a bit with respect to this topic of transparency within domains.
The player macro that affects the domain/website that is being reported by the player is the "url" parameter. This parameter when placed into the player's embed code (player's tag), will override the tags use of dynamically discovering its location on a domain/website. This means even though the player can dynamically figure out where it lives, you can override where it THINKS it lives by putting in the "url" macro into the player tag.
For further details, please see How to add third party macros to the player tag.
When adding in the "url" parameter you need to be able to provide a value. This "value" is often times a dynamic "macro" in which will be recognized and replaced with a domain/website by a third party system. This process and capability usually is seen when using an Ad Exchange/Media Exchange. This means that the syntax for this macro is going to be unique to each and every Ad Exchange/Media Exchange. More will be explained here when we look at the static player tag below.
In conclusion: in most cases you will NOT be using the "url" player macro in your standard tag. If you are working with O&O inventory and or you have the ability to let the player figure everything out for you (where it lives), we recommend it. Do not use macros just for the sake of using them. Letting the player work dynamically when at all possible will make your life easier and perform better with regards to reporting and ad requests to your ad vendors.
The static tag is designed for the other very common use case in which you are placing the player tag into a Ad Exchange/Media Exchange. In these scenarios its VERY common that the Exchange will inject your player's tag into an iFrame. This is why we have designed the static tag to do two very different things (by default) than the standard tag. These two things are:
1. The static tag includes a "static" html <img> element for the player's "impression tracker".
Unlike the standard tag which dynamically fires this "impression tracker" from the player's code, the static tag separates this into a static html element. The reason being is that we design the tag to be used in he use case in which you are putting the player into an Exchange as mentioned above. These Exchanges often times have the business model in which you pay for the impressions that tally how many times your player is served/delivered. This means that you will want to get as close as possible to an accurate report of "Media Buy Impressions" in the our reporting system as to the Exchange's system. The closest "Apples to almost Apples" scenario is that as soon as our player tag is rendered on the website, the website will then render the static <img> impression tracker which will report within the system. Sequentially this is VERY close to the impression tracker that the Exchange has in their system. The closer the gap, the more accurate the results between the two systems.
2. The static tag includes two player macros: "url" and "cb" by default.
As mentioned previously, Exchanges often will place our player's tag into an iFrame, or most certainly some sort of dynamic "code". Which means you MUST make use of player macros in order to accurately assess where the player "theoretically" lives on the internet.
What is an iFrame and why does it matter with respect to "where the player lives"?
You can consider an iFrame a webpage within a webpage. Whats interesting about iFrames is that an iFrame can be a webpage that comes from one location on the internet and can be placed into a webpage which is in a completely separate location on the internet. Imagine being inside your house and you open a door located in your house and inside that door is the inside of some body else's home. A home within a home.
If you haven't figured it out already - why does that matter?
If someone wants to send a package (standard old snail mail) to your house you will need to give them your address. However, what if the house that is inside your house (the iFrame) wants to receive a package? Well, that would mean they need to use your address, not there own, because in order to get the package to the correct location - they need to delivery to your house (since their house can't be seen from the street :) ).
All "real life" analogies aside, the player's "url" macro which is included by default in the static tag forces the player to use the domain/website (home address) of the place it can be found at. Since the Exchange will most likely put your player into an iFrame that has a location (address) that is unknown to the Ad Vendors, you will want to report the correct location (address) to the ad vendor so that they can full fill the demand (advertisement) request correctly.
The "url" player macro by default in the static tag will already have a predefined value. This value is the macro syntax for the page URL in the AppNexus media exchange system. This is the most common third party system that the platform client base works with; therefore, we default to this macro syntax value. This does not mean that it cannot be override. Should you work with another system like Media Mind, Ply or Google - each system will have its own macro syntax for the domain/website. This means you need to make sure you get the proper syntax and then use the "Edit Macros" function of the player's tag to then properly assign a new "url" parameter and "value" with the Exchange's macro syntax. Per the earlier article on how to do so, when putting in the player macro "name" of "url" and giving it a "value" of "something" it will override the default value that the static uses which is AppNexus's macros.
What does the player macro "cb" do?
"cb" is important but less important with respect to the fact that it does not affect the domain transparency of where the player lives. "cb" stands for "cache buster". In a nut shell, it is a way to make sure that the results generated from the request for our player tag are unique and not cached by a user's computer or another system. Making the request unique each and every time guarantees a fresh response each and every time. Again by default we use AppNexus's cache buster macro syntax, but you can override this in the same way as the "url" player macro by using the player macro "name" of "cb" and providing the appropriate Exchange macro value.
In conclusion: when using a static tag, you must understand how to use player macros and understand the proper macros and their syntax from the exchange you plan on putting your player tag into. While this is a very common practice in the world of internet advertising today, it is still a very technical type operation. This operation can be very confusing and often people using them are not always crystal clear to where things connect and how they behave. It is HIGHLY recommend that if you need to work with "macros" that you do what you can to understand the concept / communication between systems as clearly as possible. If it makes your head spin, which for many it does, we recommend bringing in an operations or technical specialist that clearly understands the concept to set things up. This way you will not run massive amounts of traffic with unwanted results, which can end up in confusing reporting and worse - missed revenue opportunities. If you ever find your self lost and in need of help, please contact our Support as we have specialists that understand this operation very well. We rather see things work correctly from the start rather than producing missed opportunities.