New Trigger Token: Querystring

[Anonymous]

It appears you can populate a field upon a website visit based on everything in the Visit Webpage log accept Query Parameter.  Why is this the only one missing?

There is {{trigger.web page}}, {{trigger.client ip address}}, {{trigger.referrer}}, {{trigger.search engine}}, {{trigger.search query}} but no {{trigger.querystring}} or {{trigger.query parameter}}

[Anonymous]

Jack,
How are you planning to use the query parameter in your campaigns?   

Raj

[Anonymous]

Placing it as a value in a field, interesting moment, etc.

[Anonymous]

Are there any scalable alternatives here?  We need the ability to trigger smart campaigns off of historical query parameter values of past visits without knowing what those query parameters will actually end being.

[Anonymous]

Agreed, this product feature would be huge. We are looking to pass information without form submit, and this would make our lives much, much easier.

[Anonymous]

Still having issues with this and now I'm at a new position. I will submit an idea.

[Michael_Langell]

Agree with this.  Strange why this is the only constraint without a token.  Another big use case for this token would be pulling the query parameter info when the referrer url is unavailable. This becomes more important when taking into account the below which came from Marketo Support:

Google has some restrictions in place that can sometimes prevent the referrer URL being captured. In general, there are a few things to consider when using Referrer URL. Many websites don’t allow for that information to be passed along any more. It used to be very widely used and very common practice, but more and more these days that data just isn’t utilized and many sites have moved away from providing it, which means that even if you have everything set up properly to catch that data in the form, if the referring URL does not actually pass that data along, there isn’t anything to actually capture in the form field. Referrer URL is somewhat unreliable because of this trend.

-Mike

[SanfordWhiteman]

but more and more these days that data just isn’t utilized and many sites have moved away from providing it

Note there is a nuance here. There actually is a larger percentage of sites providing a referrer than at any time in the past 10 years. But fewer sites are providing a non-redacted referrer.

This is because modern browsers allow the referrer to be customized by the source site using META tags. If the source wants to pass only its hostname as the referrer (stripping off keywords, for example) it can do that, even if the target is a non-secure page. In the past, the non-secure page would get no referrer at all under these circumstances.

[SanfordWhiteman]

Mike Langellotti here's your workaround: http://blog.teknkl.com/url-query-string-in-visit-web-page-triggers/

[Michael_Langell]

Sanford Whiteman​ can you do the same for trigger.referrer?  The above is not exactly the use case I am thinking of. 

Basically, there are a number of instances where the referrer url is empty, but there is data in the query parameters, so we do have some info on the actual referrer then.  I'd like to be able to pull that data either into the referrer url or into a custom field via token.  So in the below case, we know that this visit was actually referred by Marketo.     

  

[SanfordWhiteman]

This is an interesting example because the referrer is probably being stripped due to https:// -> http:// restrictions (it should be your branding domain).

With my technique above, you'd be able to pull {{trigger.web page}} into a custom field and see the original query string (although it's true that you'd see the entire URL, not just the query string).

Overwriting the true referrer (as expressed in {{trigger.referrer}}) isn't possible unless you use a custom Munchkin build. Alternately, even with the the default Munch lib, you can issue a second, synthetic Munchkin.munchkinFunction('visitWebPage') and that activity will use the current URL as the {{trigger.referrer}}.  But then you have an extra log entry. Still, it can be useful: Munchkin.munchkinFunction('visitWebPage', url: '/extendedReferrerTracker') can give you extended info to act on.