Hi everyone,
We are embarking on an instance copy as we need to switch CRM integrations. I am looking for information or suggestions to reduce or eliminate duplication of emails sent to contacts from an engagement stream.
The activity history is not copied over, so if we can only upload the contacts, everyone would start at the beginning of the streams again based on their areas of interest. Many have already been exhausted with the current content and will only receive a new email from a stream when we add new content. We have 10+ engagement programs with 4-10 emails each.
Has anyone ever gotten around this limitation before so that leads were not restarting in the streams?
Thank you!
Solved! Go to Solution.
Definitely doable - if you are looking to create 2 streams, 1 for exhausted people and 1 for new people.
Other questions that come to mind are
Either way, you would need to decide on a cut-off date that allows you to do the migration of leads.
Hope this helps.
Heather,
To NOT answer your question, I'm going to ask one I find more interesting :)...Why are you doing an instance copy as part of a CRM integration change?
Cheers
Jo
Hi Jo,
We are switching from Sales Force to Microsoft Dynamics. Each instance can only be connected to 1 CRM and if you need to switch or change the integration to a new one, then you must do an instance copy per Marketo.
Thanks,
Heather
Are you using emails or nested default content programs?
We are using mostly emails within the streams. We do have 1 case of a nested program because the email within it is used in more than 1 program.
Heather
Hi Heather,
Having used emails in your previous streams, you'll find the work to rebuild your nurtures somewhat more laborious but it is doable.
Engagement streams will "skip" content in programs based on program membership, and will skip emails within streams based on whether that record has been sent the specific email (based on ID, I believe) in the stream.
When you rebuild your engagement programs, I'd recommend using nested programs so you can backfill any previous cast recipients into the programs (nested programs also provide better analytics and can allow you to create skip rules based on prior/organic content consumption, which is another reason to use them).
In each of your new nested programs, create an exception list (you can create a program status for this) based on a "Was Sent Email" backfill criteria for your past emails. Assign these leads with a status of "Exception" or "Skip" (depending on your model - we have a specific default program channel designed for engagement program casts... we use "Exception" as our skip status) in your new nested programs. Then, once the new programs are placed in your rebuilt nurtures, the program membership will tell the stream which emails to cast and which to skip.
I hope that this helps.
One option to consider is using default programs and adding the emails within these programs. The default programs are then added to the engagement streams.
This allows you to set advanced logic based on the default program membership to ensure people can skip or get the content again.
This would mean you would take all the exhausted members and add them as a member to all the default programs. Similarly with people who only received a few of the engagement emails.
Yes, this would be a lot of work to do for 10+ engagement programs.
Hope this helps.
This actually relates to @Amy_Goldfine 's question. I would always suggest to put the emails you use in an engagement program into their own Default program, as the Engagement Program will recognize program membership and automatically skip a program in a stream if the person is already member of that program.
It still means that in your instance migration you would manually need to restore program memberships (although there are ways to do that via the API if you have a team that are skilled in using this method), as the database is not migrated across in the instance copy.
Thank you both @Katja_Keesom and @Floyd_Alvares2 ,
My understanding of this suggestion is that we move each individual email within an engagement stream to its own default program within the stream. Then when we move all leads over to the new instance, we would need to mark each individual person to be a member of all programs within the stream that they have already received so that they would not receive the email again?
We do have 1 program set up this way in our current instance as it is referenced in 2 engagement programs and there are many people who are in both. For the smart list of the default program, we have member of engagement program and was not sent the email before. How would this differ if we were to use this new set up? Would the smart list be member of engagement program and member of program is not the default program for the individual email?
The Default program membership determines if the Engagement Program Stream will run through that specific program for the lead or skip over it and move to the next program/email in the stream.
You definitely need to include 'member of engagement program' but not necessarily the 'member of program is not the default program for the individual email' in the smart list.
Additionally, one of the flow steps in the default program would be to include 'change program status' for the default program to one of the membership status.