Go Live Checklist

Test your setup, ship a release, and verify revenue is flowing.

Time estimate

1–2 hours for testing and launch. Then monitor for 24–48 hours.

---

Pre-launch testing

Test 1: Debug-mode preview

The wrapper doesn't have a separate preview URL — you test the live config on any page that has the tag installed by enabling debug mode via query param.

1. Visit any URL on your site where the tag is installed.
2. Append ?pbjs_debug=true.
3. Reload.
4. Open DevTools → Console and filter for AAM.

Expected:

• AAM app info … (version / build info) appears early
• AAM Processing <N> ad slots on page appears with <N> matching the slots you expect on that page type
• No Wrapper bootstrap failed: or did not load properly errors
• Ad slots render in expected positions, at expected sizes, with no layout shift

Red flags:

Signal	Likely cause
No AAM logs at all	Library didn't bootstrap — check Network for the library load
AAM Processing 0 ad slots on page	No layout matched the current URL
Wrapper bootstrap failed: …	Config shape or inventory resolution error
inventory defined for different domain with ID '…'	Cached config from a different domain — clear localStorage

See Wrapper Debugging for the full signal list.

Test 2: Network verification

DevTools → Network, reload with debug still on, filter by prebid or your SSP hostnames:

• Wrapper library — cdn.jsdelivr.net/npm/@<org>/<domain-id>@… returns 200
• Config — <env-domain>/api/portal/v1/configs/<domain-id>/ returns 200
• Prebid auction requests — outbound to your enabled bidders' endpoints
• Bid responses — returning within your configured timeout

Test 3: Auction check

In Console, once the page has settled:

pbjs.getBidResponses()      // bid responses grouped by ad unit
pbjs.getAllWinningBids()    // bids that rendered

If getBidResponses() returns an empty object after slot rendering should have finished:

• Layout didn't match — confirm the URL matches the layout's page path
• No bidders are wired up to those slots — review Demand → Prebid
• All bidders timed out — bump the timeout in Wrapper → Configs

Test 4: Multi-device testing

Test on real devices, not just browser emulation:

Device	What to check
Desktop (Chrome)	Primary layout, all slots
Desktop (Safari)	Cross-browser compatibility
iPhone	Mobile layout, touch interactions
Android	Mobile layout, varying screen sizes
Tablet	Which layout it resolves to

Don't skip mobile

50–70% of traffic is mobile for most publishers. A broken mobile experience is a major revenue loss.

---

Launch sequence

Step 1: Final review

Go to Wrapper → Releases. Review what's pending:

• Configuration changes since the last release
• Ad slot / layout changes
• Demand bidder changes

Step 2: Ship the release

1. Wrapper → Releases → Create Release
2. Add a short release note ("Initial launch", "Added article layouts", etc.)
3. Deploy

Propagation time

Library builds complete in minutes. Config changes propagate through the CDN in ~5 seconds. Full-page caches in front of your site may delay things further — purge after deploy.

Step 3: Verify live

After deployment:

1. Clear your browser cache or use a new incognito window
2. Visit your live site (no ?pbjs_debug=true — you want the real-user path)
3. Confirm ads render in the expected positions
4. Check multiple page types
5. Optionally re-enable ?pbjs_debug=true in a second tab to confirm the deployed config looks right

Step 4: Monitor

For the first 24–48 hours, watch:

Metric	Where	Healthy range
Fill rate	Dashboard → Monetization	70–95%
CPM	Dashboard → Monetization	Varies by geo / vertical
Errors	Browser Console / GA exceptions	Near zero
Page speed	Dashboard → Core Web Vitals	No significant regression

---

Post-launch checklist

Hour 1

• Ads confirmed rendering on live site
• No Wrapper bootstrap failed: or did not load properly errors in Console
• Fill rate > 0% in Monetization

Day 1

• Fill rate stabilizing (expect fluctuation on Day 1)
• Revenue appearing in Monetization
• No user complaints or support tickets

Week 1

• Baseline metrics established
• Performance trends visible
• Ready to start optimization

---

Common launch issues

Ads not showing

Symptom	Likely cause	Fix
typeof window.Wrapp === 'undefined'	Tag not in page <head>	Verify tag in page source; re-deploy
AAM Processing 0 ad slots on page	No layout matched	Check layout page-path against the URL
Slots match, no bids	No bidders wired up or all timed out	Review Demand → Prebid; bump wrapper timeout
Bids received, no render	GAM mapping issue	Check ad slot ↔ GAM ad unit mapping

For more, see Troubleshooting.

Revenue lower than expected

Give it time. First-week performance isn't representative:

• Bidders are learning your inventory
• No historical data for optimization
• Advertiser demand fluctuates day-over-day

Evaluate after 2–4 weeks of stable traffic.

Page speed regression

If Core Web Vitals dropped after launch:

1. Enable lazy loading for below-fold slots (on the slot, not the layout)
2. Reduce the number of slots per page
3. Lower wrapper timeout (try 1000 ms)
4. Check for conflicting scripts

See CWV and ads.

---

Rollback procedure

There's no one-click "Rollback" button in the portal. The rollback flow is: copy the last known-good release into a new draft release, then deploy it.

1. Wrapper → Releases
2. Find the last known-good release (use release notes to identify it)
3. Use the Copy action on that release — it becomes a new draft pre-populated with the good config
4. Deploy the draft (rocket icon)
5. Confirm the site recovers (reload with ?pbjs_debug=true, check window.wrapperTag.appVersion reverted)

Propagation is as quick as any other deploy — typically under a minute through the CDN once config-only changes are live. Library rebuilds add a few minutes when code or Prebid modules were part of the bad release.

See Rolling back for the detailed flow.

Always know your last good release

Before a major change, note which release is currently live and leave a descriptive release note. That release is your rollback target.

---

What's next

You're live. Time to learn your baseline and start optimizing.

Next: What's Next →

Read your reports, run experiments, and iterate.

---

Launch-day FAQ

How quickly will I see revenue?

• Analytics data — within 1–2 hours of first impressions
• Revenue summary — same day, updates regularly
• GAM-reported revenue — 24–48 hour delay, depending on GAM reporting lag

Should I launch during high or low traffic?

Low traffic is safer (early morning, weekends):

• Easier to spot issues
• Lower impact if something goes wrong
• More time to react

Avoid launching during traffic spikes or revenue-critical periods (Black Friday, an editorial moment, etc.).

Can I launch to a percentage of traffic first?

Yes — use Wrapper → Experiments:

1. Create an experiment with your new config as a variation.
2. Set traffic allocation (e.g., 10% to new, 90% to control).
3. Monitor.
4. Gradually increase allocation.

This is the safest way to roll out significant changes.

What if I need to pause ads immediately?

Roll back to the previous release from Wrapper → Releases. Propagation is typically under a minute through the CDN.