Best Practices for WooCommerce Integration Implementations

Jonathan: Welcome back to Do the Woo, I’m your co-host today, Jonathan Wold. And with me today is David Henriquez from Klaviyo. David, welcome.

David: Hey, great to see you and great to be here.

A diverse background

Jonathan: I’m excited about this. We had a warmup chat the other day, and I learned a little bit about your background and now folks are going to get to hear that for the first time. So you’ve had a very wide ranging background that led you to this. Talk us through where you got started in this world.

David: Yeah, sure. I’m going to go way back to the basics, I guess pun intended. Because when I was first or second grader, I had a friend who taught me the basic programming language. At a really young age we had Apple 2 and we could drop to the terminal and we would write basically choose your own adventure games. It’d be a text-based game, you’re going through the woods, you’re doing different things. I’m not that old, but I’m dating myself a bit to say that not everyone back then was teaching kids how to code and teaching kids how computers worked and everything. It was much more, you throw in a floppy and you learn the alphabet. You do things like that. It’s much more part of the curriculum today.

So, I didn’t have a ton to do with that. After getting into it at such a young age, I continued to do basic for a long time. Then when I was in high school, college, I would build websites for friends, businesses, little small businesses I knew. And I was always very technical in nature, but I wasn’t fluent in any programming language.

Jonathan: What were you building the websites in? Are we talking basic HTML?

David: Yeah, exactly. HTML, CSS and a little JavaScript. Basically highly inspired JavaScript, we can say, from other websites and things.

Jonathan: I love it.

David: So after college, I got into sales. It was a bunch of different sales roles, most of the time in technical sales roles. Then I ended up in situations where I really felt that calling back to when I had been technical when I was younger. I was in all these meetings and I felt like, well, if I had the skills, if I was fluent in technology… I really understand what the business challenges are being asked for here and I wish I could go disappear for a week, come back and show everyone. And I know they’d be really excited about it. And eventually it just became too much. So I took a program, a three-month intensive program to learn how to code fluently. Within a few weeks, I went off on my own and was just doing a lot of my own projects, teaching myself stuff.

Jonathan: Do you feel like that was worth it? Because we have a lot of these bootcamps and stuff around. How was that experience for you, just jumping into that intensive?

David: Totally great question. My experience was a little unique in that I had a really clear idea of what I wanted to do. So I went into it knowing that if I get these skills, I was fortunate to have a really solid background, really good network. So I was able to use my existing network to leverage references, et cetera, and get into technology right away. I don’t say that my experience will be the exact same for everyone, but I do highly recommend these programs. I think that even if you’re not going to become a full-time developer after, so that was very common. And the group I was with probably only 25 to 30% actually took on full-time engineering type roles afterwards. A lot of other ones found successful careers in customer success and technical escalation support.

Nowadays a lot of opportunities exist out there and being able to have a solid background in technology gives you a huge leg up. Compared to what I paid for undergrad and student loans, I think that this program had a really good return on investment. So, I can’t recommend these types of things enough. But I will say that sometimes there were students who didn’t succeed and who fell out quickly. And oftentimes, those were folks who were thinking like, “Oh, if I get this job, I have the easy path to a six figure job. And I’m just going to be able to work all over the world and travel, do whatever I want.”

Jonathan: And your background, you had this love of programming from the beginning. You went into the technical sales role where you saw some connection to it, like, “Okay, this is helpful.” So it sounded like you wanted to go further into it. You do this programming thing for a couple of months. What happens next?

David: I got a job at a company called Life Image, which was the largest medical image transfer network in the US at the time. I was a UI engineer, so I was a product engineer. I was doing a lot with React and Redux. I was not really doing a lot of styling, I was more of the state management and that kind of stuff of React. And I really liked that. I was doing that for a year and then friends had reached out to me and they said that we know some folks who have joined this company in Boston. I had a lot of background in marketing and advertising, which typically a lot of folks in Boston do because there’s a lot of those companies here. So I learned about the company, and they were looking for a sales engineer who was hard to find.

So they wanted someone who had background in sales, in closing deals and selling in competitive environments, but also could pass the engineering test here, which is known to be very tough. They were having a hard time finding folks, so a friend reached out and said, “Hey, I think this would be a pretty good fit for you.” I went from being a little cautious, like, okay, I did the sales thing. I don’t want it to just be talking technical. I want to still be learning, I still want to be doing a lot of coding, et cetera. To interviewing and realizing like, wow, I fell in love with this company. The opportunity was incredible, so I was really pumped about it.

WordPress and WooCommerce enters the picture

Jonathan: Now, at what point, if at all, has WordPress come into the picture at this point in your journey?

David: Oh, sure. Way back when I was in sales, we worked at a company that did open source website design. So we did WordPress sites, we did Drupal sites as well. We would build all kinds of websites for… Oftentimes when I started, it was a lot of really small businesses. And then as we did more and more, we were working with larger, growing tech companies.

We had a niche where company would raise a big series A, series B, they want a new website, they want focus on conversion optimization. We would build them a new site. And those were oftentimes WordPress sites. And even the sites that I built for my friends and family over the years, oftentimes those were WordPress sites too. So, I’ve always been fairly familiar with it and using it pretty regularly throughout the last 15 years or so.

Jonathan: So you have that backdrop for like WordPress, for instance, in this case. Had WooCommerce come into the picture at all, up to that point?

David: No. Up until Klaviyo I’d never used WooCommerce before specifically, it always been WordPress sites with mostly B2B sites, conversion optimization type sites.

Jonathan: Okay. Fast forward to Klaviyo, so you land the role. And the initial role was a sales engineer role?

David: Yeah. At first, I was a senior sales engineer and really helping lead sales engineering here. It was pre-sale selling into a lot of our largest, most strategic, complicated type customers.

Jonathan: Cool. And talk us through… Now, it’s been… Has it been four years now? How long have you been with Klaviyo?

David: Yeah. I just reached four years few weeks ago, actually.

Jonathan: Congratulations. In our software world, that’s a very long time, a lot happens.

David: Yeah. I’m considered ancient around here.

Continuing on the path towards being a lead developer advocate

Jonathan: So, what’s the arc of that? Because you’re doing something a little bit different now. What happened over the course, and what are you doing now?

David: Totally. So when we started at Klaviyo, there were a couple of us in sales engineering. That team grew hugely. It’s now probably 15 at least, I think 20 people globally as well. We have folks all over the world on that team now. We thought a lot about what we were doing in the early days with sales engineering. So companies would come to us, and we’d never been a services’ company, so you couldn’t pay us to build custom things. But every now and then, we would do whatever it took to help these larger brands, these more complicated situations come through. From doing that so much, we’ve been fortunate, the company has scaled a lot. If anyone’s heard about Klaviyo, you can look us up.

We’ve been fortunate to grow significantly in that time. As anyone who’s been in that situation knows, eventually you start off in startups, doing things that don’t always scale to get really good stories. So one time my VP of sales came to me and he said, “David, we want this brand. We’re going to do what it takes to get this in. You’re basically responsible for implementing them and making it happen.” Then as you get to be a much bigger company, those types of stories aren’t worth it anymore. You need to do things that scale, so you need to figure out how to do that. So from there, I helped start the developer experience team here.

That was an engineering team, I was an engineering manager on that team for about a year and a half. We started it with the goal of creating all new API documentation, eventually creating new APIs, new SDKs, building a developer portal. And doing a lot of the things right that we had known to do in the sales engineering world. Taking that and building that education, building up our tooling and being able to deliver that to our developer customers and partners, with the goal of them being able to do everything that we were doing. And really just trying to invest in the developer experience and make that much better so that it’s scalable and now folks can go out and they can do these things that we had been doing.

Jonathan: Okay. So you focus on that developer experience piece for about a year and a half, then what?

David: For the last six months, I’m working on developer marketing now. I’m our lead developer advocate, so I’m combining all of the different things I’ve done here.

Jonathan: It’s a nice natural progression too, which I like. It’s sort of, you built the experience, now let’s get more people into it and help make sure that they’re succeeding.

David: Precisely. We built it, now let’s try and get folks excited about it to use all of the great things we’ve built.

The entrance of WooCommerce into the periphery

Jonathan: We’ll talk more about Klaviyo in a moment, because I think there’s a decent amount of folks here who are not familiar with it. At this point, where did WooCommerce over the arc of that four years at Klaviyo come into the picture? Because there’s a fair amount. So, I’m curious. You have this backdrop for WordPress over the past 15 or so years, you might have been at least aware of these different things. WooCommerce at this point is the largest platform. So, I’m curious about its entrance into your periphery. At what point do you become aware of it? Tell us about that.

David: Yeah, sure. At Klaviyo, we started off as a company with customers in various industries. A lot of them software companies and apps, like many tech companies do. Then we found a niche pretty early on in eCommerce and going after commerce related sites. We found great product market fit and we doubled and tripled down there. So part of what we do is, Klaviyo is a customer platform. We’re not actually specific to any given technology or any platform, we’re a way that companies can store, manipulate and execute data-driven strategies. So we have all of your customer data, we have events for your customers. And it could be in any industry. It doesn’t have to be eCommerce. But that’s one that we’ve worked a lot in, and right now, it’s definitely our focus.

WooCommerce, like you said, being one of the largest platforms, we had a goal to help brands from all avenues of eCommerce be able to use our tool to be able to drive growth and be able to get more out of their business data. So we built an integration to WooCommerce in the early days. And as a sales engineer, you’re mostly focused on the more complicated issues and the more customized solutions. You’re not necessarily working with all of the standard SaaS platforms where there’s more of a one-size-fits-all integration. So from the very first days I was working at Klaviyo, I was working with WooCommerce merchants who were working on integrating, customizing our integration and trying to get as much as they can out of us.

Building a perspective across different platforms

Jonathan: I like it. One of the things that I love on the show when we bring in folks. So you have the WordPress background, you have this context for the ecosystem, you also have the distinct advantage of working with a lot of other platforms. And that’s a perspective that I think is often overlooked in terms of its value, because WordPress and WooCommerce, they’re more than big enough to warrant many folks who are just, this is all that they do. Yet I’ve noticed that there’s a lot of value in having that broader range of perspective. I’m curious, have you found that? Were there a lot of differences working across the different platforms? What was that like for you?

David: Yeah, totally. When I first joined here, I was lead engineer of our Salesforce Commerce Cloud integration and helped build that out a lot. And have worked on some of our Magento code base, some of our Shopify code base as well. So being able to come to each platform with that backdrop is incredibly helpful, because you can see how different companies focus. BigCommerce, another one, we’ve worked with so many of these different companies, you can see how they approach different things. Some of the assumptions that you may have made from one or two experiences, may be different in each one.

So you really want to think about, “Okay, of all of these things I’ve seen, what are some common elements and pieces oftentimes that result in common code and ways to do things?” To simplify it a bit, there’s the historic data. So all of the history of purchases and folks who have subscribed and interaction that they’ve had with your website from a historic basis, and then also on an ongoing basis.

We think about how can we build an integration that gets all of that historic data quickly and easily so that it’s accessible and you can start querying your customers to know who your best customers are, who purchases certain products, what kind of behaviors they have. And then at the same time, be able to get their real-time data. So when we come to integrations such as WooCommerce, we built the backend connection to be able to get all of that historic data. Then in the WooCommerce world, we built a plugin.

In the Commerce Cloud world, I built our cartridge. A lot of it is very similar and you see a lot of these same patterns everywhere. Then when you’re working with something like WooCommerce, you want to think about why are folks choosing this platform. What are the value adds here? Because you don’t want to treat every platform the same, you really want to understand the context you’re in so that you can get the most value and really the customers are getting the most value.

Jonathan: Let’s unpack that a bit. With Klaviyo, you have this customer management platform. Now, one of the things as to why people pick WooCommerce, there’s different reasons, I’m curious for your perspective. From what I’ve tended to see, there’s a number of reasons, but there tends to be this theme of value in the ownership aspect of it, in some way, shape, or form. Now, I’ve been a big fan for a long time of this world of SaaS and open source together. Especially when it comes to data though, it’s a curious thing where it’s like, some folks are like, “Oh, I want all this data here.”

Helping customers navigate the tension towards open source

Well, if I’m understanding correctly with Klaviyo, part of the value proposition you’re offering is like, “Hey, we have an integration where we can keep that over here, you’re still doing your thing.” How do you relate to that? How do you think about that tension between having all the important parts, be owned by the customer? Yet also, especially in the commerce world, there are very real capability gaps in terms of what you get with WordPress and WooCommerce out of the box. How do you tend to navigate that tension for folks who are inclined towards open source, whereas other platforms, they might not care about that as much.

David: That’s a great question. The way we think about it, and I think that it happens in the world a lot is, companies are going to choose open source that are focused on the speed of innovation. This is common, I’m not telling anyone anything they don’t know. But if you’re building a product and you’re responsible for it yourself, you have to get to a pretty big size to where you can commit 20, 30, 50 developers to a single product. But when you look at open source, you have tens of thousands of developers potentially in the community who are contributing to it, who are making new features and functionality. So the speed of innovation and the new feature development is going to really eclipse what’s available in the SaaS world.

I think, when you think about open source that way, it’s interesting to think about where you line up your priorities and what you care a lot about. If you’re looking for something that’s going to move really fast, that has a huge community that you’re going to be able to contribute to, open source is a great option. Open source also, the name open source, gives you access to everything. It’s fully customizable and very flexible for your company. So when you come to WooCommerce, you need to think of it in that way. That we’re going to be finding folks here who are trying to do things a little differently, who are trying to customize their website, who are trying to build things in a different way, who are trying to drive more unique experiences oftentimes.

And if you’re trying to come to them with a one-size-fits-all answer, it’s not necessarily going to work. To your other point around owning the data, just to be clear, every customer owns their data in Klaviyo. We don’t own data, we’re not a data broker or anything like that. Everyone’s data is siloed, there’s no sharing or anything like that. So we’re really like a more modern version of what you would think of as a CRM, specifically built for customer first companies. So companies who are focused on driving more personalized experiences and who are trying to use the data that they have from their customers, what their customers will tell them, to help create better outcomes for their customers and for them.

Jonathan: I love that. That’s a great explanation. Why work with an external tool versus… I’ve got my own thoughts on this, but versus just use some… There are CRM plug-ins for WordPress. You could get some basic functionality there. You could do some… What’s the value, from your perspective, of working with a SaaS for a functionality like that versus just, “Oh, I can find another plugin that does it all here in WordPress”?

David: I think it’s a good question. I think it’s a balancing act. I think for some companies, the plugin, it might work. But like you said, it often is a basic experience. What we’re trying to do is really focus on building that next generation customer platform. And the amount of R&D and the amount of effort that we’re putting into that specifically is a huge benefit versus some of what’s available right now, open source, off-the-shelf hasn’t quite got there yet. So I think when it comes to these kinds of systems, you don’t really see a whole lot of open source there.

Jonathan: This is what I love about it too, it’s there’s this question of aligned incentive. Because yes, basic features and functionality of a CRM, you can certainly get in a plugin for WordPress. But like you said, because you found that product market fit, because you found the alignment, you have the incentive to keep innovating, to keep making things better. This is what’s great about this SaaS, open source integration, because they can get that specific set of value. And all the backend stuff that you’re doing, all these other things that you can do around the life cycle of a customer, serving as a point of additional integrations.

There’s all this stuff that you can abstract away, which maybe a business just starting out might not need. At some point though, they’re like, “Okay, yeah, we need that additional capability.” And you have an incentive to provide that. And as we’re seeing in terms of adoption, it’s a great match. Customers are like, “Yeah, I love having WooCommerce as a base. There’s things that I care about where we need additional features and functionality and confidence in who’s backing it.” Like having support there, knowing that the investment is continuing. That feels like a good fit.

David: What we do really is, we’re helping companies grow and we’re really trying to help your bottom line. So when it comes to making an investment in your business, Mark Benioff originally said when he was inventing cloud software, he was going to start with sales. Because that’s where companies were going to be willing to invest in new technology in something different. If he started in HR, if he started in support, it may not have taken off as well. But he knew he needed to focus on where companies are driving revenue.

So with us, oftentimes a competitive advantage where if you’re a store, you’re a merchant who’s using Klaviyo and your competitors aren’t using that. Then you might have to ask yourself some tough questions. You may have some open source features, you may have some things you’ve built yourself. But when you have a purpose-built company who’s really just focused on this problem space, you end up with a really high quality solution. And that’s really what we’re trying to focus on. We’re the customer platform for you to be able to drive more growth out of your data. And we think we do a pretty good job at it.

Jonathan: I like the customer-first aspect of this. Back when I worked in community at WooCommerce, we would teach people how to get started in eCommerce. And it was always like, who’s your audience? What problem are you solving for them? And drilling in that customer centricity, where it’s like, if you are clear on what problem that you’re solving… It’s easy to lose sight of that occasionally. The folks who do really well as merchants, keep that in mind. And the builders who support them, we talk about this quite a bit thematically. For a builder that’s creating whether product or providing services to a merchant to help them stay focused on their customers, that’s the loop that works.

David: Absolutely.

Jonathan: Who’s your audience? What problem are you solving for them? How can we solve problems for them more effectively? That’s where a lot of innovation with WooCommerce comes in. Okay, how can we customize this to better suit their needs? This is where the flexibility can shine in contrast to a proprietary platform where you don’t have that same degree of flexibility.

David: An interesting point there is, we made a decision early on about how our APIs are going to function. Oftentimes APIs are fairly rigid. And you may have to find a schema beforehand and say, “This is going to be my placed order event. It’s going to look like this. And if you send it over the wire a little differently, it might get rejected and you might have to go into some system and reassign it.” But we have very flexible APIs, where you can send through new events for the first time. And those events, the first time we see them, are immediately available to be segmented on, they’re immediately available for automations. And the payloads are also flexible.

So you can send a standard payload with many different options and even change them as your company changes and be able to quickly use all of that without having to go through the rigorous process of redefining schemas and changing all of these different validations. Our APIs are designed to be incredibly open and incredibly flexible. So we found in a WooCommerce environment, where folks are willing to be flexible and they’re willing to customize things and willing to… And they value spending on that and getting that customization, it’s worked out great for us because it’s something that people can send over really easily to us. That’s really a huge area of our APIs, is the event.

Thanks to our Pod Friends

What examples stand out using WooCommerce

Jonathan: I’m curious about this. I imagine over the course of your past four years, you’ve seen a lot of different things with WooCommerce. You’ve seen different types of things. Are there any examples that stand out?

David: Yeah, totally. To what we were speaking about earlier, where when you’re working in an environment, you want to really think about what that environment is great at and what you’re likely to see there. So in WooCommerce, you’re likely to see highly customized, highly flexible design. We had one example, it was a children’s bookstore company. And they had a catalog of books. Every book they’d ever sold more or less was available to be reprinted, even though they may not have been advertising them anymore. And they had a massive inventory. So they had hundreds of thousands of books that were potentially available for sale.

So our integration that we had built to connect to the catalog with WooCommerce and sync over, scaled fine for thousands of catalog items and even tens of thousands of catalog items. But when you started to get to the hundreds of thousands catalog items, there were some challenges there with the scale of that.

And also there were challenges in the business use-cases because they didn’t really want that whole catalog. They only wanted the ones that they were mostly selling in the current time, but they wanted to be able to sell to someone who wanted that historic data. Even though it wasn’t as valuable for them as a business, it was a very small part. It was a very long tail, you could say.

So I actually added the customization into our backend integration to be able to optionally sync certain types of catalog items so that you could avoid different areas of the app. That was something that we didn’t build that one-off for this brand. We built it because of this brand. But now in the future, every WooCommerce customer had more flexibility in how they used their catalog. And that was really the approach we took with WooCommerce, when we would see someone doing something differently, when we saw someone had a way to customize something. Or we hit a challenge, maybe there’s a hundred thousand items, maybe the historic order’s…

There’s another example, it was a company that sold car covers and they had really customizable catalog items. You could pick six or seven different filters and then they’d be like, “Okay, this is the exact car cover you needed.” And the look-ups, when you would look up the historic orders and try and string together API calls, you end up having to make many successive ones the way it was set up. This site had gone through a few people’s hands over the years. It wasn’t, I’m not saying the most optimized site, but it was working very well for them. You ended up making a lot of these successive API calls, some of them would time out. Some of these APIs and the database they were using was really old for really old cars. They hadn’t used them in a long time. They weren’t indexes on certain tables. So the same type of functionality that I had built around how to sync catalogs differently, was then able to be reused for this brand.

And they said, “Hey, we’ve used a bunch of marketing automation platforms and they always have a hiccup here when it comes to the category items for this catalog.” We were able to use that same code to avoid syncing certain things. So, that’s the kind of lesson really that I would like to impress on people with WooCommerce is like, when you’re building for a platform like this, you really want to think about the future. And you don’t take anything as a one-off, but you add to your collective strength and this collective strength of your code every time you get an opportunity.

In software engineering, we always say, “When you enter a file, try and leave it better than it last was.” Maybe the spacing’s a little off, maybe you could add a comment, you could add some tests. It’s the same thing with an integration like this, when you’re working with WooCommerce and you find a new merchant who’s doing something differently, take the opportunity there to make your product better.

Jonathan: There’s a couple of things I love about this. The first is, so for a lot of folks who are building native WooCommerce plugins, extensions, et cetera, you’re describing a familiar process. What you’re describing is, unfortunately, and we’re hoping to see this change, a little bit rarer in the SaaS world when they do integrations. So you, to me, are describing quite an ideal where you’re taking the time to understand the differences and similarities of WooCommerce as an ecosystem and iterating based on that. It’s also cool for me to see how your own background personally gives you the context. I think this is often overlooked in this world of…

Specialization is inevitable, and there’s something really valuable to say, “How do you put teams together where you have folks who also have range and that broader context?” Because part of what I’m hearing you describe in your experience is, you have that range that helps you look at a situation. And whether you’re doing it yourself, whether you’re directing a team, you end up building much better products as a result of, okay, they saw this repeat in the last customers case where other platforms had the hiccup there. And it could be as simple as just having lacked the range to realize that, okay, we can dig into WooCommerce and we can solve this. So, I think that’s great.

David: I appreciate that. And really, that’s a huge part of the culture here is the willingness to take things further to the ground that other people sometimes aren’t willing to. I’ve had time before, I remember a specific instance couple of years ago, where we had a customer who was having a challenge. There was a way to solve that challenge short term. It wasn’t a hacky solution, but there was a workaround and it could work. But I set up a meeting with our chief product officer, I met with him and I wanted to call out this situation and say that this is an opportunity. If we can get this right in a scalable way for this customer, we know there’s many more behind it. And it’s going to allow us to be able to do something that others can’t. And it wasn’t this exact same example.

But the example previous of, if we had just said, okay, we’ll just change the catalog sync here. And we’ll just not sync your catalog, no problem. You can just do something else. We wouldn’t have had the solution the next time the other brand came to us. And when that second brand came to us, that experience and being able to say, “Yes, I have the PR that changes our WooCommerce catalog.”

Being able to speak through that with their developer, who’ve been burned several times. They, at that point, want to speak to someone who knows what they’re talking about, who’s willing to get on the phone, screen share, go through code. Talk through database queries, et cetera. Being able to have that experience is so valuable. So yeah, if I can take one lesson from a lot of this, it’s that, sometimes it might not seem like something is always worth fully investigating and going all the way with it. But if you do do that, you’d be surprised how many lessons there are beyond that initial thing you’re trying to solve for.

Jonathan: And you might find things that you didn’t expect to. There’s something about just being curious enough to stay with something long enough like, “Okay, let’s see where this goes.” I like that.

David: Absolutely.

Jonathan: You’ve learned a lot about working with WooCommerce, for those who are listening, I’m curious about two things. I’m curious about what others who might be working with a SaaS can learn from your experience. I want to focus first on, you alluded to this concept earlier of higher level themes. And it’s like, when you think about WooCommerce and it’s nature, it’s open source, it’s flexible. When you’re approaching an integration, what are some of the things that you’re thinking about?

David: When I approach just say a generic integration, there’s a few things that we are mostly focused here on at Klaviyo, as a company that’s mostly in the commerce space. Is one, what are all of the events possible in the system? So we’re a very event-driven system. We store events and profiles and some other data as well.

Jonathan: Like, this is all the stuff that a customer could do, every possible interaction.

David: Yeah, exactly. Exactly what is possible for a customer to do? They can come to the website, what can they do on the website? Do you offer them a quiz? Do you offer them some kind of experience? Are there things that the person can do outside of just purchasing. Obviously with purchasing, they can view products, they can add products to their cart, they can customize products. And anything that they’re doing there can potentially be a different distinct event. So what we try and cover is, okay, what is the first pass of integration code that we can write that’ll collect what we consider standard eCommerce events? So we can get to a baseline where typical activities, someone’s taking on a website, someone’s taking in email and SMS marketing, et cetera, we’re tracking all that. And then going further than that and saying, “Okay, what else does this platform have? Are there other methods that they store data?”

The process of mapping out events with the WooCommerce integration

Jonathan: I’m curious. That process of approaching integration for WooCommerce and just mapping out events. Was that fairly straightforward? Was that difficult? How did you find that?

David: That’s interesting question. We have a native philosophy here. If you’re a platform for eCommerce, what we consider table stakes in terms of what we need to capture for that. There’s essentially two different ways that we do this. One way we’ll do this is through a backend integration, either using something like a REST API or webhooks to be able to just get historical, which is often a REST-based API historical data.

Jonathan: To pull it from the database.

David: Yeah. And then ongoing data. Then for ongoing data, sometimes there’s webhooks, but oftentimes for something like WooCommerce, we’re going to be delivering a package of code to you, same thing as Salesforce. So in that package of code, we look into the application architecture and try and discover what are ways that we can seamlessly connect to this platform in order to get the data that we need and be able to almost listen or tie into these events.

Jonathan: Are there any aspects of that that you found frustrating or challenging? I’m thinking specifically about other plugins and integrations that would come in and do things outside.

David: Oh, totally. Great point. So oftentimes folks have access to everything.

Jonathan: For better, for worse.

David: Source code. Exactly. For better or for worse. So sometimes some plugins will change the contents of a page, they’ll change data structures. They’ll do things that we’re not quite expecting them to do. One of the benefits, again, is if folks are going to be doing this and they’re going to be customizing their site. Typically, that’s a cultural thing. That company’s okay with that, they’re willing to support custom code. In that case, oftentimes, we’ll work with them to help them learn exactly how our plugin works and how to customize it. Usually they have a good understanding of, okay, you’ve now forked it, you’re on your own version. Here’s how you make updates. When we push releases, here’s how to diff it.

But sometimes we’ll walk them through that if they’re not super familiar with it, or sometimes people don’t take the best approach. And they just said it and forget it. And it’s like, no, you still want to update for security updates. You still want to maintain this code. If you’re going to fork it, you’re now responsible for it. So we try and instill best practices. And oftentimes, I’ve gone through before forking a code, forking a plugin, pushing a change to the main one. And then just showing them. “Okay, look, here you are, you’re pulling it in. Here’s how you diff it. Here’s how you decide what to keep and not.”

Jonathan: Wow. You’re demonstrating a level of confidence and comfort in an open source ecosystem that, to me, is fairly rare. Because what you’re describing there, it fits outside of the typical pretty box of a SaaS of, we don’t have multiple versions out there. And there’s something to be said about working towards an ideal, because what you’re describing is also a source of frustration for merchants and for folks in the ecosystem. Compatibility can be a real headache between plug-ins, or it’s like, okay-

David: Yeah, totally. At Klaviyo, we are builders and we’re willing to get into the nitty-gritty. And that’s something that we’ve instilled from day one on the teams that I’ve been a part of. When I started on the sales engineering teams, which is now solution architecture team, we wanted to help merchants drive results. And we are very customer first. And if the customer wants to do something and they’re willing to customize their site, they’re willing to do these things, we’re going to be there to help them. And show them what the downsides or the considerations are, how to manage your own code in this environment. But yeah, oftentimes in a WooCommerce environment, you have to be willing to get your hands dirty, get into the code and really walk through with folks exactly how it’s working and try and explain it in a simple way.

Our ultimate goal is that folks learn how to use our platform from an API perspective, from a lower level, primitive perspective where they can add customizations and they can do things that are unique to their business to help them drive extra value. And we don’t tell them, “Oh unfortunately, we don’t support that. Or, you need to change this or you’re on your own.” We’ll try and give you the best advice possible. We’ll give you code examples. And we’re always interested, we’re always building and we want to help people find cool solutions. We don’t accept easy nos as answers, we want to be able to push the limits.

Guidance to builders use to proprietary platforms and looking at WordPress / WooCommerce

Jonathan: For anyone in the world, one of the things I’ve loved, we’re seeing more people from the world of SaaS come into the ecosystem, which I think is great for a lot of reasons. You guys are in a great spot. And part of it, I see, is because of this wider range, this approach that you’ve taken, this philosophy, being builders, as you described it. And I’d love to see more of that. What general guidance would you give to a SaaS who is entering into this open source ecosystem? Maybe they’ve just worked in closed proprietary platforms and now they’re looking at WordPress, they’re looking at WooCommerce. Any broad pieces of guidance that you’d offer based on what you guys have done.

David: Yeah, sure. I think one is, not taking certain things for granted when it comes to code and when it comes to APIs. So if you’re working with a SaaS company, they’re typically going to have very standard, very stable APIs because they’re delivering this to thousands, potentially hundreds of thousands of customers. They don’t have a choice but to do that, or else they’re in trouble. They’re going to hear it from everyone and their customers are going to be unhappy.

But in an open source environment, the API you’re expecting from one merchant could be completely customized from a different merchant. So having good error handling, having good retries in the middle tiers that you’re building when you take an API request in and you ETL it, you make changes to it. Try and build knowing that that system and that area of the app is going to need to be customized.

Jonathan: Cool. Anticipate it.

David: Building in for flexibility, so being able to say, “Hey, something as simple as when we sync in the catalog, this is the field that corresponds to the catalog name.” However, making that customizable so that another customer, maybe they call their name something else. This was a big thing in Salesforce Commerce Cloud, you could change all of the properties on objects in the system. So you might have a catalog object and you’re expecting the description field to be the name of the item.

But in Salesforce world, they have C__ for custom fields. You might have C__ for all of the fields that that customer cares about. And then some random name, like custom description. So if you build a one-off… If you build an integration in a way where you’re only expecting one type of data, but that data, the keys need to change, the values need to change. You can be in a situation where now, “Okay, well, how do I do this? Do I say really naive approach, like, well, if it’s this customer do it differently?” And that happens all the time. Then you end up with this crazy code where it’s like, “Oh man, I don’t even know what code path we’re on, it’s depending on the customer.”

So building integration-level configuration in, where you can almost have a manifest file or some kind of JSON file, YAML file, where you can reference that and you can quickly change that for different customers. So I can look at the file for one customer and say, “Oh, okay, there’s no custom mappings here. Everything looks pretty good.” But I could look at another one and that could be a 30, 50, couple 100-line file, potentially, that maps differences. And then being in this system like that, it’s much more scalable and it’s testable, and you can add these features to add customization.

Another thing, in some platforms, I won’t name names here, but it’s not WooCommerce. They might have transient 500 errors that happen regularly. And your handling of that typically might be like, “Oh, this is pretty bad. We’re getting a 500 from the company servers.”

The reason the extra work on a WooCommerce integration is worth it

Jonathan: My last question for this at the moment. The work that you’re describing, it makes sense. What is your perspective on why that works.  The nice thing about a proprietary platform is that it’s a lot of fixed things. It’s like, you know what to expect. If you’re building an integration for Shopify, for instance, on the whole, you know what to expect. And you can predict that, et cetera.

There’s a lot of ways to handle it. You can make a ton of assumptions fairly wisely. With WooCommerce and open source, you can’t really do that. What is your perspective on why is it worth all that extra effort? Because you have to put a lot more work to do a WooCommerce integration than you would have another one, presumably.

David: If you think about it, the question almost answers itself in a way where it’s like, if anyone can build an integration to a platform that’s SaaS and that’s very predictable. I’m not saying anyone can. And you mentioned Shopify, we’ll put our Shopify integration up against anyone’s. But when you take that time, it’s really similar. It’s not actually that much different, because Shopify has robust APIs and there’s a ton of different stuff you can do with them that not everyone is doing.

You could go further, we could go further and we will be going further. We just had a big announcement with them, we’re going to be working hand-in-hand with their product team too. And there’s a lot more we can do. But especially in an open-source world, when we’ve put in that level of research, development, and knowledge, we have that much bigger of a moat in that world because we’re years ahead now.

Jonathan: And you have the understanding. You have the understanding that you get through what you’ve earned by dealing with customers, by anticipating. “Okay, this customer’s using this system in a way that we didn’t expect, yet it’s working for them. And now we can take that learning and apply it elsewhere.” I like that. That’s cool.

David: So over time, it gets easier and easier. Then we get those situations where the car company comes to us and says, “Hey look, we’ve tried a bunch of different things, nothing works. We don’t think it’s going to work.” We’ll get on the phone with you since we’ve heard of you before, but, again, it’s not going to work. And you actually really open their eyes to them saying, “Oh wow, you guys know way more about WooCommerce than we do. We have one site, you guys have however many customers you have. Clearly you guys are experts here, we’re willing to trust you.” That gives you a huge opportunity. Like you said, WooCommerce is a massive market. It’s up to you to decide if that market is worth it to your business, but I’d have a hard time hearing an argument that it isn’t worth it.

I think it’s pretty big market. I don’t know what kind of markets you’re going after if WooCommerce isn’t big enough for you. But I think that there’s certainly opportunity there. So by building that skillset, by doing the things that we talked about, where you’re reinforcing really good habits. And every time you work with a merchant, every time you see something different, you’re making yourself better, you’re making your product better. Over time, you’re going to have something that’s really great and very hard to recreate without putting that kind of work in over the years.

Jonathan: It’s a great mote. David, this has been fantastic. Thank you for the time. If folks want to learn more about you or connect with you, what’s the best way for them to do that?

David: Yeah, totally. If you go to klaviyo.com, you can learn more about Klaviyo. Then if you’re interested in some of the stuff that I’m doing and the teams I’ve worked on, you can go to developers.klaviyo.com, where we have a developer portal, our API docs and all the good stuff that makes Klaviyo work from a programmatic level.

Jonathan: Awesome. David, thank you so much. Appreciate your time, and we’ll see you next time.

David: Thank you very much, Jonathan. It was great to be a guest. Thank you again.