Product Documents

Sort by:
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 2 or more activities happen at the same time i.e under 0 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)  
View full article
This article contains information on a legacy performance enhancement project that has rolled out to all customers and, in some circumstances, has been superseded by other performance enhancements. It will remain posted for historical purposes but should not be referred to.   What is “Project Orion"?   As the number of customer touchpoints expands, and the volume of digital signals from customers increases exponentially, modern marketers need a way to harness this data to deliver the personalized experiences that customers expect.   Project Orion is about big data ingestion and processing at speed and scale.   Marketo has spent the past year building a new big data architecture that allows Marketo to ingest and process trillions of customer behaviors. “Project Orion” is the code name of the development project to build a big-data infrastructure and first set of services that take advantage of it.   This platform is built using technologies that were pioneered first at Google, Linkedin or Facebook, such as Apache hadoop, an open framework for distributed storage and processing of high volume data and other scale technologies.   What are the benefits to customers?   The platform innovations include 6 specific scale and performance improvements: Track web events (via Munchkin) on any pages of your site without traffic volume restrictions Find People instantly when searching in the Marketo database Get up-to-date Smart Lists instantly with real-time membership updates and faster loading time Import People lists into the Market database in a fraction of the time Accelerate the import of Custom Activities into Marketo Generate Web Page Activity and Company Web Activity reports in less time   Plus, by establishing Marketo’s big data architecture, it creates the foundation for other next-generation platform services for performance and scale in the future.   Does Project Orion solve issues not on the list above?   Project Orion improves scalability and performance for the use cases listed above. Performance for use cases not on the list above are not expected to improve with Project Orion.   Customers with large data sets often experience the most significant performance gains in these areas. The new architecture doesn’t degrade these or other areas in any way.   When is it available? What’s the roll out plan?   The Project Orion development effort is GA and Marketo’s global data centers have been upgraded to our high-scale infrastructure. The roll out to customers started in Q3 2016.   Project Orion consists platform components/services that each have their own roll out plan and are currently being deployed to customers. Priority is based on customer need - Marketo’s Support Team is proactively monitoring customer instances for performance improvement opportunities related to Project Orion.   What's next for performance and scalability in 2017?   With our new big data architecture, we plan to continue building new platform services to further improve performance and scalability.   To learn more about what we have planned this year, come to the Marketing Nation Summit, April 23rd-26th.   Who can I contact for more information on Project Orion?   For more information on Project Orion, please reach out to your Customer Success Manager. If you’re experiencing specific scenarios where you feel that migrating to the new big data architecture will be beneficial, please have your authorized support contact open a case with our Support Team.
View full article
Introduction    As a Flow Step, the Compute Formula service takes an Excel-style formula, computes it, and returns the resulting value to the selected field.  This facilitates many different types of data transformations and use cases, including date math, text replacement, and composite scoring, among many others.  You can find the repository on Adobe Github.     Prerequisites    To deploy and use the Compute Formula Flow Step Service you will need:  Experience using a command line.  Have git installed and have basic experience in its usage.  Install NodeJS, Node Package Manager (NPM), and the Adobe IO command line tool.  Have an Adobe IO Runtime Account, and permissions to retrieve credentials for Runtime workspaces.  A Marketo Account with Admin Credentials.  An Adobe IO Runtime account.  IO Runtime is currently available as an add-on to subscribers of AEP, AEM, Commerce, or Analytics    Support    While the Self-Service Flow Steps framework is fully supported, Compute Flow is an open-source application built on the framework using Adobe IO Runtime.  Issues specific to the Compute Flow application should be logged on the github repository or on nation.marketo.com.      Deployment    Clone the Repository    In a command line, navigate to the folder where you want to clone the code from the Git Repository for AIO Compute Formula.  From there use the following command to clone to repo:    git clone git@github.com:adobe/aio-compute-formula.git    Obtain IO Runtime Credentials    Make a new project in the Adobe Developer Console, selecting the “Project from Template” option:      Select the App Builder Template and save your project:      Select a workspace, either Production or Stage, that you want to deploy the application to and use the Download All option to download the credentials to the folder where you cloned the repository in the previous step:      Once you’ve downloaded the file locally, from your command line use the following command to use the downloaded credentials for your application deployment:    aio app use <file location>    Render Manifest from Template    Now you’ll need to use the render-manifest script to create a manifest yaml file including your desired API key (this is the API key which you will use later in the installation phase) and log level (info, warn, error, or debug).  Use the following command to render your manifest:  npm run render-manifest <path:'./manifest.yml'> <apiKey> <logLevel>        Install NPM Packages    Now you will need to locally install the dependencies for this project using the following command in your command line:  npm install  Deploy Application and Obtain Service URL    To deploy your application, use the following command:  aio app deploy  Once finished the command line will list out the endpoint URLs of the application.  Copy the URL ending in ‘serviceSwagger’ for use in the next step.      Install and Configure Service    In Marketo, navigate to the Admin->Service Providers menu and use the Add New Service button.  In the dialog box, enter the URL you copied from the previous section:      Then follow the instructions for entering your API key:      In the Incoming Fields section, select the fields which you want the service to be able to write data back to:       You can always come back to change the field mappings later if you are not sure about what fields you want to be eligible for writes at this time.  Follow the rest of the installation guide and then your service will be ready to use in Smart Campaigns  Usage    Flow Step Fields    Formula    The Formula field accepts Excel-style formulas, and supports all of the functions that are supported by FormulaJS.  Lookup and other column-related functions are not available.  Your formula should not include a leading = sign as you would when entering the formula in a cell of a spreadsheet application.  While standalone mathematical statements are supported to some extent, complicated cases should be implemented as Excel functions, as some standard mathematical operators, like ^, have behaviors distinct from the mathematical operation that they represent outside of a JavaScript context.  Strings embedded into the formula field, including tokens for string-like fields, e.g. dates, should be surrounded by quotation marks for functions to behave as they are expected to.  Return String    When returning a value to a string or string-like field, such as a Date or a Datetime, you should select the field you wish to return in the Return String field.  Each field configured as an inbound field for your service will be listed in this field*.  Return Number    When returning a value to a number-type field, like Integer, or Float, you should select the field you wish to return in the Return Number field.  Each field configured as an inbound field for your service will be listed in this field*.    *If the picklist of either Return String or Return Number is empty, or does not include choices which were recently added, you should refresh your picklist choices, either via the refresh button on the flow step card or from the Admin->Service Providers menu.  Example Use Cases    Composite Scoring    A common scoring use case is to create a weighted composite score from two or more other scores.  The Compute Formula Flow Step makes this simple to do.  For this example, you will use two source scores, Behavior Score and Demographic Score, and return the value to a field called Composite Score.  To build our formula, you need to decide how to weight the source scores.  Our hypothetical marketing organization values Behavior scores at 30% and Demographic scores at 100%.  Our formula would then look something like this*:    SUM(PRODUCT({{lead.Behavior Score}}, 0.3), {{lead.Demographic Score}})    *When using numbers between -1 and 1 which have a decimal place, you will need to include a leading Zero (0) when embedding the number into your formula, e.g. 0.8.    If a person record has a Behavior Score of 3 and a Demographic Score of 20, then the resulting composite score would be 20.9.  Scores in Marketo Engage are integers, however, so you should be sure to return a round number.  Use the ROUND() function to make the output an integer.  Now our Formula will look like this:    ROUND(SUM(PRODUCT({{lead.Behavior Score}}, 0.3), {{lead.Demographic Score}}))    Now that you’ve defined your formula, you’ll want to make sure that you’ve configured the fields which you want to write back to, in this case “Composite Score.”  Go to Admin->Service Providers, drill down into the service, and edit the Incoming Fields section to enable the Composite Score field.  Composite Score is a custom field for this example, so if you do not have this field in your instance, you’ll need to create a new one, or use a different score field.      Now let’s put this into practice.  Since this is a composite score, in order for the score to be kept up to date, you need to listen for changes to the source scores to update the composite score when they change.  That means you need a triggered Smart Campaign with Data Value Changes Triggers for both Behavior Score and Demographic Score.        Insert the flow step, populate your formula, and select your desired field to return to using the Return Number field.      Now when you activate this campaign and a person’s Behavior Score changes, then your campaign will activate and return the result to your selected field.              Date Differential/Time in Stage    To measure the efficiency of marketing and sales funnels it is common to measure the amount of time that a person spends in a Marketing Stage.  In particular, the number of days a lead spends in the Marketing Qualified or Sales Qualified stages before the lead is acted upon is a significant indicator of how well aligned the marketing and sales processes are functioning.  While this information is easy to synthesize with a business intelligence application, bringing that same data into Marketo and acting upon it has required complicated API integrations to populate back to person records in Marketo.  With Compute Formula, the process is as simple as defining a formula and your return field.  The DAYS() function counts the number of days between and end date and a beginning date.    DAYS(“{{lead.SQL Date}}”, “{{lead.MQL Date}}”)            Round Robin Lead Assignment    While Marketo provides Random Sample functionality to obtain a percentage-based sample of an audience, some Sales Owner assignment use cases benefit from more fine-grained control over lead assignment.  One example of this is to take the modulus (remainder) of a lead id, using the number of potential owners that you can assign leads to.  Suppose you have 55 potential lead owners, and you want to get an approximately even distribution of leads assigned to a given owner.  One of doing this is to assign each of your owners a number from 1 to 55, and then to take the modulus of the integer lead id.  Our formula would then look like this, where the Number is the lead ID, and the Divisor is the number of potential owners:    MOD({{lead.id}}, 55)    Given an id of 117, the resulting value would be 7.  Our campaign flow would have a Compute Formula step with our formula, and Return Number set to a Sales Owner Seed field, followed by a Change Owner step configured with choices corresponding to each sales owner.               
View full article
Included in this article Summary How Leads Become Known Anonymous Web Activity Logging Triggered Smart Campaigns   Revised 9/15/2023 Clarified Qualification Rules Behavior with regard to the date of a triggering activity   Summary When a person visits a web page with your Munchkin tracking code on it, that web activity is tracked for that anonymous lead. When a lead takes action to become known, a lead record is created in your Marketo lead database and the anonymous web activity that lead had prior to becoming known is included in that new lead record. Any smart campaigns that would have triggered off of that web activity will then fire in the order of when the web activity occurred.   How Leads Become Known There are three main ways that an anonymous web activity record can be converted into a known lead in your Marketo lead database.           1. Fills out form. If the anonymous lead fills out a Marketo form, that will create a new known lead record. The anonymous web activity that lead had before becoming known will be associated to that new known lead record.        2. Clicks a link in an email. Hyperlinks in emails are automatically decorated with a tracking code that is used to associate an anonymous record back to a known lead record. If you have a lead in your database that hasn’t had any web activity yet (like a lead that was added from a list import), when the lead clicks the hyperlink in the email, that tracking code in the hyperlink will associate their Munchkin cookie to your known lead record and all of that anonymous web activity will be logged into that known lead record.        3. API call. You can use an API call to associate an anonymous web activity record to a known lead record. This can be done through a SOAP API syncLead call​, or by a REST API Associate Lead call.   Anonymous Web Activity Logging Anonymous lead activity is housed in a different database. This doesn’t create a lead record until the lead is promoted to a known lead. All activity a lead had prior to becoming known will be logged chronologically in the new lead record with the correct corresponding date/time stamps once the lead becomes known.                  Triggered Smart Campaigns Anonymous leads can’t trigger smart campaigns. However, when a lead becomes known, the active smart campaigns that would have triggered from the anonymous activity will be triggered. All trigger campaigns currently active at the time the lead becomes known will be triggered if the lead took the action being triggered on while anonymous. Only campaigns currently active at the time the lead becomes known will be triggered.                The campaign definition at the time it is triggered is what will be executed. For example, if the campaign has a Score Change of +10 but is changed to +5 just before the lead becomes known, the new lead created will be given a score of 5, not 10. The campaigns that are triggered by the anonymous activity will be processed in order of the activities that occurred, oldest to newest. In the lead’s activity log, all campaign activities (with one exception below) will be logged with the time stamp of when the lead becomes known, right before the New Lead activity. Interesting Moment flow step activities will be backdated to the date and time when the corresponding anonymous activity occurred.                  Not all flow actions in the campaign will be executed. When leads flow through campaigns as a result of the promotion to known lead, only specific flow actions will be processed. All other flow actions will be ignored. The flow actions executed will be:           1. Change Score           2. Interesting Moment           3. Change Data Value           4. Add to List           5. Remove from List Secondary campaigns (campaigns triggered off of activities performed by the campaigns triggered by the lead promotion) will not be triggered.                Pruned activities will not trigger campaigns. Anonymous web activity is not stored forever—it gets pruned over time, so any activity that has been pruned is no longer there to be triggered off of. When determining whether a person will qualify for a replayed trigger campaign, the time that the activity occurred is used.  For example, if you have a campaign listening for Visits Web Page events, and qualification rules set to let leads run through once per hour, each event that is more than one hour apart will qualify the lead for the campaign.  This may lead to several instances of the same campaign running for a person upon promotion to known.
View full article
Apple iOS 17 and Apple OSX Sonoma will introduce changes to how Safari opens URLs with tracking parameters in order to protect user privacy. Details on these privacy changes can be found on Apple’s website https://www.apple.com/newsroom/2023/06/apple-announces-powerful-new-privacy-and-security-features/   Our teams have tested the beta versions of these operating systems to learn how these changes will impact Adobe Marketo Engage emails. We have found that URLs containing our tracking parameter mkt_tok will be impacted in some scenarios by these changes. The mkt_tok parameter is used to help associate browsers to known leads using Munchkin and to render the correct email with the View As Webpage link.   Impact on links in emails The impact these changes have on links in emails will be dependent on whether your links have tracking enabled. Tracked links go through our redirection service which preserves URL parameters when browsing Safari in non-private browsing mode. Links that are not tracked are more susceptible to URL parameters being stripped by Safari. For more information on how to enable or disable link tracking please refer to this documentation https://experienceleague.adobe.com/docs/marketo/using/product-docs/email-marketing/general/functions-in-the-editor/disable-tracking-for-an-email-link.html     Action Track Link Include mkt_tok Resulting URL Impact Open link from Mail or copy/paste link from Mail into Safari ✓ ✓ URL resolves at destination with mkt_tok and third-party parameters intact. Click is tracked. Parameters not stripped. Open link from Mail or copy/paste link from Mail into Safari ✓ X URL resolves at destination with third-party parameters intact. Click is tracked. Parameters not stripped. Open link from Mail or copy/paste link from Mail into Safari X X URL resolves at destination. Third-party parameters may be stripped. Third party solutions may be impacted by stripped parameters. Open link from Mail or copy/paste link from Mail into Safari Private Browsing ✓ ✓ URL resolves at destination with mkt_tok and third-party parameters stripped Click is tracked. Browser is not associated to known lead via Munchkin. Third party solutions may be impacted by stripped parameters. Open link from Mail or copy/paste link from Mail into Safari Private Browsing ✓ X URL resolves at destination with third-party parameters stripped. Click is tracked. Third party solutions may be impacted by stripped parameters. Open link from Mail or copy/paste link from Mail into Safari Private Browsing X X URL resolves at destination. Third-party parameters may be stripped. Third party solutions may be impacted by stripped parameters.   In general, tracked links in emails will not be impacted by these changes in non-private Safari browsing as our redirection service will retain the URL parameters. If the link in the email is not tracked, then URL parameters may be stripped by Safari. If the link is opened in Safari Private browsing, then mkt_tok and some third-party parameters will be stripped regardless of whether the link is tracked and goes through our redirection service. Impact on View As Webpage links Testing has shown some impact on View As Web Page links. Action Method of inserting link Resulting URL Impact Open link from Mail or copy/paste link from Mail into Safari "Include View as Web Page" option in Email Settings URL resolves through tracking service and mkt_tok not stripped No change. Open link from Mail or copy/paste link from Mail into Safari {{system.viewAsWebpageLink}} URL has mkt_tok value stripped View As Web Page does not load and returns an error page Open link from Mail or copy/paste link from Mail into Safari Private Browsing "Include View as Web Page" option in Email Settings URL has mkt_tok value stripped View As Web Page does not load and returns an error page Open link from Mail or copy/paste link from Mail into Safari Private Browsing {{system.viewAsWebpageLink}} URL has mkt_tok value stripped View As Web Page does not load and returns an error page   Our service requires the mkt_tok parameter in the URL to render the personalized version of the email; when this parameter is stripped by Safari it will result in an error page being returned instead.   View As Webpage links that are inserted by the token {{system.viewAsWebpageLink}} are not decorated with CNAMEs and do not navigate through our tracking service and will see their mkt_tok values stripped when opened in Safari as a result. This will result in the user getting an error page.   The change will also affect all View As Webpage Links opened in Safari Private Browsing on iOS 17 and Sonoma regardless of how the links were generated. This also includes View As Webpage links in emails sent before the release of these new operating systems.   Our team has identified a solution to build our View As Web Page links in a way that will not be affected by these privacy changes. This change is currently scheduled for our October 24, 2023 release. View As Web Page links generated by {{system.viewAsWebpageLink}} and View as Web Page links opened in Safari Private Browsing on iOS 17 or OSX Sonoma will not function between when the device is updated to one of those operating systems and our October 24, 2023 release.   To lessen the impact on users opening links in Safari, please use the “Include View As Web Page” option in Email Settings instead of the {{system.viewAsWebpageLink}}. Unfortunately there is no workaround that can be offered in the interim for users using Safari Private Browsing.   As we continue to learn more about these changes, we will continue to update this post.   FAQ Q: Will click tracking be impacted by these changes? A: No, click tracking that create Clicked Link in Email activities will not be impacted by these changes.    
View full article
We are announcing some changes to Adobe Marketo Engage activities that are related to Dynamic Chat. To support new Dynamic Chat offerings announced at Adobe Summit, and to better match standardized naming conventions, we will be updating the names of some existing Marketo Engage activities and attributes and adding additional activity attributes to existing activities. These changes will go into effect in our July release (July 18, 2023 for NLD and LON datacenters, July 21 for AB, SJ, and SN datacenters).   Will these changes impact my business and how? These changes will primarily impact Smart Lists (standalone and in Smart Campaigns), Person Activity Log, and the REST and SOAP APIs:   Smart Lists The names of affected activities and attributes will change in their respective cards. Existing Smart Lists (both standalone and in Smart Campaigns) will continue to evaluate without needing any change in configuration. Filters/triggers referencing the new names of activities or new names of attributes will continue to qualify older activities and attributes with the old naming convention.   Person Activity Logs Newly created activities will use the new naming conventions. Older activities will continue to show the old naming conventions and will not be retroactively renamed. These older activities will still qualify in Smart Lists by referencing them with the new naming conventions.   REST and SOAP APIs Activity ID of affected activities will stay the same. New names of activities and attributes will be returned over the REST API from the Get Activity Types endpoint (/activities/types.json) or SOAP API from the getLeadActivity and getLeadChanges endpoints.   Integrations should be tested to ensure they can support the upcoming changes. If your integration has hardcoded references to activity or attribute names, they must be updated to support both the old naming conventions and the new naming conventions else it will run the risk of interruption.   Updates to the activities are detailed below:   Engaged With Dialogue Activity Name Existing Name New Name Engaged with Dialogue Engaged with A Dialogue   Attributes Existing Attribute Name New Attribute Name Dialogue Name Dialogue Name Page URL Page URL Status Conversation Status Chat Transcript Conversation Transcript   Conversation Summary*   Language*   Workspace* *Denotes new attributes   Reached Dialogue Goal Activity Name Existing Name New Name Reached Dialogue Goal Reached Dialogue Goal   Attributes Existing Attribute Name New Attribute Name Dialogue Name Dialogue Name Goal Name Goal Name Page URL Page URL   Language*   Workspace* *Denotes new attributes   Dialogue Appointment Scheduled Activity Name Existing Name New Name Dialogue Appointment Scheduled Scheduled Meeting in Dialogue   Attribute Names Existing Attribute Name New Attribute Name Dialogue Name Dialogue Name Agent Agent Email Page URL Page URL Status Meeting Status Scheduled For Scheduled For   Agent Name*   Routing Queue ID*   Routing Queue Type*   Routing Queue Name* *Denotes new attributes   Interacted with Document Activity Name Existing Name New Name Interacted with Document Interacted with Document in Dialogue   Attributes Existing Attribute Name New Attribute Name Dialogue Name Dialogue Name Document Name Document Name Document URL Document URL Document Opened Document Opened Document Downloaded Document Downloaded Search Terms Search Terms Page URL Page URL   Language*   Workspace* *Denotes new attributes
View full article
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.
View full article
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.
View full article
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.
View full article
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.    
View full article
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. 
View full article
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          
View full article
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.      
View full article
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.
View full article
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.    
View full article
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 
View full article
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.
View full article
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
View full article
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 full article
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 full article