In this post, we’ll clarify how Adobe Marketo Engage, Munchkin tracking, and MktoForms2 work together by breaking down the different IDs, what they mean, and when each one is created or used.
Modern customer journeys rarely live on a single system. On the web, Adobe Web SDK (Alloy) and Adobe Marketo Engage Munchkin often run side by side, each issuing its own identifiers and tracking logic. How (or whether) these two are deployed together directly impacts which IDs flow into Adobe Experience Platform (AEP), how resilient your identity graph is, and ultimately how well Customer Journey Analytics (CJA) can bring the data together and surface a more complete journey — from browsing, to lead generation, to closed deal.
In this post, we’ll compare the two most common deployment patterns:
-
Web SDK with Marketo Munchkin present
-
Web SDK without Munchkin on the pag
For each scenario, we’ll map all relevant identifiers, show how they land in XDM, and unpack how the data are stitched together in CJA for reporting.
Marketo vs Munchkin
Adobe Marketo Engage is the marketing automation system that manages leads, emails, programs, and campaigns, while Munchkin is the web tracking component of Marketo and consists of a website tracking script in the browser that sends visitor activity back into Marketo and the backend processing. There are more details in the Marketo Engage Lead Tracking API documentation, but we’ll hit the key points here.
-
Marketo Lead ID – A numeric ID (e.g., 100432) created by Marketo for each Lead and used as the primary identifier for a lead record. The ID is a plain integer, auto-incremented by Marketo's database when a lead record is created.
-
Munchkin ID – An identifier for a given Marketo Engage instance. It is in the format of 123-ABC-456 and unique to each Marketo subscription.
-
Munchkin Token – A string that is used to identify a particular browser for a lead. It is generated from the top level domain of the web page where the Munchkin JavaScript is deployed and a random value. They look something like “_mch-marketo.com- 97bf4361ef4433921a6da262e8df45a” but you might see references to an older version of the token that looks like “_mch-marketo.com-1374552656411-90718”.
-
Munchkin Cookie (_mkto_trk cookie) – A first party cookie stored in the browser that is made up of your instance’s Munchkin ID and the Munchkin token for this browser and domain. In this case, the _mkto_trk cookie would have the value “id:123-ABC-456&token:_mch-marketo.com- 97bf4361ef4433921a6da262e8df45a”. Because the Munchkin Token is stored in the Munchkin Cookie, you’ll sometimes see people use either term for the other.
-
The token is what later connects the anonymous visitor to a Lead when they submit a form, click on a tracking link in a Marketo email, or visit a Marketo personalized URL. It is also used to associate web activities with a known lead.
-
It is very normal for a lead to have multiple Munchkin tokens associated with them.
Because the Munchkin Cookie is a first-party cookie, it is only visible on the domain where it is set. If you have multiple domains with Munchkin tracking (e.g., adobe.com and marketo.com), then a lead would have a token for each of these domains.
Similarly, because the token is stored as part of a cookie, it acts to identify a particular browser. Common ways this occurs might include if a lead is visiting your site from both a phone and laptop, or uses multiple browsers on their computer, or clears their cookies.
-
MktoForms2 – The browser JavaScript object window.MktoForms2 is a global object that allows you to create, load, and fetch form objects from your Marketo subscription. In a call like MktoForms2.loadForm("//app-abc.marketo.com", "123-ABC-456", 1234), you supply the base URL to your Marketo instance, your Munchkin ID, and the Form ID that you want to load. See the Forms API Reference for more details.
IDs and when/how they’re set
Option A: Web SDK without Marketo scripts
When you run Adobe Web SDK (Alloy) without Marketo Munchkin on your site, you’re effectively creating two separate identity islands: one in AEP/CJA, and one in Marketo Engage.
What happens when there are no Marketo cookies and no Marketo web activity?
Without the Marketo Munchkin script on the page, the _mkto_trk cookie is never set. That means there is no Marketo Munchkin cookie available in the browser, and no web activity is logged to the Lead based on page views or clicks by Marketo.
When WebSDK isn’t on the page and when a Marketo Engage form is submitted, the submission is sent to Marketo, which then creates or updates a Person (Lead) record using fields such as email and any other mapped form inputs. By default:
-
ECID (Experience Cloud ID) is not part of the form payload.
-
Marketo’s Munchkin tracking uses its own cookie (_mkto_trk) as the primary key for web activity, not the AEP/Experience Cloud ECID.
-
Marketo’s Munchkin tracking script does try to collect and send ECID values opportunistically. If the tracking script sees the cookies, it will send them along as part of the web activities payload.
-
Marketo forms do not have a built-in awareness of the AMCV cookie written by Adobe Experience Platform Web SDK and does not automatically read or submit that value with a form submission.
As a result, Adobe Experience Platform (AEP) (which holds ECID-based profiles and web events) and Marketo Engage (which holds person records with email, Lead ID, etc.) remain logically separate unless you deliberately create a linking mechanism.
Link to the documentation:
On bridging identities (ECID ↔ Marketo person)
Marketo Engage’s Munchkin web tracking script opportunistically sends ECID information along with Munchkin web tracking events. If the Munchkin JavaScript sees any WebSDK cookies visible in the session, it will pass those along with the Munchkin web tracking events. If you have configured your Marketo instance with your Adobe IMS Org ID, then the back-end processing will also associate an ECID that contains your Org ID with the same lead in the Munchkin web event. If you haven’t set up the association or if the Org IDs don’t match, then the ECIDs are discarded. Because Munchkin JavaScript reads the Web SDK cookie when it is visible in the session, Web SDK and Munchkin do not need to run on the exact same page at the same time.
One possible (but not out‑of‑the‑box) approach is:
-
Use client-side JavaScript to read the ECID (from the AMCV cookie via Web SDK APIs), and
-
Write it into a hidden form field that is mapped to a custom Marketo person field, so that it is captured on form submission.
The core problem in Scenario A —
-
AEP has the ECID but no Marketo IDs.
-
Marketo has the Lead ID and email but no ECID.
Without a deliberate bridge (hidden field on form submit), these two systems cannot be joined in CJA and every report that requires connecting web behavior to a known lead will fail.
Option B: Web SDK with Marketo scripts
Depending on whether you do or do not pass the Munchkin ID into AEP.
1. With Munchkin ID passed to AEP
When the page loads, Munchkin sets the _mkto_trk cookie with a Munchkin ID, Web SDK sets or reads the ECID and optionally adds the Munchkin ID into identityMap, both IDs are sent together to AEP and treated as identities on the same profile, a form fill then links the Munchkin ID to a Lead via email in Marketo, and finally the Marketo Source Connector sends Lead ID, ECIDs, and lead attributes into AEP to enrich that stitched profile. One thing to highlight is that AEP can receive multiple Munchkin ID (Marketo subscription), but Marketo will only do one Adobe Org ID. Check with the data architectures for identity Merging and business requirements.
2. If no Munchkin ID is passed to AEP
When the page loads, Munchkin still sets the _mkto_trk cookie in the browser and Web SDK sets or reads the ECID, but if the Munchkin ID is not added to identityMap then only ECID is sent to AEP, so identity stitching in AEP relies on shared people-level IDs like email coming from Marketo via the Source Connector rather than on the Munchkin cookie itself.
Decision guide for which scenario should you be in
If you care about connecting web behavior to Marketo leads and CRM opportunities, you need Scenario B.
-
Load Munchkin alongside Web SDK and instrument the Munchkin ID capture in your tag management layer.
-
Always declare email as an identity namespace in your AEP schema and send it (hashed, SHA-256) to the Web SDK XDM(Experience Data Model) payload at form submission.
-
Ingest Marketo via the Marketo Engage Source Connector in AEP. This brings Lead, Activity, Program Membership, and Email datasets into AEP where CJA can join them to web event data.
Why ensuring a common identity between Marketo and Web SDK matters in AEP and CJA
A common identity, like ECID, captured per device/browser cookie in Marketo and WebSDK ensures all lead activities, campaign engagement, and web interactions are linked to the same profiles and identity graphs that will be the foundation for audience activation via Real-Time Customer Data Platform (RTCDP) and audience measurement and insights via CJA.
In CJA, a common Person ID needs to be defined in Connection and serves as the ID CJA uses to stitch data from different data sources. This Person ID also defines your “People” in CJA and is the basis for all People-based metrics in CJA.
After following our deployment recommendations above, to bring Marketo and WebSDK data together in CJA, depending on the reporting requirements and the ID coverage, you may consider using ECID or a consistent person identifier like Email or Marketo Lead ID as the Person ID, along with enabling identity stitching.
As a result of ensuring a common identity across the two data source systems, we can now analyze in CJA each Marketo lead’s engagement across web, email, and offline campaigns (if available via Marketo) to answer questions including, but not limited to: How does my web content influence lead engagement? How do different Marketo campaigns drive web engagement? How are the Marketing Qualified Leads (MQLs) engaging with different web assets, like whitepapers and demo videos, and who are the ones we should re-engage?