Ghostery blocking RTP campaigns

[Michael_Sogunro]

I've avoided using any of the words included in the list on the page below, but the campaigns are still blocked when I turn Ghostery on. 

https://nation.marketo.com/docs/DOC-3510-web-personalization-rtp-can-rtp-campaigns-be-blocked-by-ad-...

What are you all using to prevent ghostery from block RTP campaigns? 

thanks in advance. 

[SanfordWhiteman]

When Ghostery (or any script blocker, including built-in tracking protection) is has Marketo in its database, it doesn't have to do with keywords. The script itself is gonna be blocked from loading.

[Michael_Sogunro]

Thanks for the reply, Sanford. Is there anythat can be done so that campaigns are not blocked? 

With forms, we've changed the domain in the javascript and they now show up when ad blockers are turned on. 

[SanfordWhiteman]

No, anything that's actually tracking to Marketo (forms are more like collateral damage and aren't tracking per se) must be blocked -- that's why people are using Ghostery and attempting to subvert that is extremely unethical.

[Hartanto_Thio]

In that case, does Marketo provide API to submit form? I don't see in the REST API documentation - https://developers.marketo.com/rest-api/endpoint-reference/endpoint-index/. 

It does provide enough API to build form (such as fields), but nothing to submit the form itself.

[SanfordWhiteman]

You shouldn't have any need to simulate a form submission using the REST API (and you create a clear DoS vulnerability if you attempt to process public forms this way, because REST API limits are microscopic and easily overwhelmed by anyone mildly curious).

You don't have to worry about Ghostery blocking form submissions. Simply use your Marketo LP domain to embed the forms: that domain will not be on blocklists.  See the recent post https://nation.marketo.com/community/product_and_support/blog/2019/03/26/make-your-form-embeds-happi....

[Hartanto_Thio]

So I tried the method you mentioned and also this method and notice weird behaviors.

This is my code setup:

<!-- JS -->

window.MktoForms2.loadForm(
    MARKETO_BASE_URL, // can use either LP domain or Marketo domain
    MARKETO_MUNCHKIN_ID,
    formId,
    function(form) {
        form.onSubmit(() => {
            console.warn('submitting form');
        });
    }
);‍‍‍‍‍‍‍‍‍‍

function onSubmit(values) {
    console.warn('on submit');
    var myForm = window.MktoForms2.allForms()[0];
    
    // Override the Marketo form values with our values
     myForm.setValues(values);

    // Submit the form
     myForm.submit();
 };‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

<!-- HTML -->

<form id={`mktoForm_${formId}`} style={{ display: 'none' }}></form>
<form onSubmit={onSubmit}>
    ...
    <button type="submit" />
</form>‍‍‍‍‍

The behavior I notice using LP domain:

• Form will not submit on Chrome non-Incognito window. The submit button on Marketo form stuck on "Please wait...". I also see both messages in console, but nothing happen after. 
• Form will submit on Chrome Incognito window just fine - page refresh after submission
• Form will render and submit on FF Private window - page refresh after submission

The behavior I notice using Marketo domain:

• Form will submit on Chrome just fine.
• Form will not submit on FF Private window just fine. Tracker blocker in private window is enabled by default.
• Form will submit on FF normal window just fine.

Any clue? I don't think I should be calling /save2 endpoint directly since that I won't be able to overcome the CORS issue.

[SanfordWhiteman]

Please highlight your code using the Advanced Editor's syntax highlighter so it's readable, and provide your URL so I can inspect the environment.

There aren't any general problems like you describe, this has to be something specific to your page.

[Hartanto_Thio]

So, I tested by pasting code over to a php file and it seems to work fine.

What I find out is that the /save2 entry point is not called -- is this something we can call directly?

[SanfordWhiteman]

What's your page?

PHP isn't relevant here, and there's never any need to call /save2 directly.