Format Overview
Compare Ring DAS ad formats and choose the right one for your use case
Format Overview
Ring DAS provides multiple ad formats designed for retail media and e-commerce platforms. This page helps you understand the available formats and choose the right one for your use case.
Available Formats
Brand Store
A button on the OOP (product detail page) that redirects users directly to the brand's store with offers related to the selected product.
Web
For web integrations using JavaScript SDK (CSR) or server-side rendering (SSR).
Learn more about Brand Store (Web) integration
Mobile Apps
Native iOS/Android integration via direct HTTP API without JavaScript SDK.
Learn more about Brand Store (Mobile Apps) integration
Branded Products
A homepage display banner showing the brand logo and a curated set of products selected by the brand.
Learn more about Branded Products integration
Sponsored Product / Offer (Single Tile)
A native ad unit that blends into product listing grids (search results, category pages) as a single sponsored tile among organic products. Designed for retail media monetization without disrupting the shopping experience.
The format supports two business models depending on the campaign goal:
- Sponsored Product — promotes a specific product within the shop. The tile looks and behaves like an organic product listing, driving traffic to the product page.
- Sponsored Offers — promotes a merchant's offer for a product. The tile includes a CTA button with the merchant's shop name, driving traffic to the merchant's store.
Learn more about Sponsored Product / Offer (Single Tile) integration
Sponsored Product / Offer (Product Slider)
A horizontal product slider that mixes organic product cards with sponsored tiles served by Ring DAS. The sponsored positions are filled by the ad server; organic content is managed by your shop. The format uses the same dual-flow model as Single Tile (redirectToOffers flag):
- Sponsored Product — tile links to the product page on your shop.
- Sponsored Offers — tile includes a CTA button linking to the merchant's shop.
Learn more about Sponsored Product / Offer (Product Slider) integration
Choosing Integration Approach
All formats support Frontend (CSR) and Backend (SSR) integration. Choose based on your requirements:
| Aspect | Frontend (CSR) | Backend (SSR) |
|---|---|---|
| Time to First Byte (TTFB) | ✅ No delay – page sent immediately | ⚠️ Server waits for ad response before sending page |
| Render Time | ⚠️ Ads render after page (async) | ✅ Ads render with page content |
| User Identification | ✅ Automatic via SDK | ⚠️ Manual – pass your own identifier as sid, or forward ea_uuid cookie as lu |
| Frequency Capping | ✅ Built-in | ⚠️ Requires stable user ID |
| Audience Segments | ✅ SDK reads from cookies | ⚠️ Segment IDs must be passed explicitly |
| Contextual Data | ✅ Captured automatically by SDK | ⚠️ Must be provided in request |
| Cache Compatibility | ✅ Always fresh ads | ⚠️ Risk of stale ads on cached pages |
| Page Load | Async, non-blocking | Pre-rendered in HTML |
| SEO | Dynamic content | ✅ Server-rendered, crawlable |
| Implementation Effort | Lower – SDK handles logic | Higher – full request orchestration |
| Failure Impact | ✅ Ad failure does not block page | ⚠️ Ad failure may affect rendering |
| Ad Blocker Sensitivity | ⚠️ Higher (JS & SDK dependent) | ✅ Lower |
| Experimentation / A/B Testing | ✅ Easier and faster | ⚠️ Requires backend changes |
| Server Load / Cost | ✅ Lower (client-side work) | ⚠️ Higher (server-side rendering) |
Recommendation: Use Frontend (CSR) for most cases. Choose Backend (SSR) if you need server-side rendering for SEO or have specific performance requirements.
Next Steps
- Review the format documentation that matches your platform
- Set up your Ring DAS SDK or API configuration
- Implement the ad format that matches your use case
- Test your integration using the demo network
Updated 24 days ago