This page explains and compares the different Tracking methods available in our Tracking add-on.
The information on this page only concerns impression tracking, not click tracking. Click tracking works similarly between all methods, except for where they are stored (locally or in Google Analytics).
Table of Contents
This page is already updated for Tracking 2.0. We are releasing this new version in stages to all users. All Access customers who don’t see the update in their WordPress-backend can download it from their account and install it manually. You can also learn more about Tracking 2.0 on this page.
Ad tracking methods in a nutshell
We believe this method to be the best choice for most users in terms of performance and accuracy.
The Frontend tracking method counts ad impressions after the frontend of your website was fully loaded. It uses a single AJAX call for all ads directly loaded in the frontend and a single call for each ad loaded with a delay like ads in an automatically refreshing ad group or a pop-up.
The Google Analytics method tracks impressions and clicks in your Google Analytics account.
Tracking ad performance in Google Analytics gives you a chance to compare the numbers with any other website analytics information gathered there as well.
Use this method if you don’t want or can’t have Tracking using your server’s performance or store any data locally in your database.
This method needs the general Google Analytics for tracking page impressions on your site. You can use it simultaneously with one of the other two onboard tracking methods
The Database tracking method (formerly called Track on load) was the default option prior to Tracking version 2.0. It counts an ad impression when the server selects the ad. This could happen long before the whole page, or even the individual ad was loaded and visible.
This method is likely to track too many impressions due to counting traffic from bots, ad blocker users, or users who quickly leave your website. On the other hand, it counts fewer impressions on cached websites that don’t use the cache-busting feature in Advanced Ads Pro.
Tracking methods compared
|You should use this …||When you don’t have a reason to switch to another method.||When you want to compare ad performance with other analytics metrics.|
If your server performance is too limited to handle Frontend tracking.
|If you are technically experienced and deliver ads where the other methods don’t work.|
This method is used automatically when needed, like when serving ads through the ad server placement.
|Data is stored||In your WordPress database.||In your Google Analytics account.||In your WordPress database.|
|Works on cached websites||Yes||Yes||Only on uncached page impressions|
|When is the ad impression tracked?||After the page was fully loaded or when an ad is delivered with a delay (e.g., pop-ups).||After the page was fully loaded or when an ad is delivered with a delay (e.g., pop-ups).||When the ad is requested from the database, which is before it is sent to the visitor’s browser.|
|Performance impact on the server||Small. We are using a custom and highly improved AJAX call.|
The tracking call will show up as a network request in your browser.
The tracking call will show up as a network request in your browser.
Which ad impressions are counted or ignored?
|Counts ad impressions on cached pages (preferred: Yes)||Yes||Yes||No. It falls back to Frontend method when cache-busting is used|
|Counts ad impressions made by ad block users (preferred: see below)||Yes if the Ad block fix option is set up||Yes, if the Ad block fix option is set up and Analytics itself is not blocked||Yes|
|Counts ad impressions by bots and crawlers (preferred: No)||No||No||Yes|
|Counts ad impressions if the user leaves the page before it was fully loaded||No||No||Yes|
|Counts ad impressions in an infinite scroll||Yes, if WordPress is used to load new posts||No||Yes, if WordPress is used to load new posts|
|Compared to Google and other analytics page impressions||Similar||Similar||Higher since tracking happens before the frontend is loaded|
|Compared to AdSense ad impressions||Similar||Similar||Higher since tracking happens before the AdSense code was sent to the browser|
Should I count ad impressions made by ad-block users?
We believe you should decide whether to count ad impressions from ad block users based on their likeliness of seeing your ads.
If you are mainly displaying ad content loaded from another server, like ad networks, you should not count their impressions from ad-block users since they won’t see them anyway.
If you are mainly displaying ad content that is hosted locally, like static image ads or custom HTML, you can track their impressions from ad-block users since they are likely to see the ads.
This section should give users with programming knowledge relevant technical information about our tracking methods. See also the debugging sections here.
In general, the Frontend and Database methods are creating custom tables:
The Frontend method sends an AJAX call to
wp-content/ajax-handler.php containing the ad IDs after the page was fully loaded. This file does not load WordPress and is therefore very fast.
The custom tracking file is updated after changes in the backend. I.e., if you make changes to your site without calling the backend, then reload WP Admin once to reflect them in the tracking file.
The tracking file contains your database information. Make sure that your server permissions prevent direct access to that file.
ADVANCED_ADS_TRACKING_LEGACY_AJAX constant in your
wp-config.php file to
true to fall back to using
wp-admin/admin-ajax.php. Setting this constant or using the Google Analytics tracking method removes the
Frontend combines as many impressions as possible into a single AJAX call. There are separate calls in cases where the impression is triggered with a delay, like automatically refreshing ad groups, pop-ups using a delay option, or when using the TCF 2.0 integration and AJAX cache-busting together. There is also an individual call when someone clicks a specific ad.
Even though the AJAX call is highly performant, some hosting companies might complain about the number of “uncached hits”. If you are charged by uncached hits, and they exceed your budget then consider switching to the Google Analytics tracking method. While we had a few users whose hosting company reached out to them due to the AJAX calls, there was no negative feedback once they measured the real impact of our improved AJAX call. If your hosting company needs more details, then please forward them to us.
This method is enabled for ads that use passive cache-busting even if the general tracking method is set to Database.
The performance of the custom AJAX call depends on two factors: a) the latency between the user’s location and your server, b) your server performance. When you enable the Tracking debug mode, the plugin will also measure the time the tracking call needs on your server. This should be far below 100ms.
Note for WP Engine customers
We saw a 301 redirect of our tracking call on AMP pages.
The following statement is what their support told us about it: The 301 should pose no issue as it appears the final request ends up being a 200. I suspect the 301 is showing here due to the security header ‘add_header Strict-Transport-Security “max-age=63072000; includeSubDomains; preload”;’ being used here, and pulling it off of the CDN just from looking into things here.
Impression tracking with Google Analytics can increase the “time-on-site” metric. These tracking events give Google Analytics more points of reference for measuring the time on site as users were scrolling through articles. This brings the data closer to reality and is therefore a rather positive side effect.