Blog posts by Keshav Dave

Blog posts by Keshav Dave2026-02-15T17:16:37.0000000Zhttps://world.optimizely.com/blogs/keshav-dave/ Optimizely World Architecting AI in Optimizely CMS: When to Use Opal vs Custom IntegrationAI is rapidly becoming a core capability in modern digital experience platforms. As developers working with Optimizely CMS 12 (.NET Core), the real question is no longer: “Can we integrate AI?” But rather: “What is the right architectural approach for AI inside Optimizely?” In this article, I’ll share practical implementation patterns, lessons learned, and how to decide between custom AI integration and leveraging Opal. <h2>Why AI Integration Matters in CMS Implementations</h2> Across multiple implementations, I’ve observed recurring challenges: <ul> <li> Manual metadata tagging </li> <li> Inconsistent summaries and SEO descriptions </li> <li> Static personalization logic </li> <li> Slow campaign iteration cycles </li> <li> Limited experimentation insights </li> </ul> AI, when architected correctly, can significantly enhance these areas - without disrupting core CMS performance. <h2>Option 1: Custom AI Integration in Optimizely CMS 12</h2> For organizations requiring flexibility and control, integrating external AI services (e.g., Azure OpenAI or private ML models) remains a powerful option. <h3>Recommended Architecture</h3> Editor → CMS → AI Service Layer → External AI Provider Step 1: Introduce an Abstraction Layer <pre class="language-csharp"><code>public interface IAIContentService { Task<string> GenerateSummaryAsync(string content); Task<List<string>> GenerateTagsAsync(string content); } </code></pre> This ensures your CMS remains provider-agnostic. Step 2: Register via Dependency Injection <pre class="language-csharp"><code>services.AddHttpClient<IAIContentService, AIContentService>(); </code></pre> Keep AI logic outside controllers and content models. Treat it as infrastructure. Step 3: Hook into CMS Events Example: Auto-tag content during publishing. <pre class="language-csharp"><code>_contentEvents.PublishingContent += async (sender, args) => { if (args.Content is ArticlePage page) { var tags = await _aiService.GenerateTagsAsync(page.MainBody.ToHtmlString()); page.Tags = tags; } }; </code></pre> <h3>Important Considerations</h3> <h3>Performance</h3> <ul> <li> Never execute AI calls during page rendering. </li> <li> Use background jobs or publish-time triggers. </li> <li> Cache generated outputs. </li> </ul> <h3>Security</h3> <ul> <li> Store API keys in secure vaults. </li> <li> Avoid exposing AI endpoints client-side. </li> </ul> <h3>Prompt Governance</h3> Treat prompts like code: <ul> <li> Version them </li> <li> Document them </li> <li> Test them </li> </ul> <h2>Option 2: Leveraging Opal</h2> Opal introduces AI natively within the Optimizely ecosystem. Rather than building infrastructure from scratch, Opal enables: <ul> <li> AI-assisted content creation </li> <li> Campaign generation </li> <li> Intelligent experimentation insights </li> <li> Workflow-level automation </li> </ul> From a developer perspective, Opal reduces: <ul> <li> Integration complexity </li> <li> Maintenance overhead </li> <li> Governance concerns </li> </ul> It shifts AI from being API-driven to being workflow-native. <h2>Architectural Decision: Opal vs Custom AI</h2> In enterprise implementations, the decision should be strategic. <table style="border-collapse: collapse; width: 100.033%; height: 117.563px;"> <tbody> <tr style="height: 19.5938px;"> <td style="height: 19.5938px; text-align: left;">Criteria</td> <td style="height: 19.5938px; text-align: left;">Opal</td> <td style="height: 19.5938px; text-align: left;">Custom Integration</td> </tr> <tr style="height: 19.5938px;"> <td style="height: 19.5938px;">Speed to Market</td> <td style="height: 19.5938px;">High</td> <td style="height: 19.5938px;">Medium</td> </tr> <tr style="height: 19.5938px;"> <td style="height: 19.5938px;">Full AI Control</td> <td style="height: 19.5938px;">Medium</td> <td style="height: 19.5938px;">High</td> </tr> <tr style="height: 19.5938px;"> <td style="height: 19.5938px;">Maintenance</td> <td style="height: 19.5938px;">Low</td> <td style="height: 19.5938px;">Higher</td> </tr> <tr style="height: 19.5938px;"> <td style="height: 19.5938px;">Compliance Control</td> <td style="height: 19.5938px;">Managed</td> <td style="height: 19.5938px;">Self-managed</td> </tr> <tr style="height: 19.5938px;"> <td style="height: 19.5938px;">Custom ML Use Cases</td> <td style="height: 19.5938px;">Limited</td> <td style="height: 19.5938px;">Strong</td> </tr> </tbody> </table> <div class="TyagGW_tableContainer"> <div class="group TyagGW_tableWrapper flex flex-col-reverse w-fit"> <h3>Recommended Enterprise Approach</h3> In most scenarios, I recommend a hybrid model: <ul> <li> Use Opal for editor productivity and campaign acceleration. </li> <li> Use custom AI integration for domain-specific business logic. </li> <li> Keep AI infrastructure modular and loosely coupled. </li> </ul> This ensures flexibility without overengineering. <h2>Designing AI-Ready Content Models</h2> Regardless of approach, structure matters. Best practices: <ul> <li> Avoid storing critical data in large RichText blobs. </li> <li> Use structured properties. </li> <li> Maintain clean content types. </li> <li> Align metadata fields for AI enrichment. </li> </ul> AI works best with well-structured data. <h4>Final Thoughts:-</h4> AI in Optimizely CMS should not be treated as a feature toggle. It is an architectural layer. As developers and architects, our responsibility is to: <ul> <li> Protect performance </li> <li> Maintain security </li> <li> Ensure maintainability </li> <li> Deliver business value </li> </ul> Whether through custom services or via Opal, the goal remains the same: Build intelligent, scalable digital experiences. :) </div> </div>2026-02-15T17:16:37.0000000Z

Blog post

Designing Scalable Catalog Structures in Optimizely CommerceIn any eCommerce solution, the catalog is the backbone of the digital experience. A well-designed catalog structure in Optimizely Commerce ensures fast performance, easy management, and a smooth customer journey — while a poorly designed one can lead to slow searches, frustrated merchandisers, and scalability challenges as the business grows. In this article, we’ll explore how to design scalable catalog structures in Optimizely Commerce, the key considerations, and best practices learned from projects. <h2>Why Catalog Design Matters</h2> Optimizely Commerce can handle thousands of SKUs, but the way you structure your catalog directly impacts: <ul> <li> Performance → Faster search, indexing, and page load times. </li> <li> User Experience → Easier navigation, better filtering, fewer clicks. </li> <li> SEO → Clean URLs, optimized category hierarchies, breadcrumb trails. </li> <li> Maintainability → Simpler workflows for merchandisers and admins. </li> <li> Scalability → Ability to expand into new markets, product lines, or currencies without restructuring. </li> </ul> Example structure: <pre class="language-html"><code>Catalog: Fashion Store └── Category: Men’s Clothing └── Product: Oxford Shirt ├── Variant: Blue, Size M ├── Variant: Blue, Size L └── Variant: White, Size M </code></pre> <h2>Catalog Design Considerations for Scalability</h2> When structuring your catalog, keep in mind: <ol> <li> Performance – Large categories with thousands of items can slow down queries. </li> <li> Navigation & UX – Customers should reach products in 3–4 clicks max. </li> <li> SEO – URLs and breadcrumbs should reflect clean hierarchies. </li> <li> Admin Usability – Merchandisers need intuitive structures. </li> <li> Localization – Plan for multi-language, multi-market, multi-currency setups. </li> </ol> <h2>Common Catalog Design Patterns</h2> <h3>1. Single vs Multi-Catalog</h3> => Diagram: Single vs Multi-Catalog Single Catalog (Recommended for most cases):  <pre class="language-html"><code>Catalog Root ├── Men’s Clothing ├── Women’s Clothing ├── Footwear └── Accessories</code></pre> Multi-Catalog (When business models differ): <pre class="language-html"><code>B2C Catalog ├── Men’s Clothing ├── Women’s Clothing B2B Catalog ├── Bulk Apparel ├── Corporate Footwear</code></pre> => Start with a single catalog unless you have strong business reasons (different assortments, B2B vs B2C). <h3>2. Flat vs Deep Category Hierarchies</h3> => Diagram: Catalog Hierarchies Flat Catalog (Simpler, but wide categories): <pre class="language-html"><code>Fashion Store ├── Shirts (500 SKUs) ├── Pants (400 SKUs) ├── Shoes (6,000 SKUs) └── Accessories (3,000 SKUs)</code></pre> Deep Catalog (Organized): <pre class="language-html"><code>Fashion Store └── Men’s Clothing └── Tops └── Shirts (1,000 SKUs) └── Bottoms └── Pants (800 SKUs) └── Footwear ├── Casual Shoes (2,000 SKUs) ├── Formal Shoes (1,500 SKUs) └── Sports Shoes (2,500 SKUs)</code></pre>  Best Practice: Keep category depth 2-3 levels max and balance the size of each category. <h3>3. Product vs Variant Modeling</h3> => Diagram: Product → Variants <pre class="language-html"><code>Product: Shirt ├── Variant: Blue, Size M ├── Variant: Blue, Size L ├── Variant: White, Size M └── Variant: White, Size L</code></pre> Code Example: Defining Product & Variants <pre class="language-csharp"><code>[CatalogContentType( DisplayName = "Shirt Product", GUID = "630CB424-945B-48F3-9116-C8E15C8B1E0D", MetaClassName = "ShirtProduct")] public class ShirtProduct : ProductContent { [Display(Name = "Brand")] public virtual string Brand { get; set; } [Display(Name = "Material")] public virtual string Material { get; set; } } [CatalogContentType( DisplayName = "Shirt Variant", GUID = "2B586ABE-1646-4140-8E3E-7FEE3398E440", MetaClassName = "ShirtVariant")] public class ShirtVariant : VariationContent { [Display(Name = "Color")] public virtual string Color { get; set; } [Display(Name = "Size")] public virtual string Size { get; set; } } </code></pre> Use variants for attributes like size and color; use separate products when items differ significantly or need unique SEO pages. <h3>4. Associations for Better Cross-Sell</h3> Use associations to improve average order value : <ul> <li> Accessories → Phone → Case, Charger. </li> <li> Up-sell → Laptop → Higher model with more RAM. </li> <li> Replacement → Printer → Ink cartridge. </li> </ul> This avoids catalog duplication while enabling personalization. <h2>Performance Optimization Techniques</h2> Even the best catalog design needs performance tuning: <h3>1. Search (Optimizely Find)</h3> <ul> <li> Use synonyms (t-shirt = tee). </li> <li> Boost by category or sales. </li> <li> Avoid unfiltered queries on huge categories. </li> </ul> Code Example: Boosting Search Results <pre class="language-csharp"><code>var results = _searchClient .Search<ShirtVariant>() .For("blue shirt") .InFields(x => x.Name, x => x.Color, x => x.Size) .Filter(x => x.Color.Match("Blue")) .OrderByDescending(x => x.MarketPopularity) // Boost popular products .Take(20) .GetResult(); </code></pre> <h3>  2. Caching</h3> <ul> <li> Use output caching for product/category pages. </li> <li> Implement distributed caching (e.g., Redis) in high-traffic environments. </li> </ul> <h3>  3. Lazy Loading</h3> <ul> <li>Load related products/variants only when needed.</li> </ul> <h3>  4. Batch Operations</h3> <ul> <li>Use bulk APIs for imports and updates instead of looping item-by-item.</li> </ul> <h2>Best Practices</h2> <ul> <li> Keep categories logical & balanced (avoid dumping 10,000+ items into a single category). </li> <li> Don’t duplicate products — use associations. </li> <li> Plan for future expansion (new markets, currencies, or product lines). </li> <li> Regularly test indexing performance for large catalogs in Find. </li> </ul> <h2>Conclusion</h2> Designing a scalable catalog in Optimizely Commerce is not just about organizing products — it’s about creating a foundation for performance, SEO, and long-term growth. Thanks :)2025-08-25T11:57:57.0000000Z

Blog post

How to Create Custom Audience Criteria for Mobile Visitors in Optimizely CMSPersonalization is one of the most powerful features of Optimizely CMS. By tailoring content to specific audiences, you can significantly improve engagement, conversions, and user satisfaction. One common scenario is detecting mobile visitors and delivering a more mobile-friendly experience. While Optimizely provides built-in groups (like geographic location, referral, etc.), sometimes you need to define custom audience criteria. In this blog, I’ll walk you through how to create a Custom Audience Criterion that detects whether the user is browsing on a mobile device — and then use it in Optimizely’s personalization engine. <h2>Why Mobile-Specific Criteria?</h2> <ul> <li> Business value: Mobile visitors may need faster-loading content, simplified layouts, or exclusive mobile offers. </li> <li> Developer flexibility: Built-in rules may not be enough; a custom criterion lets you define exactly what “mobile” means for your site. </li> <li> Scalability: Once built, the same rule can be reused across campaigns, promotions, and personalized content blocks. </li> </ul> <h2>Step 1: Create a Custom Criterion Model</h2> Every custom audience criterion in Optimizely starts with a model class that defines its settings. For our mobile visitor detection, the model is simple (no extra configuration needed): <pre class="language-csharp"><code>using EPiServer.Personalization.VisitorGroups; namespace MySite.Business.VisitorGroups { public class MobileVisitorModel : CriterionModelBase { // No custom properties needed for now public override ICriterionModel Copy() { return base.ShallowCopy(); } } } </code></pre>   <h2>Step 2: Create the Criterion Logic</h2> Now we define the actual evaluation logic by implementing <code>CriterionBase<T></code>. Here we’ll check the <code>User-Agent</code> string to detect mobile devices. <pre class="language-csharp"><code>using System; using System.Web; using EPiServer.Personalization.VisitorGroups; namespace MySite.Business.VisitorGroups { [VisitorGroupCriterion( Category = "Device", DisplayName = "Mobile Visitor", Description = "Checks if the visitor is using a mobile device")] public class MobileVisitorCriterion : CriterionBase<MobileVisitorModel> { public override bool IsMatch(IPrincipal principal, HttpContextBase httpContext) { if (httpContext?.Request?.UserAgent == null) return false; string userAgent = httpContext.Request.UserAgent.ToLower(); // A very simplified check for mobile devices return userAgent.Contains("iphone") || userAgent.Contains("android") || userAgent.Contains("ipad") || userAgent.Contains("mobile"); } } } </code></pre> <ul> <li> <code>VisitorGroupCriterion</code> attribute makes it available in the Optimizely UI. </li> <li> <code>IsMatch</code> decides if the visitor meets the condition (mobile browsing). </li> <li> We used a simple <code>User-Agent</code> check, but you can extend this with a more robust device detection library. </li> </ul> <h2>Step 3: Create & Use in Visitor Groups</h2> Once deployed: <ol> <li> Go to CMS Admin -> Audience </li> <li>  Create Audience and choose Mobile Visitor from the criteria list. </li> <li> Combine it with other rules (e.g. Mobile + Returning Visitor). </li> </ol> <img src="/link/5a0fd118cd534ec88b2492d6a0e50e55.aspx" />        4. Assign this visitor group to personalized content blocks, banners, or promotions. <img src="/link/ebe6b5b5525049a3813caa00cba86707.aspx" /> <h2>Step 4: Testing</h2> <ul> <li> Use browser dev tools to switch device mode and test different User-Agent strings. </li> <li> Deploy to staging and validate across real devices. </li> <li> Monitor analytics (Optimizely Experimentation + Google Analytics) to measure engagement lift. </li> </ul>   - By creating a custom Mobile Visitor criterion, you can: <ul> <li> Deliver targeted, device-aware experiences. </li> <li> Go beyond default visitor groups. </li> <li> Set up scalable personalization strategies in Optimizely CMS. </li> </ul> Personalization in Optimizely is all about meeting users where they are. With custom audience criteria, the possibilities are endless. :) Thanks!2025-08-19T11:39:25.0000000Z

Blog post