Product Documents

March 2023 update: The deprecation of the legacy URL patterns will occur on August 1, 2023.   June 2022 update: We have decided to extend the deadline until the end of 2022 with support of old URL patterns ending in January 2023. More information to be provided once a precise date has been chosen.   In 2021, Marketo Engage made changes to the URL structure for Landing Pages, Forms, and Images & Files assets. On August 1, 2023 we will be deprecating usage of old URL structures and these references will no longer load on the web.   Why is this change being made? Technical Details Landing Pages Images & Files Forms What customer action is required?   Why is this change being made? When a Marketo Engage subscription is not configured with a branded CNAME, Design Studio assets use a common hostname shared among all customers on the same pod. This behavior can be exploited in a phishing attack where a user cannot be sure a link to a Marketo Engage hosted asset belongs to the business they expect it to belong to. By updating each instance to use its own unique hostname, it is clearer to users the destination of URLs they are accessing.   Now that all Marketo Engage subscriptions have been migrated to our new URL structure for some time, we will be ending support to the legacy, more vulnerable URL structure.   Technical Details Landing Pages, Form embed code, and resources stored in Images & Files had URLs updated from a hostname shared among all subscriptions on the pod to a hostname unique to each Marketo Engage subscription. Subscriptions configured to use a custom CNAME for their landing pages were minimally affected by this change. Landing Pages Subscriptions without a configured landing page domain Landing page paths will changed to a unique hostname for your subscription. Legacy: http://na-sj01.marketo.com/lp/123-ABC-456/unsubscribePage.html Current: http://123-ABC-456.mktoweb.com/lp/123-ABC-456/unsubscribePage.html   Subscriptions with a configured landing page domain Landing pages will continue to load from your configured landing page domain. No changes will be made. Before: http://example.marketo.com/unsubscribePage.html After: http://example.marketo.com/unsubscribePage.html   Images & Files Subscriptions without a configured landing page domain Paths to resources stored in Images & Files changed to a unique hostname for your subscription.   Legacy: http://na-sj01.marketo.com/rs/123-ABC-456/images/cuteKitten.png Current: http://123-ABC-456.mktoweb.com/rs/123-ABC-456/images/cuteKitten.png   Subscriptions with a configured landing page domain Resources stored in Images & Files will continue to load from your configured landing page domain. No changes will be made.   Before: http://example.marketo.com/rs/123-ABC-456/images/cuteKitten.png After: http://example.marketo.com/rs/123-ABC-456/images/cuteKitten.png   Forms Subscriptions without a configured landing page domain OR subscriptions without landing pages secured by SSL Legacy:     <script src="//app-sj01.marketo.com/js/forms2/js/forms2.min.js"></script> <form id="mktoForm_1"></form> <script>MktoForms2.loadForm("//app-sj01.marketo.com", "123-ABC-456", 1);</script>     Current:     <script src="//123-ABC-456.mktoweb.com/js/forms2/js/forms2.min.js"></script> <form id="mktoForm_1"></form> <script>MktoForms2.loadForm("//123-ABC-456.mktoweb.com", "123-ABC-456", 1);</script>       Subscriptions with a configured landing page domain secured by SSL In our October 2020 release, we updated our form embed code to load from the landing page domain when it is secured by SSL. No further changes will be made. Before:   <script src="//example.marketo.com/js/forms2/js/forms2.min.js"></script> <form id="mktoForm_1"></form> <script>MktoForms2.loadForm("//example.marketo.com", "123-ABC-456", 1);</script>     After:      <script src="//example.marketo.com/js/forms2/js/forms2.min.js"></script> <form id="mktoForm_1"></form> <script>MktoForms2.loadForm("//example.marketo.com", "123-ABC-456", 1);</script>       What customer action is required? You will need to audit the source code of your web pages to see if these URL patterns are in use by your business. If you have web pages or form usage that pre-date 2021 it is possible they are using the legacy URL pattern.  Most customers configure a CNAME and secure it via SSL early in the life of their instance, minimizing the impact on Images & Files URLs. Prior to our October 2021 release, all form embed codes used the legacy URL structure. If you have usage of Marketo forms from prior to 2021 it is very likely they will need to be updated to use the new URL pattern, which can be found by copying the form embed code from the Form asset page.   For Marketo Landing Pages and Emails, if you used the Image picker or Form picker that are included in the Landing Page editor or Email editor then no change is necessary. If you hard coded references to images or forms using the legacy URL pattern instead of using the pickers then these references will need to be updated to the new URL pattern.   Customer Support does not have the ability to perform this audit for you.   To begin preparing for this change, we suggest doing the following: Configure your Landing Page URLs with a CNAME https://docs.marketo.com/display/public/DOCS/Customize+Your+Landing+Page+URLs+with+a+CNAME Secure your Landing Pages with SSL https://docs.marketo.com/display/public/DOCS/Add+SSL+to+Your+Landing+Pages Begin updating pages where you embed Marketo Engage forms with the new embed code introduced in our October 2020 release (requires secured landing pages) Begin an audit of where you reference Design Studio assets on the web. This will help you begin a plan to update any existing references to our older URL structure before we begin deprecation in August 2023. Generally this will be on non-Marketo pages, as our Landing Page editor will automatically format embedded images and forms in a compatible manner. Only references hardcoded to the old URL structure need to be updated, e.g.  http://na-sj01.marketo.com/rs/123-ABC-456/images/cuteKitten.png. Relative references will continue to work without need changes e.g.  /rs/123-ABC-456/images/cuteKitten.png. Please work with your web developer to determine where you may need to make updates.

Starting in the October 2022 release, we introduced a minor change to Marketo REST API response message.   What is changing? First, let’s begin by looking at the standard defined by the Internet Engineering Task Force (IETF) in RFC 9110.    In particular, the standard for Control Data in response messages: “Response message control data includes a status code, optional reason phrase, and protocol version.”   For example, typical response message control data for a successful HTTP request would be “200” for status code, “OK” for reason phrase, and “HTTP/1.1” for protocol version.   Now, let’s cover what is changing.   The reason phrase will change depending on the deployment of infrastructure.   Why is this change being made? As part of ongoing maintenance, we must update infrastructure components to newer versions to keep pace with industry change.   What customer action is required? Action is required if you use an integration that is built using the Marketo REST API and that integration depends on the reason phrase.  If so, then your integration must be changed to remove dependencies on the reason phrase and instead should rely on the status code.   Note that this is an unlikely scenario as most HTTP libraries and integrations already use the status code.   When must customers make the change? As soon as possible.   What if customers don’t act? Integrations using the Marketo REST API may not function correctly.

In the March 2023 Marketo Engage release, we will be changing several values used to populate the Inferred Country field for new Persons.   What is changing? Several of the values used to populate the Inferred Country field are changing.  More information on inferred fields can be found here. The following table shows the values that will change.   Inferred Country Field Value Changes January 2023 March 2023 Bolivia, Plurinational State of Bolivia (Plurinational State of) Cape Verde Cabo Verde Congo, the Democratic Republic of the Congo (Democratic Republic of the) Czech Republic Czechia Holy See (Vatican City State) Holy See Iran, Islamic Republic of Iran (Islamic Republic of) Korea, Democratic People’s Republic of Korea (Democratic People’s Republic of) Korea, Republic of Korea (Republic of) Micronesia, Federated States of Micronesia (Federated States of) Moldova, Republic of Moldova (Republic of) Swaziland Eswatini Taiwan, Province of China Taiwan (Province of China) United Kingdom United Kingdom of Great Britain and Northern Ireland United States United States of America Venezuela, Bolivarian Republic of Venezuela (Bolivarian Republic of) Virgin Islands, British Virgin Islands (British) Virgin Islands, U.S. Virgin Islands (U.S.)   Why is this change being made? We are updating the 3 rd party data source used to lookup demographic and firmographic information based on client IP address.   What customer action is required? Action may be required if you use an Inferred Country filter in a smart list.  The first step is to identify all smart lists that contain the Inferred Country filter.  Do this by going to Admin > Field Management and selecting Inferred Country field from tree on righthand side.  Then click the Export Used By item from Field Actions menu to export relevant smart lists.   Inferred Country - Export Used By             Inferred Country - Field Used In             The second step is to examine each Inferred Country filter definition for each row in Field Used In column and compare against the January 2023 values in table above (column 1).  If the filter definition matches a value in the table, then action is required to ensure that new Persons will continue to qualify for the smart list.  The action needed depends on which operator is used in the filter definition.    Let’s go through a few examples to help illustrate.   Example 1: “is” Operator Persons with “Inferred Country is United States” qualify with this filter.       In this case we see “United States” in the table, so action must be taken.  To qualify persons with either January 2023 or March 2023 values, add a second filter using “United States of America” as shown below.          This way Persons with either “Inferred Country is United States” OR “Inferred Country is United States of America” will qualify.   Example 2: “starts with” Operator Persons with “Inferred Country starts with United States” qualify with this filter.       No action is needed since “starts with United States” will match either “United States” or “United States of America”.   Example 3: “starts with” Operator Persons with “Inferred Country starts with Cape Verde” qualify with this filter.       In this case we see “Cape Verde” in the table, so action must be taken.  This will not qualify Persons with either January 2023 or March 2023 values since “Cabo Verde” does not “start with Cape Verde”.  The solution here is to replace “starts with” filter with two “is” filters as shown below (like idea shown in Example 1).           This way Persons with either “Inferred Country is Cape Verde” OR “Inferred Country is Cabo Verde” will qualify.   Example 4: “contains” Operator Persons with “Inferred Country contains United States” qualify with this filter.       No action is needed since “contains United States” will match either “United States” or “United States of America”.   Example 5: “is empty” Operator Persons with “Inferred Country is empty” qualify with this filter.       No action is needed because the filter definition does not contain a value and thus cannot match a value in table.   Here is a list of related product documentation: Understanding Smart Lists Define Smart List Filters Inferred Filters Export Used By Data for a Field When must customers make the change? Before the release that is currently scheduled for March 24, 2023.   What if customers don’t act? Persons entering Marketo Engage after this change may not qualify for smart lists that contain Inferred Country filters.  Existing Persons are not impacted so they will continue to qualify as before.

If you are an authorized support contact for multiple different accounts with the same email address and Marketo login name (typically we see this with consultant profiles) you will need to follow a different process to submit a support ticket. Typically these profiles will have Universal ID for several different Marketo instances across different accounts. NOTE: Once you are an authorized support contact for more than 1 account, you will no longer have the ability to submit a support ticket through support@marketo.com.   You will need to submit your support ticket through the support portal by following the instructions below:   1. Log into your Marketo instance, click on the community tile from the 'My Marketo' page, navigate to the support tab, and click on the 'My Case Management' button. IMPORTANT NOTE: You want to make sure you do NOT click on 'Open New Case' from the main support page because you will not be able to select which account you would like to submit a support ticket for.   2. On the Case Management page, select the account you would like to submit a support ticket for by clicking on the dropdown next to the 'Create a Case' button.    3. Select the 'Create a Case' button and submit a support ticket.   You should now be all set to submit support tickets as an authorized support contact for multiple different accounts! If you have any issues or questions with this process, please reach out to the Customer eXperience and Identity team by emailing marketocares@marketo.com.    

If you are invited into a second instance with Universal ID (UID) enabled, you will need to follow the process below to ensure that you are accessing your second instance correctly. IMPORTANT NOTE: When an admin user in Marketo is inviting you into a second instance, in order for Universal ID to work correctly they will need to invite you with the exact same Marketo Login name and Email. Doing this correctly will allow you to toggle between both instances with UID.   1. Open up your Marketo new user invite email with the subject "Marketo Login Information" from no-reply@marketo.com. Click on the "Login to Marketo" hyperlink in the email   2. You will be taken to a 'Login page'. NOTE: When you are invited into your very first instance you are taken to the 'Create a Password' page but since this is your second or third or fourth instance you have been invited into with UID, you will be prompted with the login page below.  You will enter your login credentials for your original Marketo instance, click on the "I accept the terms and conditions" checkbox, and then select the sign-in button.   3. You will be logged into the new Marketo instance and you should see a grey arrow next to the instance name in the upper right-hand corner. You can click on the instance name, and you should see a drop-down with all the instances you have access to (in this case just 2).    You should now be all set! If you have any issues with that process, you can reach out to the Customer eXperience and Identity team (CXI) for further assistance by emailing customercare@marketo.com. 

As of November 2020, Marketo Measure was migrated into the Adobe Admin Console. What this means is that user management for Marketo Measure is now done through the Adobe Admin Console. Because of this, anyone who needs to be a Marketo Measure user will need to be added through the Console. For security reasons, only your organization’s System Admins can manage users.   System Admins can add Marketo Measure users by following these steps:    Navigate to https://adminconsole.adobe.com  Log in with your Adobe ID (select “Company or School” account type)  Click on the “Products” tab  Click on your Marketo Measure product card  Add the desired user to the product card. Once the desired users are added, they can navigate to https://apps.bizible.com/ and log in with their Adobe ID.  If a user needs admin permissions within Marketo Measure they will also need to be added in the 'admin' section of the Marketo Measure product card.   If you or your System Admins are having any issues with this process, please reach out to the Customer eXperience and Identity team (CXI) by emailing marketocares@marketo.com          

As a Marketo Measure only customer, you need to be set up as a Marketo Measure Only Support Contact to submit support tickets for Marketo Measure through the Nation (nation.marketo.com). IMPORTANT NOTE: Although user management for Marketo Measure is done through the Admin Console (adminconsole.adobe.com), support for Marketo Measure is still done through the Marketo Nation support portal.    In order to get set up as a Marketo Measure Only support contact, you will need to reach out to the Customer eXperience and Identity team (CXI), formerly the Customer Care team, by emailing marketocares@marketo.com and request to be added as a "Marketo Measure Only Support Contact". NOTE: The Customer eXperience and Identity team may require approval from your Account Manager (CSM, SAM, VSM, etc.) before setting you up as a Marketo Measure only support contact. If you can copy your account manager on your email or have them submit the request for you, this will move the process forward quicker.   Once the CXI team has confirmed that you need to be added as Marketo Measure only support contact, they can create your support contact profile and provide you with your login credentials.   Once you have your login credentials you can access your support portal by doing the following: 1. Navigate to nation.marketo.com 2. Click on ’Sign In” in the upper right hand corner 3. Click on the ‘I am an Adobe Marketo Measure (Formerly Bizible) ONLY customer or an Adobe Marketo Engage Sales Connect ONLY customer’ button 4. Enter in your credentials 5. Click on the 'Support' tab across the top of the page   You are all set! You can now create and manage your support cases as a Marketo Measure only customer.      

In September 2022, we released two Marketo Engage Performance Tier packages: Performance. Additional performance to meet the needs of high demand marketers. Performance Plus. Highest level of performance to meet the needs of any marketer. When you purchase a performance package, additional infrastructure is allocated to your Marketo Engage subscription. This allows your subscription to scale to meet increased demands.   Each package has a set of defined thresholds for various capabilities as described below. The thresholds represent the highest level of performance that can be achieved when using best practices. Exceeding a threshold may adversely impact performance or cause undesired product behavior. Each threshold falls into one of four categories: Entitlement, Scoping Parameter, Performance Guardrail, or Static Limit. For category definitions, and threshold values, please see the Marketo Engage Product Description here. If you would like to know how your current product usage compares with these product thresholds, please contact your account representative.   Note: Nothing changes in how Marketo has always operated, it still is a multi-tenant system and the mileage one gets is dependent on overall activity level within the subscription as well as within the data center. Published values should not be interpreted as throughputs one should consistently expect. Rather, the values represent the maximum performance thresholds/guardrails beyond which purchasing a performance package would become required.   Activities Marketo Engage supports a wide variety of activity types which are related to Person records. Every data change, action, or flow step is recorded against a Person’s activity log. These activities can be leveraged in Smart List and Smart Campaign filters and triggers. There are two activity-related scoping parameters: Maximum Number of Activities – Rolling 7-day Average Maximum Number of Activities – Peak Per Day The Rolling 7-day Average is the total number of daily activities over a 7-day period divided by 7. The time span goes back several weeks from time of retrieval. The Peak Per Day is simply the largest number of activities observed in a day over that time span.   Campaigns There are two campaign-related performance guardrails: Maximum Trigger Campaign and Segmentation Throughput Maximum Batch Campaign Throughput Campaign performance is highly variable. The type of program, the complexity of the program (smart list filters and triggers, flow steps, etc.), the number of persons that qualify for program all contribute. In addition, environmental factors such as the current load on the system will impact performance. Throughput in the context of campaigns refers to the volume of campaigns that run to completion over a given period. The Standard level of performance represents the base level of performance provided out of the box. The higher levels of performance provided by performance packages are expressed in terms of multiples relative to Standard. Using batch campaigns as an example, a throughput improvement of 8 times greater than Standard can be achieved by using the Performance package (10 times greater when using Performance Plus package).   Email There is one email-related performance guardrail: Peak Batch Email Send Rate Peak Send Rate is the maximum number of emails that can be sent in an hour. Send rates are supported for sustained periods of up to 4 hours per day, and up to 4 days per week. Marketo Engage supports both shared and dedicated IP addresses.  When you use a dedicated IP to send email, your messages are sent from a unique and exclusive IP. As such, you have complete control over your email sender reputation and thus email deliverability. Multiple dedicated IP addresses are used to efficiently distribute large email volumes leading to higher throughput. To achieve the highest send rate available using Performance Plus, you must use 5 dedicated IP addresses (Email Delivery Services and Power Pack are included).   CRM Sync There is one CRM Sync-related performance guardrail: Peak Sync Rate with CRM System Peak Sync Rate is the maximum number of records that can be synchronized in an hour and in a day. Sync rates are supported for periods of up to 10 hours per day. The rates for Salesforce and Veeva are similar due to using the same underlying technology. Sync rate performance is highly variable due to the nature of the sync process. The CRM vendor's API response time, the number of objects and records and fields within each record, whether creating new records versus updating existing records, all these things impact performance.   API There are two API-related static limits: Maximum Purchasable Number of API Calls Maximum Purchasable Size Limit for Bulk Extract Jobs Number of API Calls is the maximum number of calls that can be made: In a day (daily quota) Over the time span of 10 seconds (rate limit) At the same time (concurrency limit) Purchasable means that these limits can be increased by purchasing a Performance, Performance Plus, or in some cases by purchasing an addon. Please contact your account representative for more information. These static limits are strictly enforced. Exceeding a limit will cause the API to return an error.   Data Model There are six Data Model-related static limits: Maximum Number of Custom Object Records Maximum Number of Custom Objects Maximum Number of Fields per Custom Object Maximum Number of Custom Activities Maximum Number of Fields per Custom Activity Maximum Number of Fields per Contact Custom Object Records refers to the number of database rows that have been written for a given custom object. Custom Objects refers to the number of custom object definitions.  Fields per Custom Object refers to the number of fields defined within a custom object definition. Custom Activities refers to the number of custom activity definitions.  Fields per Custom Activity refers to the number of fields defined within a custom activity definition. Fields per Contact refers to the number of custom fields defined for a Person. Custom objects are most efficient if the fields are defined when objects are first created. Fields that are defined afterwards are slower to insert and update. If updates are not needed, then custom activities should be considered as an alternative. In many cases it is better to have several custom objects with fewer fields versus a single monolithic custom object with many fields. Consider your schema carefully before finalizing on usage.   Data Ingestion There are two Data Ingestion-related performance guardrails: Maximum Number of Web Page Visit Activities Processed Maximum Number of Form Submissions Processed There are two web page visit activities: Visit Web Page, Clicked Link on Web Page. Both occur when a person interacts with a web page that has been instrumented with Lead Tracking JavaScript.  Marketers should only instrument web pages that are related to marketing campaigns. Typically, these are landing pages that are placed in the body of an email. When a person submits a Marketo Form, a Fill Out Form activity is generated.  Forms can be hosted on Marketo landing pages or on a customer/external landing page (embedded). Settings for the Standard package are sufficient to handle typical web page visits, and form submission volumes.  If not, you may see a lag between the actual time of activity and time when the activity is available within Marketo. If you have trigger campaigns that leverage either of these activity types, high volumes can cause the trigger campaigns to fall behind.   Segmentations There is one Segmentation-related static limit: Maximum Number of Segmentations This is simply the number of Segmentations that can be created in a subscription.  Segmentations are implemented as a system triggered smart campaign. The campaign is triggered when a field in the Segment Rule is updated.  If the rule references many fields and/or the referenced fields change frequently, this can adversely impact performance.   Engagement Programs There is one Engagement Program-related static limit: Maximum Number of Engagement Programs This is simply the number of Engagement Programs that can be created in a subscription.

Hello Nation!   Based on the feedback from you, we have released a couple of interesting updates to the Filtering email bot activity. If you haven't had a chance to look at updates from the last release, here is the link: https://nation.marketo.com/t5/product-blogs/filtering-email-bot-activity-feature-v2/ba-p/322774   In the latest release, the focus was on improving the sophistication in capturing activities by bots. We are launching a new method to identify bot activities "Match with Proximity pattern". So, now we have a total of 2 methods that will be used to filter every email open or email link click activity.   The 2 methods are: Match with IAB bot list: Activities that match with the list UA/IPs from IAB will be marked as bots Proximity pattern: When more than 2 activities happen at the same time i.e under 2 seconds, they are identified as bots too. This pattern should identify activities generated by the link scanners. In the future this method will be enhanced to consider clicks coming from hidden links as an additional data point   So, if you enable the email filtering feature on your subscription, every email open or email click activity will go through the bot identification filtering i.e through the 2 methods in the order mentioned above.    Note: You will have the option to filter out i.e not log activities that are identified by the IAB list but not for proximity pattern in this current release.   If you wish to have all activities, whether they are by a bot or not, then choose the "log activity" option. This way, all activities will still go through identifications using the above-mentioned methods but will be logged into your Marketo subscription. Any email open or click activity matches with any of the 2 methods, it will be labeled as bot activities using the 2 new attributes we introduced in the last release. So, Activities that are identified as bots will have "Bot Activity" as "True" and Bot Activity Pattern as "Match with IAB list"  or "Match with proximity pattern" Activities that are identified as not bots will have "Bot Activity" as "False" and Bot Activity Pattern as "N/A" Activities that happened before we introduced these attributes will have "Bot Activity" as " " (empty) and Bot Activity Pattern as " " (empty) As you might already know, you can use these attributes as constrains in filters and triggers   To know the impact or to know what type of bots spamming your email engagement, we have added the ability to view the number of bot activities that are identified against each pattern to the admin page   Continuing on the feedback themes:   Themes Description Status More Transparency The current version identifies the bot and doesn't log activities identified as bots. Almost every customer and community expressed they would like to log the activities and do their own analysis Released (Added option to opt for logging and flag activities that are identified as bots) More Robust filtering The current version completely relies on the IAB list and we need to introduce more sophisticated filtering to identify bot activities Released (Added a new methods to identify if an activity is by a bot or not)  More Control We find a few user-agents/IPs that are creating bot activities and would like to include them in the bot activity filtering criteria Gathering requirements (If you have any feedback on this please share it in the comments) Reporting (new feedback item) In the Email performance report, we want an option to filter out bot activities so that we can see the metrics with and without bot activities  Gathering requirements (If you have any feedback on this please share it in the comments)  

In our June 2022 release notes, we have announced that functionality Forms 1.0 assets will be completely removed from Marketo Engage including the ability for form submissions to be made to the leadCapture/save endpoint. This change will irreversibly break Forms 1.0 assets on Marketo Engage Landing Pages or embedded in external websites so that they can no longer accept submissions. Our modern Forms asset, Forms 2.0, will continue to be supported and will face no interruptions.   To aid in identifying which Forms 1.0 assets are in your subscription we have created a tool accessible by users with the Admin role. To use the tool, follow these instructions:   Navigate to Admin -> My Account. Take note of your data center in the “Support Information” panel. In your URL bar, navigate to app-[your data center].marketo.com/supportTools/formIdentification. In the tool, click “Get Form 1.0 List”. Your list of Forms 1.0 assets are returned. Each Form name is a hyperlink that will open in a new tab to the Form Asset page where you can view more information including what Marketo Landing Pages the Form is used on. Only references to Marketo Landing Pages will be of concern; references to these Forms will continue to work in Smart Lists filters.   The Forms 1.0 assets will be disabled on October 14, 2022 with no option for extensions or exceptions. Please complete your review of your form usage beforehand and replace any in-use Forms 1.0 asset with an equivalent Forms 2.0 asset.    

Apple recently announced new features in their upcoming iOS and macOS releases which are designed to protect data from third parties. A broad set of FAQs on the potential impact can be found on Adobe Experience League. We have provided an additional set of Marketo Engage-specific FAQs below. Since the new features have not yet been released by Apple, much of the information below is speculative. We plan to post updates as we learn more, so please stay tuned.  UPDATE: iOS 15 is now generally available on both iPhone and iPad.  We have conducted tests using iPhones running iOS 15 with Mail Privacy Protection enabled.  Please see updates to this FAQ below (in red).    Will this impact email open-tracking in Marketo Engage?  Highly likely. Early reports suggest that the open-tracking pixel contained in Marketo emails may be obscured and downloaded as a background process, irrespective of how you interact with the email. It is possible that an email open could occur without opening the email, which could artificially inflate the number of email opens. Also, the timing of when an email open activity is generated could be impacted since it may be decoupled from the actual open.  UPDATE: Yes, we confirmed that unopened emails can trigger an email open activity.   Test Methodology We used a batch campaign to send a test email to 5 testers with Mail Privacy Protection enabled on their iPhones.  We instructed each tester to not open the email and then waited 1 week before checking results.  Create a static list of test leads Create a batch campaign to send an email to members of static list Run campaign once Wait for 7 days and inspect campaign results   Observations After the 7 day wait, we found that 3 of the 5 unopened emails had open email activities logged in Marketo.  These activities were “machine-generated” due to a background load of the open-tracking pixel that occurs when Mail Privacy Protection is enabled.  For the 3 machine-generated opens, we found that 1 occurred within minutes of delivery, and the other 2 occurred several hours after delivery.    We then had testers go ahead and open the delivered emails.  For the 2 emails that did not machine-generate an open,  we found 2 email open activities were logged as usual.  For 3 emails that did machine-generate opens, no additional open activities were observed as expected.  This is because Marketo only ever records a single email open activity for any given campaign/mailing/lead combination.   We ran same test with Mail Privacy Protection disabled and did not observe any machine-generated opens.   To summarize: When Mail Privacy Protection is enabled, some delivered emails will have machine-generated opens, and the timing of when machine-opens occur is unpredictable. When Mail Privacy Protection is disabled, no machine-generated opens occur. Will this impact email link click tracking in Marketo Engage?  It is unlikely that tracked links will be impacted.  UPDATE: No, we confirmed that click email activities are logged as expected.  No change here.   Which product areas within Marketo Engage might be affected?  While there is no immediate impact right now, here is a quick look at the potential areas of impact within Marketo Engage.   Assuming that email opens may not be accurately trackable in the native Mail app, and that a user’s IP address will be altered by the native Email app and the Safari browser, we have identified the following areas of potential impact.  Activities It is hard to predict what the impact will be on the “Open Email” activity. For example, if the open-tracking pixel request is generated even though the email is not actually opened, then email opens could be overcounted. Also, the time of the open-tracking pixel request could differ from the time of the actual email open. Finally, there are activities that contain a “Client IP Address” attribute which may not be as accurate as before (Visit Web Page, Fill Out Form, Click Link, Unsubscribe Email).  UPDATE: There is no way to identify which open email activities are machine-generated, and which are not.  Machine-generated opens will likely increase the overall number of opens, but by how much is hard to know.   The User Agent on iOS15 has changed to simply “Mozilla/5.0”.  Since some activities contain metadata that is derived from User Agent, some of this metadata has changed (Platform, Device, User Agent, Is Mobile Device).   Open Email Activity - Before iOS15 Open Email Activity - After iOS15   This could impact your smart lists should they leverage these attributes as constraints.   Here is an idea that could help provide insight into iOS15 adoption.    First, build a smart list that looks for leads that have opened email using an earlier version of iOS. Since at the time of writing, iOS15 is only available on iPhone/iPad, we limit results to those devices only. Click on the People tab and record the number of list members (in lower righthand corner). Next, add another filter to smart list for leads that have opened email using iOS15. Since at the time of writing, iOS15 user agent is "Mozilla/5.0", we limit results to that browser only.  This provides the list of leads that have opened email using a prior version of iOS and using iOS15 in past 30 days.  Click on the People tab again and record the number of list members. You can then compare the two results and gain insight into iOS15 adoption.     Here are some of our test results over the past 30, 60, and 90 days. Date of Activity (in Past) 30 Days 60 Days 90 Days Device iPhone/iPad 23,723 38,901 52,964 Device iPhone/iPad & Browser Mozilla/5.0 1,160 2,621 3,444 iOS 15 Adoption Rate 4.9% 6.7% 6.5%   From this list, you can inspect the lead activity history and identify when a lead switched over to iOS15. Your mileage may vary!   Reporting Email opens can be inferred through email link clicks without the open-tracking pixel being activated, but reporting may be impacted. The “Opened”, “% Opened”, and “Clicked to Opened Ratio” columns in Email Performance Report columns may contain less accurate data. Also, any open-related measures or fields in Revenue Cycle Analytics Email Analysis Report may contain less accurate data.   UPDATE: There is no way to identify which open email activities are machine-generated, and which are not.  Machine-generated opens will likely increase the overall number of opens, but by how much is hard to know.   A/B Testing If you use Opens as Winner Criteria, then test results may be impacted since this criteria relies on accurate email open tracking.  UPDATE: See Reporting (above).   Web Personalization The “Location” and “Industry” firmographic Web Segments may not match as they had before. This is because the segment attributes are derived by doing a lookup using the client IP address.  UPDATE: See Inferred Fields (below).   Inferred Fields Since client IP address may not be as accurate, Inferred Fields may be impacted. Send In Recipient Time Zone can use inferred fields to calculate time zone (as a fallback when known location fields are not populated). Lead to Account Matching can also use inferred company name field in matching logic. UPDATE: The client IP address behavior on iOS15 has changed.  To allow users to hide their IP addresses from websites and network service providers, requests now go through an Apple proxy server. The proxy server assigns an IP address from a pool of users grouped by their approximate location.  As a result, the location information stored in Marketo inferred fields will be less precise.  Best practices for using inferred data can be found here.   As a Marketo Engage user, what can I do now to prepare for this change?  Review your usage of product areas described above and assess potential impact. Reduce dependency on email open rates. Look for activities from the click onward to measure engagement. Think about how you measure success of your email campaigns and how email opens fit into your overall methodology. Gather device and OS data to understand potential impact. This can be done using either Email Insights or Smart Lists as described here.  UPDATE: Reduce dependency on email open rates.   As a Marketo Engage user, what should I be thinking about in the future?  Email opens are not the most important indicator for measuring success of your email campaigns. Email is the vehicle by which you drive your customers to a landing page to convert via filling out a form or other action. Web page visits, link clicks, and form fills are the high value activities that you should concentrate on.    Geographic and firmographic data based on client IP address lookup is not entirely accurate since many IP addresses return data for the Internet Service Provider instead of the actual user. In some cases, an IP address lookup will return no data at all. An alternative could be to use a third-party data enrichment service.    Privacy changes are transforming email as we know it. Changes to proxies, location data, and blocked email opens present new challenges to email measurement. Here are Deliverability resources that may prove useful to address those challenges:  Optimizing Marketo Engage Email Deliverability  Email Deliverability 101: 4 Tips to Inbox Success 

October 2021 Update https://nation.marketo.com/t5/product-documents/update-to-deprecation-of-programmatic-form-submission-methods/ta-p/317522#M1062 In January 2021, we released the Submit Form API endpoint to give Marketo Engage integrators the ability to submit to Marketo Forms through a supported and authenticated REST endpoint. Thanks to customer feedback we were able to identify a lack of parity for critical functionality such as correct handling of duplicate records and support for Program Member Custom Fields. These issues blocked some integrators from successfully onboarding onto the Submit Form API endpoint.   In our August release, we have enhanced the Submit Form endpoint to handle duplicate records the same way as Marketo forms. When there are duplicate records that match an email address submitted to the form, the endpoint will update the record with the most recent Last Modified Date.   In our October 22, 2021 release, we plan to release support for Program Member Custom Fields for the Submit Form REST API endpoint. We understand that integrators will need time to update and test these new changes before they can fully onboard onto the Submit Form endpoint. To allow additional time for migration, we are delaying blocking programmatic POSTs to the /save2 endpoint to our January 21, 2022 release. This will be the final extension.   Programmatic submissions to our form endpoints remain unsupported despite this delay. Please work to update integrations submitting via this method to one that is supported: Marketo Engage forms on Landing Pages or using the embed code, our Forms2.js API, or the Submit Form API endpoint. April 2021 Update   In November 2020, we announced that we will forbid programmatic Form POST submissions to our /save and /save2 endpoints beginning May 7, 2021. The reason for this change is to reject methods of unsupported form submissions used by bots to fill customer databases with spam data.   We understand that many customers may need more time to update the integrations to use a supported method such as the Forms2.JS API or the Submit Form REST API endpoint. We have decided to extend the deadline in which we will begin blocking all programmatic Form submissions to take place on October 15, 2021. Programmatic FORM submissions continue to be unsupported and while we are temporarily delaying enabling validation to reject these submissions, we cannot ensure uninterrupted submission following  upcoming product and infrastructure changes.   For customers that still wish to block this method of form submission to address bot attacks,   will allow you to opt-in to form submission validation on your subscription. This validation will check that form submissions are coming from Marketo Forms, Forms2.js API, or the Submit Form REST API and will reject it otherwise. This is expected to block many common sources of bot attacks.   However, if you have a form integration that currently uses programmatic Form POST to submit lead data, enabling this feature will also block your Form submissions. We encourage all customers to migrate to a supported method of form submissions as soon as possible to protect their subscriptions from bot attacks.   The original announcement is below for reference. The details remain the same aside from the schedule to block programmatic form POST submissions.   What’s changing? In our May 7, 2021 release, Marketo Engage will be making changes to our form platform to protect the stability and security of our infrastructure:   Forms 1.0 will be fully deprecated, resulting in loss of functionality of any remaining Forms 1.0 assets still in use. Marketo Engage will begin rejecting form submissions made through unsupported methods, such as programmatic form POSTs to the leadCapture/save and leadCapture/save2 endpoints.   Why is this change being made? On August 1, 2017, Marketo Engage deprecated the Forms 1.0 editor, removing the ability to create or edit Forms 1.0 assets. This change will complete our end of life efforts for Forms 1.0.   In addition, we have found that our Form endpoints “leadCapture/save” and “leadCapture/save2” are common targets for bot attacks. To protect the stability of the Marketo Engage infrastructure, and to aid customers in maintaining a clean database, we are completely disabling the “leadCapture/save” endpoint and enforcing checksum validation on the “leadCapture/save2” endpoint.   What customer action is required? Forms 1.0 deprecation Provisioning of Marketo Engage subscriptions with the ability to create Forms 1.0 assets ended December 31, 2014. If your subscription was provisioned after this date, then it will not have Form 1.0 assets. Forms 2.0 assets will be unaffected by this change.   Marketo Engage subscriptions provisioned before December 31, 2014 may still  be utilizing Forms 1.0 assets on their landing pages and website. These forms will need to be remade in our Forms 2.0 editor and replaced wherever they are still being used.   Programmatic Form POST deprecation Some integrations may be performing programmatic form POSTs to “leadCapture/save" or “leadCapture/save2” to submit data into Marketo Engage databases. This method of data ingestion has always been unsupported and will cease to work as part of this deprecation. All integrations using programmatic form POSTs must be updated to use our Forms 2.0 API, Push Lead REST API, or the Submit Form REST API endpoint releasing in the January 2021 release.   Customers using native Forms 2.0 assets on pages and/or the Forms 2.0 API do not need to take any action. Checksum validation will work natively with these supported methods.   What happens if customers don’t act? Customers that fail to replace any in-use Forms 1.0 asset with a Form 2.0 asset will find that their customers will be unable to submit to their 1.0 Forms.   Customers using integrations that perform programmatic Form POSTs to the “leadCapture/save” or “leadCapture/save2” endpoints will see these integrations fail, resulting in loss of form submission data.   Is my Form 1.0 or 2.0? Forms 1.0 and Forms 2.0 have different look and feel:   Forms 1.0 Forms 2.0 Marketo subscriptions provisioned after December 31, 2014 will only have Forms 2.0 assets.

In January 2021, we released the Submit Form API endpoint to give Marketo Engage integrators the ability to submit to Marketo Forms through a supported and authenticated REST endpoint. Thanks to customer feedback we were able to identify a lack of parity for critical functionality such as correct handling of duplicate records and support for Program Member Custom Fields. These issues blocked some integrators from successfully onboarding onto the Submit Form API endpoint.   In our August release, we have enhanced the Submit Form endpoint to handle duplicate records the same way as Marketo forms. When there are duplicate records that match an email address submitted to the form, the endpoint will update the record with the most recent Last Modified Date.   In our October 22, 2021 release, we plan to release support for Program Member Custom Fields for the Submit Form REST API endpoint. We understand that integrators will need time to update and test these new changes before they can fully onboard onto the Submit Form endpoint. To allow additional time for migration, we are delaying blocking programmatic POSTs to the /save2 endpoint to our January 21, 2022 release. This will be the final extension.   Programmatic submissions to our form endpoints remain unsupported despite this delay. Please work to update integrations submitting via this method to one that is supported: Marketo Engage forms on Landing Pages or using the embed code, our Forms2.js API, or the Submit Form API endpoint.   Previous announcement: https://nation.marketo.com/t5/product-documents/updated-april-2021-upcoming-changes-to-the-marketo-engage-form/ta-p/306631

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.

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.       

In this video you'll learn from Adobe Marketo Engage Champion Courtney Tobe how to track and report on the ROI and revenue impact of your Adobe Marketo Engage programs.   This is a quick tip from our On-Demand Webinar: Beyond the Basics: Marketo Reporting.  

In this video you'll learn from Adobe Marketo Engage Champions Amanda Thomas & Julz James how to build an Adobe Marketo Engage nested nurture program.   This is a quick tip from our On-Demand Webinar: Behavioral-based advanced nurtures.   

In this video you'll learn from Adobe Marketo Engage Champions Amit Jain & Corey Bayless how to generate authentication tokens using APIs.   This is a quick tip from our On-Demand Webinar: Getting Started with Marketo Engage APIs.  

In this video you'll learn engagement program set up best practices from Adobe Marketo Engage Champion Andy Caron.    This is a quick tip from our On-Demand Webinar: The Nitty Gritty of Next Level Nurtures. 

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, this 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.      There 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 take 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 Engage 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.