Publisher Onboarding: Integrating an SSP Step by Step

1. Integration Overview: Tag vs. SDK vs. S2S

Before writing any code, choose the integration method that matches your platform and technical capabilities. SSPs typically support three integration approaches:

JavaScript Tag (Web Publishers)

The most common integration method for web publishers. The SSP provides a JavaScript tag that you place on your pages. When the page loads, the tag initiates an auction, collects bids from connected demand sources, and returns the winning creative for rendering. Tags can be implemented in two ways:

• Synchronous tag: The ad request blocks page rendering until it completes. Simpler to implement but adds latency to page load.
• Asynchronous tag: The ad request runs in parallel with page rendering. The preferred approach for performance-conscious publishers. The ad renders when the auction completes without delaying content.

SDK (Mobile App Publishers)

For mobile app publishers, the SSP provides an SDK (available for iOS and Android) that you integrate into your app. The SDK handles ad requests, auction management, creative rendering, and event tracking. SDK integration requires app development resources and goes through your app's release cycle.

Server-to-Server / Header Bidding (Advanced)

For publishers using Prebid.js or another header bidding wrapper, the SSP provides a Prebid adapter that integrates into your existing auction setup. Server-to-server (S2S) integration moves the auction to the server side, eliminating client-side latency. This is the preferred architecture for performance-sensitive publishers with high traffic volumes.

2. Tag Placement & Implementation

Proper tag placement is critical for correct ad rendering and accurate reporting. Follow these guidelines:

Where to Place the Tag

The SSP's JavaScript tag should be placed in the <head> section of your HTML (for asynchronous loading) or immediately before the ad container <div> (for synchronous loading). The tag initializes the SSP's auction logic and defines the available ad slots on the page.

Ad Container Setup

Each ad unit on your page needs a container <div> with a unique ID. The SSP tag references this ID to render the winning creative. Example structure:

• Create a <div> with a unique ID for each ad placement (e.g., id="ad-unit-header-728x90").
• Set the container's width and height to match the expected ad size.
• Use CSS to handle cases where the ad does not fill (collapse empty containers to prevent layout shifts).

Lazy Loading

For ad units below the fold, implement lazy loading so the ad request is only triggered when the user scrolls near the ad container. This improves page load performance, increases viewability rates (since ads only load when they are about to be seen), and reduces wasted ad requests that never result in viewable impressions.

3. Ad Unit Setup & Configuration

In the SSP's dashboard, create ad units that correspond to each placement on your site. For each ad unit, configure:

• Ad unit name: A descriptive label (e.g., "Homepage - Above Fold - Leaderboard") that makes reporting easy to interpret.
• Ad sizes: All supported sizes for that placement. Multi-size ad units (e.g., supporting both 728x90 and 970x250 in the same slot) increase demand competition and revenue.
• Ad format: Display, video, native, or multi-format. Multi-format units that accept both banner and video creative typically generate higher eCPMs.
• Refresh interval: For long-session pages (news articles, forums), configure ad refresh intervals (typically 30–60 seconds) to serve additional impressions from the same page view.
• Floor price: The minimum acceptable bid for this ad unit (configured in detail in the next section).

Mapping Ad Units to Placements

Create a mapping document that links each ad unit ID in the SSP dashboard to the corresponding container <div> ID on your pages. This document becomes essential for debugging and for onboarding additional team members.

4. Floor Price Configuration

Floor prices are one of the most impactful levers in publisher yield management. Set them too high and fill rates drop; set them too low and inventory sells below market value.

Setting Initial Floor Prices

Start with conservative floor prices and adjust based on auction data:

Dynamic vs. Static Floors

Static floors remain constant regardless of demand conditions. They are simple to configure but leave money on the table during high-demand periods and risk under-delivery during low-demand periods.

Dynamic floors adjust automatically based on historical bid density, time of day, device type, and user value signals. Most SSPs offer dynamic floor pricing as a feature. Enable it once you have 1–2 weeks of historical auction data to calibrate the algorithm.

5. ads.txt & app-ads.txt Setup

ads.txt (Authorized Digital Sellers) is a mandatory requirement for monetizing through programmatic channels. Without it, many DSPs will not bid on your inventory, and your fill rates and eCPMs will suffer significantly.

Setting Up ads.txt (Web Publishers)

1. Create a plain text file named ads.txt at the root of your domain (e.g., https://example.com/ads.txt).
2. Add a line for each authorized seller. The format is: domain, account_id, relationship, certification_authority_id
3. For each SSP you integrate, add their entry. For example: ssp-domain.com, 12345, DIRECT, f08c47fec0942fa0
4. If you use Google AdSense or Ad Exchange, include Google's entry: google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0
5. Verify the file is accessible by visiting the URL in a browser.

Setting Up app-ads.txt (Mobile App Publishers)

For mobile apps, app-ads.txt works differently. The file is hosted on the developer's website (not in the app store listing), and the app store listing must include a developer website URL. The app-ads.txt file format is identical to ads.txt. Ensure the developer website URL in the app store listing matches the domain where your app-ads.txt file is hosted.

Common ads.txt Mistakes

• Wrong account ID (copy-paste errors are common).
• Missing TABACertification authority ID (the last field).
• File not served with correct MIME type (text/plain).
• File placed behind authentication or CDN caching that prevents crawlers from accessing it.
• Not updating ads.txt when adding or removing SSP partners.

6. Testing & Quality Assurance

Before going live, thoroughly test the integration to catch issues that could cost revenue or degrade user experience.

Pre-Launch Checklist

1. Tag fires correctly: Use browser developer tools (Network tab) to verify the SSP tag is making ad requests and receiving responses.
2. Creatives render: Verify that winning ads render correctly in each ad container, with proper sizing and no layout shifts.
3. Tracking events fire: Confirm that impression tracking pixels fire when ads become viewable, and click tracking redirects work correctly.
4. Floor prices enforced: Verify that bids below your floor price are rejected and impressions go unfilled rather than selling below floor.
5. ads.txt accessible: Confirm the file is publicly accessible and contains correct entries for all SSP partners.
6. Page performance: Measure page load time with and without the SSP tag. The tag should not add more than 200–500ms to page load time.
7. Ad quality: Review sample ads to ensure they meet your content and format standards.
8. Responsive behavior: Test on mobile, tablet, and desktop viewports to ensure ad units resize or collapse correctly.

Test Mode

Most SSPs provide a test mode that serves sample creatives without generating billable impressions. Use test mode during initial implementation to validate tag behavior without affecting your live reporting. Switch to production mode only after all tests pass.

7. Going Live

Once testing is complete, deploy the integration to production. Follow a phased rollout approach:

1. Soft launch (10–20% of traffic): Deploy the SSP tag to a percentage of your traffic using a feature flag or traffic splitting. Monitor for 24–48 hours for any issues with ad serving, page performance, or reporting accuracy.
2. Ramp to 50%: Increase traffic allocation and monitor metrics for another 24–48 hours. Compare performance against your existing monetization to ensure the new SSP is additive.
3. Full rollout (100%): Deploy to all traffic. Continue monitoring closely for the first week.

Parallel Running

If you are replacing an existing SSP, run both platforms in parallel for 1–2 weeks using header bidding to let them compete. Compare fill rates, eCPMs, and total revenue to validate that the new platform delivers the expected improvement before decommissioning the old one.

8. First-Week Optimization

The first two weeks after going live are critical for establishing baseline performance and identifying optimization opportunities.

Day 1–3: Delivery Monitoring

• Verify impressions are being served across all ad units.
• Check fill rates are within expected ranges.
• Confirm revenue is being recorded in the SSP dashboard.
• Review bid density data to understand how many demand sources are competing for your inventory.

Day 4–7: Initial Optimization

• Floor price adjustment: Based on the first few days of auction data, adjust floor prices upward where bid density is high and fill rates exceed 80%.
• Ad unit consolidation: If certain ad units have very low fill rates, consider consolidating them into multi-size units that attract more demand.
• Category blocking review: Review which ad categories are serving and adjust blocks if needed.

Week 2: Deeper Analysis

• Analyze performance by device type, geography, and time of day.
• Identify your highest-value inventory segments and consider creating PMP deal IDs for them.
• Request a performance review from your SSP account manager with optimization recommendations.
• Enable dynamic floor pricing once sufficient historical data is available.

9. Common Integration Issues

These are the most frequently encountered problems during SSP integration and how to resolve them: