Bloomreach Engagement is a customer data & experience platform that provides full channel automation, lifecycle intelligence, AI-driven predictive analytics, product recommendations, and more.

It works by collecting and analyzing actions that customers make in relation to your business. This can be done online on your website, through imports or backend purchase data, or other channels. After integrating your business you can harness our advanced analytics capabilities and create actionable improvements.

You can read more in our What is Bloomreach Engagement article, or our comparison to Google Analytics if that is what you are familiar with.

Bloomreach Engagement platform infrastructure

The Bloomreach Engagement application is provided as a SaaS solution hosted on the Google Cloud Platform. Bloomreach Engagement leverages GCP’s multi-tenant, geographically distributed environment to support the availability of its services. We leverage GCP’s unparalleled scalability designed to store extremely large amounts of data across many servers.

With Bloomreach Engagement there are 3 types of instances available to host your projects and data: Multi tenant instance, Single tenant instance, and Exclusive instance. You can see how these differ in the image below. You can read more about our platform and security architecture in our Security section; including a detailed overview of the features available on different instances.

Organization of data into Accounts and Projects

Each Bloomreach customer is an Account. Accounts share the contracted volumes, limits, and can share access accounts and permissions. Under the Account level, there are individual projects. These are separated on an application level and no data is shared between projects. Access is managed on a Project and Account level via our Role-Based Access Control.

Projects are isolated environments and can represent for example:

• Environments for development, staging, and production
• Separate Brands for multi-brand customer, with individual brand management teams and databases
• Separate markets with isolated customer bases

There is no limit on the number of projects in your account. Developers are encouraged to use Dev Envs to prepare new data flows, new integrations, or experiments with new customer journeys in staging environments to make sure they work on a new website the marketing team is about to launch. Isolation also guarantees that developers will not have any unwanted access to the data of real customers, which makes a lot of tedious access management quicker.

Data Structures in Bloomreach Engagement

Bloomreach Engagement is NOT a relational database - data in the platform is stored in a NoSQL structure. Data is stored with Customer records as extensible attributes and each customer has an Event stream attached.

Bloomreach Engagement was designed with the goal of speed of access and use in mind, along with platform end-user’s UX as a priority. For this to be possible, all data needs to be prepared, cleaned, and enriched at the time of ingestion and then be ingested in a human-readable format (i.e. no lookup tables, no cryptic numeric category ids, ...), and as immutable data in events stored from all sources. This might be different than what you would normally expect from a database but it is this prerequisite that leads to our great speed and efficiency.

Schemas are not checked or validated on data ingestion, and new data points can be added at any time afterward using the Data Manager or with Imports. However, there is no easy data cleanup possible on events already stored with other formats. It is always recommended to think in advance and use standard data formats.

Workflow in Bloomreach Engagement

Data ingestion

Data could be ingested through either external or internal sources. Internal sources involve real-time tracking through your website using our Javascript SDK, or mobile app using one of our Mobile SDKs. Data from external sources can be ingested via Imports. This can be done in-app or via our API, and through CSV or XML files, integrated SQL databases, or file storages.

Read more in our Imports article, and refer back to Data Structure for advice on the data format. Generally, we can say that the Bloomreach Engagement app works best with:

1. Flat data structure (denormalized and flattened)
   • Most commonly only base types (string, number, boolean, datetime, list)
   • Most complex fields are arrays of objects
   • Product catalog split into products and variants
2. Real-time updates (customers, orders, products)
   • Preferably everything is pushed in real-time via the APIs
   • If it is not possible then use CSV files and trigger the Imports via the API to pull the data
3. Immutable event data (events are only appended)

We have tracking limits. The limits are designed to be high enough to ensure that no legitimate tracking use case will ever hit the limit, and thus mainly serve to prevent inappropriate usage that could potentially affect other users. These include:

• IP based rate limits

When working with the API, you might encounter errors and it is essential to know how to react correctly depending on the error. Find our more in our API Reference.

Data unification (Single Customer View)

Bloomreach Engagement is a customer-centric system - as opposed to session-based systems, everything spins around individual customers. At the heart of our CDXP is the Single Customer View, which is a collection of data on individual customer level. This involves:

• Customer identifiers: hard and soft IDs
• Customer properties: e.g. first_name, email, ...
• Recorded events with their attributes: any actions that the customer did on your website, e.g. purchase, cart_update; and the respective event attributes, e.g. timestamp
• All customer data enrichments: e.g. aggregates or predictions

Think of our ‘Single Customer View’ as a profile for every tracked user - both anonymous and identified - that came across your touchpoints (e.g. website).

Every user activity manifests as events or properties belonging to that profile. You can use these data for various analytics and marketing automation. Created metrics, predictions, consents, and others, are then added to respective profiles. When an anonymous user is identified as an existing profile, the two profiles are merged into one.

You can read more about our data types and how they work in our detailed Data Structure structure] and Data & Assets articles.

Data activation

Once collected and unified, this data is made accessible for real-time data activation. You can process the raw data with our Analyses tools, create custom metrics and definitions, and use these for Campaigns, Ads retargeting, AI-driven Predictions, Product Recommendations or website optimization features. Customer properties can be used for further campaign personalization using Jinja. Raw data can be exported in a custom-defined structure to any file storage via any of the existing file storage integrations - such as our Bloomreach Engagement BigQuery.

Release management

To ensure that you can take advantage of all the new features that we are continuously working on as fast as possible, we release a new minor version of the app roughly every 2 weeks. Considering the frequency of the updates, we have refined our release process and implemented several measures to make sure that our releases are problem- and downtime-free.

Firstly, we operate tiered releases - a new version is first released in our internal pre-production environments, then rolling out to 1/3rd of customers, then to the next chunk, etc. By doing this, we ensure that any minor issues are resolved quickly and without impact on clients.

Secondly, all of our instances operate in High Availability mode, meaning each instance has at least 1 mirror. The release on the instance is staggered and happens for 1 mirror first, and to the rest within minutes. This ensures smooth continuity during the release process.

In rare cases where we expect downtime to occur as a result of a version release, we ensure that we communicate this early enough and schedule the downtime together with the affected clients.

Device requirements for the Engagement app

Minimum hardware requirements for laptops and desktops to work with the Engagement app include:

• Desktop/laptop CPU 4 years old or younger
• 4 GB RAM

Minimum software requirements include recent browser versions as:

• latest Google Chrome version
• latest Mozilla Firefox version
• latest Mozilla Firefox ESR
• last 2 Microsoft Edge major versions
• last 2 Apple Safari major versions

Recommended network bandwidth to access your application:

• Mobile 4G internet

🚧

Please be aware that currently, we have not optimized our platform for mobile devices, and you may experience some limitations while using it on these devices.