It triggers actions or shows CMS content to different groups of customers based on their behavior, interests, wishlists and historical data. Using targeted personalization the behavior of the customers can be measured and rewarded. You can show them special promotions, suggest them products, send them personalized emails or adapt the content and products of the web site to their interests.

Key Concepts

  • BTG means Behavioral Targeting Group
  • Customer Segment: Category which differentiates customers based on their behavior, past orders, current products in cart or other historical data. The business defines the segments taking into account what customers they want to target.
  • Customer Segment Rule: It defines a condition that the customer has to fulfill to belong to the segment. It may be based on gender, region, age, searches, products viewed, products ordered or added to the cart, pages, categories or products visited.
  • Output Action: Activity which is triggered if the customer fulfills all the rules.
    • When a customer segment applies for a user it is not processed again. 
  • It is made up by the btg and btgcockpit extensions.

Key Features

  • Cockpit for CRUD operations on customer segments, rules and actions. It also tests what customers fulfill the rules.
  • Customer Segments
    • They are assigned to websites
  • Rules
    • Order Rule: Total price, products, quantity or categories of products of the last orders. Last order date. Frequency or number of orders.
    • Cart Rule: Total price, quantity and category of products or products in cart. 
    • Website Rule: viewed categories, products, pages, referrer or URL parameter.
    • Customer-Rules: Gender, postal code, region, user group. For this rule to work, the customers must be authenticated.
    • Each Rule has a list of operands. Each one of them defines its owns parameters.
    • The catalog version is ignored when comparing products.
  • Actions
    • They can add the customer to a group
    • They show or hide a WCMS page or component. A second page or component must be shown in the later case.
  • Each WCMS page or component can have a BTG restriction which hides or shows it for some customer segments.
  • The Live Edit Perspective can be used to test a customer segments. The state of any rule may be forced to test especial cases.
  • Reports
    • Success ratio over time
    • Success ratio
    • Percentage of the users who started an action
    • Percentage of authenticated users
    • Membership: Detail of what rules passed each authenticated customer.

Evaluation of rules

Technical Details

For the BTG extension to work correctly, in each request the rules of the segment must be evaluated. Each rule contains conditions and they must also be evaluated. Doing this evaluation blindly may lead to serious performance problems.

To prevent this and to provide data for the reports, each result of the evaluation of a segment, rule or condition is saved to the database. If the result was successful (the condition was fulfilled), the saved result is used in subsequent evaluations. This means that each segment, rule or condition is going to be evaluated until it is fulfilled. Afterwards the saved result is going to be used.

We can manually invalidate some successful results, if we want to evaluate again a condition. Please read above how the BTGSegmentFilter works.

Result Scope

How long the result is valid is defined by the result scope. If is a session result scope, the result is valid as long as the jalo/http session is valid. If the evaluation scope is permanent, the result is always valid.

The results of the anonymous user are only valid during the session.

Evaluation Method

If the full evaluation mode is used, the results of all the rules and conditions are fetched from the database if the last time they were successful or they are calculated. If the optimized evaluation mode is used, BTG stops checking the rules and conditions when one was unsuccessful. The result is always saved into the database because they are used by the reports.

The full evaluation method is useful for testing your rules or for generating a complete report of what rules where fulfilled by the visitors of the site.

Condition Evaluation Scope

It indicates the conditions and their operands if there is a session available. In such a case, the condition evaluation scope would be online, otherwise offline.

I haven't found any operand which uses this flag. But I believe that the offline value is set when the page is viewed using the Live Edit mode in the CMS Cockpit.

Runtime Configuration

The scopes and the evaluation method may be set on runtime. This overwrites the values of the segment. This is used by the BTG cockpit to test the segments and rules.

Execution of the output action

The out actions associated to a customer segment are triggered once when all the rules are fulfilled. If the session result scope is used, the actions are performed in every session where the customer fulfills all the rules. If the permanent result scope is used, the actions are performed only once in the lifetime of the eShop.

If you are in the BTG cockpit, the actions are triggered every time the customer fulfills the rules.

Integration in a frontend

The storetemplate is an example of integrating advanced personalization in a frontend application. The filter BTGSegmentFilter does the evaluation of the rules in every request. The page https://wiki.hybris.com/display/release5/How+To+Integrate+Advanced+Personalization+with+Front-end+Application+-+Tutorial explains how the filter works.

Warning: The BTGSegmentFilter invalidates all the results at the beginning of a request. In a real-world website, only some rules like "Cart is empty" must be evaluated again in every request.

Further Reading

Data model of the BTG extension: https://wiki.hybris.com/display/release5/btg+Extension+-+Conditions 

Based on Hybris version 5.3

Add comment


Security code
Refresh