Wrapper Debugging

What the Anima wrapper actually exposes in the browser. Use this as the source of truth for verification and troubleshooting instructions — don't invent log lines or globals.

How the tag loads

The tag a publisher pastes into their <head> is an inline IIFE, not a hosted <script src=…>. At runtime it:

Loads the wrapper library from the jsDelivr CDN: https://cdn.jsdelivr.net/npm/@<npm-org>/<domain-id>@<version>/dist/wrapp-<domain-id>.js
Fetches wrapper config from the Portal API: https://<env-domain>/api/portal/v1/configs/<domain-id>/
Calls window.Wrapp.bootstrap(config) to initialize

The library is inert until bootstrap is called — window.Wrapp is a UMD module with a single bootstrap(config) method. The command queues window.googletag.cmd and window.pbjs.que are set up unconditionally so publisher code can queue commands against them before the library arrives.

Globals the wrapper sets

Global	When set	What it is
`window.Wrapp`	After library script loads	UMD module, `{ bootstrap(config) => Promise }`
`window.__wrapp_loader`	After the loader IIFE runs to completion	Telemetry object (see below)
`window.wrapperTag`	After `bootstrap()` resolves	Public API — command queue + events + dimension setters
`window.pbjs`	Unconditionally by the library entrypoint	Prebid.js queue, then the full Prebid API once Prebid loads
`window.googletag`	Unconditionally by the library entrypoint	GPT queue, then the full GPT API once GPT loads

window.anima is not set. Any doc or troubleshooting step that refers to window.anima is wrong.

`window.__wrapp_loader`

Telemetry written by the inline loader once bootstrap has been called:

{
  library_load_ms: number,   // ms to load the library script
  config_fetch_ms: number,   // ms to fetch config
  config_source: string,     // 'network' (fetched fresh) or 'cache' (served from localStorage)
  loader_start: number       // performance.now() at loader start
}

Useful probe: if window.__wrapp_loader is absent, the inline loader never finished — almost always means the library script failed to load or the config fetch hard-errored.

`window.wrapperTag`

Shape:

wrapperTag.appVersion
wrapperTag.appBuildDate
wrapperTag.appName
wrapperTag.config               // wrapper config
wrapperTag.inventoryConfig      // resolved inventory
wrapperTag.cmd                  // command queue
wrapperTag.insertAdSlot(…)
wrapperTag.setPageDimensions(…)
wrapperTag.setSlotDimensions(…)
wrapperTag.getDimensions(…)
wrapperTag.on(event, handler)
wrapperTag.off(event, handler)

Debug query parameter: `?pbjs_debug=true`

The wrapper follows Prebid's debug convention. Append ?pbjs_debug=true to any page URL to enable debug logging:

https://yourdomain.com/article/example?pbjs_debug=true

You can also toggle Prebid debug at runtime (both enable wrapper logging too):

pbjs.setConfig({ debug: true });

?anima_preview=true does not exist. Don't use it.

What debug-mode logs look like

When debug is on, the wrapper writes logs with a styled AAM badge (navy background, white text):

console.log(
  '%cAAM',
  'background: navy; color: white; padding: 2px 5px; border-radius: 3px;',
  message,
  ...args
);

In DevTools this appears as a navy pill followed by the message. To filter, search the Console for AAM.

Actual messages you'll see (a sampling — not an exhaustive list):

Source	Example output
`bootstrap.ts`	`AAM Processing <N> ad slots on page`
`bootstrap.ts`	`AAM app info <version / build date>`
`utils.ts`	`AAM Inserted slot <divId> at <reference> of element <anchor>`
`bootstrap.ts`	`AAM defineSlot returned null for '<divId>' (ad unit: <path>) — slot skipped`

Errors (always printed, even without debug mode)

Some errors write unconditionally to the console. Seeing any of these means something went wrong:

Prefix	Meaning
`Wrapper bootstrap failed: …`	`Wrapp.bootstrap(config)` threw
`[wrapperTag] Command queue error: …`	A queued `wrapperTag.cmd.push(…)` callback threw
`[wrapp] Event listener error for '<event>': …`	A registered event handler threw
`[wrapp] Hook listener error for '<hook>': …`	A hook listener threw
`[Wrapp] Custom script runtime error: …`	Publisher-provided custom script threw
`[cwv] Plugin already initialized`	CWV plugin double-init — usually harmless duplicate tag
`googletag (google publisher tag) did not load properly…`	GPT load or init failed
`Prebid did not load properly: setTargetingForGPTAsync is undefined`	Prebid load or init failed
`inventory defined for different domain with ID '…', no ads will be served`	Config domain ID mismatch — most often a stale cached config

A correct verification flow

Use this in any doc that tells a publisher to "confirm the wrapper is working."

Source check. View page source; confirm the inline loader is present in <head>. It contains the publisher's domain ID.
Network check. Open DevTools → Network; reload. Look for:
- One request to data.jsdelivr.com/v1/package/npm/@<org>/<domain-id> (version resolution), and
- One request to cdn.jsdelivr.net/npm/@<org>/<domain-id>@<version>/dist/wrapp-<domain-id>.js (library load, 200), and
- One request to <env-domain>/api/portal/v1/configs/<domain-id>/ (config fetch, 200).

Global check. In Console:

typeof window.Wrapp             // 'object' once the library has loaded
window.__wrapp_loader           // object with library_load_ms / config_fetch_ms / config_source
window.wrapperTag?.appVersion   // defined once bootstrap has resolved

Debug log check. Append ?pbjs_debug=true to the URL and reload. Filter Console for AAM; you should see at least AAM Processing <N> ad slots on page and AAM app info ….

Auction check (Prebid conventions). Once slots have loaded:

pbjs.getBidResponses()          // current-page bid responses, keyed by ad unit
pbjs.getAllWinningBids()        // bids that rendered

What the portal does and doesn't show

The Setup → Wrapper page shows the tag, a Copy Tag button, and a Download / Download Source dropdown with the inline source. It does not show an installation-verified indicator — the portal cannot ping the publisher's site to confirm the tag is live. Don't promise that indicator in docs.

The Setup → GAM page does show a Connection Status for each linked GAM network (Not yet verified / success badge / danger badge, with a last-verified timestamp). That's driven by the GAM sync DAG state, not by a live request.

How the tag loads​

Globals the wrapper sets​

window.__wrapp_loader​

window.wrapperTag​

Debug query parameter: ?pbjs_debug=true​

What debug-mode logs look like​

Errors (always printed, even without debug mode)​

A correct verification flow​

What the portal does and doesn't show​