Optimizely DAM integration

What an Optimizely DAM integration must do

An Optimizely DAM integration must put approved assets in the editor's hands inside the CMS and keep every placed asset valid until it is withdrawn.

Optimizely CMS is a content management system with its own media library. The DAM vs CMS guide explains why that library makes a weak DAM. The DAM integrations guide places the CMS among the other connections a DAM needs.

How Optimizely CMS models media

Optimizely CMS 12 models media as content: each file becomes an instance of a .NET media type with editable metadata properties.

• Fact: a media type is a .NET class that inherits from `MediaData` and carries the `[ContentType]` attribute.
• Fact: `ImageData` and `VideoData` are specialised base classes for images and videos, and image types show thumbnails of 48 by 48 pixels.
• Fact: the `MediaDescriptor` attribute maps file extensions to a media type, so an upload creates the right type.
• Fact: `GlobalAssetsRoot` holds media shared across sites, and `SiteAssetsRoot` holds media for one site.
• Fact: folder access rights control which editors reach which media.
• Fact: `UploadOptions.FileSizeLimit` defaults to 4 MB, and allowed extensions default to all.

Fact: content providers let CMS 12 show data from an external source as CMS content while the data stays at the source. A custom provider inherits from `ContentProvider` and implements `LoadContent`, which returns an `IContent` instance. A DAM connector can use this mechanism to show DAM assets in the CMS asset pane without copying files.

The CMS media model fits web images that editors upload for one page. The model holds no usage rights records, approval workflow or rendition presets, so a DAM supplies those.

Optimizely's own DAM in the CMS

Optimizely ships its own DAM inside the Content Marketing Platform (CMP), and the CMS documents how editors use it. The facts below come from Optimizely developer documentation.

Fact: in CMS 12, DAM metadata updates when content is published, a save alone leaves it unchanged, and a DAM Maintenance job also refreshes it. Fact: CMP fields, tags and custom properties are not available in CMS 12. Fact: Optimizely recommends the Graph integration for metadata retrieval in production, because the REST route can return 429 errors.

Fact: a scheduled job reports page URLs to CMP, so the DAM Usage tab shows where assets appear, and only published content is tracked. Buyers that consider a third-party DAM compare its connector against this documented baseline. Vendor details sit on vendor profiles, and the integrations overview rates connectors on four depth levels, from native connector to custom build.

Integration patterns for Optimizely

Optimizely DAM integrations follow four patterns, and each one sets who stores the file and who serves it.

DAMSelection assessment: the pattern choice follows the delivery model. A site that serves images from a DAM delivery layer keeps one copy and one rights check. The headless DAM guide explains that architecture, and an image CDN handles sizes and formats per device.

What must stay in sync with Optimizely

Five changes in the DAM must reach Optimizely within a stated time: new versions, rights expiry, deletions, metadata and alt text per language.

Fact: in the CMS 12 CMP integration, metadata refreshes only on publish and through the maintenance job. Alt text changed in the DAM therefore stays old on a page until one of those runs. The accessibility and alt text guide explains why alt text belongs to the asset in the DAM, per language.

Rights expiry needs a list of affected pages. Usage tracking that covers only published content misses drafts and scheduled pages, so the buyer asks how the connector treats them.

What to test in an Optimizely demo

An Optimizely demo tests the asset loop in a CMS test environment with the buyer's own content types and assets. Add these steps to the scripted demo.

1. Show which pattern the connector uses and which packages or add-ons it installs.
2. Open a page and pick an approved image from the DAM with three facets.
3. Place the same asset in an image property, a link property and a content area or block.
4. Select a named rendition and show the delivered size and crop.
5. Show alt text in two CMS languages on the published page.
6. Replace the asset with a new version in the DAM and show the page result.
7. Change alt text in the DAM and show when the page receives it.
8. Expire the rights on the asset and show the list of affected pages, including drafts.
9. Delete an asset in the DAM and show the live page.
10. Show the DAM usage report for the asset.

The Demo Script Generator formats the steps as a scenario. The panel scores each step pass or fail against criteria written before the demo.

Common failure points

Optimizely DAM integrations fail at five points that a buyer checks before signature.

• Upload limits: the 4 MB default upload limit blocks large masters in the CMS media library.
• Stale metadata: metadata that refreshes only on publish or by a scheduled job lags behind the DAM.
• Rate limits: high-traffic sites that fetch DAM metadata at render time hit API limits without caching or Graph.
• Version gaps: CMS 12 and SaaS CMS support different properties and rendition features.
• Draft blind spots: usage tracking of published content misses drafts and scheduled pages.

Questions for the DAM vendor

The buyer sends these questions in writing and asks for documentation with each answer.

1. Which Optimizely products and versions does the connector support: CMS 12, SaaS CMS or both.
2. Which pattern does the connector use, and who builds, hosts and supports it.
3. Which CMS property types can hold a DAM asset.
4. How does the connector select renditions and focal points.
5. How and how often does the connector refresh metadata and alt text.
6. How does the connector handle rights expiry and deletion on live, draft and scheduled pages.
7. Does the DAM receive usage data from the CMS, and at which interval.