uBlock blocking all Marketo Forms from Mac computers

[Anonymous]

Is anyone else having this issue? The ad blocker UBlock has recently been blocking our Marketo forms (whether embedded or not). I reached out to Marketo support and they said they do not deal with 3rd party issues but this seems like a huge problem for all Marketo customers. Anyone else experiencing this problem? Or feel like testing it on their end?

We have found that PC users do not have the form blocked, just MAC users.

If you are having the same issue I encourage you to open a case with Marketo Support.

[Casey_Grimes]

So, just a note here for future reference: it seems both uBlock and Firefox's Privacy Mode are blocking resources that come from marketo.net altogether without being too picky on subdomains.

This wouldn't be a problem if not for the fact that several out-of-the-box landing page templates reference templates.marketo.net, which is caught in the desire to block Munchkin tracking. If you're still using the Marketo-hosted versions of common assets like bootstrap.css or jQuery, you need to find CDN equivalents, whether that's at cdnjs, jsDeliver, BootstrapCDN, etc.

[Ashley_Tate]

Is uBlock Origin blocking munchkin.marketo.net//munchkin.js simply because uBlock has it flagged as a tracking script or is it being blocked because it's a third party js file?

That being said, has anyone tried to call munchkin.js via a first party url, either on their website or a Marketo landing page? 

I can test on our website since I have control over the src in the function but with landing pages, Marketo plops the marketo.net version on them automatically so I'm not sure how to handle that short of having both the third party and first party (via Design Studio) on the landing page and hope for the best?

[SanfordWhiteman]

Because it's a known tracking pixel.

Trying to route around that is defying the express privacy aims of the end user. Don't do it.

[Ashley_Tate]

Wasn't trying to go around the privacy of the user--I'm a uBlock user, too.

If what pre-fills forms is the same code that tracks activity then whoever is using uBlock will just have to suffer with always seeing a full length empty form and a preference center that won't show what they're subscribed to. 😕

[SanfordWhiteman]

If what pre-fills forms is the same code that tracks activity then whoever is using uBlock will just have to suffer with always seeing a full length empty form and a preference center that won't show what they're subscribed to. 😕

That's what I would expect if I tell a site not to remember who I am.

That very surprise of "Hey, I just navigated to that site directly and it still knew me" is what a person running anti-tracking software is trying to avoid, no?

In any case, yes, pre-fill depends (among other things) on there being a tracking cookie previously associated with a named lead. That's why it works even if you haven't just clicked a Marketo link (i.e. there is no identifying information in the URL).  It is, indeed, possible to create an associated cookie without loading Munchkin at all (i.e. without tracking page views or page clicks) but this would require custom code, and I still wouldn't say for sure this isn't "tracking" the user (by definition, you're remembering that at some point they did something that was trackable, and if the idea is to remember nothing about the session, you've violated that).

[Chris_Francis]

Marketo really needs to address this issue

[SanfordWhiteman]

Yeah, but how could they, really? If the intent of a plugin is to spare the end user any interaction with services known to track leads, it stands to reason that Marketo forms qualify.

Even though I've openly encouraged the use of the CNAME, that workaround is ethically unclear. You're circumventing what might be the end user's desired behavior. Just like running Munchkin on your own hostname, it absolutely works, but it may still be violating the end user's wishes.

Granted, posting forms is not itself the same as tracking (which is absolutely true) but that doesn't mean the end user cares about the difference, y'know?

[Chris_Francis]

Marketo either needs to be proactive with the 3rd party ad blockers OR needs to be ahead of the curve in the technology realm.  Their entire business model is based on the ability to track customers and automate marketing actions accordingly.  If they can no longer track users, they are broken and done.  So they need to be offering solutions.  Not deflecting responsibility.

[Dan_Stevens_]

This is very similar to the GDPR regulation.  Being able to track, store, process and communicate with customers/prospects is going to be much more limited to what we've been accustomed to - unless we have the appropriate consent.  Will this diminish the value that marketing platforms like Marketo are able to provide.  Probably - at least in the short-term.   But over time, this will bring opportunities like improved customer satisfaction, increased loyalty, improved brand perception and increased customer engagement.  Why?  Because we're now dealing with a sub-set of the traditional audiences - specifically those that want to have a relationship with our brands.  On their own terms.  Ultimately, this could make us all better marketers.

[Chris_Francis]

I totally agree with your thoughts Dan, but Marketo needs to be the leader in this move to Utopian relationship between customers and marketers.  They can not sit back and continue to say "we don't deal with 3rd party tools"  They need to lead in the market and make sure their tools don't break when pretty clear trends in both customer preference and regulation come to fruition.  They need to proactively communicate to marketers and users of their platform that this is the risk and this is how to mitigate the risk and how to better plan and build your campaigns.  I expect Marketo to be the leaders in this space and all of the answers I have seen from them in this forum across all the discussions basically boils down to "WE PUNT".  I find that unacceptable.

[SanfordWhiteman]

So they should be able to track users who have anti-tracking plugins enabled? No.

[Chris_Francis]

No.  But Marketo can't simple say "nothing we can do".  They need to be leaders in the market not reactors.  If this means seeing the "tracking" writing on the wall, and changing tactics and best practice and changing the way their system works then they need to do that.  But to simple say well none of our forms work if customers have tracking blockers in their browsers is incredibly passive and not responsive to the needs of their customers.  I simply expect Marketo to lead.  Not pass on the issue

[Anonymous]

All of ours are still blocked - finally know why some people were complaining our site is useless

[SanfordWhiteman]

I'd try the CNAME method, as your domain is not going to be in those public databases.  Note you need to load everything from your CNAME, including forms2.js -- obvs. that has to load first for the form to load.

I don't know if these products do reverse DNS lookups or IP-based blocking.  If they do, you're going to have to route through another IP.

[Anonymous]

uBlock sent me to Easy List who got Marketo whitelisted. All our embed forms are now working when the ad blocker is turned on.

Julie

[SanfordWhiteman]

Good news! But marketo.net is still on EasyList-Privacy and mktoresp.com is still on EasyList-Tracking. I guess they realized they had misclassified, but anyone who uses those auxiliary lists is going to have problems.

[Anonymous]

Do those host forms as well? I could reach out to EasyList again to request that they whitelist those. I am very surprised that Marketo Support isn't handling this . . . maybe I should start charging them for my time.

[SanfordWhiteman]

Those are more for Munchkin, but of course there are interrelationships.

[Anonymous]

Sanford Whiteman​ WOW this may be the form issue i've been experiencing all along!!!

[SanfordWhiteman]

If Marketo's well-known domains are blocked, that's not something they can remedy.  You can switch to using all custom CNAMEs for your assets and that can help in these cases.