[MGNLPN-354] Visitor trait not working properly Created: 21/Dec/16  Updated: 02/May/17  Resolved: 17/Mar/17

Status: Closed
Project: Magnolia Personalization
Component/s: None
Affects Version/s: 1.3.1, 1.4
Fix Version/s: 1.2.10, 1.3.3, 1.4.3

Type: Bug Priority: Neutral
Reporter: Ondrej Chytil Assignee: Antonín Juran
Resolution: Fixed Votes: 1
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Snímek obrazovky pořízený 2017-02-15 09-23-34.png     PNG File visitor-trait-ruleField.png    
Issue Links:
Relates
relates to MGNLADVCACHE-118 Personalized variant will displayed f... Accepted
relates to MGNLPN-358 Returning visitor is not resolved pro... Closed
duplicate
is duplicated by MGNLPN-303 visitor trait seems not working well Closed
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Sprint: Kromeriz 87
Story Points: 21

 Description   

VisitorDetectorFilter sets the Visitor trait object as returning for the logged user and for anonymous user this value is set according to the cookie value. So basically in the end every request is returning visitor. In VisitorVoter then the cascade conditions don't allow to check only of user is logged in making this option unusable at all.

Ideally only the selected values in the trait would be processed. Meaning that if the editor marks the checkbox for the logged user, only the logged user condition will be processed.

Suggestions:

  • In the trait selection the options don't make much sense. It's not clear what "Registered user" should represent. Returning visitor should be added instead. Logged user and New visitor should stay.
  • The voter class should be rewritten to only process checked values. The cascade condition we are using right now doesn't allow to test the values properly in all cases (e.g. the user is always returning, this disregards the check for logged user).
  • The filter class should be reviewed. Especially the way how we handle the returning visitor setting. E.g. the user is always returning if not anonymous. That doesn't have to be true if this is the first login of the user. This part might be put in a separate protected method so developers can override it with a custom logic if needed.


 Comments   
Comment by Antonín Juran [ 15/Feb/17 ]

For RN:
The options for the Visitor trait were redesigned into radio buttons and now also include the items that were originally hidden but present logically plus the new „Any“ options:

When „Any“ is selected, the trait attribute can take the value of any two remaining options on the given line. All of the three lines with options are evaluated together with the AND operator, e.g. in figure above “Returning AND Anonymous AND Any”.

Comment by Roman Kovařík [ 17/Feb/17 ]

Reopened: https://git.magnolia-cms.com/projects/ENTERPRISE/repos/personalization/pull-requests/102/overview?commentId=13589

Comment by Antti Hietala [ 22/Feb/17 ]

I would favor ease-of-use and fewer values in the visitor trait UI. While the proposed UI allows the editor to choose any combination of values, in practice only New, Returning and LoggedIn have meaningful use cases. I would propose that we simplify the ruleField and valueField to meet Ondrej's original request, see screenshot.

Why I think these 3 values are enough:

  • New visitor. Typical personalization target. You want to offer a starter deal to new visitors in order to get them to register and make a purchase. Like "Free 30-day trial. Sign up now!"
  • Returning visitor. Also a valid audience. You may want to reward returning users with targeted content, or remind them of abandoned shopping carts, or just provide the next relevant piece content in the buyer journey. "10% off your next tour!"
  • LoggedIn visitor. Also a valid audience. You may want to display exclusive content to members. "Members only: New mountain biking tour in Spain."

Technically possible values but very rare. I would leave these out:

  • New AND Registered visitor. Theoretically possible but a rare target for personalization. This would be a new visitor who just registered but has not logged in yet. It's a very short time frame typically. What content would you target to this segment?
  • New AND LoggedIn visitor. Also rare. This would be a new visitor who just registered and logged in during their first session on the site. The fact that they are a New visitor is no longer meaningful because the user has already graduated to the next level: they are now LoggedIn which makes them a lead. You have their name and email address. Now they are target for the same content as you would serve to other LoggedIn users. Inbound marketing model: Strangers -> Visitors -> Leads (they are now here) -> Customers -> Promoters
  • Returning AND LoggedIn visitor. The fact they are LoggedIn is more valuable than the fact they are Returning.
  • Returning AND Registered visitor. Possible. You might want to show different content to Returning-Registered visitors. Amazon uses this segment to greet you with "John's Amazon" and "Your recently viewed items" but Amazon doesn't show "Your recent orders" until you log in (see segment above). So this is a borderline valid target but I would still leave it out of the default value set just for the sake of simplicity.
Comment by Roman Kovařík [ 22/Feb/17 ]

This wouldn't be compatible with the current impl and it wouldn't be possible to migrate without losing the current behaviour.
The only possibility to solve this problem is to don't migrate (leave the old behaviour on the already installed instances) and change the trait only for clean installations. Is that an acceptable solution?

Comment by Antti Hietala [ 22/Feb/17 ]

Splitting the behavior between existing and new installations is unfortunately not an option. It's not something we typically would do. We'd have to at some point merge the behaviors or maintain two branches forever.

Proposal: Let's merge multiselect choices to single-select like this:

Checkbox (old) Radio (new)
New New
Registered [+ New] Returning
Logged in [+ Registered] [+ New] Logged in

Example: Registered to Returning

Before the upgrade, an editor targets content to Registered visitors. She checks the Registered checkbox and Magnolia stores her choice as registered=true in the voter.

In the upgrade we migrate the stored property to value=returning (This is how SimpleTraitValueTransformer used with option group field would store the value. Just an example, possibility.)

After the upgrade the variant still behaves as expected since a registered user is by definition a returning user. Personally unidentifiable content such as "Welcome back" is shown to the visitor and that's OK. Exclusive members-only content is not served because it should only be served to logged-in visitors. When the editor opens the Choose audience dialog she sees that her previous choice has been mapped to a new choice. The Returning radio button is now selected.

Comment by Antonín Juran [ 23/Feb/17 ]

ahietala We have cookie form processor and registered user detector. This functionality will be lost after transformation of registered user to returning user.

Comment by Antti Hietala [ 27/Feb/17 ]

ajuran, I would prefer to keep (not deprecate) the cookie form processor and registered user detector. If a client wants to add the Registered option (radio button) in the UI himself, the underlying functionality should be ready to process the option.

Comment by Milan Divilek [ 08/Mar/17 ]

This should not depend on variants order, but exact priority should be defined.
Right now if variant logged is ordered behind variant returning then variant logged won't be served in any case.

Generated at Mon Feb 12 06:36:48 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.