Bloomreach

Content types support String, Boolean, Integer, Number, Text, Date, Html, RichText, SelectableString, Link, EmbeddedResource, Taxonomy, FieldGroup, SelectableFieldGroup and OpenUiExtension fields, and schemas can be managed through the Content Type Management API inside developer projects. SelectableFieldGroup gives a polymorphic choice of nested groups. Not higher because there is no JSON or location field, and schema changes are gated behind developer projects rather than a schema-as-code workflow.

Link and EmbeddedResource fields create references between documents, multi-value links allow one-to-many, and the editor warns about incoming references when a document is taken offline or deleted. There is no first-class reverse lookup in the delivery APIs and no native bidirectional or many-to-many modeling. Reference checks exist only as editor warnings, which keeps it below 60.

FieldGroup and SelectableFieldGroup fields nest structured blocks inside documents, and experience pages compose components in containers with documents embedded per component. That is a real component and block model. Not higher because rich text is stored as HTML rather than a portable structured format.

Fields can be required, strings have maxLength, and validation rules include an email rule and regex validation on custom inputs. Custom Java validators exist only in the PaaS and self-hosted editions, not in Content SaaS. No cross-field, uniqueness or date-range rules are documented, so it sits at the standard built-in level.

Documents keep separate draft, unpublished and live versions, and Projects act as branches: a project version of a document or channel is edited in isolation from the core version and merged when approved, and a stopped campaign reverts channels to core. Version history and restore exist in the editor, but retention depth, field-level diff and a history API are not documented for SaaS. Branching lifts it above basic revisions; missing diff and deleted-content restore keep it below 70.

A native Taxonomy field type lets developers attach a hierarchical taxonomy, stored as taxonomy documents with multiple levels of categories, to any content type so authors pick categories from the tree. Values are returned through the Delivery API. Not higher because there is no documented governance of who may add terms, no synonyms, and no bulk reclassification tool in SaaS.

The Experience manager renders draft content on the customer's own SPA frontend through the SPA SDK, and editors can create, edit, select and publish content directly in the channel preview. External preview gives shareable token links per project and channel, device preview is built in, and personalized pages can be previewed with an alter ego. Not 90+ because the overlays depend on the React, Angular or Vue SDK integration and the shareable link is protected only by its token.

The rich text editor is CKEditor with predefined styles, internal document links through a picker, anchors, embedded images and an HTML source mode. Output is an HTML string, and the SPA SDK no longer sanitizes it, leaving that to the consumer. Standard WYSIWYG without a portable format or custom renderers lands in the 55 to 70 band, at its lower end.

The built-in library uploads images and assets into folders and generates a fixed set of image variants, with WebP supported since April 2025 and a customer-configurable CDN host. Uploads are limited to 4 MB and 1920x1280 for images and 10 MB for assets, there are no URL-based transforms, focal points, AVIF or usage tracking. That is basic upload and serve.

Documents are locked while one user edits them, and only a site admin can unlock a document held by another user. Projects carry a comment thread and system messages, but there is no inline commenting on content, no presence indicators, no mentions and no co-editing. Locking with project-level comments sits just under the adequate band.

Authors request publication or take-offline, and editors approve or reject; Projects add a review stage where changes are accepted item by item and two webmasters must accept before a project can run. Role privileges determine who can approve and who can merge. Workflow states are fixed rather than configurable and there is no conditional routing, due dates or per-type workflows, which keeps it in the 45 to 65 band.

Projects bundle many documents and channel changes and publish them atomically on merge, and an approved project can run as a campaign with a scheduled start and end, after which channels revert to core. Documents can also be scheduled for publication and take-offline, the Projects overview filters by scheduled run date since September 2026, and browser time zones are supported. No calendar view keeps it just under 75.

Localization is document level: each localized channel has its own folder tree, folders are linked as translations within translation groups, and the Translate action copies a document into the target tree. Pages can be synchronized between translated channels and a Translations API links and unlinks content. There is no field-level localization and no fallback locale chain, which places it in the document-level band.

Content SaaS has six predefined roles (author, project admin, editor, site editor, site admin, site developer) assignable at organization, account or site level, plus folder-based authorization. SAML SSO is supported through Auth0, but the SSO FAQ states there is no JIT provisioning, no user or role management API and no 2FA, and SCIM is not offered. No custom roles or field-level permissions keep it near the bottom of the 45 to 65 band.

Delivery API 1.0 returns a full page model per route in one request, and Delivery API 2.0 adds Documents, Folders, Images and Assets endpoints, separate from the Management APIs. The GraphQL service is commerce-scoped and does not serve content. A well-designed REST-only content API lands in the 60 to 70 band.

Content SaaS applies multi-layer caching including full API response caching with active eviction for instant updates, includes Cloudflare DDoS protection, and lets customers configure a CDN host per channel for images and assets. Delivery carries a 99.9% availability SLA. No customer-facing purge API or edge compute keeps it in the CDN-backed band.

The Webhook Management API configures webhooks on document publish and a small set of other events, retries on HTTP 500 and connection failures, and exposes execution logs through API endpoints. Authentication is through custom HTTP headers only, with no signed payloads and no event filtering beyond the trigger. Solid but narrow webhooks put it in the middle of the 45 to 65 band.

Content SaaS is API-first: the framework-agnostic SPA SDK with React, Angular, Vue, Next.js and Nuxt integrations serves web frontends, and Delivery API 2.0 serves document content to any client. SDK coverage is JavaScript only, with no native mobile or server-language SDKs, and rich text is HTML. That places it at the upper end of the traditional-CMS-with-API band.

Bloomreach Marketing (formerly Engagement) supplies a single customer view, real-time segmentation and event tracking, and its segmentations sync into the Content audiences app so editors can personalize against them; any other CDP can be connected with a JSON import. Content itself has no segment builder: the Content audiences app only appears once the Marketing or external CDP integration is added. Marketing is a separately packaged product, so this is an add-on scored near its ceiling for the depth of the sync.

Content SaaS natively lets editors create component variants per segmentation or Marketing campaign on any experience page, resolves the best variant per component at delivery, and previews combinations with an alter ego in the Experience manager. The decision engine is in Content, but the segments it matches against must come from Marketing or an external CDP. That dependency keeps it below the high 70s.

Bloomreach Marketing runs A/B tests and visual-editor experiments with evaluation, and Bloomreach Search has a full A/B testing application for search and merchandising. Content SaaS has no experimentation on its own pages and component variants are not split-tested natively. Testing therefore depends on sibling products and does not reach the Content page layer directly.

Bloomreach ships ML recommendations in Search and in Marketing, unified across web, email, push, SMS and WhatsApp with filters, position pinning and gradual rollout, and Content offers Pathways and Recommendations components to place them on pages. The engine is strong but lives in sibling products sold separately, so it is capped as an add-on.

Bloomreach Search (formerly Discovery) is a first-party search and merchandising product with faceting, synonyms, facet ranking, Ranking studio and per-query rule exceptions, and it surfaces in Content components through the Discovery commerce picker. Content SaaS on its own only has editor-side document search. Strong search in a separately licensed sibling product is scored at the add-on ceiling less one.

Bloomreach positions Content SaaS as 'a content product for commerce' and its products hold catalogs, merchandising and vouchers, but no module provides a cart, checkout, pricing or inventory. Transactions always run in an external commerce engine.

Content SaaS includes commerce pickers in content types and a first-party GraphQL Commerce API that federates live product data from commercetools, SAP Commerce, Salesforce Commerce Cloud, BigCommerce and others, extendable with Apollo Federation. That is live API federation with product pickers, which would sit in the 60 to 75 band, but first-party connectors are capped at 60. The commercetools Marketing connector is no longer supported for new implementations.

Bloomreach Marketing provides dashboards, custom reports, SQL reports and channel and campaign performance dashboards, and Bloomreach Search has a Performance dashboard with recurring exports. Content SaaS itself has no page or content performance analytics. Strong analytics exist only in the sibling products and measure campaigns and search rather than content health.

Marketing includes a tag manager, Segment and BigQuery integrations, Omniconnect and imports from Snowflake, Databricks, PostgreSQL and Redshift. Content SaaS documents no GA4 or Adobe Analytics integration; tagging happens in the customer's frontend. The integration path runs through the Marketing add-on, which keeps it near 60.

Content SaaS runs many channels in one environment, shares documents between channels, exposes channels, component groups, layouts and routes through the Site Management API, and maps the account to an Organization, Account and Site hierarchy for access. Site Development now sorts channels alphabetically for accounts with many channels. Not higher because there is no inheritance or live-copy model for rolling out changes across sites.

Content SaaS has an in-platform translate action that copies documents into linked folder trees and an asynchronous Translations API, but no official TMS connector, machine translation hook or translation memory is documented. GlobalLink appears only as a partner listing. Translation vendor work runs through custom integration on the APIs.

Roles can be scoped at organization, account or site level and propagate downward, unified administration applies across all Bloomreach products, and component groups and shared containers can be reused across channels. There are no cross-brand approval workflows, brand-level style enforcement or brand-level analytics in Content. Organization-level management without cross-brand policy keeps it in the 40 to 55 band, at its top.

Content's own library has small upload limits and no rights, approvals, versioning or usage tracking, and Bloomreach has no DAM in its suite. Bynder, Cloudinary, Brandfolder, Canto and Frontify connectors are listed on the marketplace, which Bloomreach states it does not guarantee or support. Marketplace-only DAM connectors place it in the 40 to 59 band.

Content SaaS has no video hosting, and Marketing's asset manager accepts videos up to 20 MB for campaigns without transcoding or streaming. Site video comes from YouTube or Cloudinary through marketplace integrations. Video must be embedded from external services.

The Experience manager offers drag-and-drop composition of experience pages from a developer-defined component catalog on the customer's headless SPA frontend, with page templates that editors can save and reuse, shared containers, and live preview while composing. Role privileges control who may change menus, shared containers and templates. Not higher because brand guardrails beyond the component catalog and role privileges are limited.

Bloomreach hosts the Content SaaS APIs with multi-region Kubernetes, Cloudflare protection and a 99.9% delivery SLA, and the Page Delivery API returns the full layout for each route. The website itself is a customer-built SPA on React, Angular, Vue, Next.js or Nuxt, hosted by the customer or a platform like Vercel or Netlify. Bloomreach does not render or host the frontend in Content SaaS, so this is the headless band.

Bloomreach Marketing provides surveys with unique links, NPS surveys, customer acquisition weblayers for progressive profiling and consent pages, with submissions going into the customer profile. Content SaaS has no form builder, and Jotform, Typeform and similar connectors are unsupported marketplace entries. Data capture is solid in the add-on but weblayers and surveys are not a full page form builder.

Bloomreach Marketing is a full email platform with a messages archive of sent emails, unique voucher codes, external deliverability data and support for Mailgun, SendGrid, Brevo and other providers, with segments shared with Content. It is a sibling product licensed separately from Content, so it is scored at the add-on ceiling less one.

Marketing scenarios provide drag-and-drop journey orchestration across email, SMS, push, WhatsApp and weblayers, with journey simulation, smart frequency policy, a campaign calendar and multi-step approvals. This is genuine marketing automation, but it is a separately packaged sibling of Content and is capped as an add-on.

Content SaaS manages routes and URL names per channel and models SEO fields per content type, which the frontend reads from the Delivery API. Sitemaps, redirects, canonical and hreflang tags and structured data are left to the frontend team; Bloomreach Search adds Thematic pages and a Thematic XML sitemap for product landing pages, which does not cover editorial content. SEO fields in the model with frontend-built tooling put it in the 40 to 59 band.

No Bloomreach product documents llms.txt generation, Markdown endpoints for published pages, AI crawler controls or AI citation analytics for customer sites. Bloomreach's own documentation publishes llms.txt and Markdown pages, and its Loomi Connect MCP server targets Marketing and Search operations, not published content visibility. Nothing beyond standard SEO is offered for customer sites.

The Bloomreach marketplace lists about 39 integrations for Content, which Bloomreach does not guarantee or support, alongside roughly two dozen first-party Marketing integrations and an Omniconnect builder. The Content integrations library is small and the public integrations page is now a partner directory without a count. A small directory with some first-party connectors fits the 25 to 45 band.

Bloomreach Marketing resolves known customers through customer identification, ID transformations and server-side anonymous identity, manages consent per customer, and that identity drives segment-based content personalization in Content. Content SaaS has no visitor login, registration, gated content or portal features, so authenticated experiences are built in the customer's frontend and identity provider. Identity-keyed personalization through the add-on lifts it slightly above custom.

Delivery API 2.0 (documents, folders, images, assets) offers query operators, limit/offset pagination, path/id/timestamp filtering and optional JWT-secured endpoints, with a per-endpoint OpenAPI spec and a one-click Swagger Editor link on every reference page, a public Postman workspace covering all ten Management APIs, and a live public trial host (developers.bloomreach.io) whose documented example queries are clickable. Two parallel delivery APIs persist — 1.0 remains the recommended path for SPA SDK site development while 2.0 targets everything else — and GraphQL exists only as the Commerce API for catalog data federated via Apollo, never for content. Well-designed REST with real specs, but the v1/v2 fork and absent content GraphQL keep it mid-band.

Content SaaS layers persistence-level query caching, local indexes and full API response caching behind a CDN-backed API cache, and Batch Import/Export APIs handle large content sets as polled jobs. But no rate limits are published anywhere in the Content documentation — the documented figures (Tracking API 6,000 req/min, Catalog Management 1 req/s) belong to Search and Data hub — and the client-facing CDN is bring-your-own per channel rather than vendor-operated. The rubric's 75+ band requires documented limits, so undocumented ceilings plus a BYO edge hold this below it.

The SPA SDK ships as four lockstep npm packages — core plus React, Angular and Vue — all at 28.1.0 (published 2026-08-06) with bundled TypeScript declarations and ~70K combined monthly downloads, and the lifecycle page commits to supporting a Delivery API major for at least a year after its successor ships. A prior claim of a Lit package does not hold up: the lifecycle doc names only React, Angular and Vue, and no lit-sdk is published. Search adds official native iOS (Swift) and Android (Kotlin) SDKs plus a Web TypeScript SDK, and Marketing adds iOS/Android/React Native/Flutter, but content-side coverage is JavaScript-only with no Python, Go, .NET, PHP or Ruby SDK.

The Content marketplace at marketplace.bloomreach.works lists 40 integrations, not the 176 previously cited — that figure traced to a company-wide integrations directory (Bloomreach's own footer now reads 175) spanning Marketing, Search and Data hub, not Content. Coverage includes DAM (Bynder, Cloudinary, Brandfolder, Canto, Frontify), commerce (commercetools, BigCommerce, Shopify, SAP Commerce, Vue Storefront), form embeds and developer tools, but there is no translation/TMS integration of any kind — no GlobalLink, Smartling, Phrase, Lokalise or Crowdin — and Bloomreach states plainly that it does not guarantee or support marketplace integrations. Roughly 40 apps with an unfilled key category and an explicit no-support disclaimer lands at the bottom of the 55-70 band.

Extension is iframe UI apps at predefined extension points — custom document field editors, commerce pickers via OpenUI — and the Content Integrations Management API does allow full programmatic CRUD of UI extensions plus discovery of which content types consume them, which is more than a click-only registry. The driving client library is the problem: @bloomreach/ui-extension-saas sits at 0.3.3, last published July 2023, never past 0.x in three years. There is no serverless or server-side function model and webhooks fire on only four publish/unpublish events, so this stays in the UI-extension-only band.

Content SSO runs on Auth0 and the documentation is explicit that only SAML is supported — the previously credited OIDC does not exist for Content — and provisioning is a vendor ticket, not self-service: the customer emails sign-in URL, X509 certificate, email domains and default roles to Bloomreach support, who create the connection and return the ACS URL and Entity ID. There is no SCIM, and the documented 2FA via SMS or authenticator app with org-wide enforcement lives in the Marketing security-controls guide rather than Content. API token handling is the strong part: tokens are created per use case in Setup > Content API keys with explicit expiry, per-API read/write scoping, one-time display, and role-gated duration (Site Developer capped at 30 days, Site Developer plus Site Admin unlimited for CI/CD).

Content ships a fixed set of functional roles — Content author, Content editor, Content project admin, Site editor, Site developer, Site admin — assigned in the IAM user-management UI with no custom role builder; the "security domains" credited previously are a brXM/PaaS concept, not Content SaaS. The only content-scoped granularity, folder-based authorization, carries a standing warning that it is in Beta and "should not be used in production scenarios," excludes Site Admin and Site Developer entirely, and documents unsupported cases including the inability to revoke an inherited write privilege on a subfolder or to restrict the pages and channel-root folders. With no field-level permissions and no production-ready content-instance control, this belongs in the predefined-roles band.

Re-verified portfolio clears the 80+ threshold: an annual SOC 2 Type II report plus ISO/IEC 27001, 27017, 27018, 9001 and 22301, GDPR and CCPA/CPRA compliance with a named Data Protection Officer, EU data residency for Content SaaS, and annual third-party penetration tests run per product pillar. Six ISO accreditations is well above category average. The absence of a public HIPAA BAA, and a Trust Portal that serves reports only on request rather than self-serve, prevent going higher.

Two corrections lift this. Bloomreach does run a bug bounty program, hosted on BugBase, alongside a documented vulnerability-management policy (web and threat scans, tracked and prioritised tickets), a defined security incident process and annual third-party pentests per pillar. And the "90+ Content SaaS outages" figure came from third-party status aggregators counting component-level status flips across all 30 components: Bloomreach's own incident feed records 33 incidents platform-wide in 2026, almost all Search or Marketing, and only two ever tagged to Content SaaS — a minor 2024 CMS issue and the December 2025 Cloudflare outage. No known breaches or product CVEs. Held below 75 because the bounty is not referenced from Bloomreach's own security page and the Trust Portal gates reports behind a request.

Three deployment options are contractually live: Content SaaS on managed Kubernetes, Experience Manager PaaS, and Experience Manager Self Hosted (formerly Private Cloud), which gives regulated buyers a genuine private-cloud path — the current Experience Manager SLA covers PaaS and Self Hosted together. The PaaS estate spans nine Bloomreach Cloud regions across North America, EU and APAC. SaaS is the constrained option: compute sits in a single customer-chosen region and the documentation still describes that choice as "initially EU or US-East," so the SaaS buyer has two regions and no multi-region deployment.

The Headless Experience Manager-SaaS SLA sets 99.9% Delivery API, 99.7% Management API and a lower Dashboard target, with tiered service credits (10/20/30% of monthly fees) and a termination right if availability averages under 98% for two consecutive months; PaaS and Self Hosted guarantee 99.99%. The public status page covers 30 components with a real, dated incident history, and Content SaaS had a clean 2026. The drag is governance: the Content SaaS SLA is still the one effective 22 November 2021, while Discovery was refreshed in August 2025 and PaaS in May 2025 — the CMS contract has gone almost five years untouched, and the 99.9% delivery target sits below the 99.95%+ peers.

Multi-AZ Kubernetes with compute shared dynamically between tenants, multi-AZ database-backed persistent storage per namespace, Cloudflare DDoS protection bundled at no incremental cost, and zero-downtime delivery-API upgrades, on a platform Bloomreach says has served trillions of requests per year across government, financial services and B2C commerce; MACH Alliance member. What it does not publish is any documented ceiling — no entry counts, requests per second, or concurrent-user limits anywhere in the Content docs — and each tenant runs in one region with only two SaaS regions to choose from. The rubric reserves 75+ for proven scale with documented limits.

Resiliency is architectural rather than documented: containers can be replaced in a different availability zone on a cloud failure, storage uses multi-AZ database services, and each account gets a test and a production environment. Content portability runs through the Batch Export API (a polled job returning a zip of JSON lines with a success/failure report), but that API explicitly does not export images and assets — customers storing media in the repository must extract it manually or contact support. RTO and RPO figures exist only behind the request-gated Trust Portal, backup frequency and retention are not published, and there is no multi-region failover.

There is no local Content instance, emulator or content CLI. The documented workflow is to clone the hosted Reference SPA from GitHub, run it over HTTPS locally and point it at your cloud account's Delivery API, optionally bootstrapping a channel from a storefront template; server-side isolation comes from Development Projects, which are branches inside the remote tenant. Because the back end is only ever remote and no command-line tooling exists for content or configuration — Postman collections and a Site Development UI fill that role — this sits below the CLI-plus-remote-workflow band.

Each account is provisioned with exactly two environments, test and production, which the documentation stretches across all four DTAP stages. Automation is possible — the Site Management API driven from Jenkins or GitLab CI, with extended-duration tokens for trusted developers — but schema and configuration versioning is explicitly do-it-yourself: Bloomreach recommends developers export the JSON descriptions of components and content types through the Management APIs and commit them to git themselves. There is no migration CLI, no schema diffing, and no branch-per-PR content environment; payloads are also documented as not easily portable between channels within one environment.

The 2026 docs are unusually machine-legible: every page is retrievable as Markdown by appending .md, and content/llms.txt indexes all 339 Content pages plus OpenAPI endpoints for AI agents — ahead of most peers on this axis. Human-facing coverage is solid too: per-endpoint OpenAPI specs with one-click Swagger Editor links, a public Postman workspace, a live trial host whose example queries are clickable, and framework guides for React, Angular, Vue and Netlify/Vercel deployment. Against that, several nav-linked pages are hollow — content/docs/mcp resolves to the 404 page, and loomi-connect and security-and-compliance return a heading with no body — so the set is genuinely good but visibly unfinished at its newest edges.

All four SPA SDK packages are written in TypeScript, ship type declarations and version in lockstep at 28.1.0 (August 2026), giving typed page-model interfaces across React, Angular and Vue. Type generation from the content model does exist — the marketplace "Typescript Interfaces" tool emits interfaces from your content type model for editor autocompletion — but it is labelled "Developed By: Bloomreach Community," was published in October 2022 and has never been modified since, and lives in the marketplace Bloomreach declines to support. The Discovery Web SDK ships no types entry. A four-year-stale unsupported community generator earns a little above the typed-SDK-only band but nowhere near the 80+ first-party codegen tier.

Bloomreach ships constantly overall — Search ran ~10 numbered releases in 2026 (2026-32 through 2026-63, Sep 17), Marketing ran 1.308–1.318, and brXM PaaS shipped a new major, 17.0.0 on May 4 2026, followed by 17.1.0 (Jun 18) and 17.2.0 (Aug 13). But the flagship Content SaaS CMS is in maintenance mode: of its last 10 biweekly releases, exactly one (20260902, Projects overview filtering) shipped a user-visible feature, five were bug fixes and four carried the verbatim boilerplate 'focuses on internal system improvements.' Not higher because the CMS this scorecard grades has near-zero feature velocity even as the AI/search/marketing modules move monthly; not lower because the cadence is genuinely biweekly and brXM 17 is a real major release.

The brXM release-notes overview is genuinely strong: a full version table back to 13.x with release dates, per-version detailed notes, explicit EOM/EOL status flags on every entry, and links to upgrade instructions. Content SaaS entries are structured with '🚀 Improvements' / '🐛 Bug fixes' headings plus a callout naming the exact two-week deployment lag and regional maintenance windows, and Marketing/Search entries open with a dated TL;DR. Not higher because the changelog is split across four separate homes (content/, engagement/, discovery/, xmdocumentation) with no unified feed, no Content SaaS breaking-change section, and the recurring 'Continuous improvements' boilerplate tells a reader nothing.

The Loomi Innovation Hub publishes a real three-stage public roadmap — 'NOW / Early Access', 'COMING SOON (H2 2026, Timelines Established)' with per-item quarter targets (Real-Time Web Triggering Q3 2026, LLM Query Understanding Q4 2026, Granular Access Controls Q4 2026), and 'EXPLORING / Research, no timeline' — roughly 25 named items with category tags and a 'subject to change' disclaimer, backed by half-yearly roadmap webinars (Marketing Automation Roadmap Feb 24 2026, Ecommerce Search Roadmap Jan 22 2026) and the annual Innovation Fest. Not higher because there is no community feedback or voting portal, and — decisively for a CMS buyer — not one roadmap item is an Enterprise CMS feature; the only CMS-adjacent entry is 'CMS-DAM Integration – Asset Selection', which is about Loomi consuming assets from a CMS.

brXM publishes a dated support matrix rather than a vague policy: 16.x (released Jun 2024) has Standard support to Dec 2026 and Premium to Dec 2027, and 17.x (May 2026) to Dec 2027 / Dec 2028, with every version in the release table flagged EOM or EOL, and majors arriving roughly every two years. An automated upgrade tool shipped May 2026 that applies manifest-driven code and config changes, and the SaaS modules absorb breaking changes server-side. Not higher because only the final minor of each major stays maintained — staying supported means a continuous minor-upgrade treadmill — 16.x Standard support lapses in Dec 2026 just seven months after 17.0.0 GA, and there is no semver guarantee or codemod tooling for Content SaaS APIs.

The independent developer footprint is close to nonexistent: Stack Overflow's 'bloomreach' tag holds one question ever, there is no 'brxm' or 'hippo-cms' tag, and a search returns zero Bloomreach questions created in the past year. The official Discourse forum carried 12 topics in all of 2026 to date and reports 2 topics / 15 posts / 16 active users / 1 new user in the last 30 days, while the brxm GitHub repo has 30 stars, reference-spa 20 and spa-sdk 19 (the org's only large repo, s4cmd at 1,395 stars, is an unrelated S3 CLI). Not lower because npm tells a different story — @bloomreach/spa-sdk pulls 46.7K downloads/month and discovery-web-sdk 34.7K — and commercial adoption proxies are healthy (~769 G2 reviews, a 398-entry partner directory).

Participation is thin in absolute terms — 15 forum posts and zero likes in the last 30 days, no new topic in seven days — but what little gets asked does get answered: of the 12 topics opened in 2026, most drew 1–5 replies and one drew 13, so this is a small quiet community rather than a large ignored one. Bloomreach does invest in structured engagement — a tiered Rewards Program (Advocate/Evangelist/Ambassador, powered by Deeto) and joint hackathons with Google Cloud, AWS, PayPal and the MACH Alliance (May 2026) and with Google, Shopify and Databricks (Aug 2026). Not higher because those are partner and AI-ecosystem programs, not developer community, and the forum threads that do appear are overwhelmingly legacy brXM 14/16 troubleshooting rather than Content SaaS.

The directory is substantial and properly tiered: 398 entries (329 Partner Agencies, 73 Agency Partners, 67 Technology Partners) across a Silver/Gold/Platinum program with a documented four-step onboarding that requires training and certification per level, plus regional partner awards run in both Americas and EMEA in May 2026 and platform alliances (AWS Retail Competency, Databricks CustomerLake launch partner). Depth is real at the top — Media.Monks, valantic and CACI at Platinum, VML and Merkle at Gold. Not higher because only 16 of 398 partners hold Gold or Platinum while 275 are merely 'Registered', there is no Accenture/Deloitte-scale global SI, and only two partners in the entire directory are tagged to the Content pillar (Codal, Ansira) against 19 for Engagement and 7 for Discovery — CMS delivery capacity is the weakest part of the network.

There is almost no grassroots content to find: one Stack Overflow question tagged bloomreach in the site's history and none in the past year, no independent Udemy/Pluralsight/LinkedIn Learning courses located, and no meaningful non-vendor YouTube or blog corpus. Essentially all learning material is vendor-run — Bloomreach Academy's brXM v16 Developer Foundations and Advanced Developer tracks (course versions 2026.01, 2026.09, 2026.10) — or produced by certified partners. Not lower because the multi-vendor hackathons and MACH Alliance activity do generate some genuinely third-party ecosystem write-ups, and the vendor's own Innovation Fest and blog output is heavy.

Bloomreach itself is hiring hard — 77 open roles on its Greenhouse board as of Sept 2026, weighted to engineering, AI/ML and data science across Czechia, Slovakia, India and the US — and Bloomreach Academy runs a live certification path with a Developer Foundations exam and brXM v16 courses refreshed for 2026. But demand for Bloomreach-experienced developers outside the vendor and its certified partners stays niche: one Stack Overflow question in the tag's history, a forum averaging one topic a month, only 16 Gold/Platinum partners and just two partners with a declared Content practice to recruit from, and brXM work requires Java/HST expertise. Not higher because headcount is effectively flat (~1,064, +1.5% YoY), so the vendor is not growing the talent pool either.

The commercial story is strong and externally corroborated: $260M+ ARR with record net new ARR and positive free cash flow (Feb 2026), the 2026 Inc. 5000 for a fifth consecutive year (Aug 13 2026), and a steady 14-release news cadence Jan–Aug 2026 covering Loomi for Shopify, AWS Marketplace availability, AWS Retail Competency and launch-partner status on Databricks CustomerLake. Not higher because the headline ARR figure is now seven months stale with no update since, the last new-enterprise-logo announcement was that same February release, headcount is flat at +1.5%, and not one 2026 announcement concerns the CMS — all momentum sits in the search and marketing modules.

Bloomreach has raised roughly $422M over seven rounds at a $2.2B valuation and, more importantly for buyers, reported positive free cash flow in 2025 against $260M+ ARR — a company that no longer needs to raise. Stability signals corroborate: 77 open roles on its own board, no layoff reporting in 2026, and a fifth straight Inc. 5000 listing. Not higher because the last round (Series F, Goldman Sachs) closed in 2022 so the $2.2B mark is four years stale, headcount growth has flattened to ~1.5%, and the profitability claim is vendor-reported and unaudited.

Analyst recognition in Bloomreach's chosen markets is unusually deep for its size: Leader in the 2026 Gartner Magic Quadrant for Search and Product Discovery for a third consecutive year, Visionary in the 2026 MQ for Multichannel Marketing Hubs also for a third year, Leader in the 2025 MQ for Personalization Engines, and a prior Forrester Wave Leader in Commerce Search. The commerce-first, agentic-AI (Loomi) differentiation is clear and consistently argued against named rivals. Not higher because Bloomreach is absent from the Gartner DXP and Digital Commerce Magic Quadrants that define the market this scorecard covers, three straight years as an MMH Visionary without promotion reads as a plateau, and its own product navigation now lists 'Enterprise CMS' as one bullet under a Loomi AI platform — weak positioning for a DXP buyer.

Four independent sources agree at the top of the rubric's band: G2 4.6/5 across ~769 reviews, Capterra 4.8/5, TrustRadius 4.5/5 over ~320 reviews with 2026 Top Rated Awards in Marketing Automation, Email Marketing and Ecommerce Personalization (Jun 2026), and Gartner Peer Insights 4.6/5 from 152 reviews. Per the rubric, G2 4.5+ with 200+ reviews warrants 75–85, and the corroboration justifies the upper band; recurring negatives — steep learning curve, complexity from feature breadth, slow report building — are predictable rather than alarming. Confidence is MEDIUM not HIGH because G2 blocks direct fetching (403) and the ~769 review count is unchanged from the prior scoring round, so the figure may be stale, and the review corpus overwhelmingly reflects the marketing and search products rather than the CMS.

Pricing is now entirely sales-gated: the former per-module pricing pages (/pricing/content, /pricing/engagement, /pricing/discovery) all 301 to a single 'Request Pricing' page carrying zero dollar figures, where all three products (Autonomous Marketing, Autonomous Search, Conversational Shopping) show only 'Annual Plan — Request Pricing', and the previously-citable public anchor — the Engagement Starter listing on the Shopify App Store — now 404s. Offsetting that, Bloomreach publishes unusually detailed billing *methodology* (pricing meters, allowance derivation, usage dashboards) plus its full MSA and per-product appendices, which is more structural disclosure than most sales-gated enterprise DXPs. No prices and 'illustrative only' allowance multipliers keep it in the mid-30s.

Bloomreach moved to profile-based pricing in May 2026, materially simplifying the model it is scored on: a flat annual subscription tier sized by just two meters — billable profiles and MUV — where the tier is set by whichever is higher (not additive), both averaged over the last 3 completed calendar months to smooth spikes, and every downstream allowance (events, messages, API calls, storage) is derived from contracted profiles and fixed for the contract duration. A first-party usage dashboard renders contractual limits as progress bars at account and project level. It stays below 55 because rates are unpublished, excess usage is still billed separately and sustained overage forces contract 'right-sizing' to a higher tier, sandbox/dev projects are not exempt and there is no deduplication across projects in a workspace, and three pricing models (event-based, pre-May-2026 profile-based, current) still coexist across the install base.

Bloomreach confirms on its own pricing page that Loomi AI ships in every product at no extra charge and that base plans bundle support, documentation and best-practice sessions — AI is genuinely not a paywall, which is better than most DXP peers. Against that, the platform is still sold as separately-licensed modules that stack additively ('You only pay for the modules you want. Additional modules and upgrades can be purchased separately'), core metered capabilities are tied to specific packages (event storage and profile updates apply only to Loomi Platform/Loomi AI Platform package holders; push is metered only with the Mobile App package), and the Data exports feature — the primary data-portability tool — is not universally enabled and requires a CSM request. Additive module licensing plus a CSM gate on data export holds this in the mid-40s.

The public MSA is explicit that there is no termination for convenience at all — 'neither Party is entitled to terminate any portion of the Bloomreach Services or the Agreement without cause' — and §7.4 adds an acceleration clause: on any termination other than Bloomreach's uncured breach, the customer 'shall remain responsible for all outstanding fees payable to Bloomreach for the Term and Bloomreach may declare all such fees immediately due and payable.' Fees are non-refundable, overdue invoices carry 1.5%/month, billing is annual-only with better rates reserved for multi-year commitments, and the one codified exit route (EU Data Act switching, EU customers only) still permits switching charges and 'reasonable and proportionate termination fees.' No published startup, nonprofit or education programs, so this sits in the mid-30s rather than near 50.

None of the commercial products has a free tier — all three are 'Annual Plan / Request Pricing' — and the self-serve Shopify Starter entry point has been withdrawn. Two things keep this above the pure enterprise-only floor: Bloomreach Experience Manager (brXM) remains a live, non-archived Apache 2.0 community edition (last pushed 2026-07-17), a permanent and commercially-usable open-source CMS; and Content SaaS now publishes a genuinely open shared trial environment with credentials printed in the docs, so evaluation needs no sales contact. Corrected upward from the prior assumption of a sales-gated-only trial, but a shared sandbox and a legacy OSS edition are not a free production tier, capping this around 30.

A developer can now reach a working Content CMS in minutes with no sales contact by logging into the public shared trial environment with credentials published in the docs, then following a six-milestone getting-started path (create a channel → front-end app → development project → components) backed by the Reference SPA and a 25-minute Academy crash course. That is a real improvement over the previous request-a-trial-only path. It stays below 55 because first content query still requires creating an API authorization token, building a front-end app and modeling components — days of setup before a real integration works, not the sub-hour path of self-serve headless peers.

Bloomreach's own published figures put Autonomous Search at an average of six weeks to complete with impact under four weeks, and Marketing/Engagement customers 'actively using' the platform within three months on average, with a single-channel launch cited 'in as little as a few weeks.' Those are vendor-sourced and therefore optimistic, and Bloomreach itself concedes 'our implementation takes a little longer' than competing search vendors. Roughly 6 weeks for search and ~3 months for marketing automation is adequate-to-good by enterprise DXP standards, but SI involvement and multi-module data mapping remain the norm, so this holds in the mid-40s rather than rising into the 50s.

Content SaaS is API-driven with SPA SDKs, reducing the legacy Java/Spring/JCR dependency of brXM, and Bloomreach Academy plus the new Loomi Connect MCP tooling lower the ramp somewhat. But cross-module expertise spanning Marketing, Search, Conversational Shopping and Content remains a niche talent pool relative to mainstream CMS stacks, so a moderate specialist premium persists. Score held unchanged from the prior cycle: the third-party consultant rate figures behind it could not be re-verified in this run, and no new primary evidence on hiring cost surfaced.

Every product a new customer buys — Autonomous Marketing, Autonomous Search, Conversational Shopping and Content SaaS — is vendor-hosted SaaS with infrastructure bundled into the subscription, so there is no separate server, database or scaling invoice; self-hosted brXM survives only as a legacy path. Two genuine extras keep it out of the 75+ band: Bloomreach Content serves assets from its own *.bloomreach.io domain by default but documents a customer-supplied CDN as the recommended configuration, and Loomi BigQuery is a contract allowance rather than included storage, pushing warehouse costs outside the license.

SaaS delivery offloads infrastructure, scaling and patching entirely, and the burden the prior cycle flagged most — manually policing usage caps to avoid overage tier jumps — is now a first-class product surface: an account- and project-level usage dashboard renders contractual limits as progress bars with monthly consumption breakdowns and dedicated Usage Viewer roles. Remaining effort is integration and data-pipeline ownership, multi-project configuration, and event-storage hygiene, since stored events accumulate across a project's entire history and count against allowances. Not near-zero ops, but well short of a platform-engineering team.

Exit tooling is better documented than most enterprise DXPs: Data exports emits raw customer and event data as CSV, JSON or JSON Lines with field selection, filtering and column remapping to SFTP, Google Cloud Storage, Amazon S3 or Azure, alongside Content Batch Export/Import APIs and Loomi BigQuery, and the MSA now codifies an actual switching right — a two-month notice period followed by a 30-day Transitional Period in which Bloomreach must provide reasonable assistance exporting all exportable customer data. Three things cap it in the mid-50s: that contractual right is available only to EU-resident customers under the EU Data Act, Bloomreach may levy switching charges and full remaining-term termination fees on top of it, and Data exports itself is not universally provisioned — it requires a CSM request.

Content SaaS removes brXM's JCR/Java layer but still requires channels, the site configuration model, the page/container/component model, document types vs field group types vs image set types, editing templates, core-vs-project branching, development projects, and a split between the Delivery API and ten separate Management APIs — well past the five-concept threshold, and the container/component page model does not map to standard routes-and-models thinking. The wider Bloomreach suite (Content, Search, Marketing after the Sept 2026 rename) layers a three-module surface on top. Lighter than AEM or Sitecore XP, heavier than a headless CMS with plain content types and entries.

The structured path is genuinely good: six Get Started milestones each carrying a 2–10 minute time estimate and a YouTube walkthrough, eleven hands-on tutorials, an Academy Content crash course, channel templates that bootstrap a working hosted channel instantly, a publicly credentialed shared developer environment needing no signup, and a full llms.txt index with every page fetchable as Markdown. But the tutorial code is badly stale — it teaches create-react-app (deprecated by the React team in Feb 2025), ReactDOM.render (removed in React 19) and react-router-dom v5 Switch/Redirect — the content-getting-started example repo has not been pushed since April 2023, and the bloomreach-react-sdk docs page 404s so App Router support is documented only in the GitHub README. Structure earns the mid-50s; the misleading code keeps it out of the 65+ band.

Broader mainstream coverage than previously credited: @bloomreach/spa-sdk, react-sdk, ng-sdk, vue-sdk and lit-sdk all publish in lockstep at 28.1.0 (2026-08-06) with TypeScript declarations, the react-sdk peer range reaches React 19, and the in-repo examples/next is fully current on Next 15.3.8 / React 19.1.4 / TS 5.7 with turbopack — plus Nuxt and Lit examples the lifecycle doc does not even mention. Real RSC and App Router support ships via the ./server export condition (BrPageServer, BrComponentServer). It stays out of the 75+ band because the BrPage/BrComponent mapping abstraction over the page model is proprietary and mandatory for Experience manager integration, GraphQL is Commerce-catalog-only rather than content, and there is no first-party type generation — the only codegen is a 2022 community marketplace tool.

The flagship bloomreach-reference-spa — the repo the docs instruct you to clone, shipped as a channel template and backed by Netlify and Vercel deploy guides — is pinned to @bloomreach/react-sdk 21.0.0 against a current 28.1.0 (seven majors behind), next 12.1.0, react 17.0.2, typescript 4.5.5, axios 0.22.0 and engines.node "18" (EOL April 2025); its only 2025 and 2026 commits are copyright-header bumps, with the last substantive commit in Sept 2024. It does ship example content (Pacific Nuts & Bolts), TypeScript and deploy config, and the spa-sdk monorepo's examples/ are current and version-locked, but those are minimal framework samples inside an SDK repo rather than clonable starters with content. A vendor starter that exists but has been unmaintained for four years lands below the 50–65 "basic starter" band.

Cloud SaaS removes infrastructure work and the Reference SPA needs only one required env var (NEXT_PUBLIC_BRXM_ENDPOINT) alongside ~13 optional Discovery/personalization values, but environment management is where it gets expensive: there is no CLI anywhere in the 339-page Content documentation set, only test and prod environments are provisioned, and config-as-code is explicitly DIY — Bloomreach's own guidance is to export resource JSON through the Management APIs and store that in version control. Local development additionally requires serving the SPA over HTTPS to avoid mixed-content blocking in Experience manager, threading the request path through BrPage, and separate API tokens per module. Multiple keys plus manual environment promotion place it in the heavier half of the moderate band.

The documented constraints are sharper than the branch-and-merge story suggests: only a single active developer project may contain content type changes at any one time, a content type can never be deleted once merged to core, renaming and deleting are API-only and unavailable in the content type editor, and the docs warn that altering a content type can make existing document fields "go missing" from the Delivery API with no migration tooling offered as a remedy. Projects are also only recommended up to 200 pages and 200 documents before UI responsiveness degrades. Real mitigations exist — project-context preview against draft schema, the Content Type Management API, Content Batch Import/Export, and 15 field types including SelectableFieldGroup and Content Blocks — but irreversibility plus the single-project lock keep it below the 60+ "low-risk with tooling support" threshold.

External preview is genuinely zero-effort — the docs state it is automatically enabled with no additional code changes and no SDK upgrade for any frontend already built on the Content SDKs, exposing shareable URLs for both the frontend and the Delivery API, per-project toggles and regenerable tokens. In-context Experience manager preview still costs real integration work: the request path must be threaded through BrPage, the SPA must run over HTTPS locally, a development project must be pointed at the local app, and RSC adoption forces a dual entry point keyed on page.isPreview() because BrPageServer does not work in Experience manager and Manage Content/Menu buttons never render in server components. Well-documented but code-level setup puts it mid-band, with external preview URLs secured only by the secret embedded in the link.

A Content SaaS build is fundamentally a mainstream JavaScript project — generalist React, Angular, Vue or Lit developers work against first-party SDKs and a plain REST Delivery API, with CKEditor rather than a proprietary template language and no custom query language for content. Platform-specific knowledge is still required for the page model, component mapping, the site configuration model and the project merge lifecycle, and Academy certification exists but is optional. The prior score over-weighted Marketing's Jinja templating, which belongs to a separate module rather than a CMS implementation, so this sits squarely in the "moderate platform knowledge, no certification" band.

Beyond the usual tier-1 commerce DXP staffing, the platform imposes structural coordination overhead: only one developer project may hold content type changes at a time, so schema work serializes across the team; only test and prod environments are provisioned; and with no CLI, promoting configuration between them is a manual Management API JSON export-and-commit exercise. Channel templates make a first working channel cheap, but a production build spanning frontend development, content architecture and the project merge lifecycle is not solo-developer territory.

Post-go-live self-service is stronger than previously credited: the Experience manager gives marketers drag-and-drop component management and in-context content editing on existing layouts, the Projects app lets them group changes, request review, merge or schedule them as a campaign without a developer, external preview links let stakeholders review unpublished pages with no account at all, and partial container locking lets two editors work distinct page regions concurrently. Developers remain in the loop for any new component type or site configuration change, which must travel through a development project merge, and the Projects app is only recommended up to 200 pages/documents. Real self-service on routine operations, with a developer gate on anything structural.

Content SaaS upgrades are fully managed — "no customer action required", zero delivery-API downtime, only minimal CMS maintenance windows with 72 hours' notice — but the brXM PaaS/self-hosted half carries a real major upgrade: 16→17 requires Java 21, Spring Boot 4 / Spring Framework 7 / Spring Security 7, Jackrabbit 2.22 with RMI removed, a JUnit 4 → Jupiter 6 test migration, an Angular 21 rewrite of custom Essentials plugins, and it silently drops four workflow fields from the Content REST API with "no error or warning"; majors support only a stop/start deployment with all cluster nodes stopped. Not lower because the major cadence is ~2 years (14 Dec 2019, 15 Apr 2022, 16 Jun 2024, 17 May 2026), minors are contractually backward compatible with per-step upgrade docs, and a Configuration Verifier ships with every release to diff bootstrapped config before it is applied; not higher because the prior score credited a roadmapped "automated upgrade CLI" that has not appeared in any shipped release.

The patch machinery is better than previously scored: security reports are assessed within one business day, OWASP MEDIUM+ issues can get a dedicated hotfix, and maintenance releases are backported across three major lines on the same day (17.2.0, 16.9.4 and 15.7.11 all shipped 13 Aug 2026), so a customer on an older maintained minor still receives fixes; Premium Support now adds a Content Vulnerability Dashboard fed by OWASP Dependency-Check with per-CVE Jira remediation status, severity/status filters and CSV export. Not higher because the public security-issues list has published nothing since 7 May 2025 (~16 months), live vulnerability data is Premium-gated, open-source releases lag commercial ones by 24 months (brXM 16.0.0 was open-sourced 29 Jun 2026), and a fix is "only applied in the maintained product versions" so self-hosted teams must stay on the treadmill to be patched at all.

Deprecation windows are long in absolute terms — 16.x reached GA in June 2024 and Premium Support runs to December 2027 — but the published EOL policy maintains only the latest minor of the current major plus the final minors of the two previous majors, and states that an acknowledged bug "will only be applied in the maintained product versions", which makes minor upgrades effectively mandatory to stay serviceable; latest 15.x already shows "No Support" under Standard and 16.x Standard Support ends December 2026. Not lower because the major cadence is ~2 years and Content SaaS customers face essentially no forced change; not higher because v17 removes undocumented-but-visible Content REST API fields silently, the Incubating Features policy introduced in 16.6.0 permits backward-incompatible change or removal inside minors, the commercetools and SFCC Data Hub commerce connectors were closed to new customers in January 2026, and the documentation itself is mid-migration to docs.content.bloomreach.com with the old site slated for retirement.

Content SaaS abstracts the entire dependency stack, but brXM PaaS/self-hosted is one of the heavier Java trees in the dataset — Spring Boot 4 / Spring 7 / Spring Security 7, Jackrabbit JCR, Apache Wicket, Tomcat, HikariCP, a relational database, Elasticsearch for Relevance, Maven multi-module builds, plus an optional AI module pulling Spring AI 2.0 and a vector store — and the published advisory history is dominated by exactly these transitive CVEs (Spring, Apache CXF, Wicket, Tomcat, guava, bouncycastle, semver, the Postgres Docker base image). Not higher because that surface is the customer's to scan and bump on the self-hosted path; not lower because Bloomreach Cloud auto-detects the correct JVM for an uploaded distribution and the Premium vulnerability dashboard gives per-version OWASP Dependency-Check output rather than leaving teams to derive it.

v17 added native OpenTelemetry: Bloomreach Cloud injects a Java auto-instrumentation agent into each CMS pod and pushes traces — plus separate log streaming — over OTLP to Dynatrace, Grafana Cloud, Honeycomb, New Relic or Splunk with no code changes, alongside documented New Relic, JVM-memory and application-log monitoring and a public multi-component status page. Not higher because audit logging is a separately licensed add-on that ships only sample ActiveMQ/Elasticsearch connectors and expects the customer to supply the store and build the UI, OpenTelemetry is opt-in and gated to v17+ on Bloomreach Cloud, and the Content SaaS docs contain no audit log, usage dashboard or webhook-delivery health view at all — that tier depends on Bloomreach's own 24x7 operational monitoring, with Content SaaS represented on the status page as a single ungrouped component.

Governance still rests on editorial discipline: the licensed Content Reports app offers only four activity report groups (Buzz, My Documents, Team Documents, Totals), and there is no orphan detection, broken-reference alerting, link checker or expiry health dashboard anywhere in the 339-page Content docs — while content-type changes serialize to one active developer project at a time, are irreversible once merged, and the docs warn that existing fields "could go missing" with no migration tooling. Not higher because the 2026 roadmap items the previous score credited never landed — the Content SaaS changelog for all of 2026 contains two user-visible features against eight bug-fix or "internal system improvements" entries — and the AI Search Agent that did ship adds work rather than removing it, requiring the customer to initialise a vector store, configure ingestion filters and maintain embeddings through Groovy updater scripts; not lower because Advanced Search bulk workflows, the taxonomy plugin and the Bulk Upload add-on do cover routine bulk editorial operations.

Content SaaS does most of the work: multi-layer caching (persistence-layer query cache, per-node local indexes, full API response caching with active eviction), generous default provisioning sized for billions of requests/month, per-environment scaling, Cloudflare in front, Bloomreach proactively adding resources for holiday peaks, and a page-based Delivery API that collapses a page render into one request. Not higher because images and assets are not covered — a CDN host must be configured per channel and the asset store enforces 4MB / 1920x1280 limits with seven fixed variants, pushing image optimisation back to the customer — and the brXM PaaS/self-hosted half still needs JVM tuning, HST cache monitoring, JCR repository tuning and Elasticsearch care.

The support commitment is contractually published rather than marketing copy, and the baseline tier is genuinely strong: Standard Support carries a 30-minute target response on P1 at 24x7 with phone, email and portal access, 4 hours 24x5 on P2 and one business day on P3, and review sentiment for Bloomreach support is consistently high (G2 ~4.6/5 with a ~9.2/10 support rating). Not higher because meaningful extras are gated to Premium Plus — 20-minute P1, 24x7 on P2/P3, a Slack channel explicitly "for quick questions only and not reporting product issues", bi-weekly case review, monthly SLA reporting and the security Vulnerability Dashboard — Standard is capped at fewer than five support-portal logins, a Service Level Manager is a separate purchase in both tiers, and the governing Content SaaS SLA is still the edition effective 22 November 2021.

The Discourse forum at community.bloomreach.com is the only public peer channel and it is thin: its 30-thread "latest" feed reaches back from September 2026 to mid-2025, i.e. roughly 25–30 active threads a year, about a sixth of them with no reply at all, and the Content SaaS category has accumulated just 56 topics against 1,721 for the legacy Experience Manager PaaS/OnPrem category. Not higher because there is no public Discord or Slack (the Slack channel is a Premium Plus entitlement restricted to quick questions), Stack Overflow coverage is sparse, and open-source releases trail commercial ones by 24 months so the community cannot self-help against current code; not lower because Bloomreach staff do post announcements and most threads eventually draw a substantive answer.

The shipping record is solid: brXM maintenance releases land every four to eight weeks per line and are cut simultaneously across three majors (17.2.0, 16.9.4 and 15.7.11 all on 13 Aug 2026, mirrored on 8–9 July and 18 June), security reports are triaged within one business day with hotfixes available for OWASP MEDIUM+, and Content SaaS ships dated bug-fix releases roughly monthly. Not higher because detailed release notes are 401-gated behind a documentation account so customers cannot see what was fixed without one, the public security list has added nothing since May 2025, 16.6.0/16.6.1 were marked deprecated after release, and fixes are backported only into maintained minors — resolution frequently means upgrading.

The Experience manager gives marketers a visual, component-based page builder: drag-and-drop components into containers, edit content inline in the channel preview, device preview, and a documented set of ready-made components (banner galleries and carousels, category and product highlights, product grids). Personalized landing pages are built from these same components with per-segment variants. The ceiling is that new page layouts are channel configuration — layouts, routes and the component catalog are developer artifacts managed through the Site Management API or a development project, not marketer-editable. So marketers assemble pages freely from an existing catalog but cannot invent a layout.

Bloomreach Marketing (renamed from Engagement in September 2026) is a full campaign management suite: scenario-based cross-channel orchestration, campaign/channel/project performance dashboards, and a documented set of prebuilt campaign use cases. Two items previously scored as roadmap are now shipped and documented: the Marketing agent (Affinity), which turns a natural-language brief into a reviewable multi-channel campaign with send modes, vouchers and email blocks, and Catalog triggers, which fire campaigns from product catalog changes. Content SaaS itself has campaign objects only in the personalization sense (a campaign is a segment container for component variants) — there is no editorial content calendar in the CMS. Requires the Marketing module license.

Correcting a materially over-scored item. A full sweep of the 339-page Content SaaS documentation index returns no SEO tooling whatsoever: no XML sitemap generation, no redirect manager, no SEO field types or validation, no meta/OG tag management, no canonical URL handling and no Schema.org support. The only 'sitemap' endpoints in Content are the channel routing API (brXM historically calls URL routes 'sitemap items'), which is frontend routing, not a search-engine sitemap. The documentation's own guidance on renaming or moving a document is that the URL will break and 'you may want to configure Content SaaS to forward requests' — no redirect UI is offered. What SEO capability Bloomreach has lives in Search (formerly Discovery) and is a managed service, not a self-serve toolkit: Thematic pages are auto-generated long-tail landing pages, the thematic XML sitemap is prepared by a Bloomreach TPM and files are handed to the customer to deploy themselves, SEO widgets are Related Categories/Items/Products modules a developer embeds, and 'keyword redirects' redirect search queries to a page rather than managing HTTP redirects. Per the rubric this is manual SEO field creation with no built-in validation — the 35–55 band. Being headless, meta tags are the frontend's responsibility.

Strong conversion tracking and attribution, weaker on native form building. Marketing provides Weblayers with a visual designer (the vehicle for on-site CTAs, banners and capture forms), Surveys including NPS, SMS sign-up units, and native Lead Ads connectors for Facebook/Instagram and TikTok that pipe leads straight into the CDP. Conversion measurement is a genuine strength: performance dashboards by project, channel and campaign, email revenue and engagement dashboards, Google Ads offline conversions, and the Facebook Conversions API. What is absent is a dedicated form builder as a first-class object — the Content marketplace carries Jotform, Typeform, form.io, forms.app and Google Forms embeds precisely because neither module ships one, and those marketplace integrations are explicitly unsupported by Bloomreach. Lowered from 70 to reflect that gap.

Personalization remains Bloomreach's strongest marketing capability. In Content, every component on a page can carry variants per segment or per campaign, with a documented three-step resolution order (campaign variant, then segmentation variant, then default) and an 'alter ego' preview that renders the page as a chosen segment. The segment supply is deep: Marketing provides segmentations, event segmentations, RFM, purchase-frequency, time-zone and Autosegments (AI-generated), exposed to the web, iOS and Android SDKs in real time. Search adds Personalization studio for 1:1 product ranking and Segmented merchandising rules. Slightly below the prior score because Content personalization is not self-contained: the Content audiences app only appears once a Site Admin installs either the Marketing integration or an external CDP integration, so the CMS on its own has no targeting at all.

Native experimentation with a visual editor is documented as a first-class Marketing feature: Experiments ('make any changes to your website using a simple visual editor') with a dedicated editor and developer integration path, A/B testing with documented evaluation methodology, and the Weblayer variant generator, which is now shipped documentation rather than a roadmap line. Experiments and A/B tests run across the same channel set as campaigns — email, SMS, push, in-app, weblayers — and Search's Personalization studio lets ranking rules be tested. Held at the prior score: the capability is real and mature, but experimentation lives in Marketing rather than in the CMS, so testing a CMS-authored page requires the Marketing module.

Lowering this materially after reading the end-user manual end to end. Content SaaS is missing several of the specific accelerators this item asks about. There is no scheduled publishing — the documented publication states are only Offline, Live and Changed, with publication requested by an author and executed by an editor, so a timed launch needs someone present. There is no version history or revision restore; 'Changed' simply diffs against the live version. A document must be taken offline before it can be moved, renamed or deleted. Project review requires two separate webmaster acceptances before a merge, and content-type changes serialize through development projects one at a time. Real accelerators do exist: inline authoring in the channel preview, reusable Content Blocks, component variants, and bulk workflow operations from the document search app. Net: adequate speed for edits within an established template, with structural manual steps — the 40–60 band.

Raising slightly — the documented channel set is broader than previously credited. Marketing delivers to email, SMS, WhatsApp, mobile push, browser push, in-app messages, in-app content blocks, Facebook Messenger, and paid channels via Google Ads, Facebook/Instagram, TikTok and Criteo audience sync; weblayers cover on-site. Content SaaS supplies structured content over the Delivery API and GraphQL to any frontend, with channels as the per-destination unit. That is well beyond the 4+ channels the rubric requires for 70+. The reason it is not higher is that the two halves are separate systems: Marketing composes its own message content rather than consuming CMS-authored structured content, so 'author once, deliver everywhere' holds within Marketing and within Content, but not across the pair.

Analytics is a genuine strength of the Marketing module and is broader than previously documented: Analyses, Reports, shareable Dashboards, performance dashboards sliced by project, channel and campaign with currency and filter controls, a deep email dashboard family (revenue, engagement, deliverability, domain, click heatmap), and Loomi Analytics for natural-language querying. Warehouse egress is first-party with Databricks, Snowflake and Loomi BigQuery. Search contributes Insights and Analytics with a metrics glossary. The deduction is the same as before and confirmed by the docs sweep: none of this surfaces in the CMS. Content SaaS has no analytics pages at all, so an editor cannot see how a page performed without leaving for another product. Google's integrations here are ad-audience and offline-conversion sync rather than GA4 reporting import.

Lowering within the same band. Consistency comes from structure — a per-channel component catalog, channel layouts, and channel parameters that developers can constrain to a dropdown or content picker — but there is no enforcement layer: no design tokens, no locked style palette, no approved-component governance, no restricted-override model. The documentation also records an explicit guardrail weakness: the rich text editor exposes an HTML source view and accepts raw HTML tags, with only an HTML cleaner as a backstop, and the manual itself warns that 'what looks nice in the editor may not fit well with the overall design'. That is component-based consistency without enforcement, which the rubric places at 35–55, and the source-view escape hatch argues against the top of the band.

Lowering — the previous score rested on an inferred claim of OG meta management that the documentation does not support. Content SaaS documents no Open Graph, Twitter card, meta tag or social preview capability anywhere in its 339 pages; as a headless CMS it leaves head tags to the frontend, which a developer implements. Marketing's social surface is advertising and social proof rather than publishing: social media ad audience sync to Facebook/Instagram and TikTok, Facebook Messenger as a messaging channel, and social proof banners including a location-based variant. There is no scheduling to social networks, no push-to-social workflow and no UGC embed tooling. Social proof widgets are the one item in the rubric's list that is genuinely present, which keeps this above the floor band.

Correcting a significantly over-scored item against published hard limits. Content SaaS images are capped at 4 MB and 1920x1280 pixels, assets at 10 MB — below what marketing teams routinely handle. Delivery exposes exactly seven fixed named variants (thumbnail, small, large, smallsquare, mediumsquare, largesquare, banner) with no transform query parameters, so there is no arbitrary resize, crop, quality or format at request time, and the CDN is bring-your-own per channel. Images and assets have no publication state and are public by default: anyone with the URL can fetch them. There is no tagging, no rights management, no usage tracking and no version history. Marketing keeps a separate Asset manager with tags, descriptions, folders and bulk actions, but caps images at 2 MB and video at 20 MB with no transcoding — and it is a different product from the CMS. The presence of Bynder, Cloudinary, Brandfolder, Canto and Frontify in the marketplace is the tell, and those are explicitly unsupported by Bloomreach. This is file storage with fixed renditions, not a marketing asset layer.

Structural localization is solid and genuinely first-class: translation groups linking localized channels, folder-level translation linking, a localize-content workflow, resource bundles for locale-specific UI messages in one place, page synchronization between translated channels, and a translations API for linking and unlinking. Marketing adds time-zone segmentation and locale-targeted campaigns; Search adds multi-language relevance. What pulls it below the 65+ band is that none of it is marketing-specific: there is no transcreation workflow, no locale-variant campaign approval chain, and — notably — no TMS or translation-vendor integration anywhere in the ecosystem. The Content marketplace carries no Smartling, Phrase, GlobalLink, Lokalise or Crowdin connector, so translation vendor round-tripping is custom work. This is generic localization applied to marketing content, the 35–55 band, placed above it for the depth of the channel-translation model.

Broad connector coverage across more than three MarTech categories with real event plumbing, but two corrections pull it off the prior score. Categories covered: ad platforms (Google Ads audiences and offline conversions, Facebook/Instagram ads and Conversions API, TikTok, Criteo, DV360, Adform), CDP/pipeline (Twilio Segment), data warehouses (Snowflake, Databricks, Loomi BigQuery, PostgreSQL), commerce, support desks (Zendesk, Freshdesk, Gorgias), loyalty/vouchering (Voucherify, Yotpo, Trifft) and Zapier, with documented webhooks including authentication and presets. The corrections: there is no CRM or MAP connector — no Salesforce Sales/Service Cloud, HubSpot, Marketo or Pardot, since Bloomreach positions itself as the MAP; and the commercetools and Salesforce Commerce Cloud connectors are closed to new implementations as of 1 January 2026, so new customers wire commerce data through the generic Tracking API and Data hub imports instead of a turnkey connector.

Raising slightly. The Search catalog model is more structured than generic content types repurposed for product data: catalogs hold product and item feed records with first-class variants and views (a view being a market or site-specific rendition of a record), a reserved-attributes registry, configurable custom attributes, and a versioned catalog configuration you can diff against the index that generated it. Editorial enrichment happens in Content SaaS alongside that, with Commerce Pickers letting an author browse and select categories, products and product variants from the connected platform into a document field. The ceiling is that Bloomreach is not a PIM — attribute matrices, inheritance and product data authoring live upstream in the commerce platform; Bloomreach indexes and enriches.

Best-in-class and unchanged. The documented merchandising surface is deeper than any other platform in this dataset: boost, bury and position lock; slot-based and conditional slot merchandising; group merchandising; attribute-based ranking rules; dynamic categories; segmented (behavioural) merchandising rules bound to audiences; Ranking studio with API controls and ABR-based search and category ranking; assets and media rules for injecting media into the grid; bulk operations across rules; scheduling of multiple ranking rules for the same query or category with documented conflict-resolution semantics; pre-merchandised product launches and launch windows; and variant slicing. Unlike Content, Search ships continuously — thirteen-plus documented releases across 2026.

Still strong but lowered, because the turnkey-connector story has narrowed. On the Content side the integration is genuinely deep and is the best evidence for this item: a GraphQL Commerce API federating product data from the commerce platform, with its own schema, access management and release notes, and out-of-the-box Commerce Pickers that put a product/category/variant browser directly in the document editor for BigCommerce, commercetools, SAP and Bloomreach Search. Channel property placeholders inject the GraphQL base URL and Search account into the frontend app, and SAP Spartacus and Vue Storefront ship as channel templates. The deduction: on the Marketing side, commercetools and Salesforce Commerce Cloud are now explicitly legacy connectors closed to new implementations since 1 January 2026 with no further feature development — new customers integrate through the Tracking API and Data hub imports. BigCommerce, Adobe Commerce (Magento), the SFCC cartridge and Loomi AI for Shopify remain live.

Raising slightly. Shoppable editorial is a first-class pattern on both sides. In Content, Commerce Pickers make inline product references an authoring action rather than a developer integration, and the shipped component set (banner galleries and carousels, category and product highlights, product grids) is built for shop-the-look and buying-guide layouts, with per-segment variants on each. In Search, Assets and media rules plus the Media in grid inspiration library let merchandisers place editorial media, buying guides and promotional tiles directly between products in the results grid, with a library of documented patterns. Pathways and Recommendations are documented in Content as a conversion-optimisation pattern for pages.

Unchanged. Content can be injected into transactional flows without touching commerce templates, but the vehicle is Marketing rather than the CMS: Weblayers render targeted banners and overlays on any page including cart, in-app content blocks do the same in native apps, web recommendation blocks place upsell rails, and abandoned-cart scenarios are a documented use case. Social proof banners are a documented conversion pattern. What is missing is a CMS-side authoring surface for checkout: no checkout content model, no trust-badge or shipping-callout management, and Content SaaS has no awareness of cart state. This is targeted overlay management rather than CMS-governed transactional content.

Raising — what was cited as roadmap is now shipped. Catalog triggers are fully documented with a configuration guide and a trigger-type reference, so content delivery fires on real-time product and catalog events. Around that sit documented post-purchase patterns: post-purchase email with recommendations, purchase anniversary recommendations, post-purchase NPS survey as both an email and an omnichannel journey, bi-weekly recommendation newsletters, and vouchering through Voucherify and Trifft for loyalty. Scenario orchestration carries these across email, SMS, WhatsApp and push. The limit is that all of it is CDP-driven messaging — order confirmation and delivery-tracking pages remain the commerce platform's, and Content SaaS plays no part.

Lowering — the prior score leaned on marketing-site B2B positioning rather than product documentation. A sweep of the Search and Content indexes returns no B2B-specific tooling: no contract or customer-specific pricing display, no quote-request flow, no gated catalog or account-based catalog entitlement, no spec-sheet or gated-documentation model. What genuinely applies is generic and adapted: catalogs with views can carve a catalog per market or account context, segmented merchandising can target rules at an audience, and Marketing's segmentation can drive account-persona content. Per the rubric this is basic access control applicable to B2B — the 30–50 band — placed just above it because the catalog/view/variant model does real work for large technical assortments.

Unchanged and among the strongest scores in the dataset. Faceted search with facet ranking and category facet inheritance across multi-sites, synonym management with a dashboard, bulk operations and a best-practices guide, thematic pages as auto-generated long-tail search landing pages with their own XML sitemap, Visual Search with an implementation guide, and assets and media rules that blend editorial content into product results. Ranking is AI-driven through ABR and Ranking studio, with 1:1 personalization applied to search and category results. Insights and Analytics close the loop with a metrics glossary. Search ships continuously through 2026 while Content is static.

Time-activated promotional content with channel targeting is well covered, just not from the CMS. Search provides scheduling of multiple ranking rules against the same query or category with documented conflict resolution, product launch windows, pre-merchandised product launches, and assets and media rules for promotional tiles and banners across slots in the grid. Marketing adds scheduled campaigns and weblayers with their own settings and targeting, plus vouchering. The counterweight, confirmed by the docs, is that Content SaaS has no scheduled publish or unpublish at all, so a CMS-authored promo page cannot be time-activated without someone publishing it manually.

Raising — the multi-site model is stronger than previously credited and is documented with real semantics rather than marketing language. Search organises storefronts as Account, then Site group, then Site, so a merchandiser works in the same way as on a single site but can propagate a merchandising change across all site versions or a chosen subset while retaining the ability to override at the individual site level. Supporting features are multi-site aware: add-to-recall for multisite, sequential lock for multi-site, and category facet inheritance across multi-sites. On the Content side, channels are the per-storefront unit, translated channels are grouped and can synchronise pages between them, and documents can be shared across channels. Shared product content with storefront-specific editorial is exactly the documented pattern.

Lowering against the published media limits. The discovery-side story is good — Visual Search lets a shopper photograph or upload an image to find similar products, and media rules place video and rich media into the product grid. But the media layer behind it is constrained: Content SaaS images are capped at 4 MB and 1920x1280 pixels with exactly seven fixed delivery variants and no transform parameters, which rules out the high-resolution zoom this item asks about; Marketing's asset manager caps video at 20 MB with no transcoding. There is no 360-degree viewer, no AR or 3D model support, no image hotspots and no zoom component documented anywhere. Per the rubric this is basic image galleries and video embeds, lifted above that band by Visual Search and in-grid media.

Unchanged. Nothing in the documentation addresses multi-vendor commerce: no seller profiles, no seller-contributed product content, no review aggregation and no content moderation queue. Bloomreach's 'marketplace' is an integration repository for the CMS, not a seller platform. Multi-author content is possible in Content SaaS through roles and folders, and catalog views could in principle segment a mixed assortment, but neither is marketplace tooling. This sits in the rubric's 25–45 band for basic multi-author content that is not marketplace-specific.

Lowering in line with 8.1.13, for the same underlying reason. The structural pieces are real: translated channel groups with page synchronisation and resource bundles in Content, per-site and per-site-group locale isolation with multi-language relevance in Search, catalog views as market-specific record renditions, and currency handling in Marketing's performance dashboards. What is absent is anything commerce-regulatory or vendor-assisted: no EU label or Prop 65 style regulatory content model, no currency-aware content block as a platform primitive, and no TMS integration at all, so localising a large product assortment means custom pipeline work. Generic localization applied to product content is the 35–55 band; the depth of the channel and view model places it just above.

Unchanged. Connecting engagement to commerce outcomes is the core of the product: Search Insights and Analytics tie search and category interactions to downstream purchase with a documented metrics glossary and an explore bar; Marketing supplies email revenue dashboards, campaign and channel performance with currency controls, recommendations evaluation dashboards, and Loomi Analytics for ad-hoc natural-language questions, with raw event egress to BigQuery, Snowflake and Databricks for custom attribution. The deduction is unchanged and confirmed: Content SaaS contributes no analytics of its own, so attribution to a specific CMS-authored page depends on frontend event instrumentation rather than anything the CMS reports.

Lowering. Content SaaS has a real role model — Content Author, Site Editor, Users admin, assigned in a Setup > Users app and settable as SSO first-login defaults — and channels scope what a Site Editor can touch. But the role is the unit of control: there is no audience-based content visibility, no per-content-instance permission and no field-level sensitivity, and folder-level authorization remains a Beta capability. SSO is SAML only, brokered through Auth0, with no OIDC and no SCIM provisioning, so group membership cannot drive access automatically. This is RBAC on content types and channels, the rubric's 40–60 band, not the audience-based visibility an intranet needs.

Lowering after confirming the absences directly. Knowledge lifecycle management needs review cycles, archival, expiry and version history, and Content SaaS documents none of them: no version history or revision restore, no scheduled publish or unpublish, no tagging or taxonomy model, and no archive state — a document is Offline, Live or Changed. Search is a commerce catalog engine indexing product feed records, not an internal knowledge index. What exists is folder-organised documents, a document search app with bulk workflow operations, and a fixed two-step publication approval. That is adequate content modelling with no lifecycle tooling, at the lower end because even the modelling lacks taxonomy.

Unchanged. A full sweep of all three product documentation indexes returns no portal tooling: no news feed component, no employee notification system, no personalised employee dashboard, no directory integration and no social features. Every personalisation, segmentation, notification and journey capability in the platform is built around a customer profile assembled from commerce and browsing behaviour — the segmentation primitives are RFM, purchase frequency and catalog affinity. Building an employee portal on Bloomreach means building the entire experience layer yourself on top of a headless content API, and doing so against a CMS with no scheduled publishing or version history.

Unchanged. No internal communications features exist in any module: no company news feed, no department announcement targeting, no read receipts, no acknowledgment tracking and no mandatory-read workflow. The messaging channels are numerous and mature — email, SMS, WhatsApp, mobile and browser push, in-app — but every one of them is documented against customer journeys, consent categories and marketing opt-in law, which is the wrong governance model for employee communications. Delivery and open tracking exists but is campaign analytics, not compliance acknowledgment.

Unchanged. There is no employee directory, org chart, team page or manager hierarchy capability anywhere in the product suite, and no HR system integration — Workday, BambooHR and equivalents appear in none of the integration catalogs. The ~40 Content marketplace integrations are SDKs, DAM connectors, commerce connectors, form embeds and developer tools; Marketing's ~24 first-party integrations are commerce, ads, messaging, support desks and data warehouses. A directory would be a custom content type rendered by a custom frontend, with nothing in the platform to source or sync employee records.

Lowering from an inferred estimate now that the underlying capabilities are confirmed absent. Policy management needs versioned documents, an audit trail, acknowledgment tracking and expiry reminders; Content SaaS has none of the four. There is no version history, no scheduled unpublish or expiry, and no acknowledgment concept. Worse for this specific use case, the documentation states that assets have no publication state and are public by default — anyone who knows the URL can retrieve a PDF — which makes the natural home for policy documents unsuitable for anything confidential. A document must also be taken offline before it can be moved or renamed. This is the rubric's floor band.

Unchanged. No structured onboarding capability exists: no role-specific content path, no progressive disclosure over a 30/60/90 day arc, no task checklist and no HR-triggered new-hire portal. Marketing's scenario engine could in principle sequence timed content to a person, but it is documented exclusively against customer lifecycle journeys — welcome series, reactivation, post-purchase — is triggered by commerce and browsing events rather than HR events, and is governed by marketing consent. Delivering employee onboarding on it would mean modelling employees as customers and building the portal from scratch.

Lowering. Bloomreach Search is excellent at what it does, but the docs make clear how narrowly it is bound to commerce: its unit of indexing is a catalog of product and item feed records with variants and views, uploaded as a feed and indexed by a job, with a reserved-attributes registry built around commerce fields. There is no federation to SharePoint, Confluence, Google Drive or any document repository, no connector framework for non-catalog sources, and the relevance models (ABR, visual search, category ranking) are trained on shopping behaviour. Content SaaS has its own document search app, which is folder and workflow oriented with no faceting or relevance tuning. Pointing Search at an intranet corpus would mean shaping internal documents into product feed records.

Unchanged. The mobile capability is real but customer-facing: iOS and Android SDKs with real-time segmentation, mobile push notifications, in-app messages and in-app content blocks, plus device preview in the Experience manager and responsive delivery from a headless API. None of it addresses the frontline scenarios this item asks about — there is no offline content cache, no kiosk or shared-device mode, no low-bandwidth profile and no deskless-worker app. A frontline app would be a custom build consuming the Delivery API, with push available as a genuine reusable piece.

Unchanged. No LMS integration, no native micro-learning, no course assignment, no completion tracking and no certification capability exists in any module. Cornerstone, Workday Learning, Docebo and equivalents appear in neither the Content marketplace nor Marketing's first-party integration set. Bloomreach Academy is customer education about Bloomreach itself, delivered as a separate property — it is not a product capability a customer can use to train their own people.

Unchanged. There are no employee social or collaboration features: no comments, reactions, discussion forums, peer recognition, polls, idea submission or community spaces. Surveys and NPS exist in Marketing but are customer feedback instruments delivered over marketing channels. Even editorial collaboration inside the CMS is thin — the project model provides a two-webmaster review gate and container-level locking, but there is no commenting or annotation on content, so the platform lacks a collaboration layer for its own users, let alone for a workforce.

Unchanged. There is no Microsoft 365, Teams, Google Workspace or Slack integration in any module — no embedded content cards, no bot-driven notifications, no single-pane experience. Microsoft appears only as an identity provider, through Unified SSO for Microsoft Entra ID, which is authentication rather than workplace content delivery. The integrations that look adjacent are customer-facing service desks: Zendesk, Freshdesk and Gorgias. Zapier and documented webhooks with authentication and presets make a custom Slack or Teams notification achievable, which is the rubric's basic-webhook floor rather than integration.

Correcting a materially over-scored item. The previous reasoning credited publish/archive scheduling and version history; the end-user manual documents neither. Publication states are Offline, Live and Changed only, with publication requested by an author and performed by an editor — there is no scheduled publish, no scheduled unpublish and no expiry date. There is no version history or revision restore; 'Changed' only diffs the working copy against the live one. There are no review dates, no stale-content flagging, no ownership assignment and no archive state. Archival in practice means taking a document offline manually, and the manual notes that the folder-level bulk 'Take offline all in folder' does not even verify incoming references, so it can silently create dead links. The genuine positives are reference-integrity warnings on individual take-offline and delete, and bulk workflow operations from the document search app.

Unchanged. Bloomreach has a great deal of analytics, all of it pointed outward: Marketing's performance dashboards slice by project, channel and campaign with revenue metrics; Search's Insights and Analytics report on shopper search behaviour and its conversion impact. None of it can express an internal audience. There is no views-by-department breakdown, no failed-internal-search report tied to knowledge gaps, no engagement heatmap for internal content and no adoption dashboard. Content SaaS emits no analytics of its own. Raw event egress to BigQuery, Snowflake or Databricks would let a team build internal reporting themselves, which is the only path available.

Silo-based isolation, which the rubric places at 55–70. Marketing offers three instance types — multi-tenant, single-tenant and exclusive — and projects are the isolation unit for data, users and analytics within an instance. Search separates brands as an Account, Site group and Site hierarchy, with per-site catalogs and configurations. Content SaaS is the weakest link: brands are channels inside a single instance sharing one content repository, one content-type registry and one image and asset store, so isolation is by folder convention and channel content root rather than by architecture, and there is no independent API credential or environment per brand. Lowered slightly to reflect that the Content-side isolation is organisational rather than architectural.

Lowering. Sharing works but is developer-mediated rather than a native cross-tenant feature. Components live in per-channel component groups managed through the Site Management API, so a shared library means provisioning the same catalog into each channel rather than referencing one central library. Sharing documents across channels is possible, but the documentation presents it as a developer tutorial: you configure a content-driven component's content selector to look outside the current channel's content root. Channel templates (Reference SPA, SAP Spartacus, Vue Storefront) give new brands a common starting point. This is federation and workarounds rather than native cross-tenant sharing — the rubric's 40–60 band, at the top of it because the mechanics genuinely work.

Broadly unchanged. Unified user management and Unified SSO, introduced with Data hub, consolidate roles across Search, Marketing and Clarity into one administration surface with global RBAC enforcement, which is a real centralisation win for a multi-brand account. Content SaaS governance is separate: its own Setup > Users app, its own SAML connection through Auth0, and a fixed publication approval. Cross-brand enforcement of content standards is not a platform feature — there is no global policy configuration, no mandated content model and no cross-brand approval routing. This is organisation-level management with limited cross-brand enforcement, the rubric's 40–60 band, at the top.

Unchanged, and still inferred because Bloomreach publishes no pricing. The architecture offers some economy of scale: Content channels share one instance and one repository, so an additional brand does not mean an additional CMS; Search site groups share an account and let merchandising propagate across site versions. Working against that, licensing is per module (Content, Search, Marketing) and Marketing meters by customer profiles and message volume, both of which scale with the portfolio rather than being amortised across it. Marketing projects are the brand boundary and are provisioned per brand. Net expectation is roughly linear cost scaling with modest infrastructure sharing.

Lowering slightly. Per-brand visual identity is achievable and there is a documented mechanism for it — channel parameters, exposed in a Channel properties dialog, whose editing experience can be customised through metadata so a brand manager gets a dropdown or content picker, and platform property placeholders that pass values into the frontend app. But the theming itself lives in the frontend application, not the platform: there are no design tokens, no typography or palette management and no theme propagation. Per the rubric this is basic config-driven theming per brand, the 35–55 band, at the top because channel parameters are a genuine first-class configuration surface.

Lowering. The brand-by-locale intersection is well modelled structurally: translation channel groups, folder-level translation links, page synchronisation between translated channels, resource bundles, and a translations API for linking and unlinking, with Search mirroring this as language-based site groups. Governance over that intersection is where it falls short — the approval process is identical everywhere (two webmaster acceptances on a project), so there is no per-brand or per-locale translation approval chain, no distinction between shared and isolated translation workflows, and no regional legal content governance model. With no TMS integration either, translation vendor management sits entirely outside the platform.

Unchanged. Search genuinely delivers the aggregate view this item asks about: the multi-site dashboard carries an Account, Site group and Site context selector, so a merchandiser can look at one site or roll up across all of them, and Insights works at either level. Marketing is the opposite — analytics are scoped to a project, projects are the brand boundary, and no cross-project rollup is documented, so portfolio comparison means exporting to BigQuery, Snowflake or Databricks and joining there. Content contributes nothing, so content velocity and publishing cadence benchmarking across brands is unavailable. Per-brand analytics with manual aggregation, lifted above that band by Search's genuine rollup.

Correcting downward after reading the workflow documentation directly. The previous score assumed project isolation allowed independently configured approval chains per brand; it does not. The publication workflow is fixed platform-wide: an author requests publication and a user with editor privileges publishes, with states limited to Offline, Live and Changed. Project review is equally fixed — 'at least two webmasters must review and accept the changes' before a project can be merged or run as a campaign — with no configurable number of stages, no per-channel routing and no conditional approval. There is no workflow designer. What does vary per brand is who holds the roles and which channels they can reach, and Marketing has its own separate approval model. Per the rubric, the same workflow forced across all brands with per-brand user assignment sits between the bottom two bands.

Unchanged, though the balance behind it has shifted. Search does implement real syndication semantics for merchandising: a change can be propagated across all site versions or a chosen subset while each site retains the ability to override locally — corporate push with local adaptation, exactly as this item describes, but for ranking rules rather than editorial content. Content SaaS is weaker: documents can be referenced across channels only after a developer configures a content-driven component's selector to look outside the channel root, and there is no push-update mechanism, no override-point control and no notion of a corporate master version that child brands inherit. Page synchronisation between translated channels is the closest editorial equivalent.

Unchanged. Marketing has a real consent subsystem: consent management with named consent categories, tracking consent configuration and a consent page, which can be configured differently per project and therefore per brand and region, alongside data residency at the instance level. What is missing is the guardrail half of the rubric — nothing prevents non-compliant content from being published. Content SaaS has no compliance validation, no accessibility gate, no per-region publishing rule and no policy enforcement in its workflow; its review is a human accept/reject with no automated check. Basic compliance settings available per brand, above that band for the depth of the consent model.

Lowering. A federated design system needs central maintenance, versioning and update propagation across tenants; Bloomreach has none of the three. Components are defined per channel in channel component groups provisioned through the Site Management API, so the 'central library' is whatever a team keeps in its own frontend repository and deploys — the platform has no concept of a component version, no propagation mechanism and no brand-level extension model. Channel templates seed a new brand from a common starting point but do not stay linked afterwards. The marketplace supplies third-party UI extensions but Bloomreach explicitly does not support or maintain them. This is shared components with brand override, the 30–50 band.

Lowering. Unified user management with Unified SSO is a genuine improvement — a central administration surface with global RBAC across Search, Marketing and Clarity, and Microsoft Entra ID supported for both authentication and authorization, so a central admin can manage all brands while brand teams work autonomously in their own projects and sites. The deduction is that Content SaaS stands outside it: Content has a separate Auth0-brokered SAML connection, its own Setup > Users app and its own role set, so the CMS half of a multi-brand deployment is administered separately. Neither side offers SCIM provisioning, so joiner-mover-leaver handling across brands is manual.

Lowering after examining how content types actually behave. Content types are instance-global, not per channel: they are created, renamed and deleted only inside a development project, and merging that project pushes the change into the core for every channel at once. There is no inheritance mechanism — no way for one brand to extend a global page model with extra fields without changing the shared type, and the documented pattern for brand variation is component configuration and channel parameters rather than model extension. The change process is also constrained: development projects serialise, and a content type deleted after merge cannot simply be removed. Per-brand variation therefore comes from which components a channel exposes rather than from the model, which is the rubric's basic-shared-types-with-limited-customisation band.

Unchanged. Search's multi-site context selector provides a global view across all sites for search and merchandising metrics, which is the strongest portfolio signal available, and Marketing reports per project. Nothing addresses the executive reporting this item describes: there is no content-freshness-by-brand report (Content has no freshness concept at all, lacking review dates and version history), no publishing SLA tracking, no per-tenant cost allocation and no capacity planning view. Assembling a portfolio dashboard means exporting events to BigQuery, Snowflake or Databricks and building it there. Basic per-brand reporting with manual aggregation.

A single Bloomreach DPA covers all product pillars (Content, Discovery, Engagement) and applies to all new customers with no tier gate; it incorporates the 2021/914 SCCs, defines the UK IDTA Addendum, and section 1.7 commits to delete-or-return of Personal Data on termination with the SCC Clause 8.5/16(d) deletion certification. The public sub-processor list is itemized per pillar with country and service and was refreshed 24 April 2026, Bloomreach is certified under the EU-U.S. DPF, the UK Extension and the Swiss-U.S. DPF with JAMS dispute resolution and FTC enforcement, a DPO is appointed, and EU residency is available in both Content SaaS and Engagement. Not higher because the DPA text has been unrevised since 28 December 2022, right-to-erasure tooling is a Marketing-pillar feature that the CMS does not have, and the docs warn that Asset manager file location is not guaranteed.

No BAA exists and no HIPAA content appears anywhere in Bloomreach's public material: zero matches for HIPAA across the Content (339 pages), Engagement, Discovery and brXM library documentation indexes, the 119-page marketing sitemap, and the legal sitemap, and healthcare is absent from the ten industry verticals Bloomreach sells to. The DPA goes further than silence and affirmatively disclaims the data class, stating Bloomreach 'does not require any special categories of data in order to provide the Services and does not intentionally collect or process any special categories of such data' — GDPR special categories include health data. Scored just above the no-coverage floor only because the Content CMS could host non-PHI healthcare marketing content, but nothing about this platform is configured or contracted for regulated health data.

CCPA/CPRA is handled in the DPA body plus a California privacy notice and a self-service do-not-share/opt-out portal, UK GDPR via the IDTA Addendum and a London data center, PIPEDA via Montréal, APAC via Sydney, US transfers via DPF, and the MSA and Content Appendix now implement EU Data Act switching rights with a two-month notice and 30-day transitional export — an unusually current regional addition. Bloomreach also holds an ISO Certification of Conformity for GDPR. Not higher because there is no FedRAMP or StateRAMP despite the hosting page citing government customers, no PCI DSS for a platform positioned on commerce, no IRAP despite the Sydney region, and no C5, HITRUST or named LGPD coverage.

Bloomreach maintains an annual SOC 2 Type II attestation covering the Security, Availability and Confidentiality trust service criteria, confirmed in the March 2024 renewal announcement and restated in the present tense on the current security page, with the report released to customers under NDA via the Trust Portal. Supporting evidence is a third-party pentest performed annually for each product pillar. Held below 85 because the most recent public attestation artifact is the March 2024 press release — no 2025 or 2026 announcement exists in the news archive — and the Trust Portal is access-gated behind a request form sitting on a Cloudflare challenge, so a prospective buyer cannot independently verify the current report period or scope.

Bloomreach completed the transition to ISO 27001:2022 in December 2024 and holds ISO 27018:2015 for PII processing in public clouds and ISO 27017:2015 for cloud security controls, all restated on the current security page. The certification is platform- and company-scoped rather than inherited from GCP: the surveillance audit is described as covering Bloomreach's own ISMS, quality management systems, cloud technologies, IT controls, global operations and GRC activities. Not higher because the certificates themselves are not published — no certificate number, registrar or expiry is public, and the artifacts sit behind the gated Trust Portal.

Beyond SOC 2 Type II and ISO 27001/27018 Bloomreach holds four further meaningful attestations — ISO 27017:2015 cloud controls, ISO 9001:2015 quality management, ISO 22301:2019 business continuity, and an ISO Certification of Conformity for GDPR — backed by an annual third-party penetration test for each product pillar. A prior claim of CSA STAR Level 1 does not hold up: Bloomreach does not appear in the CSA STAR registry and STAR is named nowhere on bloomreach.com. Capped in the middle of the strong-portfolio band by the absence of PCI DSS (a conspicuous gap for a commerce-focused DXP), FedRAMP, IRAP, Cyber Essentials Plus, C5 and TISAX.

Residency is strong on the Marketing side — five Google data centers across three regions (St. Ghislain, London, Montréal, Council Bluffs, Sydney) with workspaces tied to a single regulatory region and audit logs stored in the region where activity occurred — but the CMS being scored is materially narrower: the Content SaaS hosting page (updated 2026-08-06) still offers only 'the customer's choice of a single public cloud region (initially EU or US-East)', with no UK, Canadian or APAC option. Two documented carve-outs cut further: Bloomreach explicitly does not guarantee the location of files in the Asset manager and advises against storing anything sensitive there, and Cloudflare is a CDN sub-processor for select Content customers, so cached delivery leaves the chosen region. Scored as the EU/US binary the CMS actually offers, lifted slightly by the three-region footprint available elsewhere in the platform.

The Content Batch Export API gives real API-based extraction — an async job over documents, pages, resource bundles and folders returning a zip of NDJSON in the same format the Import API consumes, with an OpenAPI spec and Postman collection — and the DPA commits to delete-or-return of all Personal Data at the customer's election on termination with SCC-certified deletion and isolation of backup copies. The Content Appendix adds an EU Data Act switching right with a two-month notice and a 30-day transitional export window. Held out of the 75+ band because export is API-only rather than self-service, the export API explicitly does not cover images and assets ('you will need to export these manually ... contact Bloomreach support'), self-service erasure tooling exists only in the Marketing pillar, and no numeric post-termination retention period is stated anywhere outside the EU Data Act clause.

The audit log documentation states plainly that 'Bloomreach currently offers audit logs for Marketing and Data hub' — Content SaaS, the CMS being scored, has none, and the 339-page Content documentation index contains zero pages matching audit, security, compliance or privacy; CMS-side auditing exists only as a separately licensed brXM Audit Addon for the self-hosted PaaS product that ships sample ActiveMQ and Elasticsearch connectors and requires the customer to build their own persistence layer and UI. Where logs do exist they are well built — append-only gzipped JSON Lines, a fixed SIEM-friendly schema with identity, authorization outcome, policy-change and anonymization records, stored in the region where the activity occurred. Held to the middle of the API-polling band because access 'requires contacting your Bloomreach account representative to enable', delivery is a GCS bucket pulled with gsutil or a service account rather than a native SIEM push, and retention is a fixed 'at least 60 days' before files move to archive storage 'where they are no longer accessible for download'.

Bloomreach publishes no accessibility commitment of any kind for its authoring interfaces: there is not a single WCAG, ATAG, Section 508 or accessibility mention across the Content, Engagement and Discovery documentation indexes, the brXM library navigation, or the 119-page marketing sitemap, and a prior claim of a stated WCAG 2.1 AA target for the authoring UI has no traceable source. The only accessibility-adjacent artifact in the entire corpus is a CKEditor keyboard-shortcuts page, and that conformance belongs to upstream CKEditor rather than to anything Bloomreach built or tested. Scored in the upper part of the no-commitment band to credit that inherited editor behaviour, but there is no evidence Bloomreach has assessed keyboard navigation, focus management or screen reader support in the Experience manager or visual composer.

No VPAT or ACR is published, and no accessibility statement exists at all — bloomreach.com's page sitemap (119 URLs) and legal sitemap (95 URLs) contain no accessibility, VPAT or Section 508 entry, and direct probes of the conventional paths all return 404. There is likewise no ATAG 2.0 assessment and no European Accessibility Act statement, despite the EAA having applied since June 2025 and Bloomreach operating EU entities and EU data centers. For a tier 1 enterprise DXP whose own hosting page cites government customers, the complete absence of a procurement-ready conformance artifact is a hard blocker in public-sector and regulated buying, and leaves nothing above the no-documentation floor.

The Loomi AI Content Assistant is a documented chat panel in the CMS doing summarization, expansion, rewriting, readability, grammar and sentiment analysis, with multi-document reference context and persistent conversation threads (v16.6.0) and role-based access (v16.7.0) — but it ships only in brXM (PaaS/self-hosted) 16.4.0+ under a standard/premium license and is designated an Incubating feature; the Content SaaS documentation set contains no AI assistant page at all, and the Content SaaS changelog for all of 2026 is bug fixes and 'continuous improvements'. On the marketing side, Loomi Content copy generator (Premium tier) writes email/SMS/MMS/push copy against a project-level tone-of-voice profile. Not higher because bulk generation across many entries is still undocumented and the flagship SaaS CMS has no native generation; not lower because the brXM assistant plus tone-of-voice governance is real, shipped, multi-operation generation.

brXM's AI Content Assistant gained image support in v16.4.1 — you can ask it to analyze an image and suggest alt text in the editor — and Bloomreach Search ships Visual Search, Visual Recommendations and color-based image SKU selection, all of which are retrieval/selection rather than generation. No native AI image or video generation (Firefly, DALL-E, Stable Diffusion) appears anywhere in Content, brXM or Marketing docs as of September 2026, and the Marketing agent assembles product imagery from the catalog rather than generating it. Not higher because alt text is conversational and per-image rather than an automated asset-workflow step and there is no generative media at all; not lower because documented AI alt-text suggestion and image analysis do ship.

Text translation is a listed operation of the brXM Loomi AI Content Assistant — translate a document's content into other languages without leaving the CMS — and Multi-language Loomi Search+ extends semantic matching across languages on the Search side. Content SaaS's own localization tooling (translation groups, linked folders, resource bundles) is entirely manual with no AI or MT layer documented, so AI translation is confined to the licensed brXM assistant, invoked field-by-field through chat. Not higher because there is no MT engine, no bulk translation job, and no translation-quality scoring or locale brand enforcement; not lower because in-CMS AI translation is a documented shipped operation.

The brXM assistant offers 'Optimize for Search Engines' (keyword, structure and metadata suggestions) and Tags Extraction to surface themes and keywords for categorization, and Bloomreach Search automates SEO page curation for the product catalog. The Document Agent Phase 1 (automatic metadata and taxonomy tagging on documents) promised for H2 2026 has not appeared in any Content or brXM release note through September 2026. Not higher because there is no bulk generation of titles/meta descriptions/OG tags across entries, no on-page SEO scoring, and no schema-markup suggestion; not lower because per-document SEO suggestions and tag extraction are documented today.

Bloomreach's operational AI is concentrated in Marketing: Loomi Audience autosegments and predictive scores, Optimal send time with channel selection, contextual personalization, Catalog Triggers that start scenarios on price drops or restocks (July 2026), and the Weblayer Variant Generator that produces up to five copy variants. On the content side the operations AI is limited to the brXM assistant's tag extraction and its v16.8 Search Agent for finding content across the repository. Not higher because none of this touches editorial lifecycle — there is no AI auto-tagging on save, duplicate detection, stale-content routing or AI publishing trigger in Content SaaS; not lower because several distinct AI workflow accelerators are GA and in production use.

Marketing agent (Affinity) is a shipped, named multi-agent product: a plain-language brief produces a complete campaign — audiences, timing, decision logic, control groups, generated copy and personalization — with a reviewable brief, mandatory human approval, a dedicated Loomi Agentic User role and inherited IAM permissions, and it now builds SMS-only and email+SMS omnichannel flows (July 2026) with per-customer vouchers. Shopping Agent 2.0 adds a second named production agent on the storefront side. Not higher because it is a separately-purchased add-on excluded from the Enterprise Marketing AI bundle, its post-launch self-optimization only tunes wait/send times (dynamic wait-time only on abandoned cart/browse), it has no cross-campaign memory and cannot see manual edits, and no agent executes content-management workflows in the CMS at all.

Loomi Analytics (Premium tier) builds reports, funnels, trends, segmentations, metrics and aggregates from natural-language requests, edits existing definitions in place, explains the definitions it writes and collects thumbs-up/down feedback; Bloomreach Search adds the rebuilt Performance Dashboard (Insights 2.0, July 2026) and behaviour-driven ABR category ranking. All of it analyses marketing and commerce performance. Not higher because the promised 'Content Governance at Scale' repository audits and health reports have still not shipped and there is no content-gap analysis, topic clustering or stale-content detection for editorial content; not lower because a genuine natural-language analytics assistant is GA.

Quality checking exists only at the single-document level through the brXM assistant: check and fix spelling and grammar, improve readability, sentiment analysis for brand-tone consistency, and SEO suggestions — all invoked per item from the chat panel. Nothing audits a repository at scale: there is no brand-voice compliance run, accessibility scan, duplicate or thin-content detection, and the H2 2026 'Content Governance at Scale' and Document Agent Phase 2 items remain unshipped as of September 2026. Not higher because no AI audit product covers any dimension across many pages; not lower because documented per-item quality operations do ship.

Loomi Search+ is a GA hybrid engine that runs keyword and vector search together over catalog embeddings, with configurable vector-precision settings and a dynamic vector cutoff that widens recall for exploratory queries and tightens it for specific ones, plus multi-language semantic search and image-based Visual Search. On the CMS side brXM now ships a real vector store and ingestion pipeline (Redis or pgvector, embeddings generated on save or publish, custom backends via the VectorStoreFactory SPI) feeding a v16.8 Search Agent over the content repository. Not higher because Loomi Search+ is Premium-tier gated, the brXM vector store is on-prem only (managed Bloomreach Cloud version still unreleased) and its Search Agent cannot filter by locale, type or folder — semantic matching only.

This is Bloomreach's strongest dimension and remains best-in-class in the dataset: Loomi ships ML predictions (purchase, churn, email open, in-session, custom), autosegments generated from customer property combinations, contextual personalization that scores each customer's history in real time for web and email, Recommendations+ which models interaction order to predict the next best product, Optimal send time per customer, and behaviour-driven category ranking trained per merchant (Sept 2026). Content SaaS consumes these as synchronized audiences for page personalization. Not a perfect score because cold-start handling is undocumented, there is no dedicated personalization-performance analytics surface separate from campaign reporting, and every AI tool here requires the Loomi Platform package plus an app package.

Loomi Connect runs official region-specific remote MCP servers over Streamable HTTP with 160+ tools across Marketing, Search, analytics and Data hub, authenticated through Bloomreach SSO/OIDC with no API keys, enforcing existing IAM permissions and PII masking, and including write tools that create, update and delete campaigns, scenarios, merchandising rules, customer filters and item collections. It is explicitly Beta / early access at version 0.1.0-beta.10 — no SLA, no availability commitment, free for now with paid tiers to follow — and a separate Conversations server exists only for prototyping against a fixed sample catalog. Not higher because the server exposes no Content/CMS tools whatsoever (no reading, writing or publishing documents), there is no self-serve audit log and no product-level read-only mode; not lower because a permissioned, production-usable official server with real write operations is live.

brXM's AI module is genuine BYOM: you set brxm.ai.provider to OpenAI, GoogleGenAiVertex, Ollama or LiteLLM, supply your own API key or ADC credentials, and can run models entirely locally — with your own Redis or pgvector vector store and custom backends wired through the VectorStoreFactory SPI on a Spring AI bridge, which gives real data-residency control. Loomi Connect is model-agnostic by design (you bring and host the model; Bloomreach forwards no payloads to third-party AI providers). Not higher because this only covers the PaaS/self-hosted CMS: Marketing's Loomi features and the Marketing agent are hard-wired to Bloomreach's chosen Gemini and OpenAI models with no key or provider selection, and the vector store is unavailable on Bloomreach Cloud.

Loomi Connect gives agents a discoverable remote tool surface (160+ tools, Streamable HTTP, setup guides for Claude Code, Cursor, VS Code and Windsurf, a partner demo server, client-example repo and LangChain/n8n compatibility), while brXM's AI module exposes documented extension points — a Spring AI bridge, the VectorStoreFactory SPI, ingestion mode/type properties and Groovy maintenance scripts for the embedding store. Bloomreach's own docs are published as llms.txt indexes with .md variants of every page, which makes them directly consumable by coding agents. Not higher because the brXM AI backend is still an internal service with its REST API layer only 'planned', there is no first-party AI SDK, and the MCP layer is Beta with no Content CMS coverage.

Bloomreach publishes per-product AI transparency documentation: Marketing agent names its base models (Gemini primary, some OpenAI), documents Gemini's four safety-filter categories, enumerates bias sources, requires mandatory human review before anything goes live, keeps PII out of AI processing by default, restricts personal data to Personal Data Viewer roles, and guarantees no cross-client training; brXM adds role-gated access (xm.chatbot.user), kill switches for the provider, vector store and UI, and a PromptLoggerAdvisor that logs every prompt and response with user and conversation IDs. Brand guardrails come from the project-level tone-of-voice profile. Not higher because there is no self-serve AI audit log on the SaaS side — Loomi Connect's usage log is internal to Bloomreach support, with no product-level read-only mode or managed tool allow/deny list — and no hallucination detection, confidence scoring or IP indemnification for AI output is offered.

brXM does expose real AI consumption data: the UsageLoggingStore audit logger reports total, prompt and generation token counts per user and per conversation, embedding-generation tokens are attributed too (background ingestion logs under system-ingestion), and conversation auto-naming requests are charged and logged to the initiating user. Loomi Connect enforces per-user rate limits and offers usage tools for Search API requests and unique visitors against contracted limits. Not higher because all of the AI token visibility is log4j debug output an operator must enable and parse — there is no dashboard, no cost or credit tracking, no prompt-effectiveness analytics beyond thumbs-up/down in Loomi Analytics, and on the SaaS side the Loomi Connect usage log is expressly for Bloomreach's internal support use rather than the customer.