When a lead is merged / associated how can I make previously anonymous activity send an email?

[Jon_Wu]

Let's say I have a smart campaign that sends an email and is triggered by some activity such as Visits Web Page is example.com/promotion-confirmation. Then, let's say you hit that page anonymously, then we collect your email at a later time by calling associateLead to associate the previously anonymous activity with an email address.

At this point, I'd want my Smart Campaign to process all the events from when the lead was anonymous, and then send the email once the email is known, even though the web page visit happened in the past.

Instead, what seems to be happening is nothing. Next Generation Munchkin Tracking FAQ - Marketo Docs - Product Docs  seems to imply that my desired behavior (replay of anonymous events after merge) should be happening.

At the point of conversion (when the person becomes known in Marketo), all activities that occurred when the person was anonymous are appended to the person activity log and at this time they flow through the campaigns they qualify for.

To test, I visit the page in incognito, call associate lead and see if the campaign sent an email from the previous web page visit. Although the visit is added to history, the campaign isn't triggered. If I refresh the web page to add history now that the lead is associated, I do get an email.

This seems to be related to posts from Grégoire Michel​ (Removal of "Is Anonymous" filters. ), Mike Reynolds​, and Peter Szabo​ (Is Anonymous change >> will they get emails at merge? ).

Is what I want possible? Am I making wrong assumptions?

[SanfordWhiteman]

+1 to Greg's answer.

It's not that nothing is happening, it's the specific flow steps you want to occur won't be triggered.

But I think you'll be able to get pretty close to it with batches.

[Grégoire_Miche2 · Accepted solution]

Hi Jon,

This is not possible as only a subset of the flow steps will execute retroactively when the lead becomes known:

1. Change Score

2. Interesting Moment

3. Change Data Value

4. Add to List

5. Remove from List​

So email send is not fired.

And secondary campaigns will not be triggered.

The only thing you could do is to use a batch campaign and filters, that will run after the merge, and filter them from the past activities (for instance a specific data that hast been changed), but I am not sure you will be able to achieve what you want.

-Greg

[Jon_Wu]

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!

[Grégoire_Miche2]

Hi Jon,

Interesting moments are flow steps that DO work retroactively when the lead is "promoted" (which the exact term, rather than merged).

Secondary campaigns are campaign that would result from the execution of a flow step fired when the lead is promoted. For instance, if you create and activate a smart campaign that set the lead source with a data value change, based on a web page visit trigger. This smart campaign will run retroactively and update the lead source field. This field value change should normally fire any "data value changes" trigger, but in this case it will not because you are in a retroactive action, not a regular one.

-Greg

[Jon_Wu]

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?

[Grégoire_Miche2]

The batch campaign will have to be scheduled to run once a day. But you can then clone it 24 times and make them run 1 hour appart so that you have one every hour.

In any case, you will not be able to backfill email sends instantaneously.

Another possibility would be to create a trigger campaign on the "lead is created" trigger with a "source = form fill out" together with some filters and have this campaign to send the email. That might work.

-Greg

[Jon_Wu]

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.

[Grégoire_Miche2]

Hi Jon,

As I wrote a while ago in another post, you can use the "lead was created" filter for campaign you want to fire only after the creation of the lead.

-Greg

[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

[SanfordWhiteman]

It seems like there's no trigger that would relate to the Merge People activity that comes from Munchkin associateLead,

There is if you update a timestamp field in your associateLead call...

[Jon_Wu]

Exactly what I was thinking in general for cases where we didn't have an event

In our specific case, we write info to Salesforce first via our own backend, then that API only returns a hash to the frontend if the lead was already synced from Salesforce to Marketo. This way, new leads have a deferred association through Salesforce to prevent duplicate creation, but existing leads can be associated before events we want to take action on after email collection, are fired on the frontend.

[Jon_Wu]

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!

[Grégoire_Miche2]

Secondary campaigns might run because not all customers have been moved to Munchkin 2.0 yet. 

-Greg

[Jon_Wu]

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.

[Grégoire_Miche2]

Hi Jon,

Maybe Mike Reynolds​ can help ?

@Mike, how can we know whether a Marketo instance or a Pod has been upgraded to Munchkin 2.0 ?

-Greg

[Mike_Reynolds2]

There isn't a way for you to see directly whether you've been moved to Munchkin V2. Only way to know is to Contact Marketo Support and have them check for you.

[Jon_Wu]

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?

[Dan_Stevens_]

I checked with Support and found out we weren't on it either.  According to Support:

we generally recommend it to customers who are processing 1.5-2 million munchkin activities daily.

But doesn't it have additional benefits when anonymous leads become known?  For example the "replays"?

[Jon_Wu]

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.

[Grégoire_Miche2]

Hi Jon,

Campaigns taking hours is a qualifier for Orion, not for munchkin v2

Munchkin v2 is first for company with very high traffic volume on their web sites.

-Greg