Munchkin across local/dev/live environments?

[Marissa_Cookson]

Hi all,

My agency builds client websites and we have a setup of local, development, and live server environments. We're onboarding a couple of clients to Marketo, and I'm wondering what the best way is to integrate Munchkin code from an agency perspective.

- Munchkin is domain specific, so would it even work in our other development environments?

- If Munchkin is not on our dev server, how do we test forms that will submit to Marketo via the API?

- Can you block your in house team from becoming leads? Or would you just segment them

What is your approach to Munchkin integration and form testing?

[SanfordWhiteman · Accepted solution]

- Munchkin is domain specific, so would it even work in our other development environments?

Munchkin isn't domain-specific. A single Munchkin ID can be used on any number of domains. It's the ID (and, optionally, workspace ID) that determine which Marketo database is updated.

You can also send Munchkin activities to multiple Marketo instances at the same time (each with its own Munchkin ID). This is not exactly resource-efficient, but it is supported (the Munchkin init option altIds allows this).

- If Munchkin is not on our dev server, how do we test forms that will submit to Marketo via the API?

Well, first of all, you should not use any API -- besides the client-side Forms 2.0 API, of course, which is used by native Marketo Forms -- to submit forms. To do anything else creates a Denial of Service vulnerability.

Second, Marketo Forms and Munchkin are complementary but they a re not actually interdependent. A form post works fine without Munchkin and will upsert the corresponding Marketo lead. Where Munchkin comes in (and it is an important feature, just not critical to the operation of the form itself, and actually a different testable unit) is in associating past and future web activities with the now-identified lead, as well as in related features like Progressive Profiling and Known Lead HTML (both of which imply access to the associated lead's activity history).

So if you do not run Munchkin on your dev server, but you do (as you should in a professional context) use standard Marketo Forms to submit to Marketo, you'll get leads, but not a complete activity trail.

What is your approach to Munchkin integration and form testing?

You're going to need test leads or else you won't be able to test. You can segment test leads, making sure that people use a consistent naming pattern (like plus addressing: test+099@example.com) that can be predictably found using Smart Lists.

[Marissa_Cookson]

Thanks, appreciate the quick reply!

"Munchkin isn't domain-specific" - sorry I got confused with cookies.

[SanfordWhiteman]

Well, you want to use different registered domains for your local, dev, and live environments. Otherwise, unless you deliberately tell Munchkin to set its cookies at the full current domain (i.e. at .www.example.com instead of at .example.com) you will end up sharing cookies and majorly messing up your testing. You should probably read this post: http://blog.teknkl.com/munchkin-2-letter-tlds-broken/

[Marissa_Cookson]

"It's the ID (and, optionally, workspace ID) that determine which Marketo database is updated"

Our partner instances are currently getting setup, and their domains are defaulting to my agency's domain. Is the Munchkin ID enough to get the lead behaviour to the correct instance, or should we wait until the IT setup is complete and the client domains are correct in admin before adding Munchkin to their sites?

[SanfordWhiteman]

Cookies are, by default, unique to every unique cookie domain+Munchkin ID combo (it's best not to toy with this dedupe key unless you have a very strong need).

There's no limitation on the domain names that can be used by a given instance. Nor (this is slightly different) is there a limitation on the number of instances that can use a given domain (i.e. lp.example.com can be used by Marketo customer A or customer B, depending on who owns the domain -- or by anyone who sets their HOSTS file, for that matter).

So setting the Munchkin ID in the call to Munchkin.init() is the way you tell the Munchkin library which Marketo instance gets the hits, simple as that.

But what you don't want to happen is that a test visitor is already associated with a lead in instance A when they go to your dev site for that same instance, instance A. Using only incognito windows for testing, and always closing and reopening before opening another site, safeguards against this. But an, er, safer safeguard is to use different registered domains that can never accidentally share cookies, like example.com and example-demo.com.