Module #7: Le ciblage de contenu

Module #7: Le ciblage de contenu



Bien qu’il soit avant tout destiné à de grosses organisations, le ciblage de contenu est une fonctionnalité régulièrement demandée dans les portails d’entreprise. Le principe est simple : plutôt que de diffuser une grande quantité d’information brute dans le portail et laisser le soin à l’utilisateur de faire le tri parmi elles ultérieurement selon leur pertinence, le ciblage de contenu permet d’emblée de fournir la bonne information à la bonne catégorie de personne selon ses caractéristiques.

Rôles concernés et responsabilités

Voici les besoins que nous allons traiter dans ce module :

Qui?

Quoi?

Notion(s) clé(s)

Contributeur

[TARGET_01] Créer du contenu ciblé

  • Métadonnées gérées
  • Récepteur d’événements

Utilisateur

[TARGET_02] Voir du contenu adapté à mon profil

  • Opérateur KQL « | »
  • Variable de recherche {User.xxx}
  • Source de résultats de recherche
  • Travail du minuteur
  • Propriétés de profils utilisateurs

Pourquoi cibler?

Prenons un exemple concret : imaginez que votre entreprise possède des bureaux partout dans le monde et que vous devez réaliser un seul et même intranet pour toute la compagnie. Difficile alors de prévoir les informations à afficher en page d’accueil selon que l’utilisateur se connecte depuis Montréal, ou bien Paris. Pour résoudre cette problématique, plusieurs approches s’offrent à vous :

Scenario #1: Le « one size fits all »

Vous diffusez des informations en restant au niveau global de l’entreprise.

Avantages

Inconvénients

  • Facilité de mise en œuvre car l’information est contrôlée et normalisée selon le plus haut facteur commun.
  • Tout le monde voit la même chose ni plus ni moins.
  • Risque de mettre en place un outil trop général  pour l’utilisateur dans son quotidien et donc ne pas rencontrer beaucoup d’adhésion.

Scenario #2 : Le ciblage structurel et/ou par métadonnées

Pour orienter les utilisateurs, vous découpez la navigation de votre intranet en sections pour chacune des zones géographiques et vous segmentez votre page d’accueil en zones distinctes. De même vous ajoutez des métadonnées sur vos contenus (pages, nouvelles) correspondant à l’audience à laquelle ils sont destinés (entreprise globale, tel ou tel continent, ville, etc.) permettant ainsi à l’utilisateur de s’y retrouver.

Avantages

Inconvénients

  • Le contenu est ciblé pour un coût assez faible.
  • Risque d’alourdir considérablement la navigation et l’expérience utilisateur dans l’intranet pour la recherche d’informations. Dans notre exemple, on ne parle que d’une distinction géographique. Imaginez avec d’autres critères, le nombre de combinaisons et de ramifications possibles dans la structure de l’intranet. Un beau casse-tête en perspective.
  • Risque d’isoler les utilisateurs dans des silos les faisant potentiellement passer à côté d’informations pertinentes.
  • Votre intranet devient très dépendant de la recherche car obligeant l’utilisateur à systématiquement « creuser » dans le portail pour obtenir la bonne information en filtrant selon les bonnes métadonnées.

Scénario #3 : L’adaptation de contenu

Vous proposez du contenu adapté pour chacune des zones géographiques dans le même cadre commun. Concrètement, les informations affichées sur la page d’accueil et les autres pages du portail diffèrent pour chaque utilisateur selon son emplacement géographique (et par extension d’autres critères pertinents). Cependant, l’expérience de navigation est la même pour tout le monde.

Avantages

Inconvénients

  • Décloisonner l’information dans le portail en fournissant un cadre commun à tous les utilisateurs mais avec du contenu adapté.
  • Faire gagner du temps aux utilisateurs. En général, ceux-ci ne passent pas leur vie dans l’intranet. Si l’on parvient par défaut à fournir la bonne information aux bonnes personnes, c’est autant de temps gagné pour qu’ils puissent faire autre chose que de chercher dans le portail.
  • Coût de mise en place et de maintenance plus élevé (gouvernance au niveau du ciblage).

Dans ce cas d’étude, nous allons aborder ce dernier scénario. Pour celui-ci, il existe deux cas de figures que l’on peut rencontrer dans un portail intranet :

  • Un contenu différent pour une URL unique

Par exemple, une politique de vacances avec l’URL http://monintranet/rh/politique-de-vacances renverra un contenu différent selon que l’utilisateur se trouve à Montréal ou à Paris.

  • Un ensemble de contenus affichés dans un même composant

Par exemple la recherche globale du portail, ou le Web Part de nouvelles en page d’accueil renverront des résultats différents.

Le ciblage de contenu ≠ sécurité

Il est important de distinguer la notion de sécurité et de ciblage dans un intranet. La sécurité permet de s’assurer techniquement qu’un contenu ne soit visible seulement que par les personnes autorisées alors que le ciblage s’attache lui, à optimiser la diffusion de l’information dans le portail. Par conséquent, une information ciblée ne signifie pas nécessairement que celle-ci est confidentielle mais seulement qu’elle est davantage pertinente pour une catégorie de personnes spécifique qui doivent la voir en priorité. Pour faire le parallèle, il s’agit du même principe que les publicités que vous recevez sur internet basée sur vos habitudes de navigation. Notez tout de même qu’il est tout à fait possible de mixer les deux principes ensembles.

Le ciblage de contenu dans SharePoint

Outre les mécanismes de sécurité classique, il existe plusieurs moyens de cibler du contenu dans SharePoint (tel qu’on l’entend dans le scénario #3).

Les audiences

Disponibles dans les versions 2007, 2010 et 2013, les audiences représentent des sous-ensembles de personnes ayant des caractéristiques communes. Il ne s’agit pas ici de permissions mais plutôt de regroupements sous une ou plusieurs caractéristiques partagées. Elles se basent sur les profils utilisateurs de SharePoint, eux-mêmes pouvant potentiellement être basés sur des groupes Active Directory.

Les audiences peuvent s’appliquer à :

  • Des Web Parts pour adapter l’affichage du site selon les profils d’utilisateurs.
  • Des liens de navigation.
  • Des éléments de listes ou bibliothèques.

Concernant ce dernier point, la visualisation des données selon une audience spécifique ne peut se faire qu’uniquement à travers le composant de requête de contenu qui possède une logique interne permettant de détecter si la personne actuellement authentifiée fait partie de l’audience ou non :

Ciblage de contenu avec les audiences (avec GUID)

Ciblage de contenu avec les audiences (avec GUID)

L’avantage des audiences est qu’elles sont faciles à mettre en place. En revanche, l’inconvénient majeur est qu’elles ne peuvent être utilisées qu’avec le Web Part de requête de contenu (et donc en langage CAML). Il n’est en effet pas possible d’utiliser les audiences avec le langage de recherche (KQL ou autre) et ceci, quelle que soit la version, ce qui dans le cas de la publication intersites n’est pas envisageable.

Les segments utilisateurs

Les segments utilisateurs sont apparus avec SharePoint 2013 et fonctionnent eux uniquement avec la recherche. En revanche, pour les utiliser, il est obligatoire de passer par du développement personnalisé. Celui-ci consiste à dériver un Web Part de recherche de contenu chargé de faire correspondre une information externe (par exemple la version du navigateur courant de l’utilisateur, etc.) à un terme de taxonomie :

Principe des segments utilisateurs

Principe des segments utilisateurs

Correspondance avec des valeurs de taxonomie

Correspondance avec des valeurs de taxonomie

Le terme est ensuite utilisé à travers des règles de requêtes pour adapter le résultat en fonction de cette correspondance :

Utilisation des segments utilisateur avec des règles de requêtes

Utilisation des segments utilisateur avec des règles de requêtes

Bien qu’ils fonctionnent avec la recherche, les segments utilisateurs sont mal adaptés pour faire du ciblage par inclusion via une hiérarchie de termes (par exemple savoir si la ville de l’utilisateur actuel fait partie d’un pays particulier). C’est n’est pas impossible mais cela nécessiterait une logique plus poussée pour y arriver, chose que nous souhaitons en général éviter si d’autres alternatives sont possibles.

La recherche

Le dernier moyen pour cibler du contenu dans SharePoint consiste simplement à se servir des possibilités offertes par défaut par la recherche et en particulier les spécificités langage KQL.

Note : dans la suite du document, nous utiliserons le terme « audience » pour parler d’un regroupement sous une même caractéristique. Cependant, il ne s’agit pas de la fonctionnalité homonyme de SharePoint.

Stratégie de ciblage

Pour permettre de cibler du contenu à une ou plusieurs catégories de personnes, nous utilisons le mécanisme ci-dessous. L’exemple est donné pour un critère de ciblage « zone géographique » (le principe étant identique pour d’autres critères).

Principe de ciblage de contenu avec la recherche SharePoint

Principe de ciblage de contenu avec la recherche SharePoint

Explications :

  1. Chaque critère de ciblage est représenté sous la forme d’un ensemble de termes de taxonomie définissant une hiérarchie logique d’appartenances à des audiences.
  2. Un autre ensemble de termes est créé uniquement à partir des feuilles du premier ensemble (nœuds de dernier niveau). La raison est que ces valeurs seront accessibles par les utilisateurs via une propriété de profil publique (3) et donc que l’arbre complet ne doit pas être proposé pour éviter des valeurs non pertinentes.
  3. Une propriété « publique » est créée dans le profil des utilisateurs et configurée avec l’ensemble de termes précédent (2).
  4. Une propriété de profil privée est créée pour permettre le calcul des valeurs d’audiences implicites dont l’utilisateur fait partie.
  5. Dans un site d’auteur, une colonne de site spécifique est créée pour chaque critère de ciblage. Elle reprend les valeurs de l’ensemble de terme (1). Les contributeurs peuvent ensuite restreindre leur contenu à une ou plusieurs audiences particulières.
  6. Les contenus sont affichés à travers un Web Part de recherche. Le ciblage est réalisé grâce à l’opérateur « | » et les valeurs d’appartenances d’audiences de l’utilisateur courant (variable de recherche {User.xxx}).

Note : le détail complet étape par étape est décrit plus loin dans ce document.

L’opérateur KQL « | »

Pour permettre la récupération de contenu ciblé selon le profil de l’utilisateur courant, nous utilisons les caractéristiques de l’opérateur « | » disponible dans la syntaxe du langage KQL. La seule référence officielle sur celui-ci se trouve sur la page de présentation des variables de recherche pour SharePoint 2013. On y trouve l’explication suivante :

Description de l'opérateur « | »

Description de l’opérateur « | »

Il est mentionné que l’opérateur « | » est particulièrement adapté pour manipuler des valeurs de taxonomie à valeurs multiples via une requête de recherche.

Exemple :

Admettons que la valeur d’une propriété XXX-AllLocations dans le profil de l’utilisateur ait pour valeur :

ProfilValue

La requête :

KQLQuery

Sera équivalente à :

KQLQueryTrans

L’opérateur « | » devient donc tout indiqué pour trouver des correspondances entre des valeurs de taxonomie de contenu et celles des propriétés des utilisateurs sans avoir à écrire une multitude de condition « OU ».

Gestion de la proximité

La stratégie de ciblage vue plus haut permet uniquement de filtrer les contenus selon les audiences auxquelles appartient l’utilisateur. Cependant, si plusieurs éléments sont retournés dans les résultats de la requête, comment savoir lequel est le plus pertinent, c’est-à-dire le plus « proche » de l’utilisateur ?

Exemple

 Un utilisateur a indiqué la valeur « Montréal » comme étant son emplacement géographique dans sa page de profil.

 Un contributeur créé deux nouvelles, une avec comme audience « Canada » et l’autre « Montréal ».

Selon, le principe de ciblage vu plus haut, lorsque l’utilisateur consultera toute la liste de toutes les nouvelles, il devrait voir les deux éléments car il fait partie des deux audiences. Cependant, comment faire en sorte que la nouvelle ciblée « Montréal » soit systématiquement en premier dans les résultats car étant plus proche de son emplacement ?

Pour régler ce problème, nous introduisons la notion de poids de proximité sous la forme d’une métadonnée au niveau des contenus puis faisons un tri descendant sur celle-ci dans la requête de recherche.

Explications

  • Lors de la création d’un contenu, nous calculons, pour chaque terme d’audience d’un critère, sa profondeur associée dans son ensemble de termes. Ainsi pour l’exemple précédent, cela donne les résultats suivants pour les deux nouvelles :
Principe du poids de proximité

Principe du poids de proximité

  • Valeur de poids de proximité pour la nouvelle marquée « Canada » : 2
  • Valeur de poids de proximité  pour la nouvelle marquée «  Montréal » : 4

Plus la valeur est élevée, plus elle est « proche » de l’utilisateur car pour rappel, celui-ci ne peut choisir que les termes de dernier niveau dans sa propriété de profil publique.

  • La requête de recherche de ciblage est tri de manière descendante pour afficher en premier les éléments ayant le plus gros poids et donc ceux le plus « proche » de l’utilisateur.
Tri descendant sur le poids de proximité

Tri descendant sur le poids de proximité

  • Cas de plusieurs critères sur un même contenu

Il peut arriver que plusieurs critères de ciblage soient cumulés pour un seul et même contenu (géographique, organisationnel, etc.). Dans ce cas, plutôt que de créer une métadonnée de poids de proximité pour chaque critère, nous n’en utilisons qu’une seule contenant la somme des poids de tous les critères cumulés :

Formula

Par ce principe, la combinaison qui possédera la valeur la plus haute, sera celle la plus proche de l’utilisateur.

Notes importantes :

  • Ce principe fonctionne bien à partir du moment où il n’existe qu’une seule valeur pour chaque critère. Cependant, dans la réalité, un ciblage avec une seule valeur est dans la plupart des cas, bien suffisant.
  • Il ne s’agit pas ici de classement précis mais bel et bien d’approximations.

[TARGET_01] Contributeur : Créer du contenu ciblé

Permets à un contributeur de préciser une audience ciblée sur un contenu selon un ou plusieurs critères de ciblage.

Les contributeurs peuvent cibler du contenu selon deux critères :

  • L’emplacement géographique du bureau de l’entreprise
  • La division dans l’organisation

#

Étape

1

Définir les critères de ciblage

2

Créer les ensembles de termes pour les critères

3

Modifier l’architecture d’information pour le support du ciblage

4

Créer le récepteur d’événements pour le calcul du poids de proximité

Critères d’acceptation

Voici les critères d’acceptation qui permettent de valider les objectifs du besoin [TARGET_01] Contributeur : Créer du contenu ciblé

#

Description

AC0

Il est possible de spécifier une ou plusieurs valeurs pour chaque critère.

AC1

Il est possible de cibler un contenu selon une combinaison de plusieurs critères.

Étape #1 : Définir les critères de ciblage

La définition des critères de ciblage est la toute première étape à réaliser pour un permettre un ciblage efficace. Un critère de ciblage représente un ensemble de valeurs discriminantes regroupées sous un même axe et permettant d’isoler des audiences particulières pour l’affichage des contenus. Dans notre cas d’étude nous avons défini les critères suivants :

  • Géographique: Indique la zone géographique concernée par l’élément. Ce critère est particulièrement utile lorsque l’entreprise dispose de bureaux à travers le monde. Il peut être ainsi pertinent d’aguiller certaines nouvelles, pages ou documents en conséquence pour ne pas « inonder » d’informations le portail.
  • Organisationnel: Indique le niveau de l’entreprise concerné par le contenu. Ce découpage peut suivre le découpage logique de l’entreprise (divisions, secteurs, entité, etc…).

Il existe bien d’autres critères possibles, tout dépend de votre contexte (corps de métier, statut du salarié, etc…). Cependant, gardez à l’esprit que plus vous définissez de critères, plus vos combinaisons seront complexes. Par expérience ne dépassez pas 4 critères au maximum au risque de mêler complétement vos contributeurs lors de la création de leur contenu. De même, par défaut, lors de la création d’un nouvel élément, spécifier l’audience la plus haute pour chaque critère, cela fera gagner du temps aux contributeurs (signifie que l’élément s’adresse à tout le monde sans distinction).

 Règle fondamentale de définition d’un critère de ciblage

 Les critères doivent impérativement être indépendants entre eux et donc permettre des combinaisons potentiellement incohérentes d’un point de vue de l’entreprise (par exemple le secteur « Recherche et Développement » en Chine même si dans la réalité, il n’existe pas). Pour mitiger ce point, on assume que les contributeurs connaissent les combinaisons possibles et qu’ils ne vont pas spécifier n’importe quoi au niveau des audiences.

Étape #2 : Créer les ensembles de termes pour chaque critère

Dans un intranet SharePoint, un critère de ciblage se traduit par un ensemble de termes de taxonomie :

Zones géographiques

Niveaux organisationnels

Étape #3 : Modifier l’architecture d’information pour le support du ciblage

La modification de l’architecture d’information dépendra à la fois des critères de ciblage que vous souhaitez appliquer et du type d’élément que vous souhaitez cibler (pages, documents, nouvelles, etc.). Dans notre cas, les pages de contenu ainsi que les nouvelles sont soumises au ciblage sur les critères géographiques et organisationnels. Par conséquent, un type de contenu dédié est donc inséré en tant que parent de ces deux sous-types.

Architecture d'information pour le support du ciblage de contenu

Architecture d’information pour le support du ciblage de contenu

Voici le détail des colonnes

Champs

Description

Type

Office Location

Métadonnée de ciblage pour la zone géographique.

Métadonnée gérée.

Configurée sur l’ensemble de termes « Locations – Targeting »

Division

Métadonnée de ciblage pour le niveau organisationnel.

Métadonnée gérée.

Configurée sur l’ensemble de termes « Divisions »

Poids de proximité

Valeur du poids de proximité cumulé pour les deux critères de ciblage.

Nombre.

Étape #4 : Créer le récepteur d’événements pour le calcul du poids de proximité

Un récepteur d’événements est attaché au type de contenu « Targetable Item » pour permettre le calcul du poids de proximité cumulé pour les critères de ciblage. Celui-ci est déclenché à chaque fois qu’un élément est créé ou modifié:

Pour déterminer la profondeur d’un terme dans son ensemble nous utilisons la méthode GetTermPathFromRootToTerm de notre Framework Dynamite, qui s’occupe de remonter les termes parents jusqu’à la racine de l’ensemble de termes. Il suffit alors de compter le nombre de termes renvoyés dans le chemin pour connaître la profondeur de celui-ci.

[TARGET_02] Utilisateur : Voir du contenu pertinent à mon profil

Permets à un utilisateur du portail de voir du contenu adapté à ses caractéristiques de profil.

Les contenus sont filtrés selon les critères de ciblage suivants :

  • L’emplacement géographique du bureau de l’utilisateur
  • Sa division dans l’entreprise

#

Étape

1

Créer les propriétés de profil utilisateur

2

Créer le travail du minuteur pour le calcul automatique des valeurs d’audiences

3

Modifier les sources de résultats de recherche

 

Critères d’acceptation

Voici les critères d’acceptation qui permettent de valider les objectifs du besoin [TARGET_01] Contributeur : Créer du contenu ciblé

#

Description

AC0

Chaque utilisateur voit les éléments adaptés selon son profil.

AC1

L’utilisateur ne peut pas modifier ses propriétés de profil.

Étape #1 : Créer les propriétés de profil utilisateur

Pour permettre une association entre les valeurs de ciblage déterminées sur les contenus de l’intranet et les caractéristiques de l’utilisateur courant, nous créons plusieurs propriétés de profils correspondant à chacun des critères de ciblage. Pour cela nous réutilisons le même ensemble de termes que pour les contenus. En effet, dans SharePoint 2013, il est possible de spécifier des propriétés de profil de type métadonnées gérées.

Configuration des propriétés de profil publiques

On nomme propriétés publiques les propriétés qui peuvent se retrouver sur le page de profil de l’utilisateur à titre informationnel (le bureau où la personne travaille ou bien sa division).

Création de propriétés de profil utilisateur pour chaque critère

Création de propriétés de profil utilisateur pour chaque critère

Note : Plutôt que de créer de nouvelles propriétés de profil pour les critères géographique et organisationnel, nous modifions les propriétés « Emplacement du bureau » (SPS-Location) « Département » (SPS-Department) disponibles par défaut dans SharePoint. La nouvelle configuration se fait de la manière suivante :

Configuration des propriétés de profil publiques (SPS-Location et SPS-Department)

Configuration des propriétés de profil publiques (SPS-Location et SPS-Department)

Il est également important de maquer la propriété comme étant indexable par le moteur de recherche de SharePoint :

Ne pas oublier l'indexation de la propriété de profil par le moteur de recherche

Ne pas oublier l’indexation de la propriété de profil par le moteur de recherche

Note : Si vous voulez créer vos propres propriétés de profil, assurez qu’elles soient à valeur unique (car cela ne fait pas de sens pour un utilisateur d’avoir deux bureaux ou deux divisions).

Configuration des propriétés de profil publiques :

Propriété

Ensemble de termes

SPS-Location

Locations-Targeting

SPS-Department

Divisions

Configuration des propriétés de profil privées pour le calcul automatique des audiences

À chaque propriété de profil de ciblage « publique », est associée une propriété privée. Celle-ci, non destinée à être affiché sur le profil,  va servir à calculer toutes les valeurs de ciblage possibles pour lesquelles l’utilisateur fait partie pour un critère donné. On détermine ainsi l’appartenance de l’utilisateur aux différentes audiences du critère pour permettre le filtrage approprié du contenu par la suite.

Explications

Si un utilisateur a comme valeur « Montréal » pour sa propriété d’emplacement du bureau, alors cela signifie implicitement qu’il fait également partie de l’audience « Québec » qui elle-même fait partie de l’audience « Canada » etc…Vous l’avez compris : le but est de déduire toutes les audiences implicites pour la valeur de la propriété publique de l’utilisateur. Par conséquent, cela nécessite donc que la valeur choisie de la propriété publique soit la plus creuse possible dans l’ensemble de termes correspondant au critère.

Création de la propriété de profil pour le calcul des valeurs d'audiences

Création de la propriété de profil pour le calcul des valeurs d’audiences

Cette propriété doit nécessairement être multi-valeurs. Par exemple, pour la valeur « Montréal » de la propriété publique du profil, la valeur de la propriété d’appartenances d’audiences sera la suivante :

Détermination des audiences implicites selon la valeur de la propriété publique du profil

Détermination des audiences implicites selon la valeur de la propriété publique du profil

Configuration des propriétés de profil privées :

Propriété

Ensemble de termes

Portal-AllLocations

Locations-Targeting

Portal-AllDivisions

Divisions

Options de spécifications des valeurs pour les propriétés publiques

Pour la définition des valeurs pour les propriétés publiques du profil de l’utilisateur, deux options s’offrent à vous :

  1. Soit laisser les administrateurs spécifier les bonnes valeurs par défaut des propriétés pour tous les utilisateurs ou mettre en place une synchronisation en provenance de votre Active directory si celui-ci possède déjà les informations.
  1. Soit permettre aux utilisateurs de remplir eux-mêmes ces propriétés via leur page de profil. Cette solution peut être utile si votre Active Directory ne contient pas ces informations et que vous souhaitez utiliser votre intranet en tant que « collecteur » de données. Dans ce cas, la synchronisation des propriétés entre SharePoint vers votre AD devra être réalisée en conséquence.

Si vous  choisissez la deuxième option, la configuration exposée dans le chapitre « Stratégie de ciblage » sera nécessaire sur les ensembles de termes (réutilisation de termes). Dans notre étude de cas nous avons choisi la première option.

Étape #2 : Créer le travail du minuteur pour le calcul automatique des audiences

Bien qu’il soit possible de le faire manuellement, le calcul des valeurs des appartenances aux audiences implicites est réalisé automatiquement grâce à un travail du minuteur SharePoint. Celui-ci est chargé de détecter périodiquement les changements faits aux propriétés de profils utilisateurs et calculer les appartenances dans la propriété de profil privée selon la hiérarchie de l’ensemble de termes et la valeur de la propriété publique.

Pour indiquer au travail du minuteur les associations entre les propriétés publiques et privées, plusieurs options techniques sont possibles :

  • Utiliser une Liste SharePoint (qui devra être accessible en tout temps par le travail du minuteur).
  • Utiliser le « Property Bag » (même remarque que le point précédent).
  • Utiliser des valeurs prédéfinies dans le code et récupérées via injection de dépendances lors de l’exécution.

Ce choix dépendra notamment du fait de la probabilité que ces valeurs changent dans le futur (ce qui est quand même très peu probable).

Voici le code simplifié exécuté par le travail du minuteur pour le calcul de valeurs d’audiences :

Notes :

  • Le travail du minuteur est exécuté sur l’application web hébergeant l’intranet.
  • Pour des raisons de performances, il est important de ne récupérer que les derniers changements faits aux profils utilisateurs concernant les valeurs des propriétés (via la classe UserProfileChangeQuery)
  • Pour déterminer les valeurs de taxonomie d’audiences en fonction de la valeur de la propriété de profil publique, nous utilisons la méthode GetTermPathFromRootToTerm de notre Framework Dynamite, qui s’occupe de remonter les termes parents jusqu’à la racine de l’ensemble de termes.

Étape #3 : Modifier les sources de résultats de recherche

La dernière étape du ciblage consiste à modifier les sources de résultats de recherche pour permettre le filtrage du contenu dans les composants Web Parts du site de publication. Voici les sources de résultats modifiées ainsi que leur nouvelle requête dans le cadre du cas d’étude :

Source de résultats

Requête de recherche

Single Target Item

Récupération d’une page de contenu sur le site de publication

Single Catalog Item

Récupération d’un élément de catalogue (nouvelle)

Catalog Category Items

Récupération de tous les éléments d’une catégorie

Résumé de la thématique

Dans ce septième module, nous avons vu comment mettre en place une stratégie de ciblage entièrement basée sur la recherche SharePoint via les besoins suivants :

  • [TARGET_01] Contributeur : Créer du contenu ciblé
  • [TARGET_02] Utilisateur : Voir du contenu pertinent à mon profil

D’un point de vue technique, nous avons :

  • Créé des critères de ciblage sous la forme d’ensembles de termes de taxonomie
  • Adapter le schéma d’information pour la prise en compte des métadonnées de ciblage.
  • Créer un récepteur d’événement pour le calcul automatique du poids de proximité.
  • Créer des propriétés de profils publiques et privées pour stocker les caractéristiques des utilisateurs.
  • Créer un travail du minuteur pour le calcul automatique des audiences de l’utilisateur.
  • Modifier les sources résultats de recherche en introduisant l’opérateur « | » et la variable de recherche {User.xxx}.

Conclusion

Bien que moins précise qu’une solution de classement détaillé, cette technique reste tout à fait viable et relativement peu coûteuse pour des besoins de ciblage modéré. Dans le prochain module (#8), nous verrons comment gérer la recherche globale dans le portail.

Restez à l’écoute!

Questions fréquemment posées

  • Comment calculer un poids de proximité si plusieurs valeurs sont autorisées pour chaque critère ?

Dans ce cas de figure, nous prenons la profondeur la haute plus parmi tous les termes spécifiés pour un critère. Cependant, cela peut fausser le calcul de proximité. Par exemple si les audiences géographiques d’un contenu sont « Amérique du Nord » et « Paris », un utilisateur basé à Montréal verra ce contenu être plus proche de lui dans les résultats car la valeur la plus haute (correspondante à « Paris ») sera utilisée pour la proximité bien que pourtant, la valeur ayant déterminée l’appartenance à l’audience possède une valeur de proximité bien plus faible.

+ There are no comments

Add yours