Marketo Tracking for Dynamic & Popover Embeds

📘
First, know which player you have
Wistia has two player generations, and the required scripts differ:

Aurora (the modern default) uses player.js plus a per-video module script, and renders a <wistia-player> element.

E-v1 (the prior-generation player, common on longer-tenured accounts) uses a single E-v1.js script.

Not sure which you have? See Which player am I using?. Throughout this page, "the Wistia player script" means whichever applies to your embed.

Two data flows, two sets of rules

Wistia's Marketo integration is really two separate flows:

Flow	What it sends	Needs a tracking script on the page?
Form submission	The data a viewer enters into a Wistia Form (Turnstile) shown in the player	No — fires from the embed itself
Viewing / engagement	Plays, watch percentage, and other engagement events tied to a known Marketo lead	Yes — requires the Marketo Munchkin tracking code and an initialized Wistia player on the page

If you only need form submissions to land in Marketo, the embed shape barely matters. If you need viewing data — and most "tracking isn't working" reports are about viewing data — then you have to satisfy every requirement below. Missing any one of them means engagement events have nothing to fire from, and Marketo sees nothing.

Requirements for viewing data

For viewing/engagement data to flow to Marketo, all of the following must be true on the page where the video plays:

The Marketo Munchkin tracking code is present. Look for munchkin.js, a Munchkin.init( call, or a reference to //munchkin.marketo.net/munchkin.js. This is what associates the visitor with a Marketo lead cookie.
The Wistia player script is present and the player initializes. The integration needs the player to actually load and run in the page context so it can fire engagement events:
- Aurora: both player.js and the per-video module (embed/{hashed_id}.js) must load, and the <wistia-player> element must upgrade.
- E-v1: E-v1.js must load and build the player.
  A script reference that never initializes (see the popover case below) produces no tracking.
The Wistia ↔ Marketo integration is connected and set as Primary on the Wistia side.

Munchkin alone is necessary but not sufficient. If the Wistia player script is missing — the most common cause of silent tracking — Munchkin has nothing to attach engagement events to.

Standard embeds vs. iframe embeds

The embed shape changes how reliably the player initializes:

Standard embeds (inline scripts: Aurora's player.js + per-video module, or E-v1's E-v1.js) initialize in the same document as Munchkin, so the tracking handshake is direct. This is the most reliable setup for Marketo tracking.
iframe embeds put a frame boundary between the player and the page's Munchkin script. They can track, but the cross-frame handshake is more fragile. If you use a raw iframe embed, keep the loader script in the parent page alongside Munchkin — player.js for Aurora, E-v1.js for E-v1.

📘
Tip: surviving a script-stripping CMS
Some CMSes and rich-text editors strip scripts out of pasted embed codes. The fix is to add the loader script to your page template once, so it survives even if the per-embed scripts get removed:

Aurora: <script src="https://fast.wistia.com/player.js" async></script>

E-v1: <script src="https://fast.wistia.com/assets/external/E-v1.js" async></script>

Note that Aurora still needs the per-video module script (embed/{hashed_id}.js) for each video — that part isn't covered by a one-time template script the way E-v1 is. Never self-host either loader; see All About E-v1.js for E-v1 and the Aurora Player API Overview and Aurora Quick Start for the full Aurora embed code.

The popover / deferred-load case

Popover, modal, "click to play," and other deferred-load patterns are where tracking most often breaks. The trap: the embed (often a raw iframe) only loads when the popover opens, so until then there's no player on the page at all.

For viewing data to flow in a deferred-load setup:

The Marketo Munchkin script must be in the parent page (loaded up front, not inside the deferred iframe).
When the trigger fires, the Wistia player must fully initialize — not just have the iframe inserted. For Aurora that means player.js and the per-video module both run and the <wistia-player> element upgrades; for E-v1 it means E-v1.js builds the player. A lazily inserted raw iframe that never runs the player code tracks nothing.
Prefer the standard inline embed (Aurora player.js + module, or E-v1 E-v1.js) inside the popover over a hand-rolled raw iframe, so the player reliably boots and the integration can tie views to the lead. If you want a popover specifically, Aurora has a native, supported one — see the Aurora Popover Player API — which initializes the player correctly rather than leaving you to wire up a raw iframe.

If you must keep a custom popover pattern, confirm two things after the popover opens: the player visibly initializes, and the Munchkin script is present in the parent document. If both are true and viewing data still doesn't appear, the problem is on the integration side, not the embed.

Quick checklist

Munchkin tracking code is on the page (munchkin.js / Munchkin.init()
Wistia player script present and the player initializes — Aurora: player.js + per-video module + <wistia-player> upgrades; E-v1: E-v1.js
For raw iframe embeds: the loader (player.js / E-v1.js) is also in the parent page
For popovers: Munchkin loads up front; the player boots when the popover opens
The Wistia ↔ Marketo integration is connected and set as Primary

Setting up the integration

This page covers the embed and tracking-script mechanics a developer controls. To connect the Marketo integration itself, get your REST API credentials, and configure the Munchkin/form pieces step by step, follow Wistia and Marketo Integration in the Wistia Help Center.