Spam filters registering clicks?

[Anonymous]

Has there been any problems with spam filters scanning emails and registering clicks as they follow the links in the email?  We are getting false positives on our email clicks.

[Anonymous · Accepted solution]

There are several posts here on Marketo about this issue, and my firm has been digging into it a lot over the last few days. The short answer is that yes, this does indeed happen - spam filters (like Barracuda) / bots / junk mail algorithms do indeed click on links in emails (see this interesting blog post from 2013 regarding the issue - Barracuda calls this "multilevel intent analysis"). The spam filter is looking for redirection or malware or something like that. There isn't a whole ton that we marketers can do about it, though. Here is what we've done and found:

• First thing we did was download the entire Marketo activity log using the API, put it in a database, and started dissecting the "Click Email" event types. We also sat down with the system administrator here to review some of this data. In short: there is nothing in the User Agent, Platform, Device, etc. that will help spot these.
• Then we started looking at the timing: what about people who click before they open? What about people who click really quickly after the "Send Email" activity is logged? Well...the "Send Email" event isn't indicative of when, exactly, the email leaves Marketo's servers, so that's not really accurate - you can't spot bots based on that.
• The best way we've found right now is to include a one-pixel picture / link on the email - invisible to just about everyone (as suggested here). Anything that clicks on such a tiny little pixel you can consider a bot. True; someone might not load images and see a box, but most people won't see it at all.
• Another possibility: see if you have a bunch of clicks that all happen at the same time (or people clicking every link in an email, every week - would a real person really need to read your Privacy Policy week-in and week-out?). Those are probably bots...but I personally would want to download the data into a real database before attempting this kind of query.
• One more (really complex) possibility: when we went to our sysadmin (the guy who runs our own company's Barracuda machine) about a lot of these issues, he started to "ping" some of the IP addresses included in the suspicious "Click Link In Email" activities. One or more of them shot back a response indicating that it was a Barracuda box. If you are really, super-duper concerned with this problem, it should be possible to download all Marketo activities via the API and write some custom script / code to extract the IP addresses from the Marketo "Click Email" events and then to periodically ping all these servers to see if you can get them to self-identify as a spam filter (parse the text-strings of the responses for incriminating evidence).

We have not done this last thing, as our "one-pixel" solution has indicated (at least over the last two weeks) that it's likely not a major issue. Perhaps some day, when our organization has unlimited resources (heh), we will pursue this last option, but the reality is that we have a lot going on and better things to do to add more value to our marketing efforts.

I would also like the data to exist in a perfect world - one where our Users validate our TRON Data Discs and we can take down the evil Master Control Programs while we're on our light-cycles on the grid - but that gleaming world of perfect, neon data does not exist. For most of us, I would guess this statistical aberration will not significantly affect our analysis of content effectiveness.

Hope this helps.

[Venus_Wills]

Thanks for the information, Matt. For us, it appears that the spam filter doesn't click on all the links but just one. The click is also registering in the activity log before the "delivered email" is registered. So the one-pixel image link won't work for my case. However, I am noticing that none of these links lead to a "visit page" activity (and it should). I will try to use that filter for lead scoring. Please keep us posted if you uncover additional information about this.

[SanfordWhiteman]

I am noticing that none of these links lead to a "visit page" activity (and it should).

... as mentioned in the other thread, you shouldn't expect a VWP activity just because you saw the Clicked Email.  The anti-spam technology in use isn't going to download all libraries and do JS logging (in fact it would be a pretty good DoS attack against such services if it did). 

[Venus_Wills]

That is an important distinction to point out. I'm only looking at clicks that should result in a webpage visit (i.e., clicked link that contains armor.com should lead to a webpage visit containing armor.com). I checked the activity of a "normal" lead and the email click does lead to a webpage visit. At this point, I'm just trying to prevent these leads from scoring up from bot clicks.

[SanfordWhiteman]

Yes, it would be an acceptable approach for links that result in ​VWP ​activities in normal operation.

[SanfordWhiteman]

I think Venus Wills​ is on to something very promising here. If it can be established that the anti-spam logic never prefetches deep/long enough to log the Munchkin Visit Web Page activity -- and there have to be limits to how much it will fetch/redirect/render or it's vulnerable to an attack comparable to the old "ZIP of death" attack against anti-virus software -- if it doesn't go that deep then all we need to do is make sure the tracking server depends on some async JS calls to complete before logging the Click Link.

I can write a simple tracking server wrapper to do this, provided you all can verify that all (or a commanding share) of the link-prefetching approaches don't get around to running Munchkin.

[SanfordWhiteman]

BTW tests just now with our own MessageLabs account suggests my idea above holds real promise.

The scanner didn't even attempt to download a simple (and in fact nonexistent) script on my test page.  If that holds for other services all we need is a JS shim in-between the scanner and the tracking server and there will never be false clicks.

I must say if these jokers don't even replay a JS redirect they're pretty much vaporware.  But so be it.

[Venus_Wills]

Hi Sanford, what does this mean for the JS-impaired? Do you think the simple logic of using a Smart List to to filter out the clicks that should result in a webpage visit but did not will work?

[SanfordWhiteman]

You wouldn't need to write any JS at all -- you'd just need to point your tracking domain to a smarter server that knows how to deal with these non-human clicks.  The rest is taken care of automatically.

I think your method might be okay in controlled environments (i.e. where you never use a direct download link to a PDF and never link to pages that don't run Munchkin) but even there would be really hard to maintain.  It would basically mean that Clicked Email activities themselves are pretty useless as used in reports.  You also can't trigger on "Clicked Link in Email that is not followed in the future by a Visit Web Page" because the chronology is backward.