Kenny_Elkington

One of the biggest gains to productivity you can employ with Executable Campaigns is the ability to pass the token context of the parent campaign to child campaigns.  This allows you to template your campaigns to use contextual data from the parent and then put it into practice within reusable executable campaigns.  It also allows you to set up My Token values as defaults, and then override them by setting them in the calling campaign.  Let’s take a look at an example: Evaluating activity scores   Evaluate Activity Score   Most Marketo subscriptions use activity or behavioral scoring to some extent, and executable campaigns make it easier than ever to create an effective activity scoring model.  By using the same My Token keys in the parent and child campaigns we can craft an activity scoring campaign that can be used by any triggered activity in a single workspace.  This is what a basic templated scoring flow looks like.  The interesting moment is configured to stamp that activity log with the parent campaign name and ID for debugging purposes, and should be omitted for performance reasons in production.   Note how the Change Score step has a Change value of {{My.Activity Score}}.  This is defined as +0 in the Evaluate Activity Score program, so if executed with overriding the token context, or if the value is not defined in a calling campaign, then that will be the value used:   Calling the Campaign   Suppose you want to score when someone fills out a particular form, but you also want to apply a score when they are created by filling out that same form.  In this case you would need two campaigns, each with their own parent program.  Our New Lead campaign needs to listen to the “Person is Created” activity, needs to execute the Evaluate Activity Score campaign, and needs {{My.Activity Score}} to be defined:       Configured this way, our New Lead campaign will call the child campaign with the parent campaign’s context and increment the score by +15 and then move on to the rest of the flow. For our campaign that’s listening for a form fill, but not creation, we only need to configure the trigger and My Tokens differently:     When a lead qualifies for a run through our Evaluate Activity Score campaign, we see that the Person Score is correctly incremented by +15 when it goes through our campaign:   Working with this pattern   This pattern can be applied and modified to work with many different scoring and lead lifecycles.  There are a few things to keep in mind, though: If you are nesting executable campaigns, I.e., using the Execute Campaign step within an executable campaign, you need to set Use Parent Token Context to true through each layer where you need to use token context in the child campaign.  Using folder-based My Token inheritance can help ensure a value is set in all of your relevant folders.  For example, if all of your scoring listener programs and campaigns live in a single folder tree, you can set a {{My.Activity Score}} at the top level folder, which can then be overridden at the local program level. My Tokens that you want to override in an executable campaign should be set in both the child and the calling campaign, as well as any campaigns between the initial caller and the ultimate child. As designed, each campaign that wants to call the Evaluate Activity Score campaign, needs to be in its own program (or Campaign Folder) in order to have its own specific {{My.Activity Score}} token.  More than one score per program needs either multiple “Change Score” steps in your evaluator campaign, each with a distinct score token, e.g. {{My.New Lead Score}} = +15 vs. {{My.Form Fill Score}} = +5 vs {{My.Unsubscribe Score}} = -10, or a distinct campaign for each score-activity pair that you want to score distinctly Pair this with the suggested categorization model for Executable Campaigns for best results. ... View more

Executable campaigns are a powerful new feature designed to allow you to make your campaign logic modular, reusable and maintainable.  However, staying within the limit of three nested executables can be difficult when your campaign trees get complicated.  This article describes a simple method of classifying your executables into three categories to help you stay within the nesting limits while also remaining productive.     Three Categories for Executable Campaigns   This classification system has three categories with simple definitions:   Tier 1: These campaigns may not be executed by other executable campaigns   Tier 2: These campaigns may not execute other Tier 2 campaigns   Tier 3: These campaigns may not execute any other campaigns       By classifying your campaigns in this way, and abiding by their restrictions, you can avoid bumping up against the nesting limit.   Now we have a way to avoid the nesting limit, but how should you map your existing campaign logic and lifecycles into these categories? Let’s look at Tier 3 first, as it is the foundation of this model     Tier 3 – Task/Unit - May Not Execute Any Other Campaigns   Tier 3 cannot execute any other campaigns, and this is where individual tasks should be implemented.  Your organization can define what a task is in this context, but I think that it is useful to borrow the definition of  unit  from software development: A unit is the smallest testable part of any software.  In the context of Marketo, a unit is the smallest testable part of any campaign.   Let’s look at a common example for lead lifecycles: Taking a country input and outputting a country code to a different field.       The above is an abbreviated example using flow-step choices to match the value of Country to a particular country code.  Supposing we wrote a test for this, we would expect a lead who enters the flow with an empty value of “United States of America” to receive a Country Code value of “US”.   This or similar steps could be a unit for your business, but you do not need to limit your units to single steps.  Your Tier 3 task campaigns should tend to be short sequences of work which are used in multiple contexts     Tier 2 – Orchestration – May Not Execute Other Tier 2 Campaigns   Tier 2 (as well as Tier 1) are more flexible than Tier 3 campaigns as they can execute other campaigns themselves.  These executables can be used to string sequences of other campaigns together alongside standalone flow steps.  An example would be a Standard Data Enrichment campaign.  Where normalizing a country code is a unit or task, this is a sequence of one or more data enrichment tasks that can be maintained and modified separately from the logic of the individual tasks themselves     Tier 1 – Last-Mile – May Not Be Executed by Other Executable Campaigns   You may find that your business does not need to use Tier 1 campaigns, and that you can satisfy your organizational needs with just Tier 2 & 3 campaigns.  However, Tier 1 campaigns allow an additional layer of flexibility for you to manage your campaigns.  Typically, one of these campaigns will call a mix of individual flow steps, and Tier 2 & 3 campaigns to assemble a flow for a typical lifecycle event, like a Standard New Lead Flow.  These typically include data enrichment, normalization, scoring, and routing flows, which can be created as tier 2 or 3 campaigns.         ... View more

In late 2020, Apple announced their intent to  add a new feature to their Intelligent Tracking Prevention implementation  in Safari  called  CNAME Cloaking Defense , to be rolled out with the release of Safari and IOS 14 .   Like  many of the other efforts in Apple’s Intelligent Tracking Prevention schemes, t his feature is designed to  limit  the lifespan of cookies set by hosts which have a CNAME  pointing to a domain name which does not match the visited page’s domain name  to seven days .    Since Munchkin JS  uses  cookies  set by  a CNAME, and the underlying host to which the CNAME  ({your instance }.mktoweb.com )  points   will never match the  domain name of a visited  page ,  cookies set by Munchkin in Safari 14  browsers  will be capped to a  seven-day  lifespan.    While the reduction in cookie lifespan will have some effect on tracking known leads , traffic from Safari generally  represents  less than 10% of requests handled by Munchkin.        T he re are no apparent easy solutions to this  issue,  and each would require  significant intervention  both  on the part of  Adobe engineering and  subscribers .    Adobe will continue to explore long-term options for improving consistency and accuracy of web tracking behaviors, but at this time we have decided not to t ake any extraordinary measures to try to circumvent this change and restore  long lifespans for Munchkin cookies.  Instead,  we have decided to  focus  on  our efforts  to  integrate  Marketo  web tracking with the  Adobe Web SDK   so that all Adobe  Marketo  En gage  customers  can benefit from our best-in-class web tracking solution.   We will have more information to share when we are closer to release of this solution.   ... View more

Deprecation of Email V1 began  almost  two years ago  and beginning with the  March  maintenance   release to London & Netherlands subscriptions on  March 17 th , 2021  and all other subscriptions on March 19 th , 2021 , all API support for V1  e mails will b e ended.  A fter this release,  any attempts to interact with V1 emails via the Asset APIs will result in errors and no actions taken .  All known remaining users since  February 24 th , 2021  have been notified ,  but  it is possible  that there are still integrations which may attempt to interact with these assets.  The most common types of affected integrations are services  which  offer digital  asset management, translation, and localization .     If you do observe integration failures as a result of this change,  you will still be able to upgrade problematic assets  by editing and approving them .  Once an email asset is upgraded to V2, you should be able to resume using it with integrated services.   ... View more

  Beginning on  2020-05-07 ,  Marketo  will start to roll out version 159 of the Munchkin  JavaScript  Client.   Subscriptions which have the  Munchkin Beta f lag enabled  will see changes from this release first, after which deployment will begin on a rolling basis to subscriptions which  do not have this flag enabled.    The  most significant change in this re lease is the  deprecation of Munchkin Associate Lead.       Changes     Deprecation of Associate Lead       Beginning with this release, when the  Associate Lead method  is invoked, a warning will be issued to the browser console, indicating that the method will be removed in a future release.  For more details on what to expect from this deprecation  process   read this announcement .     Reversion of Domain Selector V2       Despite best efforts to offer an improved the selection of the domain for the munchkin cookie, the change proved disruptive in certain cases.  We will be reverting the mainlining of this change, and the f unctionality will be  hidden behind a configuration flag  as it was prior to version 158 .     Fixing Undefined Referrer when Calling Visits Web Page       Previously when calling the  Munchkin API to submit a Visits Web Page event , the referrer would be submitted with a value of ‘undefined’.  With version 159, the referrer will now be cor rectly recorded.  This bug did not  affect  normal web visit tracking.       Rollout     As with all Munchkin releases, this version will be a phased rollout,  initiallity  to customers who have enabled  Munchkin Beta  for their subscriptions, and later for all  Marketo  subscriptions.  Th is schedule is subject to change.   Customers who need early access to these features in their subscriptions should consider enabling Munchkin Beta.   Date   Release Type   Percentage   2020-05-07   Beta   10%   2020-05- 21   Beta   50%   2020-0 6-05   Beta   100%   2020-06-19   General Availability   10%   2020-07-10   General Availability   50%   2020-08-04   General Availability   100%     ... View more