Migrate to profile-based pricing

This guide covers what to do before migrating to Bloomreach's profile-based pricing model, and how to set up a new implementation correctly from the start.

For a full explanation of how profile-based pricing works, see Pricing and usage.

For ongoing guidance on staying within your allowances, see Efficient profile-based Engagement usage.

What drives usage

Understanding what drives each metric up makes it easier to prioritize pre-migration work. This guide covers 6 areas.

Before you migrate

Clean up projects

Review all Bloomreach projects before migration. Sandbox and development projects aren't exempt. Usage may be combined across the projects covered by your Bloomreach account and contract, including billable profiles and MUV. Remove full database copies from non-production environments. If you need test projects, keep them small and use hard IDs rather than real customer data.

Audit billable profiles

Your billable profile count is the foundation of your contracted tier and all your usage allowances. Before migrating, build a segment of profiles that have a billable identifier — email, phone, or hard ID — but no qualifying engagement within your defined inactivity window. Remove lapsed profiles before your contract switches so they don't inflate your baseline. See [Efficient profile-based Engagement usage] for guidance on defining an inactivity window.

Review imports

Any profile imported with an email, phone, or hard ID is immediately billable. Switch to delta imports—only import profiles where at least one attribute has changed—and consolidate imports from the same source into a single import or API call. Multiple imports with one property each count as multiple profile updates; a single import with all properties counts as one.

Check CRM and warehouse syncs

Full-record syncs that push all attributes regardless of change are one of the biggest sources of unnecessary profile update volume. Switch to delta syncs before migration so your baseline profile update count reflects real activity.

Review set-property nodes

Audit running scenarios for set-property nodes and consolidate multiple attribute updates into a single node where possible. Updating 5 attributes in one call counts as 1 profile update; 5 separate calls count as 5.

Check cookie configuration

By default, the Bloomreach cookie expires 3 years after the last interaction (cookieExpiration in the JS SDK). MUV resets every calendar month. A visitor counts toward MUV the first time Bloomreach sees that anonymous ID in the month. If the cookie stays active, later visits in the same month don't add another anonymous MUV increment. If the cookie expires, Bloomreach assigns a new anonymous ID, and the visitor can count as new again in the same month. Check your cookie expiration settings before migration. From an MUV perspective, we recommend at least 30 days.

Set data retention rules

Events accumulate indefinitely without expiration rules, contributing to your event storage footprint. Set per-event-type retention via Data expiration settings before your contract switches. Use the recommended retention table in Event storage as a starting point.

Review frequency caps and feature limits

Set a frequency policy with channel-specific caps for email, SMS, and push before you migrate. Also, check your current usage for weblayers, push, in-app, ads, and email recommendations against annual feature limits—it's easier to address overconsumption before your new contract starts than after.

Review high-frequency custom events

If you track non-real-time events to the customer profile—for example, hourly usage events—consolidate them into a single daily event to reduce billable profile updates.

Set up a new implementation

If you're integrating Bloomreach Engagement for the first time on profile-based pricing, these are the things to get right before volume builds up. Fixing these later takes more work.

Separate environments

Run test and development traffic in separate projects. Sandbox and dev projects aren't exempt. Usage may be combined across the projects covered by your Bloomreach account and contract. Set up separate projects for each environment at the start of your implementation. Don't import all your profiles and data into test or development projects—use only a sample needed for testing. If you need to run tests on all profiles, remove them once integration is complete.

Define billable profile criteria

Before your first import, agree internally on which profiles are genuinely active. Only import profiles with an email, phone, or hard ID if they're active customers or prospects. Importing a full historical database, including lapsed contacts, makes them immediately billable. Define your inactivity thresholds first, then filter your initial import accordingly.

Use delta imports and syncs

Configure customer imports and CRM or data warehouse syncs as delta operations from day one. Only bring in profiles where at least one attribute has changed. Consolidate imports from the same source into a single import or API call. These are far easier to establish as standards at the start than to retrofit later.

Review periodic event architecture

If you track custom events to the customer profile that reflect frequent, non-real-time updates—for example, hourly usage or games played — reconsider the frequency. 24 hourly events generate 24 billable profile updates; a single daily event generates 1.

Configure cookie expiration and data retention

Confirm your Bloomreach cookie expiration is correctly set (cookieExpiration in the JS SDK, default 3 years) with your implementation team before launch. Set data retention rules per event type in Data expiration settings before events start accumulating.

Set scenario standards

Configure set-property nodes to consolidate multiple attribute updates into a single node as a build standard before any scenarios go live.

Set frequency caps

Set frequency caps before you launch campaigns. Retroactive caps don't recover orchestrations you've already used.