Open gnuletik opened 7 years ago
Hello Arnaud, J'ai déployé un prototype de la configuration du CTA. Le site Cloudcannon est ici : https://app.cloudcannon.com/editor#/site/24608/update/dyngrid/index/ && https://helpful-ship.cloudvent.net/dyngrid/index/ J'attends ta validation du premier prototype. Notamment au niveau du frontmatter, histoire de partir dés le début sur de bonnes bases pour éviter de devoir changer la structure en fin de projet ce qui provoque des erreurs. Merci !
Je commence à regarder. C'est un peu trop générique selon moi et donc compliqué à utiliser.
On ne doit pas pouvoir choisir son module. On a une array CTA, une array formulaire, une array header (= image), mais bien distinct.
Les segments sont déclarés par nous dans le config.yml car nous devrons implémenter woopra. Je préfère qu'on garde la main. Ensuite, l'utilisateur peut choisir son segment dans une liste déroulante (voir multiselect) pour déclarer sa configuration.
Idem, iraiser_cid: 53 / iraiser_url: 'don.spa.asso.fr' / woopra_interaction: 'don-IMG_ete2015' partent dans le config HTML. POur l'interaction je pense qu'il faut plutôt définir une norme. Je vois pas trop comment c'est utilisé aujourd'hui, mais l'idée est d'avoir un même modèle pour tout les clients. Au passage, ce qui serait intéressant, c'est de traquer le nombre d'affichage d'une version de personnalisation. Aujourd'hui, on l'a pas et c'est compliqué de suivre vraiment les stats.
Ci-joint le frontmatter revu fm.txt
J'ai mis en place le nouveau frontmatter.
Concernant les valeurs iraiser_cid
, iraiser_url
et woopra_interaction
je les ai mise dans le _config.yml
. Cependant, je comptais les mettre dans la page ET _config.yml
pour mettre en place le principe d'héritage demandé ici.
Est-ce que c'est le principe d'héritage est à mettre en place pour ces variables du coup ?
J'ai mis en place les segments dans le fichier _config.yml
. C'est donc configurable par nous du coup.
Concernant l’interaction, elle est utilisée comme lors du dernier événement de cet utilisateur Woopra.
Ça définit donc la catégorie de l’évènement Woopra avec ce schéma : [woopra_interaction] + une valeur en dur
(ici CTA
).
Dis moi donc ce que tu veux pour les interactions. On peut effectivement générer un nom pour tous les clients.
iraiser_cid --> oui principe d'héritage iraiser_url --> pas de principe d'héritage woopra_interaction --> il faudrait avoir quelque part la trace du nom de la LP sur laquelle l'interraction a eu lieu, mais on catche peut-être en l'état l'url.
"Au passage, ce qui serait intéressant, c'est de traquer le nombre d'affichage d'une version de personnalisation. Aujourd'hui, on l'a pas et c'est compliqué de suivre vraiment les stats." Tu as compris ca car en me relisant, je vois que c'est pas clair.
En gros, sur une même url, des gens vont voir des version de header différent selon leur segment. Ca peut paraitre débile, mais il faudrait tracer ce qu'il voit avec un évènement spécifique, afin d'être plus à l'aise dans les stats et aussi contrôler qu'il n'y a pas d'erreur. l'évènement pourrait s'appeler "personalisation" et on stockerait dans le modèle :
Pour woopra_interaction
, j'ai préfxé la valeur de l'URL.
Pour pouvoir récupérer des stats sur les versions de personnalisation à l'aide d’éventement Woopra, je vais le mettre en place sur la lib de personnaisation de header. J'ouvre une issue spécifique pour ne pas mélanger avec le module CTA.
J'attends donc la validation du frontmatter de ce module pour passer aux autres modules.
Les variables à configurer pour CTA sont :