In this guide, you will find some simple yet effective best practices for optimizing your usage of the Engagement platform, specifically in terms of **Monthly Processed Events (MPE)** and **Maximum Event Storage (MES).** These tips and tricks will allow you to make the most of Engagement usage and your license while maintaining functionality and insights.
Learn more about:
[What MPE is](🔗)
[What MES is](🔗)
[How to reduce MPE](🔗)
[How to reduce MES](🔗)
# Monthly Processed Events (MPE)
Monthly Processed Events (MPE) refer to the data processing into or within the Engagement platform spanning one month. Various actions trigger events, such as when customers view items, start new sessions, receive or open emails. Essentially, any events generated by the system, via API, web-tracking, or any other import source require processing. The processed events count toward your MPE, incurring costs covered by your contract.
Below is a complete overview of actions that do and do not generate events.
|Do events get generated?||Yes||No|
|**Webtracking**||Yes, if Bloomreach SDK is nebaled for the vents specified there.|||
|**Imports**||Yes, events are imported.||No, if customers, catalogs or vouchers are imported.|
|**API**||Yes, if you send events via API.||No, if you retrieve events, customers, catalogs, etc.|
|**Customer attribute update**||||No.|
|**Recommendations**||Yes, if they are ‘shown’ or ‘clicked in.’|||
Engagement tracks and processes both [system](🔗) events, predefined and available by default, and [custom](🔗) events, tailored specifically for your business. It is important to note that different [event attributes](🔗) do not count as separate events. However, if events have the same name but differ in [status](🔗), they are considered distinct events for MPE calculation purposes.
If you send or import the same event multiple times, each occurrence will be treated as a new event. However, if there is a 1:1 duplication, deduplication takes place. Event duplication can occur when you send the same event with different attributes multiple times. To avoid this, it is crucial to ensure only unique data is tracked or imported.
You can use [deduplication](🔗) of events to clean up and prevent storing the same event twice. However, even with deduplication, the event will still be** considered processed and counted toward your Monthly Processed Events (MPEs).**
# Maximum event storage (MES)
Another aspect affecting your costs is storing data managed by the Maximum Event Storage. MES refers to the maximum number of data points (events) that can be stored in your Engagement account at any given time.
It includes all the currently active events that have not expired or been deleted. However, it is worth noting that events previously in the platform that have been deleted, expired, or moved to another storage area, like [EBQ](🔗), do not count toward this limit. In essence, MES sets the boundary for the number of events you can keep in the platform without incurring additional costs.
# Efficient usage tips
## How to reduce MPE
Go to _**Overview > Bloomreach usage**_ to explore the efficiency of MPE in your account. Here, you can find a general overview of your MPE, dashboards analyzing each communication channel, and data breakdowns to see which events and campaigns are used.
Follow these **best practices** to optimize your MPE and avoid common pitfalls.
**MES > MPE**
Your MES should be higher than your MPE. If it is reversed, this can be a recent bug, or you may have launched a new website or a massive campaign.
Use DELTA imports to avoid importing the same event repeatedly. DELTAs only bring in new or updated data, preventing duplicated events and unnecessary processing increasing your MPE.
**Event tracking shows healthy signs**
Check whether the number of your tracked events in the last few weeks is consistent with a healthy business.
_Page_visit_ can be tracked but does not need to
_View_category_, _search_results_, and _checkout_ are tracked for advanced users only.
The table below shows unhealthy signs in event tracking you should avoid.
|Badly tracked events||Explanation|
|_# cart_update > # view_item_||Likely multiple pings for the cart_update event.|
|_# checkout > # view_item_||Theoretically possible, however, checkout events are much more useful than view_item. Track only critical steps of the checkout process to reduce their tracking.|
|_# view_category > 2 x # view_item_||Some websites load new view_category events with every scroll, which is inefficient and does not bring value.|
|_# session_start > 10 x # session_end_||Either session_end is not loading, or multiple pings occur during session_start.|
|_# session_start > 5 x # view_item_||# view_item should be higher than # session_start in a healthy bsuiness.|
|_# campaign enqueued ≠ # campaign sent_||They should be within a 5% margin of each other.|
For example, notice here that, mainly from October to January, the amount of _view_item_ and _view_category_ far exceeded the number of _page_visit_ events, which is logically unsound. The same holds for the number of _session_start_ and _session_end_ events, which should logically be the same amount.
**Ad events up to 10-20% of MPE**
Make sure your ad events constitute at most 10-20 % of your MPE. If you send [ad audiences](🔗) daily to segments of customers rather than to all of them, it is vital to check the conditions in your scenarios to ensure you do not send the data repeatedly.
Before sending an ad audience to the relevant segments, check if the customer received one the previous day and whether their condition for qualifying for the segment has changed in the last 24 hours. Check out the [Ads Best Practices Guide article](🔗) for more insight into optimizing your ads.
## How to reduce MES
For more details on your stored events, you can easily create a [report](🔗) on this yourself. Go to _**Analyses > Reports**_, and create a report counting each event.
Follow these **best practices** to optimize your MES and avoid common pitfalls.
Moving events to [EBQ](🔗) will save you storage space while retaining the ability to query and analyze the data when needed. By expiring events, you will not lose data itself.
Set data [expirations](🔗) in your project to automatically delete unnecessary events. Using these expirations will help control the gradual increase in your MES. Refer to the table under the upcoming sixth tip for recommended event storage when setting expirations. Data expirations also allow you to differentiate between various attributes, with examples for _banner_ and _campaign_ events.
The highlighted period in the image below shows a steep rise in MES due to not using expirations.
**Ensure consistent tracking**
Using the table above, check whether inconsistent tracking causes inconsistent storage.
**Page_visit up to 5% of MES**
Make sure your _page_visit_ storage constitutes no more than 5% of your MES. One of the first things to expire is this event, as it has the least benefits.
**Campaign and banner storage only up 30% each of MES**
Make sure your _campaign_ and _banner_ storage both constitute no more than 30% each of your MES. Expire irrelevant campaign types, statuses, and banner actions using the optimization table below.
**Optimize event tracking and retention**
Refer to this table for guidance on which events are not necessary to track and the recommended retention period for optimizing your data storage.
|Event||Main use||Recommended tracking||Recommended storage|
|**_first_session_**||Analytical: The lifetime attribution analysis calculates the time since customers first visited your web.||Always||Forever|
|**_session_start_**||Analytical: Calculate the number of visits per period, visit frequency, campaign efficiency, and analyze paid ad attribution.||Always||13 months|
|**_session_end_**||Analytical: Calculate the average time spent on the web.||Always||1 month|
|**_page_visit_**||Mostly quality control when necessary to check something in-depth.||Depends. Not always if everything is already being tracked.||1 month or less|
|**_banner_**||Analytical: weblayer campaign efficiency (especially when running A/B tests), some banners (subscription) are also used for triggering scenarios.||Always||Subscription banner - show/close: 1 month - click: 6 months Other banners: - show/close: 1 month - click: 3 months|
|**_campaign_**||Analytical: campaign efficiency, triggering based on email engagement, etc.||Always||- Type = split: 1 month (for A/B tests) - Email enqueued: 3 months - Email delivered/opened/clicked: 113 months (year-to-year comparison) - Email others: 1 month Ad communication: 1 week - Other communication channels: 3 months|
|**_checkout_**||Abandoned checkout campaigns, watchdog, funnel analysis.||Only for advanced users. Not required for newer users as _cart_update_ covers 99% of your needs.||1 month|
|**_cart_update_**||Abandoned cart campaigns, watchdog, funnel analysis, feeding recommendations.||Always||1 month|
|**_view_item_**||Abandoned browse campaigns, watchdog, social proof banner, funnel analysis, and feeding recommendations.||Always||3 months|
|**_view_category_**||Feeding recommendations, social proof banner, funnel analysis.||Only for advanced users. Replaceable by _view_item_ to identify customers’ favorite or last browsed category.||1 month|
|**_search/search_results_**||Funnel analysis.||Only for advanced users.||1 month|
|**_purchase_item_**||The trigger for post-purchase campaigns, feeding recommendations, and determining favorite/least purchased categories.||Always||13 months|
|**_double_opt_in_**||Triggers the “double opt-in campaigns” for consent.||Always in the EU. Recommended for other regions as well as it makes identification and segmentation more accurate.||1 month|
|**_consent_**||Required for any communication.||Always||Always|
You can reduce your MES by [deleting data](🔗) in the Data Manager. But note that deleting data will reduce MES only, not MPE.