Comment acheter un logiciel de test A/B conforme au RGPD

Mise à jour : Convert est désormais entièrement conforme au RGPD. Vous pouvez consulter notre parcours vers la conformité au RGPD ici.

Nous nous engageons également à aider nos clients à se conformer au RGPD. Pour faciliter cela, nous fournissons à tous nos utilisateurs une copie signée de notre accord de traitement des données (DPA).

De plus, nous suivons de près les développements concernant les prochaines mises à jour du Règlement ePrivacy. Comme toujours, nous serons aussi proactifs que possible pour assurer la conformité, tant pour nous que pour nos clients.

Alerte spoiler : oubliez-le.

Il n'existe pas d'outil de test A/B conforme.

Cela signifie qu'il n'y a pas de "certificat" d'un outil de test A/B garantissant que vous éviterez ce procès de 20 millions d'euros d'une autorité européenne de protection de la vie privée. Mais ce qui est possible, c'est que vous choisissiez un outil de test conçu dans un souci de confidentialité. Celui qui ne vous causera pas de problèmes lors de l'utilisation de sa configuration par défaut.

Cet article vous aide à poser les bonnes questions sur votre fournisseur d'outils de test A/B, avant la date d'entrée en vigueur du RGPD (25 mai 2018). Je déconstruirai chaque élément important du RGPD et du prochain règlement ePrivacy (projet 15333), et vous donnerai une liste de contrôle à la fin.

(Cliquez ici pour accéder directement à la liste de contrôle)

Dans cet article…

Minimisation des données

Le principe de minimisation des données est essentiellement l'idée que, sous réserve d'exceptions limitées, une organisation ne doit traiter que les données (personnelles) dont elle a réellement besoin pour atteindre ses objectifs de traitement.

Considérant 39 du RGPD ; Art.5(1)(c)
Les données personnelles doivent être adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités pour lesquelles ces données sont traitées.

Alors, quelles sont les données minimales nécessaires pour exécuter des expériences ? Je veux dire, avez-vous besoin de collecter tous les détails de l'adresse IP, du navigateur et de l'ID de l'appareil pour obtenir les résultats de votre test A/B ? Non. Vous les collectez car l'outil peut les collecter. Avec la confidentialité au fond de votre esprit, concentrez-vous sur les éléments que vous devez collecter et ne stockez pas le reste. Ce qui est essentiel pour mener une expérience, c'est :

• Variation vue
• Objectif atteint : oui/non (sur les objectifs de revenus, le nombre de produits et les revenus)

Lorsque vous souhaitez approfondir les différents résultats par sous-segment dont vous avez besoin, par exemple :

• Sous-segment : oui/non

L'outil de test A/B n'a pas besoin de stocker une ligne de données pour chaque utilisateur final. Ce que vous devez stocker pour obtenir des informations est :

• Nombre total d'utilisateurs finaux ayant constaté une variation spécifique (total et par sous-segment)
• Nombre total d'utilisateurs finaux d'une variante ayant déclenché un objectif

Et, dans un contexte de commerce électronique :

• Les produits moyens par variation et
• La valeur moyenne des commandes par variation…

…qui peut être recalculé à chaque nouvelle commande (sans mémoriser les commandes individuelles).

Le reste des données statistiques peut être recalculé à la volée sans stocker de lignes individuelles de données d'utilisateur final. Cela permet à votre outil de test A/B de se conformer aux directives de minimisation des données et réduit considérablement le risque d'atteinte à la confidentialité et à la sécurité.

Pensez-y. Que ferait quelqu'un avec seulement les totaux d'une expérience ? S'il n'y a pas de données d'utilisateur final stockées sur votre outil de test A/B, pas même des données pseudonymes/hachées, il n'y a aucun moyen de ré-identifier les utilisateurs finaux.

Les données personnelles incluent l'adresse IP

Les données personnelles, telles que définies par le RGPD, si différentes des définitions précédentes des informations personnelles identifiables (PII). Désormais, les adresses IP, les cookies et l'ID utilisateur sont toutes des données personnelles.

Peu importe ce que vous pensez de cette définition, c'est la loi. Le 19 octobre 2016, la Cour de justice de l'Union européenne (la « CJUE ») a publié son arrêt dans l'affaire 582/14 – Patrick Breyer c. Allemagne. Elle a estimé que les adresses IP sont des données personnelles dans certaines circonstances. L'arrêt est globalement conforme aux conclusions de l'avocat général dans cette affaire, de mai 2016.

Les données à caractère personnel sont définies à l'article 2, point a), de la directive comme "toute information concernant une personne physique identifiée ou identifiable ("personne concernée"). Une personne identifiable est une personne « qui peut être identifiée, directement ou indirectement […] » (nous soulignons). Une analyse plus approfondie de la question de l'identifiabilité est fournie par le groupe de travail de l'article 29 de l'UE, dans son avis 4/2007.

Les adresses IP sont donc des données personnelles. Période. Vous pouvez choisir de les anonymiser sauf si vous recevez le consentement explicite du visiteur (ce que vous voudrez peut-être éviter). Mais même si vous le faites, ce sera toujours à la frontière du consentement et cela entraînera le risque de ré-identification.

Nous vous suggérons de ne pas stocker les adresses IP dans votre outil de test A/B, pour rester à 100 % du côté sûr de cette nouvelle loi.

Maintenant, vous pourriez vous demander… si nous ne pouvons pas stocker les adresses IP, comment gérez-vous le ciblage par pays ?

La solution la plus simple consiste à utiliser l'appel de l'utilisateur final pour appeler le script de suivi et identifier le pays. Stocker la combinaison variation/pays dans un sous-segment mais non connecté à un utilisateur. Ajoutez simplement une vue supplémentaire à ce sous-segment, de sorte qu'il soit mélangé avec les centaines d'autres dans ce segment et fondamentalement juste +1. Donc, encore une fois, aucun moyen de déconstruire l'utilisateur final individuel de la base de données.

Une note supplémentaire sur la géolocalisation est que les données de pays elles-mêmes sont trop larges, mais vos sous-segments de région, de ville ou de code postal nécessiteront le consentement de l'utilisateur final. Combiné avec d'autres éléments, il peut s'agir de sous-segments très petits (même 1 seule personne !). Là encore, vous pourriez stocker des données personnelles, et cela nécessiterait le consentement de l'utilisateur.

Cookies et données personnelles

Selon le RGPD, les cookies sont également des données personnelles. Mais tous les cookies ne sont pas créés égaux. Il est possible que certains nécessitent le consentement de l'utilisateur, tandis que d'autres non. Les détails seront déterminés par le nouveau règlement ePrivacy, une fois qu'ils seront approuvés. Pour l'instant, nous avons le projet 15333, qui comporte une exception pour les logiciels d'analyse Web, comme les outils de test A/B.

Les outils de test A/B sont exempts d'exigences de consentement, tant qu'ils « évaluent l'efficacité d'un service de la société de l'information fourni ». Mais dès que vous vous lancez dans un ciblage très spécifique des utilisateurs finaux ou que vous essayez d'identifier la nature de qui utilise le site Web, vous vous déplacez dans un domaine qui nécessite un consentement.

Vous devriez revérifier que les cookies utilisés par votre outil de test A/B n'ont pas d'identifiant unique. L'identifiant unique peut qualifier un cookie de données personnelles.

Bien que le règlement ePrivacy (projet 15333) ne soit pas encore une loi et qu'il soit destiné à compléter le RGPD, le RGPD lui-même nous donne quelques indications sur les types de cookies qui, de par leur nature, impliqueront le traitement de données personnelles. Il y a 1 récital qui est essentiel à cela :

Cela nous indique que les cookies qui contiennent un identifiant unique pour l'appareil et/ou la personne associée à l'utilisation de l'appareil doivent être traités comme des données personnelles. Cette idée est également renforcée par le considérant 26, qui précise que les données à caractère personnel sont également définies par des données qui peuvent raisonnablement être utilisées, seules ou en conjonction avec d'autres données, pour identifier une personne.

Votre outil de test A/B doit donc supprimer tous les identifiants uniques pour se conformer au RGPD. De plus, ne stockez jamais la fiche individuelle liée à un cookie côté serveur. Cela le ferait tomber en dehors de l'exception dans les réglementations ePrivacy.

Les identifiants pseudonymes (par exemple, des chaînes de chiffres ou de lettres), qui sont souvent contenus dans les cookies, sont également considérés comme des données personnelles. Ainsi, dans le cadre du RGPD, tout cookie ou autre identifiant attribué de manière unique à un utilisateur et donc capable d'identifier un individu, est considéré comme un traitement de données personnelles une fois que cet identifiant est stocké côté serveur.

ID utilisateur et données personnelles

Stocker un identifiant d'utilisateur spécifique à un individu, ou tout autre identifiant que vous pouvez relier à des données personnelles individuelles… est… vous l'avez deviné… des données personnelles. Ainsi, ceux-ci nécessitent un consentement et doivent être évités (le considérant 30 s'applique également ici, tout comme le considérant 50 ci-dessous).

Convert a une fonctionnalité appelée Universal User ID. Si cela, par exemple, est utilisé pour reconnecter des sessions à partir d'un système de commerce électronique après l'achat des utilisateurs, le consentement peut être intégré dans les conditions convenues avec la relation client. Mais nous suggérons toujours un consentement séparé pour une unification des appareils, des sessions et des navigateurs, car il est préférable de ne pas supposer avec GDPR, mais d'offrir une transparence absolue.

Vous envisagez toujours de stocker des données personnelles ?

Vous avez donc décidé de tout stocker dans votre outil d'A/B testing ? Eh bien, stocker un ID de session, un ID utilisateur ou tout autre identifiant signifie que vous devez vous assurer qu'il est

• Protégé
• Exact
• Mise à jour sur demande
• Effacé au besoin

Permettez-moi de vous présenter quelques éléments de la loi GDPR dans le contexte du stockage des données personnelles et de tout le plaisir qui en découle.

RGPD et précision des données de l'utilisateur final

Ainsi, lorsque vous disposez d'un outil de test A/B qui stocke des données personnelles et que vos tests deviennent significatifs, vous avez besoin d'un outil qui gèle ces résultats une fois que les utilisateurs finaux remplissent les formulaires dont vous avez besoin sur votre site Web. Si les paragraphes précédents ne vous ont pas déjà convaincu d'avoir des données personnelles stockées dans votre outil d'analyse, cette partie de la loi GDPR le fera. Je vais coller l'article entier qui le précise ici.

Alors… je vous laisse y réfléchir une minute…
…
…

Ouais je le pensais. Maintenant tous ensemble avec moi… dites ceci à haute voix.

• Je m'engage à ne pas stocker de données personnelles dans mon outil d'A/B testing
• Je m'engage à ne pas stocker de données personnelles dans mon outil d'A/B testing
• Je m'engage à ne pas stocker de données personnelles dans mon outil d'A/B testing

Vérifiez donc bien votre fournisseur de tests A/B et assurez-vous qu'il n'y a aucun moyen qu'il enregistre des enregistrements individuels de visiteurs uniques.

Je veux dire, nous voulons tous apporter de meilleures idées et de bonnes nouvelles aux clients et aux patrons. Et c'est génial d'explorer les tests A/B perdus et de voir si un sous-segment a gagné.

Mais vraiment… voulez-vous faire partie de ces personnes qui cachent le nombre total de visiteurs sur vos captures d'écran de présentation et étonnent les gens avec 1460 % de gains sur une variante de Chrome en Suède ?

Acceptez simplement ce qui suit : vous configurez un test avec une hypothèse claire, exécutez l'expérience et arrêtez-la lorsque suffisamment de trafic est arrivé (pas de furetage). La recherche de gagnants dans de minuscules sous-segments ne fait pas de vous un meilleur spécialiste du marketing.

Avec GDPR, plus vous stockez, plus vous en saurez et plus les segments de trafic ont de chances de devenir de véritables utilisateurs finaux. Parallèlement à cela, vient une demande plus élevée que vous protégiez les données, demandez les données (en utilisant les demandes d'accès au sujet), effacez les données et mettez à jour les données.
Ne le stockez pas, assurez-vous que votre outil de test A/B ne le stocke pas, et vous aurez une chose de moins à vous soucier.

SI vous décidez que cela ne vous dérange pas de demander le consentement et de stocker toutes ces données personnelles dans votre outil de test A/B, assurez-vous que votre outil de test A/B vous permet d'exporter facilement des données brutes basées sur des visiteurs uniques. Assurez-vous qu'il est verrouillé. Qu'il peut modifier les intérêts, les catégories et autres segmentations que vous avez stockées sur les utilisateurs, et qu'il peut effacer les données sans modifier les résultats historiques des tests A/B.

En collectant des données personnelles, vous devrez respecter les droits des citoyens de l'UE et des personnes en Europe au moment de leur visite sur votre site Web. Ceci comprend:

• La possibilité pour eux de voir les données que vous avez collectées sur eux dans les expériences, les audiences et les segments (et les objectifs).
• La possibilité de mettre à jour/rectifier tout ou partie des données les concernant.
• La possibilité de supprimer leurs données à leur demande.
• La possibilité d'exporter toutes les données. Ainsi, si un utilisateur en fait la demande, vous devrez exporter les données liées à son ou ses adresse(s) IP ou identifiant unique. Il peut être facilement exporté sous forme de fichier .csv par exemple.

Ainsi, lorsque vous décidez de stocker des données personnelles, vous devez proposer une demande d'accès au sujet concernant l'accès, la rectification et l'effacement des données.

• le droit d'accéder
• le droit de limiter le traitement
• le droit de rectification
• le droit d'être oublié
• le droit à la portabilité des données

Chaque demande d'accès au sujet devra être traitée et résolue dans un délai d'au plus un mois à compter de sa réception, comme décrit dans le texte du RGPD.

J'ai peur de demander, mais qu'en est-il des sous-segmentations pour les variations ?

Vous pouvez collecter ces données à l'aide de dimensions personnalisées, de variables personnalisées… et bien plus encore.

Maintenant, ne recommençons pas. Vous venez de me promettre que vous ne stockeriez rien sur la base des droits des utilisateurs finaux sur ces données dans l'article 15 du RGPD. Mais même si vous ne disposez d'aucun identifiant pour connecter ces informations, vous pouvez toujours stocker des données personnelles. Cet exemple explique pourquoi.

Les technologies qui permettent aux mobiles, tables ou appareils de bureau peuvent être connectés à leur emplacement actuel. D'autres organisations peuvent également souhaiter utiliser ce type d'informations pour fournir un contenu ou une publicité spécifique à un lieu, cependant, les données de localisation, en particulier les données sur le schéma précis des mouvements d'un individu au fil du temps, peuvent révéler des détails très intimes sur la vie personnelle de cette personne. Il s'agit de données personnelles.

Donc, pour votre outil de test A/B, cela signifie que vous pouvez stocker un utilisateur individuel dans plusieurs segments et, ensemble, cet individu peut être identifié en tant que personne. Le conseil est donc de ne jamais stocker des enregistrements individuels, mais uniquement des groupes de segments dans la base de données. Et demandez le consentement lorsque vous commencez à collecter plusieurs sous-segments qui impliquent des données de localisation sur des emplacements plus spécifiques qu'un pays. Votre outil de test A/B peut vous donner un conseil lorsque vous collectez trop de segments mais, à mon avis, stocker des enregistrements individuels pose juste des problèmes.

Et connecter des données tierces ? Comme Blue Kai ?

Vous avez besoin du consentement de l'utilisateur final. Ou, BlueKai et vous pouvez être co-contrôleurs ; ce qui signifie qu'au moment de la collecte des données de l'utilisateur final, BlueKai a demandé le consentement en votre nom. Cela étant peu probable, au moment de la rédaction de cet article, vous avez besoin d'un consentement pour enrichir vos audiences en outils d'A/B testing avec une forme de consentement sur les données. Demandez à votre fournisseur de données, par exemple BlueKai.

Ne pas suivre pour l'Europe uniquement ? Êtes-vous sûr?

Ne pas suivre (ou simplement DNT) est un paramètre de confidentialité que les utilisateurs finaux peuvent définir dans la plupart des navigateurs. Vous devez honorer DNT en tant que signal de la manière dont vous et vos utilisateurs finaux souhaitez que nous utilisions les données . Au cours des dernières années, de nombreux utilisateurs finaux ont signalé qu'ils souhaitaient une nouvelle façon de s'engager avec les marques. Par exemple, au Canada, où la législation fédérale canadienne apporte des modifications à la Loi sur la protection des renseignements personnels. Ou au Congrès américain avec une nouvelle étape dans le Privacy Shield. Ou dans l'Union européenne où les États membres expriment leur soutien à une interaction plus respectueuse avec les utilisateurs finaux. Vous devez les entendre et les respecter.

DNT a trois valeurs possibles :

1. Ne pas suivre (désactiver le suivi)
2. Suivre (opter pour le suivi)
3. Null - Aucune préférence

Par défaut, les navigateurs Web utilisent la valeur nulle (aucune préférence), indiquant que l'utilisateur final n'a pas exprimé le désir d'être suivi ou non. Votre outil de test A/B doit avoir un paramètre pour ne pas charger AUCUN script lorsque la première option, Ne pas suivre (désactiver le suivi) dans le navigateur est définie.
Jonathan Mayer et Arvind Narayanan sont les deux principaux chercheurs de l'Université de Stanford qui ont travaillé sur la technologie Do Not Track. Leur modèle utilise les informations de l'en-tête HTTP pour désactiver universellement tout suivi en ligne.

"En tant que modèle technologique, Do Not Track est clairement supérieur à un mécanisme de désactivation", a déclaré Mayer, faisant référence aux engagements pris par les autres navigateurs de Google de prendre en charge la technologie sur leurs sites Web.

"Donc la question technologique est désormais réglée : c'est Do Not Track."

Votre outil de test A/B peut avoir les options suivantes :

• Ne pas suivre est suffisamment important et est respecté par l'outil sans que les clients aient besoin d'activer ou de désactiver quoi que ce soit. Cela fonctionne tout simplement (divulgation complète : chez Convert, nous avons choisi celui-ci…).
• Ne pas suivre peut être activé ou désactivé par les utilisateurs pour toute la plate-forme (vérifiez que c'est par défaut pour tous vos projets en tant qu'administrateur).
• Ne pas suivre peut être activé par les utilisateurs de la plate-forme par projet et par région (Europe) et doit être vérifié par l'administrateur sur chaque projet.

Ensuite, ce qui se passe réellement lorsqu'il est allumé est important.

Placerez-vous un cookie (non suggéré) ou l'outil ne se charge-t-il pas du tout (nous l'avons sélectionné). L'inconvénient du premier (placer le cookie) est que les cookies peuvent déclencher un avertissement aux utilisateurs finaux, et le propriétaire du site Web peut recevoir plus de demandes de données de la part des utilisateurs. L'inconvénient de ne pas charger le script du tout est que l'extension du navigateur et les utilisateurs ne sont vraiment pas suivis (et donc les visiteurs suivis pour une variation ou une expérience peuvent commencer à différer de l'outil d'analyse). À mon avis, la deuxième question est plus logique. Le GDPR va de toute façon gâcher les chiffres, puisque différents outils obtiendront ou non le consentement. Donc, les faire correspondre tous pour déterminer un "vrai" résultat deviendra presque impossible, de toute façon.

Responsabilité

Oui, vous devez modifier vos conditions d'utilisation, votre politique de confidentialité et votre politique en matière de cookies (ou l'inclure dans votre politique de confidentialité). Vous devez également avoir un gestionnaire de consentement sur le site Web et…

Juste un rafraîchissement du processeur et du contrôleur (déroutant, non ?).

Vous êtes le responsable du traitement dans la relation entre le visiteur de votre site Web (utilisateur final). Votre outil de test A/B est le processeur.

Cela signifie que vous êtes responsable de la conformité au RGPD et que vous ne pouvez pas pointer du doigt votre fournisseur d'outils de test A/B. La façon la plus intelligente de le faire est de vous assurer que votre fournisseur d'outils de test A/B fait tout pour se conformer, comme décrit dans cet article.

Suivi des revenus ? Numéros de commande en tant que données personnelles ?

Là j'ai des doutes. Les ID de commande (numéros de commande ou ID de transaction) seront-ils des données personnelles ?

Je ne pense pas, mais la séparation des données personnelles des informations non identifiantes (par exemple, un numéro de commande du nom et de l'adresse du client) est simplement une bonne pratique.

Étant donné que nous ne voulons pas que les clients s'inquiètent d'une éventuelle modification des réglementations ePrivacy, nous, en tant qu'entreprise, avons décidé de ne pas stocker ces informations dans notre section de suivi des revenus de l'outil.

La combinaison de la valeur moyenne des commandes, des produits achetés, des revenus et de l'ID de commande est un peu trop d'informations non identifiantes pour figurer dans nos bases de données. Mais c'est à vous et à votre fournisseur de tests A/B de discuter de la manière dont vous souhaitez gérer cela. La minimisation des données nous demande essentiellement de stocker le moins possible. Comme nous n'en avons pas besoin pour le suivi des revenus, nous les supprimons de l'ensemble de données, ainsi que les revenus individuels, le nombre de produits et toute autre donnée de commande au niveau individuel (utilisateur final).

Intégrations ?

Si vous envoyez des informations sur les variantes et les expériences auxquelles l'utilisateur final a participé, nous suggérons son consentement.

Merde, une bonne nouvelle ?

Ouais…

Vous vous souvenez de ces murs de cookies où vous deviez accepter les cookies pour pouvoir lire le contenu ? Eh bien, ceux-ci sont partis. Vous ne pouvez plus les mettre en place et il s'agit donc soit de montrer du contenu à tous les visiteurs, soit de demander le consentement pour des trackers spécifiques, soit de le déplacer derrière le paywall.

C'est ça?

Pas plus…

Le GDPR stipule que les cookies améliorent l'expérience Internet d'un utilisateur, par exemple en se souvenant de l'historique de son panier. Ou lorsque vous remplissez un formulaire sur plusieurs pages.

L'analyse dans GDPR est possible tant que les données personnelles collectées ne sont traitées que par la première partie. ePrivacy est spécifique en ce qui concerne les cookies, là où GDPR ne l'est pas. Lire le projet de règlement ePrivacy 15333, article 21 ;

Ah une dernière chose… Serveurs basés aux États-Unis contre l'UE

L'endroit où vous hébergez votre site Web est-il important ? Ou d'où le script de suivi des tests A/B est-il chargé ? Ou où se trouve votre jeu de données réel ? Oui, ce ne serait pas dans cet article sinon

Les emplacements des serveurs concernent principalement les transferts de données - qui seuls nécessiteraient un consentement s'ils impliquent des données personnelles. Nous devons examiner le chapitre 5 du RGPD sur les transferts de données personnelles vers des pays tiers ou des organisations internationales. Cela nous donnera un aperçu de ce qu'il faut faire si les données sont stockées en dehors de l'Union européenne.

Le niveau de protection des données à caractère personnel des pays tiers est évalué par la Commission européenne au moyen de «constatations d'adéquation», qui sont contraignantes dans leur intégralité pour tous les États membres. Une fois que l'« adéquation » d'un pays tiers a été reconnue, les données personnelles peuvent être transférées vers ce pays sans qu'il soit nécessaire de prendre d'autres mesures de protection.

Un principe général pour les transferts (article 44) et les transferts sur la base d'une décision d'adéquation (article 45) explique que la discussion tourne souvent principalement autour du transfert de données vers des pays extérieurs à l'UE (et la Norvège, le Liechtenstein et l'Islande), où vous n'ont que des options :

• Privacy Shield (pour les États-Unis) et les pays adéquats (la Commission européenne a jusqu'à présent reconnu Andorre, l'Argentine, le Canada (organisations commerciales), les îles Féroé, Guernesey, Israël, l'île de Man, Jersey, la Nouvelle-Zélande, la Suisse, l'Uruguay et les États-Unis ( limité au cadre du Bouclier de protection des données) comme offrant une protection adéquate.
• Clauses contractuelles types, également appelées clauses contractuelles types
• Règles d'entreprise contraignantes (visées à l'article 47 du RGPD).

Il est fort probable que votre fournisseur de tests A/B soit une entreprise américaine, et le choix le plus simple semble être le Privacy Shield et le SCC, car il ne s'agit que d'un effort ponctuel. Pour notre société, cela signifie que même si toutes les données de nos clients (des utilisateurs finaux de leur site Web) sont stockées sur des serveurs neutres en carbone à Francfort, notre base juridique pour la société américaine serait Privacy Shield et SCC (nous aimons simplement être plus sûrs et ont tous les serveurs avec des ensembles de données client en Allemagne).

conclusion

Le GDPR est massif, et pas seulement limité aux entreprises de l'Union européenne. En regardant maintenant, au projet de règlement ePrivacy 1533 et GDPR, nous pensons que vous pouvez tester A / B en utilisant Convert Experiences sur tous les visiteurs sans consentement.

Nous avons une configuration de page entière sur la façon dont Convert en tant qu'entreprise deviendra conforme, et une feuille de route d'application complète sur les détails sur lesquels nous travaillons pour faciliter la conformité au RGPD.

Demandez à votre fournisseur comment il voit son outil en termes de conformité et quand il travaille à simplifier massivement la structure de sa base de données pour effectuer des tests A/B sans demander son consentement.

Parce que si votre outil nécessite un consentement, cela aura un impact énorme sur votre pile marketing. La grande crainte est qu'avec un outil de test A/B basé sur le consentement, vous perdiez plus de 80 % de votre trafic avec lequel travailler.

Test A/B : liste de contrôle de la conformité au RGPD

Minimisation des données

Question du vendeur ?
Quels champs stockez-vous par visiteur unique dans votre base de données (après l'achèvement de la feuille de route) ?

Exemple de réponse
Rien

Données personnelles

Question du vendeur ?
Stockez-vous l'IP des visiteurs ?

Exemple de réponse
Non

Question du vendeur ?
Stockez-vous le pays/la région/la ville ou d'autres données de localisation par visiteur ?

Exemple de réponse
Non

Question du vendeur ?
Pouvez-vous décrire le contenu des cookies ou créer un lien vers un article d'assistance ?

Exemple de réponse
https://convert.zendesk.com/hc/en-us/articles/204495429-Convert-Experiences-Tracking-Cookies-Structure

Question du vendeur ?
Combien de temps les cookies sont-ils stockés ?

Exemple de réponse
6 mois.

Question du vendeur ?
Stockez-vous des identifiants d'utilisateur uniques (identifiant de session, identifiant d'appareil, identifiant d'utilisateur ou e-mail) et/ou nous autorisez-vous à stocker des e-mails ou d'autres données personnelles ? Si oui où est-il stocké ?

Exemple de réponse
Non, nous n'autorisons pas non plus le stockage d'informations (voir également les conditions d'utilisation). Exception, il existe une fonctionnalité d'identification universelle lorsqu'elle est activée par le consentement du client est nécessaire

Question du vendeur ?
Comment votre outil nous aide-t-il avec les demandes d'accès au sujet des utilisateurs finaux ?

Exemple de réponse
Soutenir en ne stockant aucune donnée personnelle

Question du vendeur ?
Comment votre outil prend-il en charge Do Not Track ?

Exemple de réponse
Oui, par défaut le script n'est pas chargé (voir aussi notre feuille de route de l'application de test GDPR A/B)

Minimisation des données

Question du vendeur ?
What fields do you store by the unique visitor in your database (after roadmap completion)?

Example answer
Nothing

Security

Vendor Question?
What server location (country) is our end-user data stored?

Example answer
Francfort, Allemagne

Vendor Question?
If end-user or company information is stored outside the EEU what legal base you are using to transfer the information.

Example answer
End-user information is not stored and not transferred outside the EEU, unless customer requests debugging logging (stored max. 6 days). Customer information and debugging logs could be transferred on bases of Privacy Shield to US servers.

Vendor Question?
What security systems you have in place on databases and system where end-user information is stored?

Example answer
C5, DoD SRG, FedRAMP, FIPS, ISO 9001, ISO 27001, ISO 27017, ISO 27018, PCI, DSS Level 1, SEC Rule 17-a-4(f), SOC 1, SOC 2, SOC 3

GDPR compliance

Vendor Question?
How does your company prepare for GDPR compliance?

Example answer
Find all about out company GDPR compliance program, here.

Vendor Question?
How does your company assist us as controller with GDPR compliance of end-user data?

Example answer
The application roadmap is now public.

Disclaimer: Note that this article represents the views of the author solely, and are not intended to constitute legal advice.