Betreff: *Aktuell* bester Weg für mehrsprachige E-Mail-Abos?

[Dennis-DWFB]

Hi zusammen,

in den letzten Monaten wurde ja viel mit Workarounds für mehrsprachige E-Mail-Abos ausprobiert. Und mittlerweile hat man ja durchaus auch einiges an nativen HubSpot-Funktionen, die man hier nutzen kann (wie z.B. die Beta für mehrsprachige Subscription-Seiten). 

Wie wäre denn wohl *Stand heute* das sinnigste Vorgehen, wenn man Folgendes aufsetzen möchte...:

• Website inkl. HubSpot, jeweils dreisprachig Deutsch/Englisch/Niederländisch
• Sowohl normale Newsletter-Abos als auch Leadnurturing-Abos in allen 3 Sprachen
• Nutzung der nativen HubSpot-DOI-Mail ohne Workflow-Workaround

Wenn ich das richtig sehe wäre das momentan wie folgt:

• E-Mail-Abos für jedes Vorhaben setzen und von der mehrsprachigen Subscription-Seite Gebrauch machen
• Native DOI-Mail nutzen und alle 3 Sprachen hier Richtung "Bitte E-Mail-Adresse bestätigen" bedienen.
• Die eine mögliche E-Mail-Bestätigungsseite in allen 3 Sprachen bedienen.

Ich hatte erst überlegt, in der nativen DOI-Mail mit Smart Texten nach Sprache zu arbeiten. Aber Smart Content scheint hier generell nicht zu funktionieren, weil die E-Mail schneller verschickt wird, als das System Smart-Verknüpfungen begreifen könnte.

Freue mich auf Impulse.

Gruß und danke!

Dennis

[Dennis-DWFB]

@karstenkoehler  Danke dir wie immer sehr für die Antwort.

Ich denke, man ist hier auf einem guten Weg. Trotzdem sehe ich immer noch große Schwierigkeiten beim Umsetzen einer komplett in sich geschlossenen getrennten Opt-In-Reihenfolge; dem geschuldet, dass die letzten Meter nach wie vor auf 1 Bestätigungsseite mit 1 Domain stattfinden. 

Wenn du domain1.com, domain2.com und domain3.com in einer Enterprise mit getrennten Opt-In-Workflows hast und auch diese Subscription-Beta nutzt, dann wird der letzte Klick nach Bestätigung der E-Mail nach meinem Verständnis gerade immer noch auf 1 einzigen der 3 Domains landen. Und das macht vor allem bei klar getrennten Unternehmen innerhalb einer Gruppe beispielsweise aktuell noch wenig Sinn.

[karstenkoehler]

Hi @Dennis-DWFB,

das sollte auch ohne Brand Domains funktionieren, richtig. Die Funktionalitäten sind da aber auch stark im Wandel, ist schließlich eine Beta. Das kann sich von heute auch ändern.

Eine Anmerkung noch zur E-Mail-Präferenzseite / E-Mail-Einstellungsseite: Die lassen sich aktuell nicht gestalten. Hier gibt es eine Standardseite, sehr schlicht, aber mit HubSpot-orangem Button und keinerlei Möglichkeiten, Schriftart, -farbe oder sogar Titel zu bearbeiten.

Viele Grüße!

[karstenkoehler]

Hallo @Dennis-DWFB,

ja, mit der Multiple Email Preference Centers BETA kannst du mehrere Abonnement-Seiten erstellen und auch entscheiden, welche Abonnements dort erscheinen sollen. Die einzigen Abonnements, die überall erscheinen, sind die Default-/Standard-Abonnements.

Die einzelnen Abonnement-Seiten können, müssen aber nicht Brand Domains zugeordnet sein.

Aktuell gibt es aber trotzdem nur eine Bestätigungsseite, hier lässt sich nicht nach Brand Domain unterscheiden.

Viele Grüße!

[Dennis-DWFB]

@karstenkoehler Mega, danke dir. Das löst zwar immer noch nicht das Problem fürs Enterprise/Brand-Domain K.O.-Kriterium für viele unserer Kunden mit der Bestätigungsseite, aber es ist ein guter Anfang. 

Wenn ich das richtig sehe ist Folgendes aber gleichzeitig mit der Beta möglich, abgesehen davon, dass die E-Mail-Bestätigung jeweils auf derselben Domain landet:?

1. Leadgen über www.domain123.com mit eigenen Abos, Opt-In-E-Mails und Co. für mails über die info@domain123.com und E-Mail-Einstellungsseiten über email.domain123.com. 
2. Leadgen über www.domain456.com mit eigenen Abos, Opt-In-E-Mails und Co. für mails über die info@domain456.com und E-Mail-Einstellungsseiten über email.domain456.com. 

Ach so, und dabei fällt mir noch eine Verständnisfrage ein: Benötige ich überhaupt zwangsläufig unterschiedliche Brand Domains für diese Beta? Oder, wenn du sagst "kann auf unterschiedlichen Brand Domains sein, aber muss nicht", funktioniert das auch schon alleine mit unterschiedlichen gekoppelten E-Mail-Domains (dann natürlich mit nur einer Brand Domain für alle E-Mail-Abos und deren Subscription-Seiten)?

[Dennis-DWFB]

Hi zusammen, 

ich muss dieses Thema nochmal aufmachen, um nicht unnötig ein anderes Thema zu eröffnen. 

Ich habe heute zufällig diese Beta-Option hier für Marketing Enterprise gesehen. Weiß irgendjemand, was es damit auf sich hat? Das "klingt" jetzt erstmal so nach dem was ich suche:

• Pro Brand Domain eigene Subscription Seiten
• Pro Brand Domain eigene Bestätigungsseite (?)
• Pro Brand Domain eigenen E-Mail-Abos auf der Subscription Seite

@karstenkoehler Ich zähl' auf dich 😉

[karstenkoehler]

Hi @Dennis-DWFB, wegen der Vertraulichkeit bei Kundenprojekten leider nicht möglich – so gern ich das mit einer rein fachlichen Sicht auf die Dinge und im Sinne eines gemeinsamen Austauschs tun würde. Viele Grüße!

[Dennis-DWFB]

Das stimmt. Viel Text ist es nicht. Aber die Sache mit der Navi nervt mich schon ein wenig. Schauen wir mal. Wenn du *möchtest* kannst du mir gerne mal nen Link zu 'ner Website schicken, auf der du das funktionierend für mindestens 2 Sprachen umgesetzt hast. Würde da furchtbar gerne mal als Lead den DOI-Prozess durchlaufen um zu sehen, ob wir vom gleichen sprechen.

[karstenkoehler]

Hallo @Dennis-DWFB,

ich kenn leider eure Setup en detail nicht, habe das aber in der obigen Form in mehreren Portalen laufen. Gegebenenfalls kontaktiert ihr dazu einmal eure/n CSM?

Die Varianten wären ansonsten so korrekt, ja. Ich würde in dem Fall die erste bevorzugen, so viel Text muss schließlich nicht untergebracht werden.

Viele Grüße!

[Dennis-DWFB]

@karstenkoehler Fluppt leider nicht. HubSpot leitet leider nicht automatisch weiter (wovon ich in meinem Posting weiter oben ausgegangen bin). Es orientiert sich nur an der Sub-/Domain, also ob z.B. en oder de vorkommt. Man müsste also ggf. einen externen GEO IP Lokalisierungs- und Weiterleitungsdienst implementieren; was wiederum Extrakosten mit sich bringt. 

Bleiben uns die Varianten:

1. Mehrsprachiges Dankeschön mit demselben Template/derselben Navi
2. Einsprachiges Dankeschön mit diversen Links zu Mulilanguage-Dankesseiten mit ihren jeweiligen Headern und Footern.

[Dennis-DWFB]

Das werde ich selbstverständlich tun, sobald wir bei der "Mehr-als-das-geht-einfach-nicht"-Lösung angekommen sind 😉 

Der saure Apfel, in den wir dann einfach beißen müssen, wird die System-DOI-Mail sein. Entweder verschiedene Sprachen in 1 Mail oder die Einigung auf Englisch. Gilt dann insbesondere ja für den Footer und die Abmelde-Links. 

[karstenkoehler]

Dann tun sich ja vielleicht jetzt doch noch Möglichkeiten für eure DOI-Prozesse auf 😉

Falls ich dir mit meinen Antworten weitergeholfen habe, freue ich mich, wenn du die jeweiligen Beiträge als Lösung markierst.

Viele Grüße!

[Dennis-DWFB]

Ganz ehrlich? Habe ich noch keinen Meter dran gedacht. Bei Mulit-Language habe ich meistens Direkt-Links auf die Sprachseite bzw. die Sprachschalter zum wechseln im Kopf, wie man es bei Blog und Co. macht. Aber ich kam noch nicht auf die Idee, dass sich auch die Bestätigungs-Links ggf dann automatisch an die Sprache anpassen, je nach Browser-Land. Ich gebe den Puls direkt mal an unsere Programmierer zum testen weiter. Danke!

[karstenkoehler]

Hallo @Dennis-DWFB,

bei der Bestätigungsseite kann man mit Multi-language Content auf Template-Ebene arbeiten – bist du hier auf Probleme gestoßen?

Viele Grüße!

[Dennis-DWFB]

Am Ende des Tages kommst du dann aber doch mit der Hybrid-Lösung an deine Grenzen, wenn es um die 1 Bestätigungsseite geht. Spätestens hier musst du dann mehrsprachig im Fließtext werden oder dich auf 1 Sprache committen. (Wie du sagst... ich bin auch kein Fan von Smart-Content).

Ich hoffe, dass HubSpot die ganze Thematik nicht unterschätzt und wirklich an was dran ist. Ich weiß nicht, wie viele Unternehmen sich alleine für HubSpot statt beispielsweise Evalanche entschieden hätten, wenn es hier ähnliche DOI- bzw. generell DSGVO-Möglichkeiten geben würde. Die German Angst lässt grüßen.

[Dennis-DWFB]

Hi @karstenkoehler , 

danke dir schon mal für die Antwort!

Solche hybriden Modelle haben wir teilweise schon bei Kunden laufen. Problem ist, dass es irgendwann sehr unübersichtlich wird, wenn es zu viele Workflows gibt. Das wird dann auch jedes Mal haarig, wenn man was neues dazu plant. Deshalb würde ich gerne versuchen, möglichst schlank zu bleiben. 

Die Haupt-Painpoints, die wir gerade haben, sind:

• Nur 1 System-DOI, also auch nur 1 Footer
• Smart-Content funktioniert in der System-DOI nicht, weil die Mail schneller verschickt wird, als der Kontakt in der Liste landet
• Nur 1 System-Bestätigungsseite. Ähnliche Problematik wie bei der 1 E-Mail. Also nur 1 Header und Footer in 1 Sprache möglich

Hast du zufällig Erfahrungen damit, was "passiert", wenn man noch eine E-Mail-Versanddomain verknüpft? Also beispielsweise in unserem Fall statt der mail@fette-beute.com noch eine mail@fette-beute.nl  etc. in den Domain-Einstellungen verknüpft? Hat man hier wohl irgendwie einen Mehrwert, was Mehrsprachigkeit angeht?

[karstenkoehler]

Hi @Dennis-DWFB,

---

Solche hybriden Modelle haben wir teilweise schon bei Kunden laufen. Problem ist, dass es irgendwann sehr unübersichtlich wird, wenn es zu viele Workflows gibt. Das wird dann auch jedes Mal haarig, wenn man was neues dazu plant. Deshalb würde ich gerne versuchen, möglichst schlank zu bleiben. 

---

Das lässt sich in den meisten Fällen mit definierten Prozessen und Zuständigkeiten gut lösen. Ich habe solche hybriden Modelle in mehreren Enterprise-Portalen aufgesetzt, mit jeweils mehr als 10 Teams, Sprachvarianten, verschiedenen Absendeadressen und E-Mail-Footern sowie nachgelagerten Erinnerungen. Da nimmt man natürlich einen gewissen Grad an Komplexität in Kauf, der sich aber mit sauberen Namenskonventionen, Zuständigkeiten und Training abfedern lässt.

Grundsätzlich lassen sich die Workflows meiner Erfahrung nach auch sehr gut modular aufsetzen, indem man die einzelnen Varianten ggf. in klar voneinander abgetrennten Workflows oder Verzweigungen abbildet – damit man Teams, Sprachen und Variationen hinzufügen oder entfernen kann, ohne das ganze Konstrukt zu gefährden.

Einfacher wäre natürlich schöner, aber es lässt sich umsetzen und gut überwachen.

---

Hast du zufällig Erfahrungen damit, was "passiert", wenn man noch eine E-Mail-Versanddomain verknüpft? Also beispielsweise in unserem Fall statt der mail@fette-beute.com noch eine mail@fette-beute.nl  etc. in den Domain-Einstellungen verknüpft? Hat man hier wohl irgendwie einen Mehrwert, was Mehrsprachigkeit angeht?

---

Das würde, soweit ich weiß, nichts an der grundsätzlichen Problematik ändern. Durch das Hinzfügen einer weiteren Option tun sich keine zusätzlichen Optionen bei der DOI-E-Mail auf. Die HubSpot-eigene DOI-E-Mail hat aktuell, egal wie man es dreht und wendet, nur eine Variante.

Damit ist dann das ganze Thema auch eine typische "Hobson's Choice": Du hast die Wahl, aber eben nur zwischen einer Option. Deine Anforderungen lassen sich nur mit einer hybriden Herangehensweise erfüllen.

Ich vermute, dass HubSpot die DOI-Funktionen weiter entwickelt, aber das wird noch eine Weile dauern, schließlich gibt es dazu noch keine Beta.

Viele Grüße!

[karstenkoehler]

Hallo @Dennis-DWFB,

kommt für dich eine hybride Lösung in Frage?

Bei so einer hybriden Lösung würde man die DOI-Funktion aktivieren, aber die System-E-Mail auf eine nicht genutzte Seite beschränken. Damit hat man sämtliche Funktionen aktiviert, kann aber mit der Eigenschaft "Bestätigungsstatus der Marketing E-Mail" seine eigenen, benutzerdefinierten Workflow-basierten DOI-E-Mails erstellen – sehr verkürzt zusammengefasst.

Damit lässt sich dann auch Mehrsprachigkeit sauber abbilden. Mit den Standardeinstellungen sind mehrsprachige Varianten meines Wissens nicht umsetzbar, außer man entscheidet sich für eine DOI-E-Mail, die tatsächlich alle drei Sprachvarianten in einer E-Mail (untereinander) in sich vereint.

Man könnte natürlich bei dem hybriden Vorgehen im Formular die Sprache mit abfragen und dann per Smart Content die Variante ausspielen – hängt von den konkreten Anforderungen des Unternehmens ab. Manchmal müssen die DOI-E-Mails grundsätzlich anders gestaltet werden, sodass Smart Content nicht mehr reicht. (Und ich bin grundsätzlich kein Freund von Smart Content, wo er sich vermeiden lässt.)

Bei den Abonnements ist, glaube ich, das von dir beschriebene Vorgehen die aktuell beste Lösung.

Gib gern bescheid, wenn ich auf etwas näher eingehen soll.

Viele Grüße!