Embedding an email subscription form to a customer website is done by using an iframe. I was told by customer support that this is currently the only option. A downside of this method is that the subscription form sets a number of cookies, including marketing cookies used for tracking users across multiple websites in order to present advertising. According to current privacy principles, a website visitor needs to be given an option to decline cookies that are not essential for the basic function of the website. The problem is that the embedded subscription form does not work if the visitor has declined marketing cookies. Would it make sense for Mailjet to develop an alternative way of using the subscription form? For example, hosting the form on Mailjet server in a way that only a link to it would be required on the customer website. This way, no additional cookies would be set through the customer website.

Lorsqu'on travaille sur un template marketing, si l'expéditeur pré-renseigné n'est pas validé, les emails de test ne sont pas envoyés alors qu'un message popin est affiché pour indiquer que la demande a été correctement traitée.

=> Il faudrait qu'il y ait une vérification préalable de l'expéditeur et qu'un message d'avertissement indique à l'utilisateur que l'envoi ne peut pas être fait car l'expéditeur choisi est invalide/non confirmé. (Sinon nos utilisateurs ne comprennent pas du tout ce qui se passe)

When working on a marketing template, if the pre-populated sender is not validated, the test emails are not sent while a popin message is displayed to indicate that the request has been correctly processed.

=> There should be a prior verification of the sender and a warning message indicating to the user that the sending cannot be done because the sender chosen is invalid/unconfirmed. (Otherwise our users do not understand at all what is happening)

La longueur maximale de 100 caractères sur les sujets d’email n'est pas suffisant. Avant cela ne nous posait aucun problème car le texte des variables n’était pas comptabilisé en totalité dans le calcul de la longueur.

Auparavant, l’inteface mailjet nous remontait une longueur de 34 caractères pour l’objet « [[data:segment:""]] - Info entretien de votre [[data:raison_sociale:""]] [[data:emvadmin3:""]] [[data:secteur:""]] ». => Chaque variable était exclue du calcul de longueur et comptabilisée pour un seul et unique caractère, ce qui était satisfaisant pour nous.

Aujourd’hui, l’ajout de la variable « [[data:raison_sociale:""]] » correspond à 26 caractères, ce qui est en moyenne beaucoup plus que la valeur qui apparaîtra effectivement dans le sujet du mail après remplacement. Si on ajoute plusieurs variables, cela s’accumule et on dépasse très vite la limite. Ce n’est pas acceptable.

Nous ne pouvons pas nous contenter de la solution temporaire d’utiliser un template existant = Si nos gestionnaires souhaitaient utiliser un autre sujet, non référencé dans les templates, ils se retrouveraient à nouveau bloqués et là nous n’aurions rien pour les aider, l’usage des appels API étant totalement exclu pour nous.

The maximum length of 100 characters on email subjects is not sufficient. Before that we had no problem because the text of the variables was not fully counted in the calculation of the length.

Previously, the mailjet interface reported a length of 34 characters for the subject "[[data:segment:""]] - Maintenance info for your [[data:raison_socie:""]] [[data:emvadmin3:" "]] [[data:sector:""]]". => Each variable was excluded from the length calculation and counted for a single character, which was satisfactory for us.

Today, adding the variable "[[data:raison_socie:""]]" corresponds to 26 characters, which is on average much more than the value that will actually appear in the subject of the email after replacement. If we add several variables, it accumulates and we very quickly exceed the limit. It's not acceptable.

We cannot settle for the temporary solution of using an existing template = If our managers wanted to use another subject, not referenced in the templates, they would find themselves stuck again and there we would have nothing to help them, l the use of API calls being totally excluded for us.

Ajouter des nouveaux types de formulaires comme le proposent SendInBlue par exemple :
-formulaire à partager via un lien. C'est vraiment le top, on construit notre formulaire avec un éditeur visuel, cela génère un lien (hébergé chez vous directement) avec le formulaire et responsive design bien sûre.

autre possibilité : générer un formulaire HTML (sans Iframe) car les iframes sont de plus en plus bloqués pour des raisons de sécurité. Cela permettrait de créer un formulaire via votre éditeur visuel PUIS de l'intégrer en HTML sur notre site.

Add new types of forms for example:
-form to share via a link. It's really the best, we build our form with a visual editor, it generates a link (hosted directly with you) with the form and responsive design of course.

another possibility: generate an HTML form (without Iframe) because iframes are increasingly blocked for security reasons. This would allow you to create a form via your visual editor THEN integrate it in HTML on our site.