Solved! Go to 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:
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.
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.
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.
Courtney Grimes Matt Roberts Dan Stevens (and anyone else) if you can confirm what Venus discovered please do so I can get the workaround out... this stuff is difficult to test independently as I eventually got blacklisted by MessageLabs -- and whitelisting skips the test entirely. Of course I have other addresses to test with but more input is better.
Have a lot going on at present - it will take me some time to get around to this, likely not for another month or so. But I'll try to look at this when I can.
Cool, I know everyone's busy... just need enough people to be interested because frankly I can't get my own team worked up about this (though they should be).
This is actually a pretty ingenious concept, but I'm probably going to have to wait a little bit in terms of testing (don't have any nurtures doing numbers large enough for a sample size right now and none of my clients have a blast going in the next few days.) I'll definitely try this and report back in the next week or two, though.
OK!
While I don't have a high volume of examples, I've observed this behavior in my instance. In fact, we have some "hand raise" links that say click here to be contacted and I added a visited webage constraint to the smart campaign that triggers the alert to our reps. Before adding the constraint, I had reps complaining that some people they were calling stated they never clicked the link despite the click being recorded in their activity log.
That supports the concept. Thanks!
I'd be happy to provide insight here. Can you just summarize what the specific ask is?
We need to establish that the link-prefetching scanners don't execute JS.
So: do you see a pattern of Clicked Email activities that would usually be followed by a Visit Web Page activity (that is, the link in the email goes to a page that runs Munchkin) but don't have a subsequent Visit Web Page?
I was able to observe this with MessageLabs (Symantec).
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?
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.
Yes, it would be an acceptable approach for links that result in VWP activities in normal operation.