So would Debbie's solution work better if the href were a bogus url?
Yes, although it's not an all-around solution, more a way to throw some more babies out with the bathwater.
So, I just want to quickly note here that we've discovered a new type of anti-spam checking behavior over the past several days that conventional methods have a hard time capturing. Rather than fire around the time of delivery, it fires on a recurring basis, presumably until the recipient actually opens the emails and clicks on any links. From an antispam point of view, this makes sense--you can't bait and switch the URL contents after delivery--but it's massively annoying to find. I'm trying to come up with a predictable way of catching this outside of IP traffic so it can be managed via Marketo, but it may be a bit until there's a bulletproof way to catch this.
Thank you for sharing this. I'm going to poke around and see if any of our clients are experiencing that.
I'm going to poke around and see if any of our clients are experiencing that.
Periodic rescanning isn't a brand-new thing, btw. Services have been doing this for 10 years or more, just not in conjunction with the headless browser environments that now enable the scanning to be more accurate.
There won't be a way to catch this. Whole idea is it's indistinguishable from normal HTTP traffic.
You have to mandate a human-only type of interaction (like waiting until somebody has clicked a button, then retroactively noting that they clicked the email link that led to the page with the button). Any unattended interaction can be forged.
It's unbelievable to me that Marketo hasn't found a way to fix this yet. It's been a known issue for well over a year now. These fake clicks make the analytics useless. You'd think it would be a top priority to find a real solution other than end-user workarounds.