Thank you - that is a very helpful idea!
I have this setup as described but it doesn't catch any bots at all since its been live - are there specific settings I need to make sure are setup on the form?
I just followed you as well. I'm interested in learning about how you implemented recaptcha.
Here's the client-side part: MktoForms2 :: reCAPTCHA
On the server side, of course, you need to check the verification using a webhook. Configure it like this:
It looks like I'll have to get my developers to add the JS to the page(s) where the forms live, right? Or did you include all of the java/CSS within a rich text field?
You have to add JS to the page, yeah.
where it says payload template in webhooks, it says secret=....
Is that a MKTO code or a recaptcha code?
That's the Google API key that they'll generate for you when you sign up to the service. It's specific to your use of ReCAPTCHA.
Found this thread about implementing Google's reCaptcha to Marketo forms (via https://nation.marketo.com/message/132824#comment-132824) and have some quick questions:
1) When do you call the webhook that talks with Google reCaptcha's servers to verify the submission? In the program flow?
2) Do you put in a wait step afterwards and then check the value of the ReCAPTCHA_Verified field? Then, if it's false, you stop the flow. And if it's true, you continue the flow?
Yes, triggered by Filled Out Form.
Wait step? Nope, never use a wait step to await a data value change. Trigger on the Data Value Changed event.
But it's more complex than exiting stop the (chained) flow, because while not adding fake fillouts to a program is vital, it's also vital to figure out how to keep bad leads out of your database without also letting a malicious person "slam" good leads out of your database (think about what happens if I fill out a form on your behalf but don't pass the ReCAPTCHA).
I need to describe this logic more deeply on my blog but I have many other posts pending at present....
Is your workflow possible within one program or does it require multiple programs in order to operate?
If the latter, I'm thinking the first program is called when the user fills out the form and captcha (calling the Webhook). The second program would executes when the reCaptcha Success field is populated in Marketo (we would store some list state data in the first program).
For background, we've been using the hidden honeypot field in a Marketo form, but recently had a bot add a large number of email addresses to our list.
Looking forward to your blog post. Thanks again.
Coming back to this. Does the trigger on Data Value Changed live in a different program or the same program as Fill Out Form? Are you storing list state data (i.e. what list they need to be added to) in the event that you have multiple lists you want to add a lead to? Sanford Whiteman
Sanford Whiteman Here's what I have set up currently:
I've tested the above and it's working fine. Now, what's next? Do I have another Trigger for Data Value Changed for ReCAPTCHA_Verified? If so, how do you know which form the lead just filled out? Are you storing the form name in some other Marketo field in the Filled Out Form trigger?
Does your workflow handle multiple form submissions? For instance, if you had two, three, or four forms that the user could fill out. Would you have to have separate webhooks and triggers for each form to prevent collisions (i.e. submitting two+ forms at the same time)?
I've tested the above and it's working fine. Now, what's next? Do I have another Trigger for Data Value Changed for ReCAPTCHA_Verified?
If so, how do you know which form the lead just filled out? Are you storing the form name in some other Marketo field in the Filled Out Form trigger?
You can store the form names in a history field if you need this info, but remember, until you delete the lead completely (which you should after a time to save both $ and database clutter) the Filled Out Form activity is in the the lead's history. So you can run a Smart List to see which "people" were bots and then group by the form(s) they came in from.
What you most need to manage aren't the persistently failing leads, but those that already exist as good leads but are later submitted by a bot (a targeted attack against that person, who knows?). So check that the lead was created by the bad form fillout. Of course you also should be blocking/staging field updates or else you're letting somebody overwrite fields even if they fail the ReCAPTCHA (this happens before you even check Google). There are many form data cases that the vast majority of people don't bother with, unfortunately.
In theory, not just different webhooks but different hidden fields to store ReCAPTCHA end user responses. But really, if you only take positive action when somebody passes ReCAPTCHA (otherwise, they're quarantined) it doesn't matter if the bot forces itself to fail the Google endpoint lookup by submitting a lot of forms. They'll still fail.
I just got reCAPTCHA working with Marketo forms. If you're interested, follow me and I'll follow you back and we can discuss it.
cool - yeah just followed you, let me know
One thing we implemented that doesn't block the spam emails, but prevents them from going to sales is email validation upon form submit. By doing this we've seen our email delivery increase and caught the "bad" emails. We have found about 5% of our form submissions are junk and this has really helped us. We use Informatica (StrikeIron) for this. The tool isn't perfect, but it catches the majority.
Another great tip - thank you!
On Thu, Jul 2, 2015 at 1:18 PM, Nichole Cunningham - PRODUCTION <
Nichole Cunningham - PRODUCTION, why don't you do the email validation before the form submission, and prevent the creation of leads without a valid email address? Most of our new leads with invalid email addresses are due to typos in the email address. It's bad to let these be submitted for several reasons - the lead doesn't get an email delivering what they requested, which results in a bad impression. They may never submit a form again, so you've wasted lead gen $ and lost a potential customer. if they submit the form again with a valid email address, there will be two leads that may not get merged, so your source attribution metrics won't be accurate when the lead becomes a Contact and Won Opp. .
We are implementing a real-time validation with Strikeiron right now that we hope will solve this issue.
We've (Etumos) built a small product to do the same thing, but integrated with Marketo Forms 2.0. Does real-time validation on the email address then uses Marketo's native error codes to get the user to correct their input.
Demo to see it in action is here: Demo: Real-Time Email Verification in Marketo
Nuance to it, based on lots of testing I've done, is that this is based on MX responses, so if someone puts in a valid email address that they don't actually own, it won't kick the email address out (e.g., email@example.com )
Edward Unthank | Founder, Etumos
Hi there! This is obviously an old post, but looks like this Etumos tool l may help in what we're looking to do. Problem though, go to fill the form on the landing page you referenced and it's not letting me submit my business email as it's not accepting that it's real... can you offer any help or additional info here?
What's the address?
firstname.lastname@example.org - I've also just created a post on the topic here if you're interested in looking : Block SPAM/Bot Form Fills - Not reCaptcha or Honeypot
The reason your email address is flagged when you fill out the demo form is your domain's MX is deliberately returning indeterminate results. After a delay, your MX will finally return correct results (if you try to submit again now, you'll see the disposition is known).
With Etumos Verify, you can configure an indeterminate result to be considered a pass instead of a fail (though the Verify demo page doesn't set this config option, as it's trying to be most precise). Then you periodically re-check those indeterminates via a webhook. Of course this means you have to let the form submit... that's why the default is to block indeterminates (which, debatably, represent a mailserver misconfiguration).
Ok, so to have this accept indeterminate results would this also mean in this config you would also allow in false domains (before re-checking and spitting out)? Or is indeterminate a level above "fake" altogether?
Indeterminate is a level above and considered separate from nonexistent, but someone could put up an MX (like yours) that makes every mailbox indeterminate.
Alright, last thing, the spam we've been getting makes me think this is a human logging hundreds of form fills - almost always come from @qq.com - so the goal is not only to check the domain but also verify the recipient is legitimate, it sounds like this tool just checks domain validity - is that correct? or the webhook checks both just after submission? Wish we could keep this out of the db altogether of course
Verify checks, end-to-end, the mailbox@domain. Not just the domain!
The question is whether the domain's MX gives a real-time result for whether the mailbox exists. If it refuses to give a real-time answer you must continue to check periodically (although it may refuse indefinitely). Because you need to retry at least a full minute later you can't do that within the form itself, you have to let the form post and then check using a 'hook. This means you will likely still get an actionable pass/fail but that happens after the lead is in the system -- you need to defer processing a lead any further until you get firm knowledge either way. Note it's exactly the same with reCAPTCHA, though they are targeting different cases. With reCAPTCHA you must let the form submit, then check if the reCAPTCHA matched. You can't check the match in the browser, that's where the hacking happens.
Thanks for the thorough explanation! I'll look through the recapctha implementation docs you've made for the rest of my implementation q's on this further then! Much appreciated
Retrieving data ...