This section covers all information about the Implementation of the DMP Pixels.
| Contents of the Table |
|---|
Place this exported code (Javascript) on the website. For an easy implementation it is advised to put it in a centralized <head>Pixel</head> or <body>Pixel</body> section.
An important step of the implementation is to check whether the pixel is implemented correctly and the data is being collected properly. In order to do so the DMP includes a feature to verify the DMP pixel loads in a user-friendly way and without the need for developer skills. The Pixel Activity Monitor can be enabled as an On-Site pixel module and serves as a tool to verify the DMP pixel is active on the website. It will pop-up as a floating and draggable element in your browser and shows all data events that are initiated by the implemented pixel script. This also includes interaction events like ‘Time on Page’, ‘Page Scroll’, and ‘Form Interactions’ that are originating from the default pixel modules. Please note that this module is not available by default.
A step-by-step guide on how to enable the Pixel Activity Monitor:
Note that the tool can also be used for demo purposes. An extension like Greasemonkey (Firefox) can be used to automatically run the Pixel script on a given website. |
Add the exported code to the creative in the execution platform. Most platforms support 3rd party impression tracking through one mechanism or another. Many ad servers include a user interface which lets you paste in third-party Impression tracking URLs. If the ad server doesn’t have a UI for trafficking third-party impression tracking URLs, you should still be able to include them at the creative level. Some ad servers offer creative templates that include options for third-party trackers. With other ad servers you might have to change the creative type to one that lets you enter or edit the HTML code for the creative.
The default impression tracking pixel template can be found below:
https://go.flx1.com/imp?id=12345&m=11&pl=1 |
Creative macros allow you to transmit impression-level information to systems outside of the execution platform - in this case our DMP - which you can then use for audience building purposes, reporting and/or campaign optimization. In this example, you would like to capture information about the advertising campaign and inventory you're buying and store it in our DMP.
Our DMP supports the export of both a JavaScript and an image type impression tracking pixel. The only difference that may be noticed from the export URL is the additional "t=gif" parameter. In most execution platforms you only have to add the URL of the pixel and choose between a type for the actual implementation. However, if this is not supported you need to implement the impression tracking pixel as HTML tags which can be done as follows:
Javascript Pixel Example
<script src="//go.flx1.com/imp?id=12345&m=11&pl=1"></script> |
Image Pixel Example
<img src="//go.flx1.com/imp?id=12345&m=11&pl=1" width="1" height="1" /> |
With the implementation as outlined in this entry our pixel automatically determines the correct protocol and handles the requests according to the standard(s).
Add the exported code to the creative in the execution platform. Most platforms support 3rd party click trackers and offer a feature to simply copy/paste a click tracking template as part of the user interface. In addition, most execution platforms do have a landing page URL macro available that can be set as value for the "&out" parameter to automatically redirect to the landing page that is set on another level (i.e. advertiser or campaign). If this is not supported you can either put the click tracking pixel in front of the landing page url or add it to the creative code that will be trafficked directly into your ad server.
The default click tracking pixel template can be found below:
https://go.flx1.com/click?id=12345&m=11&pl=1&cid=12345678&out= |
Creative macros allow you to transmit impression-level information to systems outside of the execution platform - in this case our DMP - which you can then use for audience building purposes, reporting and/or campaign optimization. In this example, you would like to capture information about the advertising campaign and inventory you're buying and store it in our DMP.
With the implementations as outlined in this entry our pixel automatically determines the correct protocol and handles the requests according to the standard(s).
As a developer responsible for the pixel implementation, are there any other methods to verify the pixel implementation?
Yes, Firebug or comparable tools can be used to verify the generic DMP pixel loads and the successful measurement of the enabled interaction tracking modules. It can also serve as quick check to make sure the successive segment and conversion events are implemented properly. First navigate to the website where the On-Site Pixel is active.
Tool | Method |
|---|---|
| Firebug | Validate that the pixel is loaded by looking into the Net panel and search for 'customer_id-pixel_id.js' being called from the 'c.flx1.com' domain. Tip: use the relevant pixel_id as a filter value. |
| Chrome | Validate that the pixel is loaded by looking into the Network panel of the Developer Console and search for 'customer_id-pixel_id.js' being called from the 'c.flx1.com' domain. Tip: use the relevant pixel_id as a filter value |
The parameter "devid_g" is only relevant for Android devices whether the parameter "devid_a" is only relevant for iOS devices.
The parameters "id", "m" are required and automatically generated when exporting a pixel.
The "t" parameter indicates the pixel type and can be either an image pixel (gif) or a script tag (js).
The "sitid" parameter indicates the platform and should always be "2" in case of a pixel that is implemented on a mobile app.
Cache: It is possible that third-party software caches pixel requests even though we explicitly specify not to.
Browser plugins: It is possible that clients have tools like ad-blockers installed which block our pixels, not the creatives.
Page drop off: The location and exact implementation of the pixel determines when a pixel will fire. This may differ from third-party tracking, which is placed before or after the Mapp pixels.
Users without JavaScript: In this case, not all of the Smart Pixel Functionality will be enabled on the Mapp pixels.
Illegitimate traffic: Our system has its own traffic quality filters, which exclude non-human traffic like anti-virus software and botnets.
Time zone: Our pixel gathers data in UTC time zone only.
Cross-device: For example, if you are using Google Chrome and are signed in to your account, Google will apply cross-device tracking. (https://developers.google.com/analytics/devguides/platform/user-id)
Session lifetime: Our user IDS are unique as long as the cooking remains intact. Third-party analytics tend to use custom session lifetime (e.g. 30 minutes inactivity).
Latency: The ad server tracks the impression when the auction is completed and then starts the process of displaying the creative to the user. This means that the ad server may also count impression which aren't actually seen by a user due to Javascript errors, network problems or similar issues. We track the impression form the moment that the creative has been loaded - a process which starts a few hundred milliseconds later.