Avec l'arrivée du nouveau Dashboard, nous en avons profité pour également refondre le script Poool, celui qui se cache dans le code de vos pages et grâce à qui toute la magie opère ✨

Dans cet article, nous vous expliquons tout sur l'ancien et les nouveaux scripts. Eh oui, ils sont 2 👶

Démarrons par une petite définition...

poool.min.js (le script Poool initial) a été imaginé à l’époque pour répondre à un besoin précis : afficher un wall sur un site média, bloquant ainsi l'accès au contenu et le débloquant si le lecteur s'abonnait ou effectuait une action alternative (inscription à une newsletter, visionnage d'une vidéo pub etc.)

À l’époque, les sites étaient construits avec des technologies basées sur le rechargement de la page à chaque changement de page.

Aujourd'hui nous avons accès à des technologies qui permettent d'effectuer énormément d'actions sur une page (voire de changer de page) sans que cela n'entraîne un rechargement.

Par exemple, les sites utilisant le langage React fonctionnent comme cela : il existe 1 page concrètement, tout le reste n'est qu'un ensemble d'animations. Il n'y a pas de rechargement de la page. Pour l'utilisateur, c'est totalement transparent.

Également, à l'époque, il n'y avait pas forcément d'équipe technique à disposition, il revenait aux équipes marketing elles-mêmes d'intégrer les scripts à exécuter (dont celui de Poool) dans Google Tag Manager (GTM).

Le script Poool a donc été construit de manière à ressembler à ce que les équipes qui allaient l’intégrer avaient l’habitude d’utiliser, i.e un script comme celui de Google Analytics.

Pour résumer simplement, poool.min.js a été fait à la base pour être exécuté sur une page, puis ignoré, puis rechargé après la prochaine navigation. Donc, une fois affiché, le wall ne peut pas ré-apparaître sans rechargement de la page.

Découlant de ce premier constat, pour des sites développés avec des technologies fonctionnant sans rechargement de page entre deux actions (par exemple en React), il a fallu trouver un fonctionnement spécifique pour qu'Access fonctionne.

Également, il est impossible d’afficher deux walls dans la même page sans avoir des conflits entre les walls.

Enfin, l'utilisation d'un seul script fait qu'on ne peut pas séparer ce qui concerne le wall spécifiquement et ce qui concerne le reste des interactions, comme le tracking des visites, conversions ou la segmentation native.

Par exemple, si vous ne souhaitiez pas avoir recours à la segmentation native, vous étiez quand même obligé de tracker l’ensemble des interactions du lecteur avec le site (visites, conversions...)

La solution travaillée par notre équipe technique a été de séparer le script Poool en 2 scripts : Audit et Access.

Pour le bon fonctionnement de notre produit, nous ne pouvions pas arrêter de tracker ce qui se passe dans le wall. En revanche, il est parfaitement possible de se passer de différentes données extérieures au wall.

Ainsi, le script Access est obligatoire pour l'affichage des walls et le script Audit est optionnel. Il faudra intégrer 1 script Access pour chaque wall souhaité sur la page.

Comme vous pouvez le voir, les deux scripts permettent de tracker des éléments différents.

Intégration Audit + Access

Dans le cas où Audit et Access sont utilisés ensemble, tout le tracking (page et wall) passera par Audit.

Intégration Access uniquement

Access trackera uniquement les données liées au wall, vous n'aurez donc pas accès à la segmentation native par exemple.

Intégration Audit uniquement

Dans le cas particulier où vous souhaiteriez tracker les conversions, vous devrez intégrer le script Audit seul sur la page où s’effectue la conversion.

L'intégration des scripts Poool sera réalisée par votre équipe technique. Toute la documentation technique est disponible 👉 ici

Intégration Audit + Access

L'équipe technique intègrera le script Audit puis le ou les scripts Access nécessaires à l'affichage du ou des walls souhaité(s).

Dans cet exemple, nous avons intégré le script Audit ainsi que 2 scripts Access pour afficher deux walls à différents endroits de la page : 1 wall par-dessus tout le contenu et 1 wall sous l'article.

Intégration Access uniquement

Si vous ne souhaitez pas avoir accès à la segmentation native, les conversion etc., votre équipe technique pourra intégrer seulement le ou les scripts Access nécessaires à l'affichage du ou des walls souhaité(s).

Dans cet exemple, nous avons intégré uniquement 1 script Access pour afficher 1 wall sur la page.

Intégration Audit + Access

Rien ne change

Intégration Access uniquement

Vous aurez accès au Contexte par défaut et vous pourrez paramétrer des Contextes et des groupes personnalisés.

En revanche, vous n'aurez accès qu'au groupe "Tous les utilisateurs" car sans le script Audit, vous ne pouvez pas accéder à la segmentation native (donc aux groupes natifs Volatiles, Occasionnels etc.)

La création des scénarios

Que vous utilisiez l'une ou l'autre intégration, la façon de créer des scénarios ne change pas.

En revanche, grâce au nouveau script Access, une petite nouveauté s'est glissée dans les paramètres des widgets.

Il s'agit du champ "Elément parent cible dans la page (sélecteur css)" qui vous permet de renseigner le sélecteur CSS de "l'endroit" où vous souhaitez afficher votre wall dans votre page.

Pour comprendre ce concept, n'hésitez pas à consulter notre article Comment mettre un wall par-dessus mon contenu ?

Selon ce que vous avez configuré, le lecteur verra 1 ou plusieurs walls sur la page.

Chaque wall sera chargé de manière asynchrone pour ne pas ralentir la page.

Rassurez-vous, si vous aviez précédemment intégré Poool, vous n'avez strictement rien à changer.

En effet, le script initial a été entièrement réécrit pour utiliser Audit + Access implicitement, afin de garantir une transition transparente et surtout pour vous éviter d'avoir à refaire une intégration.

Votre intégration actuelle n'est donc pas impactée par ces changements.