Publishing third-party ad codes on your ad server may be necessary for various scenarios. For example, if you have publishers/traffic but no advertisers, utilizing ad codes from third-party ad networks can be a viable option. Fortunately, Adserver.Online simplifies this process by providing a special HTML/JS banner.
What is third-party code?
Third-party code is a fragment of Javascript and/or HTML tags (e.g., IMG, IFRAME, SCRIPT). So, it's not a complete HTML page but a small fragment.
Example of third-party code:
<iframe src="https://some-url" width="240" height="400"></iframe>
To ensure the proper functioning of the HTML/JS banner, it is crucial to avoid inserting HTML and BODY tags in the code field. The system will automatically add all necessary tags.
Clicks tracking
In most cases, it's technically impossible to count clicks over 3rd-party codes due to browser policies.
The only chance to count clicks is if the 3rd-party code supports click tracking explicitly via particular parameters.
Impressions tracking
The third-party code is a black box. There are no technical ways to determine whether it displayed an ad or not. Hence, it's impossible to count impressions that happened inside a third-party ad code.
That's why the HTML/JS banner counts an impression every time it injects third-party code into the target page. The system will count an impression even if the third-party code displays nothing.
Injection types
The logic behind HTML/JS banners is straightforward—they inject third-party code into a website's page. That's it. However, there are different ways to do that.
IFrame container
This is the default, safe, and recommended mode.
In this mode, the system creates a "Friendly" Iframe within the target webpage and injects third-party code. This ensures that the page code and the third-party code do not interfere with each other. The third-party code is contained in the iframe, preventing any potential damage to the page or vice versa.
IFrame container (strict)
This injection type works similarly to the previous one with one exception – it creates IFrame with a "sandbox" attribute. The value of the attribute is the following "allow-scripts allow-popups allow-forms".
The sandbox attribute enables extra restrictions for the content in the iframe.
You can use it when you don't trust the 3rd-party code and don't want to allow it to access your page content.
Note very old browsers may not support the sandbox feature.
Direct injection
In this mode, the system injects 3rd-party code directly (without Iframes) into the target webpage. To work in this mode correctly, 3rd-party code must support asynchronous loading.
It's not always easy to understand whether ad code supports asynchronous loading or not. The following hints may help you:
- The easiest and most reliable way is to check it from the code documentation if it's available.
- If the code contains the string "document.write", it does NOT support asynchronous loading and will NOT work in "Direct injection" mode.
- If the code contains the string "async", it will work normally.
- If the code contains only the HTML tags IFRAME, IMG, A, and no SCRIPT tags, it will work in Direct injection mode.
Direct injection (in-place)
This injection type works similarly to the previous one with one exception—it uses a different way of executing SCRIPT tags from third-party Javascript code. They are executed in the same container where a banner is located on a page, whereas the previous type executes Javascript codes into the HEAD section of the page.
This type might be useful for codes containing only a single SCRIPT tag. For example, <script src="https://example.com/tag.js"></script> and nothing else.
Also, you may try this type if no one of the others made your 3rd-party code work well.