I am submitting this discussion in case others may have wondered about this and were unable to find an answer in the Community.
I realized after an email campaign this morning that many leads were getting lead score increases for clicking links in an email but by the time an alert was sent to Sales, the lead score had significantly dropped because the email was bounced. What happened here is that the clicked activity was not from the actual recipient of the email, it was a link scanner from the recipient's email server. The server first "clicks" the link in the email to make sure it is safe and if it is, will then deliver it to the recipient. In my case, the email was bounced anyway so the lead first received a score increase for the click and then a decrease since the email bounced.
Marketo filters and triggers are unable to determine if the email click is from the actual recipient or a link scanner, it can only see if the link was clicked at all. In order to only score clicks AFTER the email is delivered to ensure the click was from the recipient and not a link scanner:
- run a smart campaign trigger of "email is delivered" is any
- create a list
- the flow step of the smart campaign will be to add the leads to a list
- create a scoring campaign with the trigger of "clicks link in email" and a filter of if the leads are part of the list (this ensures the click trigger happened after the email was delivered)
- put a score step in the flow
If batch scoring is easier, I would pull in the two filters of "clicked link in email" in time frame today and "email was delivered" in time frame today. This workaround will only score the click if the email was delivered, but the click could have been before the delivery. So I would recommend the trigger option to ensure the click was after the delivery.
Another option is to remove scoring for clicks link in emails altogether if the links direct to your website anyway. You can just increase the score for visiting the landing pages to avoid the false positives of a score increase for the clicks in the email.
Hope this provides some insights into link scanners. Please share your experiences and best practices as well.
Thanks for the thoughts on this, Devraj! Those workarounds will add some useful coverage.
Unfortunately, as we know from previous investigations, there is no way to fully combat this issue. For example, it is convenient for us when the Delivered event occurs after the scanner pre-fetches the link, but in some SMTP architectures this will not be the case. And I would expect it, if anything, to become less common because it gives spammers' C&C boxes something to signal on and also consumes more resources on the scanner side.
As for triggering on Visited Web Page instead of Clicked Email, this too will not always work because the more sophisticated scanners are known to follow the JS redirect to the next page and even log the Munchkin hit. This makes sense because if the goal is to detect redirects to malicious sites, you can't stop checking after the first page.
I'm also kinda wary of having a list created for every email and a global trigger for all Delivereds. That can really tax a Marketo instance
Ultimately, this issue needs to be dealt with -- to the degree it can contained at all -- using Marketo's internal tech. Maybe they will allocate resources to this under the new regime!
Great insight as well Sanford. I guess all we really can do is try to utilize the workarounds available in the meantime.
We often have clicks as a major conversion point, and thus this problem is crucial for us. Too many clicked before delivered. I tried to build a workaround that I believe follows the same logic (as offered above):
1. Trigger "Email is Delivered" = > Add to list ABC
2. Trigger "Clicks in Email" + Filter "Member of the list ABC" = > Success = True, Send Alert, etc.
Ultimately, it is not working consistently. With big batches the sequence of actions seems hard to catch. After multiple testing, I deactivated all those extra steps. What we do is adding filter "Visited a webpage". Not perfect either, and we are losing some legitimate leads, but it is much more closer to reality. And we plan on adding simple forms to all LPs.
If anything else is invented to resolve the issue, I would be super excited to learn.
It's been claimed that Marketo's click tracking server is being tuned to exclude this traffic. However, allusions were made to using "source IPs" for detection which is, I deeply hope, a doomed exercise. (If this proves possible, then mail scanners as a whole are useless. This is horrible for security. Read this to see how easily links can be weaponized.)
We are having the same issue as you, and we thought about implementing this model but found that our testing records were not always getting through as you mentioned.
Do you have an estimate of how accurate the solution is? Does it catch 90% of the clicks typically? 20%? Somewhere in between?
Have you also found a solution for fixing reporting to match your new "click" definition?
Thanks in advance!
Has anyone heard if they have a solution for this issue? We are coming across this to many degrees, causing a lot of confusion to our sales teams that have been trained to review the MSI email open/click information in Salesforce, score inflation, and reporting issues for activity and email reports. Grégoire Michel Josh Hill have either of you come across any updates from Marketo or additional workarounds for these bots/scanners that are affecting anything related to email activity? Thanks!
I've heard nothing official. Fact is they probably overbet on how easily-- or even if -- they could combat this situation.
What you have to take into account is people do send spam using Marketo and definitely could link to phishing sites. A blanket whitelist of Marketo on the scanners' part, or allowing Marketo to know all the possible egress IPs, would be an awful idea.
The only sharing relationship I know of between mail scanners and 3rd parties is when the 3rd party is specifically -- and only -- charged with security auditing. That is, they send phishing emails to see if a company's employees can be fooled into clicking on a phishing link. In that situation they need to see only human clicks.
Similarly, the entire concept of a mail scanner is that it should be indistinguishable from a human. If it's distinguishable, it's broken.
Not much to add on top of Sanford's comment on this.
Alignement between the sender's email address domain, the SPF domain and the links in your email (the branding server) will reduce the likeliness of your email to be seen as a risk of being a phishing email and might reduce the number of these false positives.
I have seen situations where people where having very weird open and click email stats, as they were sending emails from email@example.com, with a SPF and branding domain in mycompany.com and these stats came back to making sense when they removed these discrepancies.