Kevin_Tuttle1

When using webhook connections with Marketo, you will often come across an API connection with a two-step process. The first connection needs to send the authentication information, after which you get back an access token, and then that token needs to be provided in the second (and any other subsequent) queries to provide the necessary authentication. Both the Marketo and SFDC REST APIs follow this model. Marketo's Webhook functionality, though, is only a one-step process, so it's necessary to employ separate Webhook configurations to get this to work.   The first step is to create a new custom field on the Person object to hold the access token value. This field will hold the temporary, generated access token value between webhook connections.   Next step is to create a Webhook just to do the initial authentication step. It will save the returned token value in the Access Token field. Here is an example that connects to SFDC:   The last step is to create the Webhook that does the actual work with the remote API. Here I setup one that can update a Lead's Sync_To_Marketo__c field. Note the custom headers that pass captured Access Token value through on the Authorization header.   ... View more

Unlike more traditional script development, where you can use debugging tools to step through your work, writing Velocity scripts in Marketo, particularly complex ones, can be frustrating as it's challenging to get feedback and make the little tweaks that often lead to resolving those tricky bugs. One trick that I like to use to help with this process is having a Static List of test records ready to go for use in Previewing a sample email (or Landing Page) with the misbehaving Velocity Token.   Here's the code from the previous post that goes through the (sadly uncommon) field where the Person's favorite ice cream flavor(s) information is tracked and adds a line to the email referencing it.   Velocity scripting   And this script works for our very limited use case where we only care about three flavors and aren't concerned with similar variants like "vanilla swirl" that might make our "contains" function behave incorrectly.   Now I'll do the unthinkable and purposefully break the Token by removing a quote like so:   Now, when previewing the email, I get an error like below, which is clearly indicating that there's an issue near the string "rocky" but doesn't provide much more detail beyond that.   If it was a really complex script, the debugging process could involve making a change to the Script, going back to the email, going to Preview, choosing a Person, waiting for that to load, only to find that the problem wasn't really fixed. Fortunately, to avoid this tedious process, you can use a Static List populated with test records. I put one together with ten sample records, all with ice cream preference data populated:   Then, while keeping the Token editor open in one browser tab, I choose to Preview the email in another, picking the above list in the "View By" section of the preview screen. The great part about this is that when you change the person you're viewing in the preview, by clicking one of the arrows next to their name, it refreshes both the email and the Token. So whether you're tweaking the Token, or the email (or both), checking to see if your change worked is just a single click away rather than going through the process of re-opening the email, choosing the person, etc.   After fixing the bug in the Velocity code, all I have to do is click the right arrow to go to the next person in the list and the Token changes are reflected right away and I can see that the update has resolved the mysterious error message and our ice cream message is back as it was before!   In the next blog I'll go into some more complicated use cases that will require a correspondingly more complex structured data format that will make use of some of Velocity's more advanced data functions. ... View more

Through Dynamic Content, Marketo Engage offers a very powerful way to personalize emails and landing pages based on the properties of a Person. Creating Segments allows each Person to be filed into one (and only one) group for a given parameter. A common use case is for personalizing an email based on the language requested by the recipient. Segments can be setup (left) and then used to customize the content of content modules (right).   As you can see, when you have only eight different options, they are all mutually exclusive, and each completely changes the entire content of the block, using Segments with Dynamic Content is a great solution.   But what if the personalization was about something far more important:   You could set up Segments for the various preferred flavors: But to which Segment would you assign the record above? Vanilla? Rocky Road? If you pick one or the other then you're losing information and that Person would always get personalized content for one or the other based on which was ranked higher in priority. You might create an additional Segment called "Vanilla + Rocky Road" just for those that like both, but making one Segment for every possible combination would get unwieldy in a hurry. And if the difference between the two in the content is pretty small, it may not even be worth it.   For situations like this, Marketo Engage offers special Email Script tokens that implement Apache's Velocity Engine - a Java-based scripting language, not, confusingly, to be mistaken for JavaScript.   Upon creating the Token, and clicking "Click to Edit", an editor pops up with a place for the script on the left, and a list of existing custom fields and objects on the right. The Marketo Developers site has documentation with common examples available, and this won't be a general tutorial on Velocity Scripting, but rather tips on the development process, troubleshooting errors, and some common pitfalls for the starting coder.   A functional, if not particularly compelling, example of a script that uses our custom field could be this: You can see that building a script for this field allows for multiple different matching scenarios to happen simultaneously. While the Dynamic Content could only say one or the other, with the scripts, the marketer can empathize equally with those that like vanilla and those that like chocolate. And here is the first gotcha... Gotcha #1: Make sure your field is checked on the right This is one of the most common errors that I see, especially when copying scripts from one Token to another. You must ensure that any fields referenced on the left are checked on the right. Pasting in code will not automatically check any fields in the code itself. Being checked tells the rendering engine that it needs to have that value available and if it isn't checked then your script will have just an empty value for that field.   This is true whether you are selecting standard fields, custom fields (as above), or fields in custom Marketo objects. Any referenced field has to be selected to work.   ... View more

Executive summary An overview of the current functionalities available in both Marketo Engage and Adobe Analytics to get data from the former to load into the latter in an automated fashion.   Data Insertion Options Adobe Analytics offers two methods for loading large amounts of data into its database: a private FTP site for uploading delimited flat-files (up to 50 MB), and API endpoints for directly posting the data. Both sources go through the same internal pipeline once uploaded and are merely different entry points for the data. Adobe Analytics API As with Marketo Engage, Adobe Analytics has both synchronous options for inserting real-time data, and asynchronous bulk import options for loading large quantities of data in a flat-file format.   Data Insertion API Allows for both HTTP GET and POST commands GET commands use less bandwidth but do not return a response. All data is provided via the query string in cleartext. POST commands can also use the HTTPS protocol – where supported Uses a SOAP interface that requires all commands be wrapped in compliant XML Endpoints vary and can be assigned and designated by Adobe ClientCare Note that while this server-side method does provide additional flexibility beyond the client-side JavaScript system, there are data points that can only be collected by the latter. Sample Code (Python) import httplib xml='<?xml version="1.0" encoding="UTF-8"?> <request> <scXmlVer>1.0</scXmlVer> <reportSuiteID>Corp1_rs</reportSuiteID> <timestamp>2010-03-20T10:33:22-07</timestamp> <visitorID>169</visitorID> <ipAddress>10.0.0.1</ipAddress> <pageName>Test Page</pageName></request>' conn = httplib.HTTPConnection("namespace.sc.omtrdc.net:80") conn.request("POST", "/b/ss//6",xml ) response = conn.getresponse() print(response.status, response.reason) print(response.read()) Sample GET query GET /b/ss/[rsid]/0?g=apps.sillystring.com%2Fsummary.do&r=http%3A%2F%2Fapps.sillystring.com% 2Fsummary.do&ip=192.168.10.1&gn=summary&v2=14911&c10=Brazil&vid=1286556420966514130&ts=2009-03-05T01%3A00%3A01-05 HTTP/1.1 Host: [namespace].sc.omtrdc.net Keep-Alive: timeout=15 Connection: Keep-Alive X-Forwarded-For: 192.168.10.1       Data Sources The best solution for asynchronously loading large amounts of data is to setup a Data Source that will allow for the upload of flat files. This API support calls in both REST ( JSON) and SOAP (XML). As with the Data Insertion API, the endpoint will be unique and can be created by Adobe ClientCare.   There are three kinds of Data Sources that can be created: Traffic, WebLog, and Generic. While they use different endpoints, the creation process is the same for all three.   Call one of the Data Source setup methods (DataSource.SetupTraffic, DataSource.SetupWebLog, DataSource.SetupGeneric) to create the type of data source you need. Call DataSource.GetIDs or DataSource.GetInfo to get the Data Source ID of the new Data Source. Call DataSource.BeginDataBlock and, if necessary, DataSource.AppendDataBlock to add data to the new data source and submit the data source to the Processing Queue. Call DataSource.GetFileIDs or DataSource.GetFileInfo to get the File ID of the Data Source file in the Processing Queue. Call DataSource.GetFileStatus to monitor the status of the data source file. When data source processing completes, the data sent through the data source is available in Analytics. Call DataSource.Deactivate to manage the data source as needed. Data imported for the current day should be available about 2 hours later; data for the previous day takes about 3 hours.   References Data Sources API (GitHub) Data Insertion API (GitHub) Adobe Analytics Import Guide Data Sources Overview Data Sources Types and Categories ... View more