We are sending emails to our contacts based on their preferred language. However, in case the contact wishes to see the content in another language, we add a link to the web version in the header to the other language.
Ex. I received and email in English, but would like to see the content in Spanish. In the header of our email, we have a link that would say “Spanish version” and it would bring you to the web version of the Spanish email.
We have a tendancy to personalize our emails with custom properties added to links in our email. These links will lead our contacts to a web page (external to HubSpot) that will have references to some of the products they own. This is working fine.
Where we are getting inconsistencies is in keeping these personalization tokens when the contact switches to the other language web version of the email.
Ex. The contact receives the English version, decides he wants to see the Spanish version, so clicks on the link, and then from this web version clicks on other links in the email that had been personalized. They no longer get the personalized experience.
After the tests that we’ve done, it seems sometimes it works, and others not.
What would be a good way to keep these personalization tokens in this type of situation ?
Or what could explain that sometimes it works and other times it doesn’t ?
The reason it only works sometimes is that when you switch to the other language’s web version, HubSpot doesn’t always know it’s the same contact. If the tracking info or cookie gets dropped, the personalisation breaks.
The fix is usually to pass the tokens in the link. So when you add the “Spanish version” link, include the contact details you need as URL parameters and make sure they carry through on the links in that version too.
Another option is to avoid multiple web versions and just use one email with smart content by language, so HubSpot only has to personalise once.
Best,
Francois www.smitmarketing.co.uk
This is a well-documented pain point with HubSpot’s web version architecture, and the inconsistency you’re seeing has a fairly clear explanation.
When HubSpot sends an email, personalization tokens in links are resolved using a contact identifier that gets embedded in the email’s tracked URLs. That identifier is what allows HubSpot to know who is clicking and swap in the right property values. The web version of the original email works because that same identifier travels with the request.
The problem arises with your language-switch link. When you link to the web version of a different email (the Spanish version, in your example), that URL points to a separate email record. Unless the contact identifier is explicitly passed along in that URL, HubSpot has no reliable way to associate the session with the contact. The times it works are likely cases where HubSpot’s tracking cookie is active in the browser and can fill in the gap. The times it doesn’t work are where that cookie is absent or expired.
A few approaches worth testing:
Pass the contact identifier manually. Build your language-switch link using a HubSpot token that appends the contact’s email or vid to the URL as a query parameter (e.g., ?email={{ contact.email }}). Your Spanish web version or destination page can then read that parameter and use it to maintain context.
Use a single email with language-conditional content. Rather than two separate emails, one email with smart content or conditional blocks based on a “preferred language” contact property sidesteps the cross-email linking problem entirely. The web version of a single email retains its identifier cleanly.
Middleware redirect page. A lightweight redirect layer that captures the identifier from the inbound click and re-appends it to the destination URL gives you full control regardless of which language version the contact lands on.
That said, if deep link personalization is core to your email strategy, it may be worth looking at Blings. Blings integrates with HubSpot and uses on-demand generation, meaning personalization is applied at the moment the contact opens or clicks, not at send time. The Live URL carries the context inherently, so language switching and link personalization stay intact regardless of how the contact arrived.