Jon_Wu

Hi Greg, I was playing around with that before, but it seemed like the "Person is Created" trigger might only fire for new leads. Is that right? I was trying to find a trigger for when Munchkin cookies are associated with a lead (new or existing). In our new architecture, our primary method of associating Munchkin cookies with somebody is via server side POST, so we'll always get a Fills Out Form activity. It seems like there's no trigger that would relate to the Merge People activity that comes from Munchkin associateLead, but in that scenario, we don't need to worry about batch campaigns. Our fallback to server side POST is using the REST API to associate a lead too, and I'm not sure if there was a triggerable event for that either, so we could catch those few rare leads via the scheduled batch method. Thanks, Jon ... View more

We're going to try batch campaign setup this way, then we'll have all the batch campaigns act as a cron job to trigger a single campaign where all the logic is stored. To reduce the delay, I just thought of a push vs poll mechanism that we'll also try. Since we use server side POST to associate leads, we can use Fills Out Form "Associate Tracking Cookie (form name)" as an extra trigger for the batch campaign in addition to the periodic scheduled tasks. This might hammer that one campaign, but hopefully that doesn't cause issues since it will just be flushing out static lists, which will just be a few people each due to the frequency of runs. ... View more

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. ... View more

Yeah it seems that way to me too and I'd want to use the v2 behavior now so my campaigns don't break later. We also have some bugs happening where webhooks execute and make people known and break deduplication, even if they don't have an email and support said that'd be fixed when we get on v2. However, it's frustrating that there's no indication of when that would happen, even though we're affected by weird bugs now. ... View more

Thanks Mike. Support finally figured it out after a week and it looks like we're not on v2. They said they only migrate for people having performance issues. Our marketing team has had issues with campaigns taking up to an hour or hours to send or process in the past, so I wonder if that qualifies. From my engineering perspective, I'd also want to be on v2 ASAP since I'd hate to build a campaign now that depended on non-v2 behavior, that later breaks when we're migrated. Next Generation Munchkin Tracking FAQ - Marketo Docs - Product Docs seems to indicate that rollout began early 2016. Is complete rollout happening this year? ... View more

Yes, which I knew if I was on 2.0. Scary to think that these little details could change after I get something working. I did a brief test with a webhook on the primary and secondary campaigns and they seem to fire even when emails don't send - both in my initial SC and in secondary ones. I recently stopped firing webhooks for leads without an email because it was causing them to be treated as known and also breaking deduplication. They said this issue would go away later when I was migrated to some newer stuff, so maybe they were referring to Munchkin 2.0. My previous case for firing webhooks was for scoring so I was writing back to the lead, so maybe if I don't write any fields back, it wouldn't be a problem. I feel like I don't want to get too far in the weeds until I know I'm on 2.0, otherwise things might fall apart if I get really creative. ... View more

Ah that would make sense. I reached out to support last week to see if we were migrated but they don't seem to get the question. ... View more

OK that makes sense. I was afraid this would be the case, that I'd have to set up many batch campaigns to reduce a delay, but it makes sense given the constraints. Unfortunately, I can't use a form fill out trigger because of the way I'm getting leads into Marketo (which is pretty complicated). Sanford Whiteman​ had suggested that push all our leads through Salesforce, so that's where this tricky complexity comes in. When people fill out a form on our site, we no longer use Marketo forms and instead push the info into Salesforce. If the person isn't in Salesforce, we won't call associateLead from Munchkin so that the lead is synced from Salesforce to Marketo first, to prevent duplicate lead creation. Our full flow for new emails / leads / contacts is pretty complex: 1. Add person to Salesforce and push Munchkin tracking cookie into a JSON array in the Salesforce Contact 2. Within 5-10 minutes, the Contact syncs to Marketo 3. A SC fires a webhook to our backend with the lead's email 4. Our backend calls an Apex REST API endpoint in Salesforce which finds corresponding Contact in Salesforce, the pushes a message into a Google Pub/Sub Topic with the lead's email and lead ID, for every cookie that exists in the JSON array, then it clears the JSON array (all transactionally) 5. Our backend receives a message for each cookie via a Pub/Sub Subscription, then tries to first associate it with the lead via server side post and the email address (to conserve API calls), then if that fails, we fall back to using the lead ID and the associate lead REST API That backstory is ultimately why we now have an issue lead promotion is delayed, even after we have the user's email. FWIW, I've also noticed that secondary campaigns do seem to run - they just don't send email. For a web page visit on my anonymous lead, I had a SC that changed a field, added the lead to a list, and added an interesting moment. Then I set up 3 separate SCs that were triggered off those 3 separate types of changes to send an email and log distinct interesting moments, and those all ran. It kind of seems like they process it all in real time, then just merge what happened anonymously, into the promoted lead when the promotion happens. I think we'll play around with the batch campaigns to see if we can get that flow to work. Thanks for all the help! ... View more

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: http://example.com/_event/#foo=bar&utm_campaign=send-email&many_other_params=baz&utm_term=VIP?foo=bar&utm_campaign=send-email&many_other_params=baz&utm_term=VIP 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. ... View more

Gotcha, thanks for clarifying. So, it sounds like my 2 proposals were secondary campaigns so that wouldn't work. What's the general idea with a batch campaign? Is that something that'd have to be scheduled to run once / day, or can I backfill email sends instantaneously? ... View more

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! ... View more

Thanks for the replies Grégoire Michel​ and Sanford Whiteman​. I was having issues finding info on what to expect in terms of deferred processing after a lead merge. That list is super helpful. Is that documented anywhere? What are secondary campaigns? In terms of a batch campaign, what would my trigger be and what would I be looking for? If I ran something looking for past activity after a merge, would I run into duplicates when multiple merges happened unless I had some kind of state tracking? I'd love to hear more about the batch strategy, but that list of steps gives me 2 other ways I think could work. 1. If I only want an action to happen once, we could use Add to List, then have a campaign that sends the email with Added to List as the trigger. This way, if they did something multiple times before the merge, they'd still get the email, but I could allow them to run through the email campaign multiple times in case they need to re-request the email later on. 2. If I want to trigger something every time once merge, could I add an Interesting Moment instead of initially sending an email, then have a separate campaign that fires every time the Interesting Moment is seen? That seems like it'd work just like #1, but without deduplication since all moments would theoretically be processed. Would these 2 suggestions work as I think, and what's the batch solution you mentioned? Any gotchas I should be aware of? Thank you! ... View more

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. ... View more

I had an issue like this too and came to the same conclusions after long threads with support. We had a high score webhook writing to the lead that was causing leads without an email to be considered known. This also caused our total number of "known" leads to grow a lot since they'd never be deleted. Although I hit this years ago and worked around it, I recently got hit again by this on a related issue where webhooks were causing anonymous leads to become known, thus breaking automatic lead deduplication. Since the webook would make people "known" the deduplication by email address wasn't kicking in, even for leads directly added to Marketo via form or REST API (not via Salesforce where we'd expect duplicates to come from). Support said this issue would be fixed with Munchkin v2, but also said we weren't fully migrated and didn't know when... Very frustrating as you've noted. ... View more

Greg's suggestion was good. I think trying to trigger on stuff in the past just doesn't work and really shouldn't be an option. The thought of "triggering" based on past things doesn't make much architectural sense anyways. Curious why is data value changes a better trigger? For us, the limitation is that we automatically decrease the lead score that I'm watching to track recency. We need to ensure that only positive changes kick campaigns off. We'd really like to say trigger on positive score change, but we currently only increment by +1 so change = +1 works fine for now. Also if you have any tips or insight about my engagement question above I'd love to hear it. It's more thinking, now that I know how to do what I was trying to do, am I actually using the right tool for the job?     ... View more

Thanks Greg. This makes sense and i think that would work. I was intrigued that I could define a trigger like this, but from a technical / backend perspective it doesn't make a lot of sense to be able to trigger on events in the past: Does this just not work in general? I'm an engineer and I've been reviewing our campaigns set up by marketing in the past few days. I saw that we use smart campaigns in the way I've described to send a small number of drip emails. Are we missing out by not using engagement programs? It feels like the programs offer some flexibility of cadence, pausing, and periodic scheduling at a given time, however it seems like most of this is possible with a smart campaign - maybe with a little more work. On the flip side, it seems like a potential downside of engagement programs is the fixed schedule. If I trigger a smart campaign from an event the user did, I can email them again around the time of their activity - a time that individual might like to shop at. I don't think you can do this in an engagement program. Does that understanding seem right? Thanks for your help! ... View more