We have some campaigns where we want to add multiple constraints on the SAME field. Is this possible?
For example, imagine I have a Visit Web Page trigger that matches a certain URL and has a constraint for querystring. Perhaps my constraint is querystring contains utm_campaign=promo1. This works well.
However, how would I make a trigger that only matches a querystring that contains BOTH utm_campaign=promo1 AND utm_term=specificTerm? This is just an example, but matching on multiple contains is necessary in scenarios where we can't control the order of parameters we're matching on, or when the parameters might be split up in the URL.
I chatted with support and they told me that selecting multiple values had AND logic, not OR logic, but I tried it and that wasn't true. The tooltip also said that ANY of the values I selected would be matched, so the chat agent was definitely wrong.
Thanks!
Solved! Go to Solution.
You don't actually need a faux (additional) page view, you can change the state of the initial page view. Rearrange (or totally preprocess) the query parameters before you call Munchkin.init(). Then you'll have everything in the right state to be caught by the standard trigger.
Another approach is to encode the query string as-is in the hash, then pass {{Trigger.Web Page}} to a webhook to do the heavy lifting. Pre-filter so you only send interesting hits to the webhook (i.e. if the query string contains utm_campaign, then call the webhook to see what else it contains). This is something you can do quite easily using FlowBoost, if you're interested.
You're right, it's definitely going to match any value (OR) if you set it up like that.
Short of writing the values to the lead record I am out of ideas on this one.
Yeah writing values to the lead wouldn't work super well with tons of events pouring in 😕 but that's an interesting idea.
If there's no way inside Marketo to match like that, it'd almost be easier to detect it in JavaScript, then fire a faux page view that could be detected, but that's obviously not ideal due to the maintenance and coding overhead.
You don't actually need a faux (additional) page view, you can change the state of the initial page view. Rearrange (or totally preprocess) the query parameters before you call Munchkin.init(). Then you'll have everything in the right state to be caught by the standard trigger.
Another approach is to encode the query string as-is in the hash, then pass {{Trigger.Web Page}} to a webhook to do the heavy lifting. Pre-filter so you only send interesting hits to the webhook (i.e. if the query string contains utm_campaign, then call the webhook to see what else it contains). This is something you can do quite easily using FlowBoost, if you're interested.
Sanford Whiteman wrote:
You don't actually need a faux (additional) page view, you can change the state of the initial page view. Rearrange (or totally preprocess) the query parameters before you call Munchkin.init(). Then you'll have everything in the right state to be caught by the standard trigger.
Are you thinking, I'd rearrange using HTML5 history like this?
window.history.replaceState(null, null, location.pathname + '?rewritten-params')
Another approach is to encode the query string as-is in the hash, then pass {{Trigger.Web Page}} to a webhook to do the heavy lifting. Pre-filter so you only send interesting hits to the webhook (i.e. if the query string contains utm_campaign, then call the webhook to see what else it contains). This is something you can do quite easily using FlowBoost, if you're interested.
Is the idea here to copy the query string to the hash because that appears in the web page name in Marketo and because you can't the query string to the webhook?
Then, would you send the web page URL + hash (of the query string params) to the webhook, and have it write back to a field such as Email To Send, then have a campaign that watches for Email To Send data changes to actually send the desired email?
Is the idea that with FlowBoost, I'd just be sending all the data to a JavaScript function that can return whatever to write to a field that I can watch for changes?
Duplicating the query string to the hash to get 2 conditions
If I'm on the right track above, in specific scenarios (where the params were in a suitable order), could I duplicate the query string to the hash, then match the page URL in Visits Web Page starts with some-page-url-without-the-hash, and add a contains constraint on the query string, then use choices in the flow to filter by Visited Web Page contains something-in-the-hash? It seems like I could match 2 conditions this way, although it's a bit complex.
Reordering params + faux event tracking
Reordering the desired parms to be contiguous might be viable for a few cases but won't be able to meet all our tracking needs at once. Our actual implementation runs off "events". In our case, we have a central tracking function that logs to all our analytics. Since Marketo doesn't support custom events from Munchkin, we implement this by logging a faux page view to /_event/, then add key/value pairs in the query parameters of the faux event, e.g. category=baby&pageType=search&eventName=Form%20submission&formType=Sample%20request. Since we always fire an additional event for every page view anyways to capture supplemental page data, we could just reorder that before sending it, without modifying the actual page's URL.
Is using filters on Web Page activity viable?
Could I add approximate complex boolean logic using filters with
Web Page: is ...
Date of Activity: in past 1 minute
Querystring: contains ...
then just stack multiple of these filters on with an AND? It seems like this works, but I wonder if it'd be unreliable.
I'd need to make sure I didn't run though the campaign multiple times this way, but I wonder it'd work well enough.
Thanks for helping me brainstorm these strategies!
Are you thinking, I'd rearrange using HTML5 history like this?
window.history.replaceState(null, null, location.pathname + '?rewritten-params')
Exactly. I do this when I want to hand-craft the logged URL.
Is the idea here to copy the query string to the hash because that appears in the web page name in Marketo and because you can't the query string to the webhook?
Yep!
Then, would you send the web page URL + hash (of the query string params) to the webhook, and have it write back to a field such as Email To Send, then have a campaign that watches for Email To Send data changes to actually send the desired email?
Is the idea that with FlowBoost, I'd just be sending all the data to a JavaScript function that can return whatever to write to a field that I can watch for changes?
You can either watch a field for Data Value Changes, or use the Webhook is Called trigger and check the response (which alleviates the need to have a custom field).
Duplicating the query string to the hash to get 2 conditions
If I'm on the right track above, in specific scenarios (where the params were in a suitable order), could I duplicate the query string to the hash, then match the page URL in Visits Web Page starts with some-page-url-without-the-hash, and add a contains constraint on the query string, then use choices in the flow to filter by Visited Web Page contains something-in-the-hash? It seems like I could match 2 conditions this way, although it's a bit complex.
You could interpolate the query string into the pathname actually, then you'd be able to get two conditions on the trigger side (which is what you want -- the flow choices are historical IIRC).
Reordering params + faux event tracking
Reordering the desired parms to be contiguous might be viable for a few cases but won't be able to meet all our tracking needs at once. Our actual implementation runs off "events". In our case, we have a central tracking function that logs to all our analytics. Since Marketo doesn't support custom events from Munchkin, we implement this by logging a faux page view to /_event/, then add key/value pairs in the query parameters of the faux event, e.g. category=baby&pageType=search&eventName=Form%20submission&formType=Sample%20request. Since we always fire an additional event for every page view anyways to capture supplemental page data, we could just reorder that before sending it, without modifying the actual page's URL.
Definitely, if you already are sending this then it's not an extraneous hit.
Is using filters on Web Page activity viable?
Could I add approximate complex boolean logic using filters with
Web Page: is ...
Date of Activity: in past 1 minute
Querystring: contains ...
then just stack multiple of these filters on with an AND? It seems like this works, but I wonder if it'd be unreliable.
Here's where I would definitely be wary. I don't like to rely on lookbehind filtering like this. The granularity of events never seems accurate enough for me.
You could interpolate the query string into the pathname actually, then you'd be able to get two conditions on the trigger side (which is what you want -- the flow choices are historical IIRC).
Is the hash just part of the pathname, and is the pathname synonymous for the web page name?
To get 2 conditions, would that be using both the pathname and the querystring? I didn't see a way to add 2 conditions for a single field.
Example Scenario
My ideal scenario is to be able to perform AND logic in both the trigger and the flow, but I see that's not quite possible. Here's an example that's a bit simplified, but it represents the general idea of what I'm trying to do.
Let's say you hit http://example.com/_event/?foo=bar&utm_campaign=send-email&many_other_params=baz&utm_term=VIP. I want to trigger the campaign based on page and utm_campaign, but then send different emails depending on the utm_term.
1. The ideal scenario would be to trigger the campaign on just page and utm_campaign, then use Add Choice in the flow to vary the email.
Since you can't access the querystring in the flow, let's say I copy the querystring to the hash so it becomes:
Smart List
Visits Web Page
Web Page: starts with http://example.com/_event/
Querystring: contains utm_campaign=send-email
Flow
Send Email
Choice 1
If: Visited Web Page contains utm_term=VIP
Email: VIP Email
Choice 2
If: Visited Web Page contains utm_term=Premium
Email: Premium Email
Default Choice
Email: Default Email
2. I could also create multiple campaigns with triggers that had mutually exclusive constraints on the querystring, but I'd somehow need to match both utm_campaign AND utm_term (originally non-contiguous) in the trigger to make this work. The other downside of the latter is more Smart Campaigns to manage, and the possibility of human error causing overlapping conditions or missing cases, leading to duplicate or missed emails.
I feel like there's no way to get this to work unless I copy the query string into the hash or somewhere in the path as well, at which point I should just go back to the simpler option 1 and use Flow steps to filter after the initial trigger.
Is using filters on Web Page activity viable?
Could I add approximate complex boolean logic using filters with
Web Page: is ...
Date of Activity: in past 1 minute
Querystring: contains ...
then just stack multiple of these filters on with an AND? It seems like this works, but I wonder if it'd be unreliable.
Here's where I would definitely be wary. I don't like to rely on lookbehind filtering like this. The granularity of events never seems accurate enough for me.
Gotcha. Although this seems simpler, it seems scary to me as well. Unintended triggering will happen without extra protections, and who knows if the activity processing was delayed, and the actual activity was a while ago.
I've confirmed that the flow choices are historical as you mentioned, which means my above strategies won't work. The best seems to be to reformat upfront, use a webhook with {{trigger.Web Page}} to process and make decisions elsewhere such as FlowBoost or a custom RESTful service.
It's a bummer you can't use {{trigger.Web Page}} in choices, but you could also probably use it to log an interesting moment, then set up a trigger on one of those instead of using a webhook.