Efficient profile-based Engagement usage

This guide covers how to keep your implementation efficient and stay within your contracted allowances and feature limits on profile-based pricing.

For a full explanation of how each metric is defined and measured, see Pricing and usage.

For pre-migration and new customer setup steps, see Migrate to profile-based pricing.

📘
Note
Not sure which pricing model you're on? Check Which pricing model am I on?

Billable profiles

For how billable profiles are defined and counted, see Billable profiles.

Define an inactive profile

Base your inactivity definition on your purchase cycle. Recommended defaults for B2C:

No email open or click in the last 18 months.
No purchase in the last 36 months.
No session_start in the last 18 months.
No events on profile at all (all expired, or never tracked).

Low-frequency categories such as insurance or automotive may extend this window to 48–60 months. Beyond 60 months, consider data minimization under GDPR or equivalent regulations.

Once you have identified inactive profiles, export them first (via Data exports or the customer list CSV download), then delete them.

Reduce billable profile count

Build a lapsed profile segment: profiles with a billable identifier and no qualifying engagement within your inactivity window.
Filter customer exports before import. Any profile imported with an email, phone, or hard ID is immediately billable.
Account for new channel integrations. Adding WhatsApp or SMS creates profiles with phone numbers and increases your billable count if these are net-new profiles rather than additions to existing billable ones.

Monthly unique visitors

For how monthly unique visitors (MUV) is defined and counted, see MUV.

What affects MUV

Cookie lifetime

The Bloomreach cookie expires 3 years after the last interaction by default (cookieExpiration in the JS SDK). MUV resets every calendar month—a visitor counts 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. A short cookie expiration window can inflate MUV—if a visitor's cookie expires and they return within the same month, they're assigned a new anonymous ID and counted as a new visitor. Review your cookie expiration settings if MUV is growing unexpectedly.

Late identification

Identify visitors as early as possible. If a visitor first appears anonymously and then logs in later in the same month, both first-time events can count toward MUV. After that identified first-seen event, later visits in the same month add 0.

Project scope

MUV is measured at the project level and may be combined across the projects covered by your Bloomreach account and contract. There is no deduplication across projects in the same workspace. Review each project separately.

What doesn't affect MUV

Expiring session_startEvents don't reduce your MUV count. MUV is recorded at the moment of the visit—deleting the event record afterward has no effect on the count already registered.

Profile updates

For how profile updates are defined and counted, see Profile updates.

Avoidable update sources

CRM and data warehouse syncs

Full-record syncs that push all attributes regardless of change are the biggest source of unnecessary volume. A daily full sync across 500,000 profiles = 15 million updates per month from a single job. Switch to delta syncs — only push profiles where at least one attribute has changed.

Imports

Consolidate imports from the same source into a single import. Even with 15 updated properties, it counts as 1 update. 15 separate imports with 1 property each = 15 updates. Replace recurring full-file imports with delta files.

Scenario set-property nodes

Audit running scenarios for set-property nodes. Remove any where the attribute is not actively used downstream.
Consolidate multiple set-property actions into a single node. Updating five attributes in one call = 1 update per profile.

Event storage

For how event storage is defined and measured, see Event storage.

Events accumulate indefinitely without expiration rules. Set per-event-type retention rules to keep your stored footprint in check.

Recommended retention by event type

Event type	Recommended retention
`page_visit`	1 month or less
`session_end`	1 month
`cart_update`	1 month
`banner` / `campaign` show, close	1 month
`view_item`	3 months
`banner` click, `email` opened / clicked	3–13 months
`session_start`	13 months
`first_session`	3 years
`purchase` / `purchase_item`	Indefinitely
`consent`	Indefinitely

If you have access to Engagement BigQuery (EBQ), use it to archive older historical data while keeping it queryable without contributing to platform storage.

Email and channel orchestrations

For how orchestrations are defined and counted, see Platform allowances.

Frequency policy

The account-level default frequency policy is the most effective lever for reducing orchestration volume. It applies a hard cap across all active campaigns and scenarios without requiring changes to individual sends.

Set a default cap in account settings.
Add channel-specific caps. Email, SMS, and push have different cost profiles and should each have its own limit.
Apply engagement-based eligibility in high-volume campaigns. Prioritize engaged subscribers and limit sends to less-engaged profiles.

Suppression

Keep suppression lists current: unsubscribes, hard bounces, and complaint profiles, excluding them from all sends.
Ensure soft bounce exclusions are configured in the cumulative soft bounce policy settings.

Annual planning

Map expected peak months against your annual allowance at the start of the contract year. Annual allowances are shared across the full year—a high-volume period early in the year reduces what's available later.

Feature limits

Some feature limits may prevent further use of that feature once the limit is reached. This is different from allowances, which may trigger commercial follow-up rather than automatic blocking.

Feature	Primary risk
Weblayers and experiments	Always-on weblayer with no display frequency set
Browser push notifications	Broadcast push cadence
In-app messages	Multi-step flows re-served to the same users at common touchpoints
Ad sends	Daily retargeting audience refreshes with full audience overlap
Email recommendations	Multiple recommendation blocks per triggered email
Weblayer recommendations	Recommendation block on every page load
Mobile push recommendations	Push with recommendation content at volume
In-app recommendations	Recommendation blocks at high frequency

Optimize by feature

Weblayers and experiments

Set display frequency to once per session where repeat exposure adds no value. You can also set the customer filter to show the weblayer only if it hasn't been shown in at least X days, depending on the use case.

Browser push

Use browser push for triggered campaigns such as abandoned cart, price drop, or back-in-stock rather than broadcast sends.
Segment tightly. A highly relevant audience uses the annual cap far more efficiently than a broad one.

In-app messages

Set display frequency caps on content blocks to prevent repeated serves within a short window.

Recommendations

Each recommendation block per message counts as one serve per recipient. An email with 3 blocks = 3 serves.
Reduce blocks per template. One well-placed block often performs comparably to three.

Review usage regularly

Set a regular cadence to review the metrics below and course-correct before issues compound.

Monthly

Review billable profile count. Check for unexpected growth from new integrations or imports.
Check MUV trend. Flag any spikes that correlate with cookie or tracking configuration changes.
Monitor orchestration volume by channel. Verify frequency caps are working as intended.

Quarterly

Run a profile update audit. Identify top sources of write volume and assess delta sync performance.
Review feature limit consumption rates. Project whether you'll reach annual caps before contract renewal.
Re-assess the lapsed profile segment. Remove profiles that have crossed your inactivity threshold since the last review.

Annually

Repeat the pre-migration steps as a health check.
Map peak traffic and send months against remaining allowances.
Engage your Account Manager at least 60 days before renewal to discuss top-ups or tier changes proactively.

FAQ

Does expiring session_start events reduce my MUV count?

No. MUV is recorded at the moment of the visit. Expiring the event record afterwards has no effect on the count already registered.

If I import a profile with 15 updated properties, does that count as 15 profile updates?

No. If consolidated into a single import, it counts as 1 update. However, 15 separate imports with 1 property each = 15 updates. Always consolidate imports from the same source.

Are anonymous profiles billable?

No—unless the fallback rule applies. See Billable profiles for details.

Are all projects counted in my usage?

Usage may be combined across the projects covered by your Bloomreach account and contract. There is no deduplication across projects in the same workspace, so non-production projects can inflate measured usage.

Does setting an attribute to its existing value still count as a profile update?

Yes. Any write operation counts, even if the value hasn't changed. This is a key reason to implement delta syncs.