Embed Webinars With Tag Managers And Cookie Consent

Embedding Wistia webinars and live events on a consent-managed page — whether you place the embed code directly or inject it through a tag manager like Google Tag Manager — comes down to one thing: the Wistia player scripts have to be allowed to load. This guide covers the supported patterns, what happens when a consent manager blocks Wistia, how to wire up viewer consent, and which decisions sit outside Wistia's control.

How a Wistia webinar embed loads

A Wistia webinar (live event) embed is the same Aurora player embed used for any media — two scripts plus a web component:

<script src="https://fast.wistia.com/embed/abc123.js" async type="module"></script>
<script src="https://fast.wistia.com/player.js" async></script>

<wistia-player media-id="abc123"></wistia-player>

Everything the player needs is served from fast.wistia.com. The <wistia-player> web component does nothing until player.js (and the media-specific embed/<hashed-id>.js) have loaded and registered it. If either script is prevented from loading, the element stays inert and no player renders at all — this is different from a player that loads but doesn't track.

Placing the embed: direct vs. tag manager

Both are supported. The trade-off is when the scripts run.

Direct page placement (preferred for webinars). Put the embed code straight into your page's HTML. The scripts load with the page, the player is ready as early as possible, and there's no extra layer that can defer or strip the tags. For a live event where viewers may arrive right at start time, this is the most reliable option.
Tag-manager injection (Google Tag Manager, Tealium, etc.). Supported, with two things to plan for:
1. The player scripts are external resources, not analytics tags. If your tag manager only fires Wistia on a "marketing"/"analytics" consent category, the player itself won't load until the visitor accepts that category — so a visitor who declines sees no webinar. If the video must always be visible, place the player directly (or fire it on an "always-on"/functional category) and use the consent API to control tracking separately (see below).
2. Inject a Custom HTML tag, not just the <script>. Include the <wistia-player> element (or render it from your own code) along with the scripts, and make sure the tag fires on the page/route where the embed should appear.

When a consent manager blocks Wistia

Consent platforms (Cookiebot, OneTrust, Osano, and similar) work by blocking scripts until the visitor consents, usually by rewriting <script> tags or holding them in a category. When Wistia's scripts fall into a blocked category:

fast.wistia.com/player.js never loads, so <wistia-player> never upgrades and the webinar doesn't appear.
Nothing Wistia-side can override this — the block happens in the visitor's browser before our code runs.

To fix it, the consent manager has to be configured to allow the Wistia player scripts (the fast.wistia.com resources above) in whichever category you want the webinar to play under. How you do that is specific to your consent tool's interface — Cookiebot's auto-blocking allowlist, OneTrust's script categorization, etc. Those click-paths live in your consent platform's own documentation, not Wistia's.

📘
Rule of thumb
If the webinar must be visible to every visitor, the player scripts cannot sit behind a consent gate — allow them unconditionally and control data collection with the consent API instead. If the webinar should only appear after consent, gate the scripts and accept that visitors who decline won't see it.

Controlling tracking with the consent API

Loading the player and tracking the viewer are separate decisions. Once the Wistia embed script is present on the page, you can set a visitor's tracking preference directly, regardless of your account's default Privacy Mode setting:

window._wq = window._wq || [];
window._wq.push(function (W) {
  W.consent(true);   // allow tracking for this visitor
  // W.consent(false);   // anonymize this visitor (Privacy Mode)
  // W.consent('default'); // defer to your account default
});

W.consent() (no argument) returns the current value. The preference is persisted in the browser's localStorage, so you set it once per visitor rather than on every page load. A common pattern is to call W.consent(true) from your consent manager's "accepted" callback and W.consent(false) from its "declined" callback — that way the player still renders for everyone, but only consenting viewers are tracked.

For the full consent API, including how it interacts with account-level Privacy Mode and iframe embeds, see Player Privacy Mode.

🚧
Live events and registration data
Privacy Mode anonymizes viewing analytics, but it does not suppress data captured by a Wistia registration form on a live event — registration details are still collected. If you need minimal data collection for a webinar, either use a marketing-automation-platform (MAP) registration form (Wistia doesn't store that data) or turn registration off entirely. See Player Privacy Mode for details.

What's outside Wistia's control

Wistia supports the embed and the consent API described above. The following are owned by your setup, not Wistia Support:

Your consent manager's configuration — which scripts land in which category, and whether the Wistia scripts are allowed. This is set in your consent platform.
Your tag manager's trigger logic — which pages/routes fire the embed tag, and the consent conditions you attach to it.
Your page's own Content-Security-Policy — if your site sends a CSP, it must allow fast.wistia.com (and the player's media domains) in script-src and the relevant directives, or the scripts are blocked before any consent tool is even involved.

If a webinar embed isn't loading on a consent-managed page, work through these in order: confirm the Wistia scripts aren't blocked by the consent manager, then by CSP, then verify the tag fires on the right page — before opening a support ticket.