Dans certains cas, un site peut faire appel à des marques blanches, ou en proposer. L’intégration technique de tels éléments se fait le plus souvent en Iframe. Cette balise permet d’importer dans sa page web, une autre page, dont à l’affichage, il n’est quasiment pas possible d’en détecter l’origine distante.
Par exemple, un module de recrutement externe peut être ajouté à une page web, en étant intégré dans le template général du site. L’affichage de la page ne permettra pas, sans en lire le code source, de constater l’import d’un fichier distant.
Seulement, lors d’une configuration Analytics, les informations relatives à l’utilisation d’une telle marque blanche, ne sont souvent pas prises en compte, soit en raison d’un autre domaine (importation d’Iframe), soit parce que le module est partagé entre plusieurs comptes (exportation).
Pourtant, les interactions des utilisateurs sur de telles Iframe sont très souvent importantes pour la rentabilité d’un site Internet. Dans l’hypothèse d’un module de recrutement, géré en Iframe par une société distante, il est important de pouvoir remonter et analyser les réponses aux offres proposées.
Cela d’autant plus, si l’on utilise le marketing pour accroitre la rentabilité du service proposé au sein de l’Iframe. La page étant en dehors du domaine du site, où se trouve la configuration Analytics, seules les interactions avec le site (le template de la page, finalement), seront prises en compte dans l’analyse, ce qui n’apporte absolument aucune information pertinente.
Bien évidemment, pour pouvoir tracer le contenu de l’Iframe et remonter les informations essentielles, il faut pouvoir accéder au code source de cette Iframe. Si l’éditeur du code ne permet aucune modification par le client, du contenu embarqué, l’opération ne pourra se réaliser.
Dans le cas où l’éditeur met à disposition, de clients, une Iframe et cherche à en tracer l’utilisation, étant propriétaire de son code, il pourra effectivement le faire.
Si l’éditeur accepte d’importer un conteneur, il suffit alors de déclarer le domaine de l’Iframe dans le code Analytics, en cross-domain (s’il est différent de celui du site) pour programmer les évènements, objectifs et/ou commerce électronique.
Seulement, tout le travail de programmation devra se faire au sein même de l’Iframe et non sur le template qui l’appelle. Les déclencheurs basés sur les urls, le seront d’après celles de l’Iframe.
En ajoutant un champ dans le datalayer permettant d’identifier l’origine de l’interaction, entre l’iframe et le site, il sera possible de filtrer, segmenter.
L’utilisation de fichiers distants sur un site Internet n’est donc pas un problème, tant que le code source est accessible et qu’il permet d’embarquer le conteneur d’un TMS. Bien que les éléments à tracer soient imbriqués dans un autre site, le cross-domain offre la possibilité de lier les dimensions analytiques entre-elles et mesurer l’ensemble des interactions.
Les modules dynamiques distants, qui participent à l’activité du site, ne posent donc aucun problème particulier, pour être intégrés.
Or, s’il est possible de placer un conteneur sur une Iframe, de tracer chaque interaction pour Analytics, rien n’empêche l’utilisation de tags médias et donc la mesure fine et précise de la rentabilité des opérations marketings liées aux services proposés dans un tel module.
Ainsi, utiliser une Iframe, sur son site Internet, dès lors qu’ils sont possible d’en modifier le code source, offre exactement les mêmes avantages qu’un site Internet, pour la programmation de comptes Analytics et media.
Dans certains cas, un site peut faire appel à des marques blanches, ou en proposer. L’intégration technique de tels éléments se fait le plus souvent en Iframe. Cette balise permet d’importer dans sa page web, une autre page, dont à l’affichage, il n’est quasiment pas possible d’en détecter l’origine distante.
Par exemple, un module de recrutement externe peut être ajouté à une page web, en étant intégré dans le template général du site. L’affichage de la page ne permettra pas, sans en lire le code source, de constater l’import d’un fichier distant.
Seulement, lors d’une configuration Analytics, les informations relatives à l’utilisation d’une telle marque blanche, ne sont souvent pas prises en compte, soit en raison d’un autre domaine (importation d’Iframe), soit parce que le module est partagé entre plusieurs comptes (exportation).
Pourtant, les interactions des utilisateurs sur de telles Iframe sont très souvent importantes pour la rentabilité d’un site Internet. Dans l’hypothèse d’un module de recrutement, géré en Iframe par une société distante, il est important de pouvoir remonter et analyser les réponses aux offres proposées.
Cela d’autant plus, si l’on utilise le marketing pour accroitre la rentabilité du service proposé au sein de l’Iframe. La page étant en dehors du domaine du site, où se trouve la configuration Analytics, seules les interactions avec le site (le template de la page, finalement), seront prises en compte dans l’analyse, ce qui n’apporte absolument aucune information pertinente.
Bien évidemment, pour pouvoir tracer le contenu de l’Iframe et remonter les informations essentielles, il faut pouvoir accéder au code source de cette Iframe. Si l’éditeur du code ne permet aucune modification par le client, du contenu embarqué, l’opération ne pourra se réaliser.
Dans le cas où l’éditeur met à disposition, de clients, une Iframe et cherche à en tracer l’utilisation, étant propriétaire de son code, il pourra effectivement le faire.
Si l’éditeur accepte d’importer un conteneur, il suffit alors de déclarer le domaine de l’Iframe dans le code Analytics, en cross-domain (s’il est différent de celui du site) pour programmer les évènements, objectifs et/ou commerce électronique.
Seulement, tout le travail de programmation devra se faire au sein même de l’Iframe et non sur le template qui l’appelle. Les déclencheurs basés sur les urls, le seront d’après celles de l’Iframe.
En ajoutant un champ dans le datalayer permettant d’identifier l’origine de l’interaction, entre l’iframe et le site, il sera possible de filtrer, segmenter.
L’utilisation de fichiers distants sur un site Internet n’est donc pas un problème, tant que le code source est accessible et qu’il permet d’embarquer le conteneur d’un TMS. Bien que les éléments à tracer soient imbriqués dans un autre site, le cross-domain offre la possibilité de lier les dimensions analytiques entre-elles et mesurer l’ensemble des interactions.
Les modules dynamiques distants, qui participent à l’activité du site, ne posent donc aucun problème particulier, pour être intégrés.
Or, s’il est possible de placer un conteneur sur une Iframe, de tracer chaque interaction pour Analytics, rien n’empêche l’utilisation de tags médias et donc la mesure fine et précise de la rentabilité des opérations marketings liées aux services proposés dans un tel module.
Ainsi, utiliser une Iframe, sur son site Internet, dès lors qu’ils sont possible d’en modifier le code source, offre exactement les mêmes avantages qu’un site Internet, pour la programmation de comptes Analytics et media.