When to use SOAP API and when to use Munchkin

[Anonymous]

We have two options with the Marketo MA module on our website - using the SOAP API (which is currently active) or using Munchkin (which we used in the past on a previous version of the site). Our developers set up the module to use SOAP, but we recently noticed that somehow the endpoint URL on the website did not match up with our endpoint URL in Marketo. It was not off by much at least. I think this may have been causing some issues, but I can't find much documentation on how to test that things are working as intended. Most of the documentation out there is focused on how to set things up. I'm having a hard time finding anything on checking results.

Is there an advantage on using Munchkin over SOAP API when your website needs to capture anonymous page activity, leads from forms (Marketo and non-Marketo), etc?

[Edward_Unthank_]

Great question, Lee.

There are three APIs that you can use primarily, and which one you want to use depends on what your setup is and what your setup will be in the future.

REST API: This is a more secure version of SOAP, and it offers lots of functionality mostly meant for interacting with objects less frequently than Munchkin. It's less stable than Marketo's SOAP API at the moment, but it has a larger offering of API calls and is growing.

Great cases for this end up being adding and removing leads from static lists (great for triggering marketing events within Marketo because that's the optimal trigger with the lowest amount of noise for large-quantity changes).

Good for Creating/Updating leads and then requesting auto-response campaigns. My normal one-two combo is: (1) Create/Update Lead and then (2) Request Campaign. That will allow you to use progression statuses appropriately for Marketo programs (and SFDC campaigns when synced) for reporting and auto-responses or whatever else you want.

While SOAP has only a few types of objects it can interact with, REST is expanding to other objects such as Asset Objects (folders, email templates, emails, and probably more in the near future).

SOAP API: This is less secure than REST, but (as of writing this) the SOAP API is more fully developed and stable than the REST API for Marketo. Marketo put all their eggs in the SOAP basket when first developing APIs, and only in the last year have started developing for the (more secure) REST API. I like to think of SOAP as good for large-volume updates of non-complicated information.

You can do the same things as the REST API, generally, but this is more tied to the Activity Record, Lead Record, and Opportunity details. I think of SOAP more for porting large volumes of database data to third parties such as for analytics or BI tools.

Munchkin: Helpful when you want website page tracking events like phantom page visits. Phantom page visits are probably the best functionality you can get with Munchkin. I like to think of Munchkin as the web stalking you want to do with lots of information per visitor each session, but the ability to customize those events.

This is great if you have specific product events that you want to track, where people visit fake visits and you use these as hooks to measure product engagement. One of the great drawbacks on Munchkin is that your events don't send success or failure messages, so for the skeptical this means having redundant API calls that clog up your API.

Another major drawback on Munchkin tracking is that it uses one of the noisiest tracking behaviors—page visits—that ends up being the bottleneck on high-volume traffic websites. If you're not careful about how you track things here, I've seen queueing delays of up to 4 hours between hitting an actual page and that page visit being logged in a lead's activity. The same queueing problem happens with lead creation, so that an Associate Lead call via Munchkin can have a 4-hour delay—really a problem if you're looking at email auto-responses upon lead creation or 5-minute followup!

Sanford Whiteman​ can probably pick apart my answer with more nuance and add his own ten-cents!

Cheers,
Edward Unthank | Founder, Etumos

[Anonymous]

So is what you are saying is if we need to do page tracking and form tracking then we should have stayed with Munchkin? Does the SOAP API in Marketo work better when there is a form? I don't know as much about the Marketo side of things, I mainly work on the website. We are having an issue with a smart campaign that was cloned and I am trying to see if maybe the issue is it was set up for Munchkin tracking codes when we are now using SOAP.

[Edward_Unthank_]

Hey Lee, I can't tell from the information what the best solution would be or what the problem is. I would suspect people wouldn't have jumped to a SOAP integration without having good reason to do so, but there are too many moving parts to be able to know from the information so far.

Edward

[Anonymous]

Are there particular reports or Analytics on the Marketo side I can look at to get a better idea of if information is coming in? I've been digging through the Web Activity report and sub reports and see activity from Yesterday. I'll need to take a closer look at the Smart List we have set up for the page we are trying to track. It's using a "visits web page: contains" series of filters. It all started because one of my co-workers was troubleshooting this campaign with people at Marketo and they told him Munchkin was not turned on and that needed to be fixed.

[Edward_Unthank_ · Accepted solution]

There are lots of ways to figure out what's going on, but here's where I'd start.

Here's what I think is going on:

• Someone along the way chose not to implement the Munchkin tracking snippet on the new site. Web visits aren't being tracked. You can verify this by choosing a page and creating a smart list to see if someone visits (new smart list, add a filter "visited web page, web page contains 'why-stealthwatch', within last 90 days").
• Forms are created through Drupal and then the lead information is sent to Marketo through SOAP. You can verify this by sending a test with a unique email address through a form and then checking Marketo's Lead Database to verify that it shows up.

On the front-end, lancope.com does not have Munchkin analytics code on the site. This is either an oversight or (I'm guessing) a business decision based on privacy or security concerns that happened when you implemented Marketo.

It looks like all your forms are Drupal-hosted forms that submit somewhere and then probably through SOAP get communicated to Marketo. That's fine, but it looks like you're missing Munchkin for web activity tracking. If you're not using Munchkin and getting web visit data in the system, you're not using one of the most valuable pieces of Marketo—turning Marketo into a glorified email send platform.

Marketo Support told you that Munchkin needs to be turned on, but I'm guessing that your security ops team or development team purposefully chose not to implement Munchkin tracking on your site.

To test if leads are coming through, find a form that communicates with Marketo (or should communicate with Marketo) and put in a test lead. Then search the Marketo database for that test lead. If it doesn't show up within an hour or two (should be nearly instant), then you have a problem. Create a unique testing email address and search the database for that.

Edward

[SanfordWhiteman]

Like Edward Unthank predicted, I'll chime in and differ a bit.

My stock answer about choosing server-side APIs over client-side Munchkin & Forms is "Show me the design." Show that you understand why you're using a server-side solution and prove it's the best fit.  Many times, SOAP was chosen because you had back-end PHP developers available but no JS devs.  That's a fine reason, but it's not a technical reason, and I'm naturally skeptical that the back-end folks actually built a scalable, error-detecting, queue-based system, nor -- most important -- that they understood that by coupling individual front-end actions to individual back-end calls, they were limiting you to 10,000 somethings per day (assuming SOAP wasn't being used for any other task). Even if 10,000 sounds like a pie-in-the-sky number, this fact must be in your documentation: We can only identify 10,000 new leads per day.

In my answer on this post I elaborate more on my feelings about this.   Like I say there, I'm not pointing the finger only at others.  We ourselves have screwed up by deciding API interactions were more robust, only to not roll out anything even close to robust in practice.

Anyway, it's true that using client-side APIs can introduce latency getting data into your instance if you have a high-traffic site.  But that same high-traffic site is more likely to overflow the 10,000 API call limit.  If I had to choose between slowly getting data and not getting it at all, I'd choose the former!  Of course, you can buy more API calls, but it's really costly.  Definitely if I'm using Munchkin I'm not also using the API for redundancy: that defeats the purpose, IMO.

Lee Jordan​​ as for your site, like Edward said there are multiple questions here: Why is Munchkin not turned on for activity tracking? Was this an informed decision or a confused one, once SOAP was chosen for forms? Were the designers aware that embedded Marketo forms were an option when they chose Drupal-native forms?

[Anonymous]

I have answers to some of this, but I was not part of the pre-launch discussions. I can’t really answer what I do know candidly on this forum either. This has been very helpful information from both of you, and has given me enough to go back to our developers and team and figure out what we need to do. Thank you both!

[SanfordWhiteman]

OK, good luck!