Apologies if this has been asked, I tried looking before posting this.
Can we ship Klaviyo code inside of a web feed and would it be parsed the same way once it’s received?
For example, if I populate web feed content with a Klaviyo/Django {% if %} argument and logic, would it be parsed after the web feed response is received?
Let’s say we ship a feed.footer component as compiled HTML that has Klaviyo logic for a conditional {% if %} and it wants to access person.id — would this work as expected?
Dov caught me up on the thread here behind the scenes. You can in fact render both HTML and Django from a feed in our editor by using various filters and tags, here's how:
HTML from a feed You can render HTML from a feed by using the Django filter |safe, this tells our interpretor that the content is "safe" to render as raw HTML rather than just displaying it as the original text. You can also use this strategy for raw HTML strings contained in event data or profile properties. Here's how this would look:
Django and HTML from a feed You'll notice that the same strategy doesn't work for Django in a feed (or event or profile property). This is due to the discrete steps in our rendering pipeline. In order to display feed content, we need to "render Django" on the template. Then, we would need to "render Django" again on the template in order to render the feed content as Django. We don't do this by default or allow it to be re-triggered in order to avoid render loops, but luckily there is a tag that takes care of this for us.
The "render_variable_assign" tag can be used to set a variable on the template and the "render_variable" tag will render that variable on the page. This tag will be evaluated by our render pipeline before the initial Django render takes place, so you can set up a variable in the first render cycle using that tag so the content will be rendered during the following cycle. Here's how you would do this:
{% render_variable_assign feeds.html_and_django_test.html_and_django as feed_django_data %}
{% render_variable feed_django_data %}
Given a template like the following:
Assuming each property name is what it says it is (html_property is a property containing html, etc), previewing this template would look like this:
I've added an example feed and a template (called "[kl] data from feed example") to your account so you can see how this works!
Yes, you can use if statements in our web feeds and it would parse in the same manner once received. For more information on web feeds, I recommend checking out our article on the topic here.
Hey @Dov , I tried this out and it doesn’t seem to be compiling the variables nor the HTML. Any input is appreciated. The JSON response was received successfully, but it’s being parsed as a string.
I apologize for the initial confusion, there actually is not a way to get web feed content interpreted as HTML in the email source, as it will come in as a string. The immediate workaround is to provide a feed that uses strings and apply the styling within the Klaviyo editor. Sorry about that initial confusion.
I apologize I was mistaken originally, there actually is not a way to get web feed content interpreted as HTML in the email source, as it will come in as a string. The immediate workaround is to provide a feed that uses strings and apply the styling within the Klaviyo editor. Sorry about that initial confusion.
Ah. Bummer. No worries about the misunderstanding.
So the problem we’re facing is here:
We have a ton of flows. Like, plans for scaling it up to 100+.
Each of these flows are composed of many different templates, messages, etc. Let’s say they can be anywhere from 1 - 10, or even more, messages each depending on the flow logic.
This is going to get exponentially harder to maintain with design and template updates. Say we update a navigation block or a footer block, or a content block. We’d have to manually go through all of these flows and update ALL templates. That sucks, big time. (Pun intended)
What we’re trying to avoid here is rolling our own system - which we are capable of - but we don’t want to essentially rebuild Klaviyo.
There must be a way to update all of these templates at once? Or maybe there isn’t. Which would suck - because we dig Klaviyo.
This puts us at the same problem - if we dynamically update and redeploy all templates - we still need to manually update them in the flows to be in sync.
I’d love to hear your thoughts, @Dov . What do you think a good solution is here?
As it stands today, updating templates and template blocks is a manual process (see more on this topic here),however, I have some wonderful news to share.
By end of Q4, we will be pushing out a brand new template editor including a feature that will allow you to add a saved block to multiple messages at once, then later edit the saved block(s) and see those edits reflected across all messages.
Help is on the way, thanks for your patience here!
Hey @Dov thanks for the help, and congrats on the new launch of the template editor.
We’re working around this instead as it seems the universal saved blocks may be out later this year. For now, there is some basic questions here.
You mentioned we can use Klaviyo personalization variables inside of Web Feed responses. That doesn’t seem to be the case, or I may be missing something - can you let us know simply if we can use Klaviyo variables inside of web feed components? See my attachment below.
If we can’t use the above, is it possible to do a string replace from a web feed response? It doesn’t seem to be supported in the Django language by design -- or if you guys have a universally registered filter that we may be missing, this would be very helpful. For example, replacing { “sample_key”: “https://somewhere.to/some/place?={{ EMAIL }}” } and replacing that {{ EMAIL }} with bruce@springsteen.com (or whatever we wanted).
If neither are possible - please let me know and we’ll find a workaround.
Dov caught me up on the thread here behind the scenes. You can in fact render both HTML and Django from a feed in our editor by using various filters and tags, here's how:
HTML from a feed You can render HTML from a feed by using the Django filter |safe, this tells our interpretor that the content is "safe" to render as raw HTML rather than just displaying it as the original text. You can also use this strategy for raw HTML strings contained in event data or profile properties. Here's how this would look:
Django and HTML from a feed You'll notice that the same strategy doesn't work for Django in a feed (or event or profile property). This is due to the discrete steps in our rendering pipeline. In order to display feed content, we need to "render Django" on the template. Then, we would need to "render Django" again on the template in order to render the feed content as Django. We don't do this by default or allow it to be re-triggered in order to avoid render loops, but luckily there is a tag that takes care of this for us.
The "render_variable_assign" tag can be used to set a variable on the template and the "render_variable" tag will render that variable on the page. This tag will be evaluated by our render pipeline before the initial Django render takes place, so you can set up a variable in the first render cycle using that tag so the content will be rendered during the following cycle. Here's how you would do this:
{% render_variable_assign feeds.html_and_django_test.html_and_django as feed_django_data %}
{% render_variable feed_django_data %}
Given a template like the following:
Assuming each property name is what it says it is (html_property is a property containing html, etc), previewing this template would look like this:
I've added an example feed and a template (called "[kl] data from feed example") to your account so you can see how this works!
This is awesome. Those are definitely some Django (or Klaviyo?) tags and filters I wasn’t aware of - aside from safe, which I thought was a Liquid thing. Thank you so much for this info. Let me loop back and we’re going to do a small test refactor and apply some of this and I’ll let you know how this all goes. This seems pretty bang-on though.
By clicking “Accept All Cookies,” you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts.
Privacy Preference Center
Your Privacy
Strictly Necessary Cookies
Performance Cookies
Functional Cookies
Targeting Cookies
Site Analytics
Your Privacy
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
Privacy Notice
Strictly Necessary Cookies
Always Active
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
Performance Cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
Functional Cookies
These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
Targeting Cookies
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
Site Analytics
These cookies record your visit to our website, and are used to track your visit including information such as: web page interactions (clicks, hovers, focus, mouse movements, browsing, zooms and other interactions), referring web page/source through which you accessed the Sites, heatmaps and scrolls, screen resolution, ISP, and statistics associated with the interaction between device or browser and the Sites. If you are accessing our Services with a European IP address, you have been asked to consent to the use of these cookies (you are free to deny your consent).