How to determine whether a catalog component has been trigged by the Targeting & Relevance module

33 views
Skip to first unread message

Jeffrey Houben

unread,
Jul 6, 2015, 8:10:12 AM7/6/15
to hippo-c...@googlegroups.com
Hi,

We were wondering if there is a method to determine whether a catalog component has been triggered by the Targeting & Relevance module and if so, which Persona and/or Target Group was responsible for the trigger.

So we actually want to be able to have access to this information from inside the catalog component and then be able to put this information (Persona, Target Group, Component, etc.) on the request for use on our templates.

Is this possible without having to rebuild/overwrite too much. We want to ensure that no targeting filter logic is overwritten by custom code to prevent anything from failing in case a new version is released.

Thanks for any pointers and/or tips.

Ard Schrijvers

unread,
Jul 6, 2015, 8:36:17 AM7/6/15
to hippo-c...@googlegroups.com
Hey Jeffrey,

from code, you can access the profile for the current visitor via
com.onehippo.cms7.targeting.ProfileProvider#get . From 10.0 and higher
the previous method is deprecate (still works), you should use
TargetingStateProvider.get().getProfile(), also see [1] and [2]. From
TargetingStateProvider.get() you also get access to the
RequestLogEntry, Visitor and Explanation next to the TargetingProfile

Does this help or do you need to access more info?

Regards Ard

[1] http://www.onehippo.org/library/enterprise/enterprise-features/targeting/using-the-targeting-profile.html
[2] http://www.onehippo.org/7_9/library/enterprise/enterprise-features/targeting/using-the-targeting-profile.html

Jeffrey Houben

unread,
Jul 7, 2015, 1:33:28 AM7/7/15
to hippo-c...@googlegroups.com
Rereading it, it was perhaps too vague :-).

What we would like, is the ability to know whether a catalog component that has been set with a Relevance rule has been triggered on a page by a Persona or a Target Group.
If we can do this then we can place this information (Persona ID/Name, Target Group ID/Name) on the request, use it on the JSP template to pass it on or to set variables for analytics purposes (usually through Javascript).

Since we already have onclick events hooked to these components, we can then actually see how many times a catalog component bas been triggered and then also how many times it has actually been used.

Since there can be multiple of these catalog components on a single page, where some of them have and some of them dont have Relevance rules set, it is imperative that we can track these individually whether and how often these have been triggered.


Op maandag 6 juli 2015 14:36:17 UTC+2 schreef a.schrijvers:

Ard Schrijvers

unread,
Jul 7, 2015, 6:57:48 AM7/7/15
to hippo-c...@googlegroups.com
Hey Jeffrey,

On Tue, Jul 7, 2015 at 7:33 AM, Jeffrey Houben
<jeffrey...@randstadgroep.nl> wrote:
> Rereading it, it was perhaps too vague :-).
>
> What we would like, is the ability to know whether a catalog component that
> has been set with a Relevance rule has been triggered on a page by a Persona
> or a Target Group.
> If we can do this then we can place this information (Persona ID/Name,
> Target Group ID/Name) on the request, use it on the JSP template to pass it
> on or to set variables for analytics purposes (usually through Javascript).
>
> Since we already have onclick events hooked to these components, we can then
> actually see how many times a catalog component bas been triggered and then
> also how many times it has actually been used.
>
> Since there can be multiple of these catalog components on a single page,
> where some of them have and some of them dont have Relevance rules set, it
> is imperative that we can track these individually whether and how often
> these have been triggered.

I understand what you are after. Unfortunately, in the 7.9.x it is
very hard what you want. Perhaps with a severe hack you could achieve
it. In the 10.0 you get it almost for free:

TargetingState state = TargetingStateProvider.get();
TargetingProfile profile = state.getProfile();
// map of all non default variants where the keys are the component Ids
Map<String, String> selectedVariants = profile.getSelectedVariants();

I think supporting what you require can be done in the 7.9.x
(similarly as above) as well but does require some 7.9.x work for
engineering. If required, best to contact Hippo support

Regards Ard

>
>
> Op maandag 6 juli 2015 14:36:17 UTC+2 schreef a.schrijvers:
>>
>> Hey Jeffrey,
>>
>> from code, you can access the profile for the current visitor via
>> com.onehippo.cms7.targeting.ProfileProvider#get . From 10.0 and higher
>> the previous method is deprecate (still works), you should use
>> TargetingStateProvider.get().getProfile(), also see [1] and [2]. From
>> TargetingStateProvider.get() you also get access to the
>> RequestLogEntry, Visitor and Explanation next to the TargetingProfile
>>
>> Does this help or do you need to access more info?
>>
>> Regards Ard
>>
>> [1]
>> http://www.onehippo.org/library/enterprise/enterprise-features/targeting/using-the-targeting-profile.html
>> [2]
>> http://www.onehippo.org/7_9/library/enterprise/enterprise-features/targeting/using-the-targeting-profile.html
>
>
> The information contained in this e-mail communication is solely intended
> for the person/legal person to whom it has been sent, and as it may contain
> information of a personal or confidential nature, it may not be made public
> by virtue of law, regulations or agreement. If someone other than the
> intended recipient should receive or come into possession of this e-mail
> communication, he/she will not be entitled to read, disseminate, disclose or
> duplicate it. If you are not the intended recipient, you are requested to
> inform the sender of this e-mail message of this immediately, and to destroy
> the original e-mail communication. Neither Randstad Holding nv nor its
> subsidiaries accept any liability for incorrect and incomplete transmission
> or delayed receipt of this e-mail.
>
> --
> Hippo Community Group: The place for all discussions and announcements about
> Hippo CMS (and HST, repository etc. etc.)
>
> To post to this group, send email to hippo-c...@googlegroups.com
> RSS:
> https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
> ---
> You received this message because you are subscribed to the Google Groups
> "Hippo Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hippo-communi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/hippo-community.
> For more options, visit https://groups.google.com/d/optout.



--
Hippo Netherlands, Oosteinde 11, 1017 WT Amsterdam, Netherlands
Hippo USA, Inc.- 745 Atlantic Ave, Eight Floor, Boston MA 02111,
United states of America.

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com

Jeffrey Houben

unread,
Jul 10, 2015, 1:05:29 AM7/10/15
to hippo-c...@googlegroups.com
Hi Ard,

Thanks. Discussed it internally and we will wait for the Hippo 10 upgrade which we have planned for Q3 this year.

Op maandag 6 juli 2015 14:10:12 UTC+2 schreef Jeffrey Houben:

Ard Schrijvers

unread,
Jul 10, 2015, 4:01:41 AM7/10/15
to hippo-c...@googlegroups.com
Hey Jeffrey,

On Fri, Jul 10, 2015 at 7:05 AM, Jeffrey Houben
<jeffrey...@randstadgroep.nl> wrote:
> Hi Ard,
>
> Thanks. Discussed it internally and we will wait for the Hippo 10 upgrade
> which we have planned for Q3 this year.

Yes, I think that is the most solid approach. If you think of more
requirements that you have that are currently not possible, I'd love
to hear them because we can after GA still improve some parts. Or if
you have ideas for better developer feedback about what is going on in
the relevance engine, pls let us know

Regards Ard

>
> Op maandag 6 juli 2015 14:10:12 UTC+2 schreef Jeffrey Houben:
>>
>> Hi,
>>
>> We were wondering if there is a method to determine whether a catalog
>> component has been triggered by the Targeting & Relevance module and if so,
>> which Persona and/or Target Group was responsible for the trigger.
>>
>> So we actually want to be able to have access to this information from
>> inside the catalog component and then be able to put this information
>> (Persona, Target Group, Component, etc.) on the request for use on our
>> templates.
>>
>> Is this possible without having to rebuild/overwrite too much. We want to
>> ensure that no targeting filter logic is overwritten by custom code to
>> prevent anything from failing in case a new version is released.
>>
>> Thanks for any pointers and/or tips.
>>
>
Reply all
Reply to author
Forward
0 new messages