Skip to main content

I’m getting the following in Chrome Dev Tools Console window when loading my home page and other pages.

 

GET https://static.klaviyo.com/onsite/js/klaviyo.js?company_id=XXXXXX&shop=mystore.myshopify.com net::ERR_BLOCKED_BY_CLIENT

 

I have Klaviyo integrated with a shopify store and it seems to be working ok, but perhaps some part is not working. I’d appreciate any help to understanding and resolving this. Thanks.

Hi there @tcalabris,

Welcome to the Community and thanks for sharing your question here. First, I have omitted your company sensitive information from the API get request so please take note of that in the future.

ERR_BLOCKED_BY_CLIENT usually occurs when a request is blocked by something like the Chrome developer tools or an ad blocking plugin. Are you able to produce the issue in an incognito window? 


I look forward to hearing back from you

Alex


Hi Alex,

I appreciate your quick response. I can reproduce it every time in a regular window. However, I was not able to reproduce it in an icognito window. Dev Tools doesn’t show it. What exactly does that mean? I just want to make sure there is no issues with Klaviyo as we launch are new shopify site soon. 

Thanks,

Tom


Hi @tcalabris,

This error is commonly caused due to one of the extensions installed within Chrome. Most likely you will see this error appear if you are using an extension such as Adblock or a browser safety plugin.

For example, Adblock or browser safety extensions use a set of parameters which defines what will be blocked. In other words, they contain a list of filters which a web page's URI's are checked against upon page load. If a particular resource is requested (e.g. https://googlesyndication.com/pagead/js/adsbygoogle.js) and triggers a filter, then that resource will not be displayed to the user and will display the ERR_BLOCKED_BY_CLIENT message in the Chrome Console.

There are a few ways to debug and solve an ERR_BLOCKED_BY_CLIENT message.

  • Disable the extension. This is the simplest solution for the visitor of a website. If you choose to want to see the resources which are being block, simply disable the ad blocker extension which is generating the error.
  • Whitelist the domain. In many extensions that produce this error, you as a user can also whitelist particular domains. Therefore if you trust a domain and don't want to block any resources, this will also resolve the ERR_BLOCKED_BY_CLIENT error.
  • The best way to help avoid returning a ERR_BLOCKED_BY_CLIENT message to a visitor is to debug what resource is returning this error, and why. Certain extensions such as AdBlock Plus (in combination with Firefox), provide the ability to show which rules are blocking your resources. Once ABP is installed in Firefox, click the ABP extension icon and select Open Blockable Items. This will return a list of URLs along with the filter that triggered the block. The above example shows the filter .net/ads/ is active which triggers the associated resource to be blocked therefore returning a ERR_BLOCKED_BY_CLIENT error in Chrome. Being aware of which filters are triggering your resources to be blocked can help in the debugging process in the event that a file name contains text that triggers the filter.

There are a couple of different ways that an ERR_BLOCKED_BY_CLIENT message can be avoided. However, debugging the issue with an extension such as Ad Blocker Plus can help further determine why the resource was blocked and what can be done to help prevent future blocking if required.

 

Thanks,

Alex


Hi Alex,

I appreciate your very detailed explanation. And thanks to you, I found the culprit. I forgot that I have a DuckDuckGo extension installed, which does exactly what you are saying. It blocks tracker code, ads and popups, etc. Here’s the evidence I was looking for:

 

I really appreciate your help. 

Thanks,

Tom


Glad to hear you found the culprit @tcalabris! Hope the rest of your day goes well!

Alex


Hello!

We have also come across the above and are trying to figure out the best way to deal with it. We came across Duck Duck Go blocking embedded signup form, leaving a very nasty hole in critical landing pages.

Clearly, we cannot ask customers to disable their ad blocking, and it feels like this is an issue that is more likely to occur in the future as more and more browsers (like Safari) block ad networks and tracking by default. Also, it would also be impossible to test _all_ ad blockers to see which ones block Klaviyo.

We could use CSS to place something in the Klaviyo container (which would then be replaced if Klaviyo initialises) ...or some similar hacky placeholder until Klaviyo is loaded…

Any suggestions?

Platform: Shopify (with our in house theme).

 

 


Hello @Shell,

Our forms are very susceptible to blocking software (uBlock Origin, Adblock Duckduckgo etc) so if a customer is using any of those it's very likely they didn't get shown the pop-up, and therefore won't be counted. I know from personal experience that even with adblockers, sites do place CSS or some element as a replacement on their site that asks for visitors to disable adblockers.

If you are running into an issue or a specific example of a form not showing up to someone who doesn't have a blocking plugin or if you have someone who saw the form but the counter didn't go up then our support team could investigate. 


Hello @Shell,

Our forms are very susceptible to blocking software (uBlock Origin, Adblock Duckduckgo etc) so if a customer is using any of those it's very likely they didn't get shown the pop-up, and therefore won't be counted. I know from personal experience that even with adblockers, sites do place CSS or some element as a replacement on their site that asks for visitors to disable adblockers.

If you are running into an issue or a specific example of a form not showing up to someone who doesn't have a blocking plugin or if you have someone who saw the form but the counter didn't go up then our support team could investigate. 

As we’re embedding sign-up forms in promoted landing pages, we’ll probably need to rethink how we use Klaviyo in this context — effectively asking visitors to modify the setup of their browser for any site should be a red line (and I suspect the drop-off of visitors challenged to do this would negate any effort in that respect). An interesting one to ponder, unless there’s some server-side way of injecting these forms (Shopify apps or otherwise)? The problem is the lack of a same-domain solution.


Reply