Ben Sibley
Forum Replies Created
-
Sounds amazing! Nice work getting these things built for yourself.
Feel free to post here if anything else comes up.
There is a way to implement this yourself. You can use the rest_url_prefix filter to change /wp-json/ to something custom. An AI tool could write you a function for this easily, and once you add it to your site, it will get around the ad blockers. Right now, they are using the full path, including /wp-json/ to recognize our tracking, so this will get around it.
We don’t do anything like this ourselves because the ad blockers will find out and then implement a new way of blocking our script. It will be a cat-and-mouse game that we can never win because there will always be a way for them to identify and block our request.
Thanks for the additional feedback. We are moving as quickly as we can.
It’s important that the IP addresses are fully obfuscated and stored in a format that they could never be returned to their original state. We get the visitor’s geolocation using their IP address first, and then save the generated ID instead of their IP address. Their location is saved in the database as well.
Hi there,
The geo database was last updated on January 19, 2026 in the plugin. It looks like the link on our site is out of date, but the library that gets used in the plugin is recent. It should have no trouble getting the correct country. City level data is more difficult and is accurate ~66% of the time. When the city is incorrect, it fetches a neighboring city. You could replace the file we use with the more accurate city level file if you want. We don’t use that because the file is much larger, and I believe the licensing might be different.
Using an Ajax request to circumvent ad blocking is an interesting idea. We will look into this to see if it could prevent ad blockers from blocking our requests. My concern is that these browser extensions have access to everything, so they will probably find a different way to block the request, like potentially checking what’s in the request before blocking it. Either way, it’s worth investigating, so thank you for bringing that to our attention!
We haven’t been able to work on the Jetpack-style chart yet. Sorry that we haven’t made progress on that. We always have a big stack of new features and updates to get through, lots of which we intend to include, but it takes time.
In regards to the web core vitals tracking, this is another feature that we just haven’t had time to explore yet. It is a big feature, so it’s something that we might consider “out of scope” for Independent Analytics, and could be better suited in a separate plugin.
Hi there,
Thanks for getting in touch about this.
When a page is loaded, Independent Analytics makes one REST API request to your site to record the view. The query that writes the view to the database only takes a few milliseconds. The 1.2 second delay is how long it’s taking for WordPress to load. Anything you can do to speed up your site, such as removing uneeded plugins will help with this.
It’s also important to note that this request is deferred until the page is fully loaded. For this reason, it does not impact the loading experience for visitors, nor does it impact your Core Web Vitals. You can still achieve a perfect 100/100 Google PageSpeed score.
Thanks for letting me know that the issue has been resolved. We will be addressing the deprecation notices in version 2.15.
If you experience any further issues, please let me know and I’ll be happy to help.
Hi there,
Thanks for getting in touch. I’m sorry to hear about this error.
We are aware of the deprecation notices and will be addressing them soon in an update. Can you search your debug log for the Fatal or E_Error that occurred? That will point directly to the source of the error that occurred when you were in the post editor.
I am not able to recreate this same error when using Independent Analytics with PHP 8.4.21, so it would be good to see the relevant error message here so we can find out what’s happening.
Thank you!
No worries! Thank you for sharing your solution with others here, and for leaving an awesome review!
If anything else comes up, feel free to post here and I’ll be happy to help.
Got it. Thanks for letting me know.
I’m not sure how the request would take that long. It is essentially just loading WP and then writing a few rows to the DB. Those DB write operations should complete in a millisecond or two, whereas loading WP might add anywhere from 300-600ms to the total request time. For it to take 90s, it seems like the site would have to be unresponsive to any requests at that time.
Hi Noelle,
I’m sorry to hear about this performance issue. I can help you get to the bottom of this.
The iawp/search request is for the REST API endpoint that Independent Analytics uses to record page views. On the request, it writes new data to the database to record the view. Writing to the DB is extremely fast, so the majority of the time this request takes is primarily waiting for WP to load.
I visited your site, and when I checked the REST API request in the waterfall, it appears to be taking a reasonable length of time: https://share.iawp.io/cRBNVns8
What kind of performance test did you run that returned a 90 second delay for the iawp/search request?
Great, I’m glad to hear that resolved the error, and thank you for sharing that link for other users with this issue.
If the site is missing the PDO extension, then that is definitely an issue. That will prevent the Analytics from working at all. You should see an error message about this when you view the Analytics menu.
With that said, it should be a quick fix via cPanel. You just need to enable the PDO extension for PHP version you’re currently using. We have a tutorial on how to do that with screenshots here: https://independentwp.com/knowledgebase/common-questions/pdo-error/
Hi there,
Thanks for using Independent Analytics.
When using the WP Crontrol plugin, you should see a line like this in the Action column:
Closure in wp-content/plugins/independent-analytics-pro/IAWP/Cron_Job.php at line 16. The “Closure” is an anonymous function that gets called.
I don’t think it should be saying, “None.” I’m going to recommend that you deactivate and then reactivate Independent Analytics, and check if that resolves the message you’re seeing in WP Crontrol. Reactivating the plugin like this won’t have any impact on your data or settings.Forum: Reviews
In reply to: [Couprix] языковые файлыYou should probably post a support thread and give the developer a chance to respond before leaving a one-star rating. It only has one other review, so this pretty much killed its chances of gaining new users.
Got it. It sounds like they are most likely blocking the tracking, but if you want to share a link to your site, I can take a quick look to make sure the tracking script is firing everywhere.