Long story short I have about ten forms that I use each catered towards a specific asset-type (events, whitepapers, analyst reports etc.) and for many smart-campaigns I use a form fill trigger with "form = event" extended with the filter webpage = "*url-example*"...not sure if this is a good practice or not, but it has afforded a pretty good scalable way of getting the right info with triggers specific to each asset without having to build or break down too much....but here lies the problem.....this method seems to work as long as I put in the url with both an ending slash and without (query string data doesn't seem to be an issue)
i.e. As long as I put these:
These would all work:
However for some reason, some visitors to my page end up with a hash (#ip-form) on the end of their urls: google.com/blablabla/#ip-form. So far my running theories are something related to Mozilla (seems to happen a lot with these guys), something related to accessing a page with modified cookie settings, something related to users accessing via proxy or vpn...but honestly I am not nearly technical enough to know how to approach testing or solving this one.
So here is my question: Why does this hash appear for some users? and is there a particular reason Marketo will not look past it the way it seemingly does with query data when using the webpage is filter option on a form-fill trigger?
Using a contains filter should take care of this, no?
On a technical level, one annoyance with hashtags -- and I use them happily in my projects -- is that once one is set, it can end up suffixing all the user's URLs even when they're not on a page that uses/needs them.
If you want to strip the hashtag, you could add a tiny line of JS on any page that isn't using hashes and might be ultra-sensitive to them:
if ( document.location.hash ) document.location.replace( document.location.pathname + document.location.search );
Thanks for the hash suggestion Sanford! I will take a look at it as an option. As for the trigger operand, I wanted to try contains but when webpage is used as a condition for the trigger it only gives you is or is not as options. I suppose I could remove the filter as a condition and try layering it on as a separate filter. Will definitely check out if there is a workaround that way.