Warehouse-native Is No Silver Bullet | Chris Hexton, CEO and Co-founder at Vero

→ Link to the collection.

There's a lot to like about warehouse-native apps, but can they easily replace their traditional counterparts? Not really!

When it comes to email engagement, a warehouse-native email tool isn't always suitable — they're especially not a good fit for real-time use cases.

This episode is hosted by Luke Ambrosetti, a community member, former guest, and leading expert in the Warehouse-native space, who works with companies building apps on the Snowflake Data Cloud.

Our guest, Chris Hexton from Vero, an email marketing tool that also offers a warehouse-native version, explains what one needs to make a warehouse-native app work, when it's not the right choice, and why sometimes it makes sense to use both.

Let’s dive in:

Q. How would you define a Warehouse-native App or what Snowflake calls a Connected App?

I would define it as a software application that does not have its own data backend.

Instead of syncing and then storing a copy of our customer’s data, Vero connects directly to the customer's data warehouse and uses that as the data backend.

Thereon, all data read and write is from and back to the customer's data backend.

So users of Warehouse-native Apps don't need to sync or store customer data, eliminating data integration work.

Does that come with a caveat? Are there any limitations?

As you said, this can really reduce the costs as the data is not being stored twice, it just stays in one place — the customer’s data warehouse. And one doesn’t have to set up new data pipelines or new libraries to sync data to the email marketing tool.

Not having to sync data doesn’t mean this isn’t any work to be done. You obviously need a data warehouse and there needs to be data in there that can be used to create audiences and personalize emails. That’s the caveat.

Q. Okay but what are the specific steps that need to be taken in the data warehouse for a Warehouse-native App to work?

The two main steps are data collection and transformation.

To bring the data into the warehouse, one needs to instrument their product (telemetry) using CDI tools like Snowplow, RudderStack or Segment. Additionally, one might need to ingest data from third-party apps such as Stripe into the warehouse for which ELT tools like Fivetran or Airbyte can be used.

The second step, data transformation, is making sense of that data — joining it, stitching it, etc.

For email marketing use cases, one needs to build audiences using the data made available in the warehouse. The stitching of data, therefore, entails taking data from disparate sources and creating one row or record per user so that the marketer has all the data she needs to build a specific audience for activation purposes.

This second step of cleaning, and organizing the data is a critical step, for which most of our customers use dbt.

That makes perfect sense.

So a lot of the traditional email marketing tools offer a visual segmentation layer, making it easy for non-data folks to iterate and build workflows quickly.

Q. Do warehouse-native email tools also offer that?

One of the key selling points of any marketing automation or customer engagement tool is to enable marketers to do their job without relying on others, as efficiently as possible — not all marketers are super familiar with SQL and they’re definitely not familiar with the raw data floating around in the data warehouse.

At Vero, we've launched a very raw interface where one has to use SQL to build audiences or segments. That said, we’ll soon release a visual editor (visual segmentation), similar to what traditional SaaS tools offer.

So to answer your question, the visual segmentation or querying capability of a warehouse-native app works differently than that of its traditional counterpart, and there are two possibilities here:

1. Data engineers can set up certain tables and views in the data warehouse and we can then build a traditional, visual drag and drop condition builder on top of those tables and views.
2. The other way is to have data engineers build SQL queries with variables that a less technical user can select and play around with, without really seeing the underlying SQL.

These are the two main schools of thought and I believe both bring it up to a level that’s very approachable for a less technical person.

Luke: I agree with those two approaches. You don't have to fiddle with APIs and can do all the transformation work within the data warehouse, which you're probably already doing anyway.

Yeah I've seen you talking on LinkedIn about those traditional tools that promise a no-code or low-code set up, but one still needs data in those tools and that's often where things get stuck, right?

Maybe the data you actually need as a marketer never even makes it because the support from the rest of the org just isn’t available.

Hence, even in the early days with the less than a user-friendly interface that, we still see marketers who are super pumped because they have real confidence in the underlying data in a way they didn't before.

Vero offers two products — Vero Cloud, the traditional email marketing tool and Vero Connect, the warehouse-native component.

Q. What are the pros of each and when should each of those be used?

Vero Cloud, our core product, has been around for a while whereas we launched Vero Connect about 12 months ago. The key thing you need to use Vero Connect is a data warehouse with some (usable) data in it.

If you don't have a data warehouse in place, or you don’t have the resources to wrangle and transform the data in it, then perhaps a traditional email tool (Vero Cloud) is a better fit.

For relatively small or new organizations that are maybe graduating from something like MailChimp, Vero Cloud is a great fit 'cause in essence, we're spinning up a managed data warehouse for the customer behind the scenes and giving them the tools — such as forms to capture blog subscribers — to get relatively simple data in there.

As organizations mature, they graduate to the “connected way” of doing things — that's at least where we're at the moment.

Do you have customers using both products? If one uses the traditional version, why would they want the warehouse-native version?

Yes, we've definitely got a couple of customers using both.

Building on my answer before, we’re seeing that there are several different use cases for email marketing in an organization.

The killer use case for the warehouse-native version is product (lifecycle) marketing that includes engagement that takes place after a user signs up — product updates, announcements, or automated messages to nudge customers toward activation.

On the other hand, for top of the funnel use cases such as newsletters, customers usually don't have requisite data in their warehouse, and that's where they prefer using a traditional SaaS email marketing solution.

Why might someone move from one to the other?

As a company scales, they collect and wrangle more data and eventually have to keep millions of rows in sync across several different tools which can be very costly in terms of time, and one might fear that the data isn’t actually syncing as expected, (resulting in data quality issues).

Therefore, as the org matures and hires their first data engineer (or someone puts that hat on), they end up with a data warehouse, leading to more trust in the data as compared to the data lying across different cloud solutions (such as Vero Cloud).

Email marketing/engagement is such a wide category with teams using multiple email tools.

Q. Which use cases are not fulfilled by warehouse-native solutions today?

Another area where a warehouse-native app is not a good fit now, and may never be, would be transactional email.

Emails that need to be sent milliseconds after someone requests a password change, for example, is not a good fit for the warehouse-native version because generally speaking, people rebuild the models and the views in the warehouse on a periodic basis that's definitely not going be milliseconds.

🥁🥁

You can also tune in on Spotify or Apple Podcasts.

If you enjoyed this episode hosted by Luke, you should check out the one where he’s the guest