It is important to understand how exactly are clicks tracked in Post Affiliate Pro. There are 5 different linking methods which all track a bit differently so lets work through and explain each of them.


Standard links (redirect links)

these links look like:


and the tracking happens when the link is clicked and the request goes to click.php script. The script looks at the parameters, evaluates them and saves the click if everything is correct. When the click is saved it redirects the customer to the banner destination URL defined in the actual banner (in this example banner with ID 73d672s1) or to the Main site URL or to the Declined site URL defined in your merchant panel Configuration->Tracking Settings.

Unfortunately it might not be as easy as that since from version there is an option to hash the tracking script names so it doesn't have to necessarily be click.php but it can be a bunch of random letters and numbers instead like for example /scripts/zhkc57n4awm. However if you see 'c' letter in this bunch of letters and numbers then you can be sure that it is the click.php tracker.

One way or another this is the easiest linking type to debug since all what is needed is to add &PDebug=Y at the end of the URL and open it in your browser (debugging via this parameter has to be enabled first under Configuration->Event logging!). You would see the whole logs from saving of this click and after reading through them you should see why exactly it doesn't track, so you would call a link like this:


Possible reasons are:

- incorrect URL parameters, go to Configuration->URL parameter names and check whether a_aid and a_bid are set there for affiliate and banner IDs.

- affiliate not approved, look in Affiliates->Affiliates manager for the affiliate with ID from the link.

- campaign to which the banner belongs not Active or set as Type private or public with manual approval (Private Campaigns feature) to which the affiliate isn't invited

- fraud protection, look in Configuration->Fraud protection->Click tracking


DirectLink Tracking is quite specific so it has its own debugging article.


Mod Rewrite links

these essentially work almost the same way as redirect links do, however they rely on .htaccess file and mod_rewrite rules on your own domain which are generated by PAP based on the configuration of the links. This link type by itself is quiet complex for setting up so we would presume that people using these links know what they are doing and in such case it is enough to explain that the mod_rewrite links rely on .htaccess rules which based on the settings in PAP merchant panel Configuration->Tracking settings read the opened URL address and execute a call to click.php or its hashed counterpart with 'c' character the same way as Standard/Redirect links above do. So with this in mind you evaluate the URL which is not working, test your .htaccess whether it makes the actual request to click.php (hashed counterpart) and redirects to the destination URL and follow the steps from Standard links paragraph to find out why a click isn't saved.


New Style, Anchor, Short Anchor links

These links point directly to your website which has to be integrated with click tracking code. Besides that after the link is clicked the parameters must remain in the URL in your browser's address bar after you land on the landing page so the click tracking code can read these. Here is how these links look like:

New Style link

Anchor link

Short Anchor link

First step to debug these links/banners is to click the actual link and have Firebug in Firefox or Developer tools in a different browser enabled and to look at the Network tab. In my example I am going to click this test link:


After clicking I am interested in looking at the address bar to see whether the URL parameters like #a_aid=testaff&a_bid=40039433 are still present in the address bar after landing on the page. Sometimes websites contain various redirects which might not preserve the URL/query string parameters and in such cases the click tracking code, even if correctly added on website and executed, can't read the parameters and wouldn't know for whom it should save the click.

Second step is to look at the Network tab of your Developer Tools whether the actual call to Post Affiliate Pro's track.php script or its hashed equivalent (which would always contain 'r' letter) was made and whether its status was 200 OK.

On the screenshot above you can see 2 other Post Affiliate Pro calls being made to trackjs.js and its hashed equivalent zhkJ57n4awm which always contains 'j' charater and to pap.swf or in this case its hashed equivalent zhkJ57n4awm.swf. Call to trackjs.js simply means that the click tracking's javascript code header part was initialized and it never means that the actual tracking happened. The call to pap.swf is used to create a flash cookie in the visitor's browser and is a better sign.

However the call you are mainly interested in is to the track.php or to its hashed equivalent with the R letter so in this case to zhkr57n4awm. This means that the click tracking code attempted to save a click and create cookies.

The easiest and most reliable way to debug is to right click this call in Network tab of your Dev tools and click on Copy Location to copy the whole call with all its parameters and to open this URL in browser tab with adding &PDebug=Y parameter at its end. So in this case I would debug by opening this URL address:


Opening this URL would directly print the logs for saving of this click and you could read through them to identify the issue in saving the click object.

Third step is for those who can't make sense of the logs received by following previous steps and would cover all the possibilities why a click wouldn't be saved. This step assumes that the call to track.php or its hashed equivalent was actually made so you could see it in the Dev tools with 200 OK status.

- incorrect URL parameter names, check in Configuration->URL parameter names whether these are set the way as you see them in the link you used.

- affiliate not approved, look in Affiliates->Affiliates manager for the affiliate with ID from the link whether the affiliate is approved in the system.

- campaign to which the banner belongs is not Active or is set as Type private or public with manual approval (Private Campaigns feature) and the affiliate isn't invited/added in it. If no banner is used in the link then default campaign is selected.

- account mismatch (for Post Affiliate Network users only), the accountID defined in the click tracking code doesn't match the account under which the click should be saved, so the recognized campaign doesn't belong to the account whose click tracking code was executed.

- fraud protection, look in Configuration->Fraud protection->Click tracking

- crashed database tables (for self-hosted licenses only) - contact your server admin, hosting provider support and ask them to check your Post Affiliate database for crashed tables. A good indicator of this issue is when you get the click saved by adding the &PDebug=Y parameter but it doesn't save without it when it should be processed by the cron job. In those cases most probably one of the qu_g_visits tables is crashed.

- wrong order of query string and anchor parameters in combined links, in case you have a link in which you have both parameters introduced with ? sign (query string) and parameters introduced with # sign (anchor) then the anchor always comes last. So real life examples:

Wrong Anchor link

Correct Anchor link

Wrong New style link

Correct New style link
To conclude - Anchor and its parameters always comes last.
Debugging with Event Logging
Another option of debugging would be to use Event Logging although it is essentially the same thing as if you would use the PDebug=Y parameter. In older versions of Post Affiliate Pro PDebug=Y parameter wasn't available so this might actually be the only option for owners of older versions how to check the logs to see why a click wasn't saved.
In your merchant panel, navigate to Configuration> Event logging and turn on "Clicks" in the Debug section and save the changes. Now, make a test click and turn the debugging off. Navigate to Tools> Event logging and browse the event logs. You should be able to find a problem easily. If you are using cron job (hosted with us accounts always use cron jobs), then you might need to wait for up to 15 minutes until the click is processed and before you can see the logs.