This blog promotes knowledge sharing through experience and collaboration. For more product information, visit our WebSphere Commerce CSE page. For easier navigation, utilize the Categories to find posts that match your interest.
Beware of Growing DMMBRGRPPZN and DMUSERBHVR Tables
Both the DMMBRGRPPZN and the DMUSERBHVR marketing tables can rapidly grow if marketing dialog activities are not well defined. Alternatively, well defined activities can prevent these tables from growing, which helps reduce database size, resulting in potential database performance improvement.
First, let's look at the DMMBRGRPPZN (marketing member group personalization) table. This table contains customers that are explicitly included in a member group by the customer's Personalization ID. WebSphere Commerce uses this ID to present customers with personalized content, such as recommended products, promotion codes, or images.
When a customer enters the site for the first time as a generic user, a unique personalization ID is placed in their WC_PERSISTENT cookie. The personalization ID remains the same throughout the session as long as WC_PERSISTENT cookie is present. If this customer becomes a guest user, the personalization ID is associated with their guest member ID. If the customer becomes a registered user, the personalization ID is associated with the registered member ID. If the customer leaves the site as a guest user, and later returns to the site, they are assigned a new guest member ID. However, the same personalization ID is now associated with the previous guest user ID, and the new guest user ID.
Given that personalization ID can be for generic or guest users, it allows merchandiser to configure marketing activities for generic and guest user.
With above activity, record is inserted in DMUSERBHVR table, and when user qualifies target condition (i.e. views a product 5 times from Men's category) record gets added to DMMBRGRPPZN table.
Later customer segment can be used to show personalized content.
Now, what is the problem with Activity 1? And why do such activities lead to rapid growth in DMMBRGRPPZN and DMUSERBHVR tables?
The Activity is configured for all types of users. For generic and guest users as soon as a user clears the browser cookies, or if a cookie expires, the personalization ID is lost. However, the record in DMMBRGRPPZN table persists since shopper participated in activity.
Now this raises a question: Why there isn't a cleanup mechanism to remove these orphaned records from DMMBRGRPPZN table? The simple answer is that clearing browser cookies manually or cookies being expired are client-side events that the server does not know about. For this reason, there is nothing in the product today to help clean up entries from DMMBRGRPPZN table.
To overcome this situation, consider configuring the marketing activity with an cleanup strategy. Given that customers are added to the segment using the Add to Customer Segment action, we can utilize the Remove from Customer Segment actions in marketing activities to remove a customer from the segment.
This could be done in the same dialog activity in which the customer was added, for example:
Or periodically you could setup a cleanup dialog activity like:
As illustrated above in example 1, the DMUSERBHVR is populated for most dialog activities, experiments, targets that record behavior (e.g. Catalog Browsing Behavior), and actions that record behavior (e.g. Recently Viewed). Given that this table populates the behavior needed to carry out next action, there is no best practice in structuring activities to reduce the DMUSERBHVR size. However, we do have a dbclean entry to manage this table:
objectname="marketing_userbehavior" statement="delete from dmuserbhvr where days (current timestamp) - days(lastupdated) >=?"
For more information refer to Database Cleanup utility objects - marketing_userbehavior
For more information on personalizationID refer to
For more information on Marketing activity data storage and process flow refer to