Skip to main content

Verifying Installation

A healthy install means: the inline tag is in your page's <head>, the library script loads from jsDelivr, the config fetches from the Portal API, and window.Wrapp.bootstrap(config) runs without error. This page walks through each check.

There's no "verified" indicator in the portal

Setup → Wrapper does not currently display whether your tag is live on the publisher site — the portal has no way to ping your origin. All verification below happens from your own browser.

1. Page source​

  1. Open your site in a browser.
  2. View page source (Ctrl/Cmd + U, or right-click → View Page Source).
  3. Search for wrapp or your domain ID.

You should see an inline <script> block in <head> — the same block you pasted from Setup → Wrapper. Confirm the domain ID in the script matches the domain ID shown in the portal.

2. Network tab​

  1. Open DevTools → Network tab.
  2. Reload the page.
  3. Filter by jsdelivr or by your domain ID.

You should see three requests:

RequestExpected
data.jsdelivr.com/v1/package/npm/@<org>/<domain-id>200 — version resolution (may be 304 on repeat loads)
cdn.jsdelivr.net/npm/@<org>/<domain-id>@<version>/dist/wrapp-<domain-id>.js200 — wrapper library
<env-domain>/api/portal/v1/configs/<domain-id>/200 — wrapper config

If any return 4xx/5xx, see Wrapper Debugging → errors and Troubleshooting.

"network" config source is the healthiest signal

After the requests complete, window.__wrapp_loader.config_source === 'network' means config was fetched fresh; 'cache' means a localStorage fallback was used because the network fetch failed. (config_source is only ever 'network' or 'cache'.) A persistent 'cache' means your Portal API request is failing.

3. Globals in the Console​

Open DevTools → Console and run each of these:

typeof window.Wrapp             // 'object' once the library script has loaded
window.__wrapp_loader           // telemetry: library_load_ms, config_fetch_ms, config_source, loader_start
window.wrapperTag?.appVersion   // version string once bootstrap has resolved
window.wrapperTag?.appBuildDate // build timestamp
window.pbjs                     // Prebid.js API
window.googletag                // GPT API

What each result tells you:

ResultMeaning
window.Wrapp is undefinedThe library script never loaded — check Network for the jsDelivr URL
window.Wrapp exists but window.__wrapp_loader is undefinedLoader IIFE started but didn't finish — check Console for errors
window.__wrapp_loader.config_source === 'cache' persistentlyConfig fetch is failing; the wrapper is running on the last cached config — check the Portal API request
window.wrapperTag?.appVersion is undefinedBootstrap hasn't resolved — check Console for a Wrapper bootstrap failed: error

For more on each global see Wrapper Debugging.

4. Debug logs​

Append ?pbjs_debug=true to the URL and reload. Filter Console for AAM — the wrapper logs are prefixed with a styled navy AAM badge.

You should see (among others):

AAM Processing <N> ad slots on page
AAM app info <version / build info>

If you see none of these even with ?pbjs_debug=true, the wrapper library did not bootstrap. Check the Network tab requests from step 2 and any red errors in Console.

Errors appear without debug mode

Fatal errors (Wrapper bootstrap failed:, [wrapperTag] Command queue error:, googletag … did not load properly, Prebid did not load properly:) always print to Console regardless of debug mode. See the full error list.

5. Auction activity (after you've set up inventory)​

Once you have ad slots and demand partners configured and a release deployed, you can confirm bids are flowing using standard Prebid APIs:

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

If the first returns an empty object after slots have loaded, either the layout didn't match the page URL, no bidders are configured for those slots, or all bidders timed out.

Verification checklist​

  • Inline <script> block is present in <head> and contains the correct domain ID
  • jsDelivr library request returns 200
  • Portal API config request returns 200
  • window.Wrapp is defined
  • window.__wrapp_loader.config_source === 'network'
  • window.wrapperTag.appVersion is defined
  • With ?pbjs_debug=true, the console shows AAM Processing <N> ad slots on page
  • No Wrapper bootstrap failed: or did not load properly errors

Troubleshooting​

window.Wrapp is undefined​

The library script never loaded. Check in this order:

CheckFix
Is the inline tag in page source?If no, re-paste from Setup → Wrapper into your template
jsDelivr request in Network tab?If no, content-security-policy may be blocking the CDN — whitelist cdn.jsdelivr.net and data.jsdelivr.com
jsDelivr request 4xx/5xx?Confirm your domain ID in the tag matches the portal
Ad blocker or privacy extension?Disable and retest

Tag loads, but no AAM logs even with ?pbjs_debug=true​

The library loaded but bootstrap didn't fire. Check Console for:

  • Wrapper bootstrap failed: — usually a config-shape mismatch or a missing property. Report with the error message.
  • inventory defined for different domain with ID '…' — the cached config is for a different domain. Clear localStorage and reload.

Status: intermittent​

If some pageviews show the wrapper and others don't:

  • Full-page cache is serving some HTML without the tag — purge the CDN cache
  • The tag is only on some templates — confirm it's in the shared partial used by every page type
  • Conditional loading logic (consent gate, A/B test) may be skipping the tag

Testing on localhost​

The wrapper will try to load and run on localhost, but bidders typically reject requests from unrecognized domains. Expect the library to load and AAM Processing … to log, but most auction activity won't complete. Test on a real domain that's configured in Anima.

Next​

Enable Core Web Vitals tracking → (recommended)

or

Create ad slots → (continue setup)