Troubleshoot Tracking – What to do when there is no traffic?

Written by

Hessel de Jong

in

,

This guide provides steps to troubleshoot tracking methods in the Burst WordPress plugin. The article does not address issues with collected data but rather the methods of tracking data.

Javascript errors on your front-end

Often, there is a javascript error on the front-end of the website. You can check this by going to your website (in private mode, so you’re not logged in as administrator). Then right click on the screen, click “inspect element”, “console”. If you see any errors here, the first thing you should check, is if you have a caching plugin enabled. If so, deactivate to check if this resolves the issue.

If that is the cause, please ensure you don’t minify or combine these two Javascript files: 

  • burst.min.js (or burst-cookieless.min.js depending on if you have enabled cookieless tracking.)
  • timeme.min.js
  • burst-goals.min.js (This file only loads when there is a goal set on the current page.)

Be aware: When you have enabled WP_DEBUG the above files become just ‘.js’ instead of .min.js’.

In most caching plugins you can add these two files to an ‘exclusion list’. We recommend checking the documentation of the plugin you are using and look for a way to exclude JS files. Most plugins will clear the cache after changing settings, but make sure to clear all caches after.

Endpoints blocked

Issues arise when both the primary and fallback tracking methods (Endpoint & REST-API) are disabled or when you receive a “Tracking error.” in the Burst Dashboard.

If there is no tracking error, but statistics are not showing up in the dashboard, there is presumably a problem on the ‘front-end’ of your website. Which is most likely caused by a plugin conflict or a caching issue.

Two main tracking methods in Burst

  • Endpoint (Primary method)
  • REST-API (Fallback method)

Burst selects a method based on your server configuration and provides a notification if there’s a problem.

While tracking with REST-API isn’t problematic and ensures your plugin works correctly, for optimal speed, we recommend using the endpoint method.

What to do in case of a complete tracking failure

If a “Tracking error” surfaces, it signifies that both the Rest API and endpoint are malfunctioning. Start troubleshooting with the endpoint and consider REST-API as a secondary solution.

Endpoint issues & solutions:

  1. Permissions issue:
    The endpoint might not have read permissions, because it is located in the Burst plugin folder.
    Solution: Adjust permission to allow Burst to read the endpoint.

    • Access your server with FTP and navigate to the folder with your WordPress installation, typically “Public HTML.”
    • Navigate to the Burst Plugin folder. “wp-content” > “plugins” > “burst-pro” (or “burst-statistics” for the free plugin)
    • Right-click “endpoint.php” and find ‘settings’ or ‘permissions’.
    • Modify permissions to a minimum of “664” or ensure ‘reading’ is enabled.
    • This should enable visitors to read the endpoint and allow their visit to be tracked.

REST-API issues & solutions:

  1. Pretty permalinks:
    If Burst indicates your permalinks aren’t configured properly, adjust them to a setting other than ‘plain’.
  2. Security plugin interference:
    Some security plugins restrict the REST-API.
    Solution: Temporarily disable your security plugin to see if REST-API works. If successful, identify and disable the specific setting in the security plugin that restricts REST-API usage.
    If this doesn’t rectify the issue, contact your hosting provider.

Cron issues

Burst uses summary tables to load data faster in the back-end. The summary tables are updated with scheduled jobs, Cron jobs. If the WordPress cron functionality is not working for some reason, the summary tables might not be updated correctly. You can check this by adding

define( ‘BURST_DONT_USE_SUMMARY_TABLE’, true );

To your wp-config.php. As of the next update (1.6.3 or higher), summary tables will only be used for high traffic sites.

Other causes: Resolving plugin conflicts with WordPress Health Check & Troubleshooting plugin

  1. Allow tracking yourself: Make sure your own IP and user role are not blocked otherwise this will not work. These settings can be found here Dashboard > Statistics > Settings > Advanced
  2. Install & activate: First, go to WordPress Plugins Repository and install the “Health Check & Troubleshooting” plugin. Activate it.
  3. Access the tool: In your WordPress dashboard, go to Tools > Site Health > Troubleshooting.
  4. Enter troubleshooting mode: Click on the “Enter Troubleshooting Mode” button. This will disable all plugins and use a default theme, but only for you as the logged-in user. Other visitors will see the site as normal.
  5. Test plugins individually:
    – First reactivate Burst Statistics or Burst Pro.
    – Reactivate each plugin one by one.
    – After each activation, check the site’s functionality to identify which plugin causes the conflict.
  6. Identify & resolve: Once the problematic plugin is identified, you can:
    – Deactivate and delete it.
    – Seek an alternative plugin.
    – Contact the plugin developer for support.
  7. Exit troubleshooting mode: Once you’ve resolved the conflict, go back to the Site Health > Troubleshooting tab and click “Exit Troubleshooting Mode”.

Conclusion

By configuring your caching plugins correctly, adjusting permissions or adjusting security settings, you can resolve most Bursts’ tracking issues. If problems persist, inspect REST-API settings and consult with your hosting provider. Remember to always keep ‘burst’ and ‘timeme’ excluded from JS cache in other plugins for smooth operation. Is your issue error still not resolved after following these steps? Open a support thread on the WordPress forums.

More posts

Frequently asked questions