Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about how to build more successful integrations. They discuss how to approach the different areas of risk including work estimates, API integration, co-marketing opportunities and more.
Items mentioned in this episode:
Welcome to Startups for the Rest of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching and growing software products whether you’ve built your first product or you’re just thinking about it. I’m Mike.
Rob: And I’m Rob.
Mike: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. How are you doing this week, Rob?
Rob: Doing pretty good, man. Just doing a lot of work on TinySeed. It’s been fun to start have more and more exposure to more and more startups. We’ve had a lot of exposure to a lot of different founders of startups over the years through all the stuff that we do with MicroConf and book, blog, podcast, etc. Then I felt like I leveled up when I started angel investing and got in depth views, ongoing longitudinal of a more companies and TinySeed feels like another leveling up for me. It’s just seeing a lot of different data, a lot of different applications, and seeing what’s working, and what’s not, tactics, strategies, approaches, even what is working with the founders who are successful and not, that’s been a fun thing to continue to begin to.
Mike: That’s cool.
Rob: How about you?
Mike: Well, on my end, I’m in the midst of rolling out some Bluetick updates. The main focus here is to provide, I don’t want to say platform, but more of a mechanism for me to do more in the future in terms of displaying emails inside of the applications. Right now, I can send emails out and you could see those emails, but you can’t see the replies to those emails in there or see the history there. Some of these updates are going to allow people to do that and also, give people the capability to inject Bluetick into existing conversations which is not something that it’s capable of right now.
I had actually answered somebody’s question through Twitter the other day. They were asking, “Can it do that?” I was like, “Not yet, but that’s on the roadmap but it’s coming soon. It’s coming in the future.” This will put me in a much better position to be able to do that. And then there’s also various things with the Google authentication stuff that’s in there. Frankly, I’m worried about how that’s going to turn out because it’s a completely opaque process. I have no idea what the end result is going to be so I’m still, I don’t want to say sweating it out, but what is going to be the end result of this.
Rob: Sorry. I don’t know what else to say. That sucks. Goodluck is probably…
Mike: I guess. I mean, there’s really nothing to say. It’s just waiting for them to go in. I don’t know what their checklist looks like, I don’t know what they do or anything. It’s a huge hole, I’ve no visibility here and it sucks. There’s nothing I can do either which is the worst part. It’s just they’re going to either approve it or reject it and they’re going to move on with whatever their timeline is which they’ve been fairly vague about until just very recently where they’re like, “Oh, yeah. You only have three days left.” I’m still waiting to hear from them so if anyone here works in Google and is involved in that process, please email me.
Rob: Yeah, email Mike. Due to some recent fixes that I mentioned last episode, fixes to our WordPress theme, comments are now appearing to end-users and there were a couple that I want to read through.
Episode 436: How to Respond to Customer Suggestions. Steve says, “Great podcast. I’ve made every mistake mentioned in here plus a few more. We have one additional solution while working with customer request. I had found that if a customer wants a specific feature and it makes sense to them in a product, though they want it now and you see it down the road, charge them to put it in now. We charge it as an expedited feature release, it has helped us grow Skills DB Pro…” which is his product, “…to an enterprise level offering while getting paid along the way. One more bootstrapping thought.”
I think that’s a good one. It’s not something that I tend to do with SaaS apps, but back when I had these one more time downloadable stuff, we definitely did it on a number of my products especially the ones that were smaller where a few thousand dollars and kind of expedited feature, this actually moved the needle on the product versus if you’re doing million or more, worst if you have a seven-figure SaaS app then try to charge a few grand to expedite a feature, it’s almost not worth the hassle is how I found it. But I think that was a cool suggestion that some folks might be able to take advantage of.
Mike: Awesome. Anything else?
Rob: Yeah, we have a comment on episode 437 where we talked about MicroConf Europe. I think this was back when we were still trying to figure out where it’s going to be or maybe we even said Croatia, but Rob said, not me, a different Rob says, “Come to Barcelona.” What do we say to that, Mike?
Mike: Do you live in Barcelona?
Rob: No. Well, that’s the first thing because everybody wants us to come to their city, but we have. We came to Barcelona twice.
Mike: Yup.
Rob: We tend to go to cities two years in a row and then we move on to keep things varied. Episode 440, How to Build Case Studies That Don’t Suck. Sarah said, “Great episode as always. You mentioned a book called the Hero’s Journey. There seems to be a few around with that name, can you give any additional details of the right one?” I don’t know if I mentioned a book, but I did mention Joseph Campbell’s Hero’s Journey. I never read a book about it. I tend to go Google and there’s this amazing diagrams and in-depth articles. I mean, the first result on Google is amazing, and it’ll give you the whole overview. Then maybe Joseph Campbell wrote a book called the Hero’s Journey. You can totally go to Google for that but frankly, just getting the idea of what a hero’s journey is like is pretty easy to do from the googs.
Last comment for the day, episode 441 where we answered some listener questions, and then in our aftershow, we talked about the first MicroConf Dungeons and Dragons game. Patrick Mckenzie, his character died early on and he became the final enemy, he was the boss, he was voicing the boss. Christoph Engelhardt chimed in and he said, “My biggest question is what kind of enemy in Dungeons and Dragons game constantly mutters ‘charge more’. Okay, I’ll see myself out.” I thought that was worthy of mention. One of the few funny lines I’m sure that will happen in today’s episode; one of the very, very few, Mike.
Mike: I don’t think I’ll be in any of this.
Rob: That was it. That was all one and done. Today, we’re talking about successful integrations. You want to dig us in?
Mike: Sure. I kind of based this outline loosely on some of the challenges that I’ve encountered integrating with other apps, taking Bluetick and just whether it’s integrating with IMAP servers or going into Zapier or other third-party applications or even using certain libraries, like code libraries. Some of this is retrospective like, “If I were to go back and do it again, how would I approach it?” Because there’s certainly things that I look at now and I would’ve done very differently and then there’s other things where I don’t know how much I would have changed or how much it would have changed, what the end result of that was. I think that these are the things that I’ve learned along the way of doing it and that are generally applicable to most people if they’re going to look to integrations.
I’m sure you have a ton of experience here in terms of taking Drip and integrating it with, I think it was like 30 or 35 different other applications, and incorporating them with Drip throughout it’s, I’ll say, rise to fame.
Rob: Yeah, I mean there was that, there was HitTail. I did, I don’t know, it wasn’t half a dozen, but it was approaching that, DotNetInvoice did a few. I had multiple apps, many apps I would say, that we’ve done integrations. Some successful, some not, some technically successful but revenue-wise, they weren’t that great and then others that were pretty simple and easy-to-build that wound up having a big impact on revenue. Yeah, a lot of learning and some do’s and don’ts along the way.
Mike: Before we dive in, what I want to do is provide a definition of this so that we’re working from the same page here. I’ve loosely defined integration as, it’s a part of your business where there’s something that’s handled internally and is reliant upon a third-party. Essentially, it’s outside of your direct control and there’s varying degrees of visibility and influence that you have over whatever the processing is or procedure or how it works. Some of the examples of those are things like code libraries or third-party APIs. Baremetrics, for example, is heavily reliant upon Stripe’s APIs. If those Stripe APIs went away, the business goes away.
I think a lot of discussions we’ve had in years passed about integrating with Twitter is they decided on a whim to go a route and either change the process of who is authorized to interact with their APIs or who has them available or even what you can do with them. Obviously, all these large companies like Google, and Facebook, Twitter, they all have varying things that they want to do in the future and those may directly conflict with you as an entrepreneur. These are areas of risks. Those are the types of things that you want to keep in mind when you want to integrate with somebody or something outside of your company. That could be software integrations, it could be business processes, it could even be a joint venture that you’re doing with somebody.
But I think the focus today is going to be more on the technical side of things but also taking into account the inter-business relationships as well because you have to know that the person you’re working with or the business entity on the other side isn’t going to totally screw you and if they do or if they could, what ways might those be. It’s really just providing some visibility to those areas of risk.
Rob: Right. Building your app on someone else’s platform where if they turned off the knob, you would lose 50%-80% of your revenue overnight, that’s one thing, and that’s platform risk. You can de-risk it by going to multiple platforms, sometimes you don’t need to de-risk it. It does impact sales multiples, if you ever try to sell a SaaS app that is entirely reliant on a platform and you don’t have an official contract, it’s a risk, so it requires to look at it and factor it in.
We’re not going to dive into all of that today. This is more about building individual integrations. You’d think about Drip that has all these incoming stuff from Stripe and from Shopify and from Event Pride, any one of those going away would have been a bummer because people want it and used it but it would not have been business-ending. That’s really more of the integrations we’re talking about today. We’re talking about both the process, the dev side of building it, the business development side of, how can you leverage that to get more customers and leads and we could touch on like deployment support and that kind of stuff.
Mike: As you’ve said, the best case scenario is really, if something goes away maybe you’ve lost some time or money and that’s about it but the worst case is everything that you’ve built is effectively gone and that kind of leads towards building on somebody else’s platform and you just have to evaluate that as a risk. We’re going to start through this list.
The first one is what level of effort is going to take to build something. I’ll […] up this by saying that I think in most cases, your estimate to build an integration are going to be too low by a lot. That will change over time as you get more familiar with building integrations and you create more infrastructure in your own application in order to build those things but what I’ve found is that there’s a few different places where I thought things were going to be in a certain way and it turns out that they weren’t.
For example, documentation is an area where when you’re trying to build a third-party integration or integrating to something else, I found documentation tends to be lacking, even if the documentation is there and it seems to be extensive, what I’ve found is that a lot of times that documentation is inaccurate and it’s because companies don’t keep their documentation up to date. There are places where it will say one thing and is absolutely not true or it documents in a certain way and it says, “Hey, this is how it works.” When you go start implementing it, it turns out it doesn’t actually work that way. These things sound like they shouldn’t be that big of a deal but in some cases, they really are. If you designed everything in a certain way, those things really throw a wrench into your plans.
Rob: Yeah. There’s an interesting X factor or a variable that is outside of your control that gets thrown in when you’re dealing with someone else’s API. It could be bugginess or it could be docs that are out of date. There’s a bunch of different things. It’s different when you’re just building your own app. You know there are going to be things that you can’t control in terms of, “Oh, I run into this problem. I couldn’t solve it quick enough. There’s a bug I couldn’t find for two hours,” or whatever, but external APIs can be one of the most frustrating things to develop against.
Here’s the thing, we got to the point with Drip since we’ve built so many of them, we basically almost by looking at documentation and whether we knew the founders or not, whether it’s a big company or a small company, we could gauge like, “Oh, this is Fortune 500 integration and they’re using SOAP. This is going to take a week to build,” versus, “Oh, it’s a REST API written by some […] developers that we know. We can probably literally build what we need in four hours.” I mean there were integrations we would get done in half a day. It’s because we have a whole repeatable system and a bunch of code on our side to help do that copy/paste and polymorphism and that kind of stuff but we would ballpark engage, “Yeah, I think this one is going to be a lot worse.” It’s like all APIs are certainly not created equal.
Mike: Another thing I’ve run into is there’s time that you’re going to have to do some sort of black box testing to figure out how things really work especially when you’re going up against external resources or external APIs that are providing data for you. Interesting thing I ran into was there was a code library I was using that says, “Oh, if you pull this information back, you get a list of strings over here and you get a list of integers over there and they represent the same thing.” Early on, I was trying to work with those and pull the data back and one of them took five seconds and the other one took 60 but it’s supposed to be identical data. The numbers, the integers should have been a lot faster and they weren’t. I ended up using just the strings, that worked fine.
Recently, I’ve gone back, and I’ve been doing some more test performance on that section of things and came back and said, “Why is this taking so long? It shouldn’t take that long.” I found some access to some additional logging capabilities and I printed it out and it turns out they’re actually returning not just those numbers but also a set of dates. I was like, “Wait a second. Why is this requesting dates?” It’s not even actually requesting one of the information I asked for, it’s requesting this other thing, and then just interpreting it and throwing those integers in there. It actually doesn’t even work. Like, “Wow, that’s just painfully wrong.”
Rob: That’s amazing.
Mike: Yeah. It works but only because of some other thing that happens to be going on. It’s issuing the wrong command to the server but those are the types of things that you’re going to run into and you won’t, since you don’t have the visibility into those things, you can’t troubleshoot somebody else’s code or somebody else’s server. It makes it difficult to find those things and it just takes longer. You have to do timing performance, benchmarks, and see how much memory allocation needs to be done for different things. You may not be able to do everything all in one shot. Those are the types of things that—it just takes longer, makes the process of implementing especially the early integrations that you do, just makes it take that much longer.
Rob: Here’s something I’ll say on how to streamline this. If you’re only going to build a few, then just do what you’re going to do and go straightforward. There are reasons to do this: a, it makes your product more sticky because you can get data from more places and therefore users get more value out of it; b, it makes your customers lives easier; and c, it can be a co-promotion opportunity. Off the top of my head, those are the top three reasons to do it.
If you’re going to build a bunch of them, then you’re going to want to standardize on the code side and like I said, develop something where it’s easy to just pop them in, you don’t have to build custom UI for each one. I mean, again, look at the Drip UI and we just pop an item in the dropdown list to add the next trigger or action that’s triggering something in Drip or sending out an action, something that goes out of Drip.
The other thing to think about is or the way we were doing it was, if I recall, we have three levels. We had a V1, V2, V3 of any integration that we did almost without fail where we would build a very simple integration first, and that was our V1, and that would typically take less than a day to build. Sometimes, it only had one or two triggers, one or two actions, something like that. It was easy to build, we’ve got two, three API, we’d push it live, we’d promote it, we’d see who used it, we’d see the request.
The best-case scenario is that we’ve got a bunch of people saying, “Oh, this is cool except for it doesn’t do this for me.” It’s almost like customer development where we’re iterating on the feature, almost like it was its own product because Drip had—off the top of my head—I’m going to say 20 different triggers and Stripe has 20 or 30 different actions. Well, there is no reason to build essentially 50 endpoints, 20 in and 30 out. Again, don’t quote me on those exact numbers but you get the idea of what I’m saying. There’s a lot. It’s a lot of work, it’s a lot of code to do.
If you build two in, two out, pretty simple, you throw it live and then as people ask for stuff, you can add another one in almost minutes. I mean, you have to write unit test and stuff but it’s very trivial to add. If you get enough people asking about it, well, you take it to that next level where it’s a tighter integration, you can add OAuth later. At first you can paste an API key which is a little janky but then OAuth becomes the V2, and you just build tighter and invest more in that, the more people who use it. That was how we did it and it seemed to work out pretty well in general.
Having the ability to watch the actual user behavior on your integrations before investing weeks of time is hugely valuable because it can save you a lot of time. There were integrations that we built, that V1, and 20 people used it out of thousands of customers, and we never did OAuth and we never added that extra week or two of development on it because there was no business case to do.
Mike: What I like about the strategy you just outlined—doing the V1 and then V2 and then V3—is that it allows you to come back and start very simple. Then as you start to see the technical problems with it, but also the features and functionality they’re missing, that customers are asking for, it allows you to fill them in afterwards. You don’t have to worry about as much about going back and rewriting some of those things that you’ve already built in order to satisfy what the customers need because you didn’t build very much to begin with. You did it really more or less to help pull that information out of the customers and find out what it is that they wanted and then take that forward.
That’s actually a mistake that I’ve probably made early on with integrating with Zapier is that I put too many things in there, but it was partly because customers were asking me to do a lot. I don’t what to answer how I would change that, but I think that I would probably spend a little bit more time on going back and verifying with Zapier directly like how this should have been done.
Rob: Yeah, it’s easy to over build. You get in there and you think they need to be able to do everything that they can do through the Bluetick UI or everything that the API offers, they need to be able to do that in Zapier. I would say that’s not true for a V1. You may miss something, but take your best guess, 80/20 it. What are the 2 out of 10 things that you think or you know people are using or your gut feel of what you think they’ll use which is sometimes you just don’t have the data and then pop it in. When they’re like, “Oh, I also want to do XYZ.” Well then you put that in your queue, and you build it out as soon as you can.
Integrations are—they’re a curious thing because I remember with HitTail, we skipped this with Drip too, but it was like, “Do you integrate with Shopify?” It’s like, “What do you mean by that? What does an integration mean in your head? Does that mean that we’re taking data in from them and we’re triggering things? Does that mean you want us to pull data and display it as a report? Does that mean you want us to push things into your Shopify store?”
Same as Stripe, “Do you integrate with Stripe?” It’s like, “Yeah, we do but what do you need it to do?” It was often digging in questions and then they would have a use case typically. It’s like, “Well, I want once someone purchase, I want to be able to mark them as a customer and drip.” It’s like, “Well, yeah, of course. We do that.” Or, “Once an invoice is created on the second Tuesday of every month, I want this and that to happen.” It’s like, “Oh, we don’t handle that use case, but we can build that.”
Saying integrating with Basecamp or Highrise or with Slack, that can mean a whole slew of things. Integrating with Slack can literally be, “Oh, I’ll just dump a message in there when someone says something.” It’s an integration but it might not be what everyone has in mind. You often want to dig in if people are asking for these things and find out really what is your exact use case and then just build those one at a time but build it in a framework such that it’s easy to add other functions.
Mike: Yeah. The question that I’ve kind of usually responded to for those types of request is, “What is it that you’re trying to do?” Because usually, that’ll entice people enough to give you the information that you need to either extrapolate it or what you need to build or what sorts of things they’re trying to do and whether it’s even remotely possible. If it is, then you can dig in a little bit more with the technical stuff but usually, at a high-level, it gives you enough information to say, “Yes, this conversation is even worth pursuing or it isn’t.”
Rob: Right.
Mike: Next step we’re going to dig into is the actual API integration itself whether you’re calling an external API or they’re trying to call back to yours from an external application. What I found is that, because there’s so many different ways to design an API, it’s probably not going to be likely that your API is going to be able to be used directly by the other application. This applies whether it’s having to respond to webhooks or accepting them or tracking them or just make external function calls.
If you have an external application that’s calling into yours, they already have a standard way of doing it. You may need to change how your product works. If you’ve already built an API, it may not be the easiest thing in the world to change your API especially if you have other customers interacting with it or your application depends on it. Bluetick for example is a single-page application and it’s got an API specifically for the app itself, it’s also got a public API and then I have additional endpoints that I’ve created.
This is one of the, I’ll say, hacks that I’ve learned is that creating your own dedicated endpoints for other apps could be in your best interest to do. It sucks to have to maintain them in addition to the other code that you have, but it may be the best way to go about providing a mechanism for them to talk to your app without having to rewrite all the different things in your app. Even if you would have just two of them that need to call into your application, they may be doing things differently between each other and then your application may be doing something else as well which makes it hard. You can’t standardize on one thing that’s different for three different people. A dedicated endpoint for each of them is a good way around that. I won’t say the best way, but it is a way that is workable.
Rob: Another thing to think about is rate limiting. I think I’ve talked a little bit about how segment, well, there are few people, segment was the most notorious for it a couple of years ago, but they would accidentally DDoS us. Someone would activate something, and it would just hammer your API and we had rate limiting in place. We had a Ruby Gem that basically sent back, I believe it’s a 304 response, 403, there’s some response where you encode. It’s like, you’ve been rate limited, you can send this much per hour, and wait this long before you can send your next batch and they just weren’t honoring that. There were several that weren’t honoring so you have to code the work around those. I know that Zapier has rate limits and we coded early on to help with those.
It’s one of those things that in the early days doesn’t matter and as you scale, it matters a lot because it’ll either take your API down, it could take your app down, your database down, it can take web servers down, or it can mean, if you’re not queuing things and you’re hitting and you’re getting rate limited, you could lose customer data. If you are queuing them, it could back your queues up because you have all this retrial logic. If a failure happens, it’ll just fill your queues up and say you have to expect rate limits and it’s a bunch of code, it solve problem logically but it can require a lot of code on your end to properly implement rate limiting.
Mike: Another thing that’s similar to that which is parallel request. You may end up with request that are coming in on your API that are close enough to each other where if that resource doesn’t exist, for example, then it needs to be created. If you don’t have your transactions set up properly in your code, then you can end up with duplicate resources created inside your app and then suddenly, things start to fall over because it’s basically what amounts to a raise condition, which you never would’ve run into in normal interactions with your app because users aren’t clicking on things with milliseconds between each request. If that happens to your app, if it’s coming to an external API, that can easily happen. You do have to be careful and cautious about those types of things which some frameworks are good about transactions and some are not so much.
Another thing to think about when you’re looking to integrate with an external API is what customers are using that and what visibility do you have for the other side of things. If you’re receiving commands or queries from another system, can you log into that system and see what has been initiated, can you see what has been satisfied, can you see the errors that we’re running to? Because a lot of those things, you may not necessarily have the information on your own servers like there could be requests that’s going out. You may see the request come in, but you don’t necessarily know if it was responded to properly or it’s sending back the wrong data.
If your code is incorrect or it’s not responding properly, how would you know that? The only way to know that is to go to the other side and look from there. Being able to monitor things both internally and externally is important. You don’t always get that external viewpoint that you need, and you may not be able to track them down to particular customers either. If you see an incoming request not just, why did it come in, and where did it come from, who is the vendor, but what customer of yours is that request associated with. If you can’t see those things, it makes it difficult to troubleshoot, it makes it difficult for you to offer support for your own customers.
Rob: Another think to think about is when you are building the integration, who can you contact for support. Is the documentation—we’ve already covered a little bit—is it good, is it buggy, is it correct or not? Do you have email access, phone access to a developer on there? Because you’re going to run into problems, and do you have access to a developer? Do you just email their general support that they have specific integration support?
We love integrating with the three-person startup where two of the founders were developers. I mean, those went so smoothly, they could fix things so quickly, and they knew how everything worked. You’d email them and be like, “Hey, there’s a problem here. This is the result we’re getting.” And they’re like, “Fixed.” It was so good. The larger the teams get and if you’re sending an email again, to Salesforce, to their support, to try to get integration, it’s an absolute nightmare. You hear back a week later, and they don’t understand your question at all, and they don’t escalate you, blah, blah, blah. Those are kind of the two extremes that I’d point out but it’s something to think about when building this.
Mike: The last one, typically comes around when there are webhooks of like, “How do you go about testing them?” This also applies to just you sending information over but how do you go about making sure that the stuff you’re developing has a test area on the other side? Are you working with production data? I would hope not but there are cases where you are going to have to do that which means that you have to create an account on their side and use that to do all of your testing and effectively it’s in production but on your side it’s not. That makes it hard because you have to keep things straight locally like, “Oh, is this information here that we’re working with in production or not on their side?” You may have internal flags or toggles or fields that you use to keep track of that stuff, but it can get complicated especially if you’re trying to document that. It’s got to be documented in places where it’s easily accessible by you to understand what’s going on both side and which environment it’s going on.
Rob: And then, as you get it built, there’s going to be an approval in publication process and again, with smaller startups there’s typically not much of a process. You send an email, you say, “Hey, this is live. We’re going to push this live in our UI next Tuesday.” They’re like, “Cool.” With Zapier or Salesforce or someone who’s doing a lot of integrations or having a lot of people integrate with them, they are going to have a process, they’re going to have a checklist of requirements. You’re going to want to look at approval timelines because I know some apps take weeks and/or months to get approval publication timeline after it’s approved.
Is there a beta period? This is something that Zapier I think does well. It feels like a pain when you’re doing it, or it feels like hoops to jump through but they’re doing it because they want to keep the quality of the service side. If they don’t have the beta period and all that where you have to get 10 users using it because they want to force you to work out the bugs basically. I think they do a good job of that. Then how will you get support during beta? How will you provide support to your folks during beta? It’s all things to think about to get it live. Oftentimes, writing the code is the least time intensive piece of this whole process.
Mike: Yeah. I think the piece of this process that does take the most time is just making sure that there is that trust factor there on both sides that, “Hey, this is going to work and is generally going to be good for everyone who’s using it but if it’s not working or it’s buggy or there’s problems of any kind where there’s transaction delays or things are just overly slow or they’re using too much memory or there’s scaling issues on either side, all of those things can essentially erode the credibility of the integration.
At that point, one side of the other is going to want to back things off a little bit and introduces this additional delay. Delay factored just from becoming comfortable with it is important, but you also need to have ways to resolve that. This begs the question of, “How are discrepancies or disputes handled” Those disputes or discrepancies can be like, “We expected this data, we got this data instead.” Or it could be something along the lines of, “This isn’t working right. Why is it taking so long?” Or it maybe it could be a designer or an architectural issue, “Oh, you said that you want to send us data XY and Z but it’s also including this other thing. Why is it doing that? I don’t think that it should.” You have to have someone resolve that.
Sometimes, you’re talking directly to developers. Sometimes, you’re talking to an anonymous email box where you have no idea who’s answering it or what their ability to make change is or even knowledge of the entire system is. Each of those is going to be a different approach but they’re things that you have to be aware of especially when you’re working with larger companies or smaller ones.
Rob: Then something we’ve alluded to several times during the episode is I mentioned there my top three reasons for building integrations and one of them is the comarketing opportunity, the business development so to speak, which is to be able to both promote who you’re integrating with and for them to promote you in one way or another. There are a lot of ways to do this such as joint webinar is a pretty good way. You think about it, if you’re integrating with another startup, you both want the exposure to each other’s audience. If you’re integrating with Stripe or Facebook or Google or whoever, you’re not going to get that, but it’s nice to think about high-touch opportunity to show how the integrating works and the benefit it provides—so joint webinar is one.
Certainly, I found a lot of success with the joint email. We email our list, you email yours. Copromote blog posts also on both announcement blogs for each company. There are the functionality updates whether they handle that via email or in-app or whatever. You can offer in-app announcement on both. Even providing customized landing page that says, “Welcome, Pipedrive users. Welcome, Stripe users.” That they can link to from the other place that you can get is in their app directory, their integrations directory. There’s typically one in the app and out on their public market website. That’s another place you want to be.
From there, we found that building custom landing page for some of them, but not all, worked really well and increased conversions quite a bit. There were a couple of integrations where the clickthrough from the in-app or from their integrations directory on the marketing site to our landing page and then sign-up for a trial was something like 30%. It was outrageously high. We asked for credit card upfront. Typically, the number is very small, and it was 20%-30% and it was shocking. We did so much to tune that page and split test it but the ones where we were getting 3% or 4%, you obviously don’t care as much about those.
But those comarketing opportunities can be fascinating because if you get a big email sent out to 30,000 of their marketing list or customer list or whatever, you can get a nice bump there. But then if you get in their app directory or you get in these other longer, living links basically, you not only get the SEO juice from that, but you then get that flywheel of traffic. I’s not huge, again, maybe it’s 100 visitors a month, so it’s not a huge amount but if you’re getting 10%, 20%, 30% of those to sign-up for a trial, that’s 10, 20, 30 trials every month that shows up. Then you multiply that by 10, 20, 30 integrations and you start to see how you can potentially build a flywheel out of this.
Again, you can’t just take this advice and apply it to your app without thinking, “Does this make sense? Is it going to provide the value? Do I have the leverage for these folks to do all of this?” That is the integration marketing playbook that can help grow your business not only as a one-time thing but as a sustainable approach. With that, I think we’re wrapped up for the day.
If you have a question for us, call our voicemail number 888-801-9690 or email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from We’re Outta Control by MoOt. It’s used under Creative Commons. Subscribe to us on iTunes by searching for Startups and visit startupsfortherestofus.com for full transcript of each episode. Thanks for listening. We’ll see you next time.
Episode 351 | Harnessing the Power of Your Marketing Data
/
Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about harnessing the power of your marketing data. Syncing information between marketing tools is a difficult task and its easy to make mistakes. The guys talk through some ways to make it easier.
Items mentioned in this episode:
Transcript
Mike: In this episode of Startups For the Rest of Us, Rob and I are going to be talking about harvesting the power of your marketing data. This is Startups For the Rest of Us, episode 351. Welcome to Startups For the Rest of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching, and growing software products, whether you’ve built your first product or you’re just thinking about it. I’m Mike.
Rob: I’m Rob.
Mike: We’re here to share experiences to help you avoid the same mistakes we have made. What’s going on this week, Rob?
Rob: Do you ever notice that when you intro the show, you say, “Rob and I are going to be talking about XYZ” and that I say, “Mike and I talk about XYZ”?
Mike: No.
Rob: You haven’t noticed that? Alright. I wonder if anyone else has.
Mike: Why do you think that is?
Rob: I think because you’re actually talking about the conversation we’re about to have because you know that 20 seconds later, we’re going to be talking about this, whereas I’m kind of like putting it up as an intro, as if it was independently recorded – almost like it’s done after the fact. “In this episode, Mike and I talk about blah blah blah.” It’s almost like it’s something that happened in the past.
Mike: Like you’re a time traveler, and you’re doing it in the future.
Rob: Exactly. Anyways.
Mike: Anyways.
Rob: Now that we’ve lost all our listeners, you know what’s up for me? This week – last week, once this episode goes live, Clay Collins stepped down as the Leadpages CEO, and he decided that it was a good time to bring in someone to scale the company. He made specific comments of – which I really respected – like this was his impetus. He initiated it. This wasn’t just him offering flowery language, as some founders get kicked out by their board. They say things like this, but I know the backstory of that guy.
I know the inner workings of what happened, and he said, “Look, I’m really good at growing a company from zero to $10-15 million, and we’re a lot more than that now. We need more process, and we need someone who can really scale this thing up to $50-100 million, so the COO John Tedesco, who I’ve worked with now for a year, in essence, since we’ve been at Leadpages – he is taking over as CEO.”
Clay is really taken some time off. He’s gonna spend more time with his family. The dude is super smart, and he reads a lot of stuff. He’s into investing. I mean, he has enough hobbies to keep him busy, and he won’t be down for long. He’s like one of us, where it’s like you’re just constantly – you have that next thing going. Frankly, I applaud his decision to do this, and I think he’ll have some nice – I hope he’ll have some nice restful time as he steps away from it.
Mike: Honestly, I think that’s really smart and insightful on his part to know really where he fits into the startup process and understanding where he provides the most value and realizing that there’s probably going to be a time, where either he’s not good at it or he doesn’t enjoy it. So it’s better to move things around and put a succession plan in place, so that he can go do the things that he really wants to do or is really good at, versus continuing down that road because you feel pressured to or you feel like you are supposed to do that versus “this is the right thing to do.” I agree with you. I think that that’s totally the best-case scenario – is he makes that decision as opposed to somebody else making it for him.
Rob: Right. And making it for him, like kind of overstaying your welcome, and then people are like, “Um…” They’re bored like, “Um…” Your C-Level Suite is like, “Dude, what’s going on here?” Yeah, I agree. It is genuinely – obviously there’s always uncertainty when this type of thing happens. From my perspective, when I first heard – which is a while ago – I was like, “Alright.” Clay and I worked close together, and I know him. He’s a known quantity. I know how we interact together, so I was a little concerned because they did a national search for replacement. They didn’t just say, “Well, the COO is gonna take over.”
My concern was like, “Who’s that gonna be? Is it gonna be someone that I don’t know that runs a company completely different than Clay did? It’s gonna be this big shakeup that I’m not going to enjoy working with all that stuff,” and then the more I learned and the more I heard they were thinking about going with John, I had an inner sense of relief because he’s a known quantity. I’ve worked with John, so there’s obviously gonna be some changes. I’m sure, John’s gonna run it a different company than Clay did, just because they’re very different people, but I’m really genuinely curious and interested to see what’s coming here in the next couple of months.
Mike: I wouldn’t think it’s unusual for a company to run a national search like that and then end up hiring somebody internally anyway. I would imagine that even if somebody applies internally – if they were planning on doing a search for a CEO anyway, they’re gonna do that just so that they get a lay of the land and see if there’s other things that they’re missing because the last thing you wanna do is promote somebody from within, only to find out that they’re really not a good fit for that particular thing and you feel almost obligated to give them the position, versus if you actually do a full-blown search. You’ll feel a lot better about making the decision – assuming you go internally anyway.
Rob: Totally. It’s almost like a fiduciary duty or could be considered. It’s like we’ve got to protect all the shareholders. Let’s do the right thing, rather than do something that may look like an inside job or an insider – almost like a nepotism thing, although it’s not family, but that kind of stuff.
How about you, man? You are knee-deep in a launch right now.
Mike: Yeah. I sent out my first launch email yesterday and trying to record a video today that I still have not gotten to, and I’m hoping to get to that soon. But I got a few replies for my email that I sent out yesterday, from people who are interested in signing up. I’ve got some other people, who I’ve talked to over the past week or two that they basically just said, “Hey! This is not a good time right now, but in a couple of weeks, let me know” or they’ve got a vacation coming up or they’re gonna be out of the country or what have you.
I’ve got some things that are coming up, but the real impetus is really push hard on the email list this week. I’ve got a series of, I think, four or five emails that have got to go out, and I’ve still gotta write most of them so that’s gonna be the big priority for me over the next several days – is getting those emails written and scheduled, and then making sure that all the signup code is in place, so that people can get in, and they know what to do and have some videos that will walk them through how to do different things. All that stuff. It’s not hard. It’s just time-consuming to be honest.
Rob: Yeah. I know how that goes. How would you describe your mood? Are you excited? Are you stressed out? Are you just wanting to get it over with?
Mike: Real stressed out, to be honest. It’s just because I know all the different things that need to get done. There’s like the short list and then there’s the long list. The short list is the time-consuming stuff that has to be done in a relatively limited time frame, and then there’s the long list of all the things that I would really like to do or should be done or need to get done, but I can push them off theoretically until after the launch date, but I’d rather not, if I could get them in. I just can’t. I don’t have the resources or time or anything to be able to do that. Plus my wife’s out of town this week, which I hadn’t anticipated until after I decided on the launch date, and then I realized, “Oh, she’s out of town from Wednesday morning until Sunday night.”
Rob: Piece of cake.
Mike: Sure.
Rob: These kids are watching themselves, right?
Mike: Right. They’re cooking me dinner and making breakfast, yeah.
Rob: That’s perfect.
Mike: Right.
Rob: Totally not happening.
Mike: Yeah, totally not burning the house down.
Rob: Yeah, that’s pretty much what you’re trying to do. Oh man, I didn’t hear that part.
Mike: Yeah. What’s even worse is on the schedule, it was messed up. I thought she would be back Saturday night, because that’s what the calendar says. She looked at it and realized that on her calendar, it shows that she’s out till Sunday, but her hotel only goes until Saturday. It was like, “Oh, that sucks!” because I really thought – it was two days ago, when I found out that she was not gonna be back until Sunday.
Rob: I’m sorry. That’s not cool. Yeah, [inaudible 0:07:31] when you get this.
Mike: It’s nobody’s fault.
Rob: No. I don’t mean, not cool on Ally’s part. I just mean it’s not cool when that kind of stuff happens, and this is entrepreneurship. This is launching a startup, while you have a real life and you have a family, and this kind of stuff happens. It’s a drag, and it stresses you out, but it would almost be too easy without these wrenches getting thrown into the works.
Mike: Business would be awesome if you didn’t have to worry about customers or money.
Rob: Customers, people, money. Yeah.
Mike: Support issues. Yeah.
Rob: Yeah. Cool, so what are we talking about today? Is it one of the most fascinating topics that we’ve ever talked about on this podcast?
Mike: Absolutely. It’s all about harnessing the power of the marketing data that you have available to you and making sure that the data that you have in each tool is accurate, which doesn’t sound very sexy, but at the same time, it’s very useful. If you don’t have things wired up properly, you can very easily miss things from one tool to the next. Or let’s say that things aren’t getting synced properly between your app and either your marketing software, like your marketing automation software or your email list software. Your billing code, for example, because somebody can sign up for an account, but they may use a different email address – is their generic catchall for all the credit card statements and stuff that they sign up for because they want all of the billing emails to go there. But they don’t want to use that email address to actually sign up for your service, so now you’re going to end up with mismatches between things.
What we’re going to be doing today is talking about how to synchronize some of that information between your prospects, leads, and the contacts and the fact that – of course, generally doing that sucks, but it has to be done. One of the things that I’ve noticed is that inside Drip, for example – I think that Drip does a really good job of this. But they differentiate between tags, events, and custom fields. Since I look to that as the source of authority for those types of things, why don’t you explain a little bit about the differences between them? Because I think you guys are doing a fantastic job of explaining it on your website.
Rob: Thank you. I appreciate that. The reason we do a good job, I think, is that we have been asked that question, especially in the early days, so many times – “What is the difference between these things?” To me, this is the heart of marketing data. In almost any marketing system you go into, you’re gonna see tags and custom fields, for sure, and then we innovated in the marketing automation space, in the email marketing space. We brought in events, so we pulled that over from analytics like Kissmetrics and Mixpanel.
Here’s the simple answer. Tags are basically just a string, like a single word or phrase that you can attach to a person, so you typically use it to segment or bucket groups of subscribers. I might import 10 subscribers, and you just say, “I’m gonna tag them with ‘microconf 2017 attendees’.” That tag is just a piece of text, and it attaches to the record. Then you can later search who has these tags. I only want to send to people with these tags and not these other tags. Tags, I think, are pretty well-known, and they’re common now in marketing automation platforms and in a lot of others likes sales platforms and stuff.
Custom fields are really just name-value pairs. That’s how you think of it. If you use MailChimp, they call them “merge tags.” We call them “custom fields,” but it’s basically like if you want a first name, then the name is “first name” and the value is “Rob.” Or you could have last name or telephone number or address, so there’s just a name-value pair. It’s kind of like having two tags that are linked, but really it’s just name-value.
Events are the thing that – there’s no other marketing automation platform that has events, like Drip does. Again, we borrowed it. We migrated it over from analytics. Events are similar to tags, in that they have a name. There’s a text thing, but they also record a timestamp of when the event happened. You can look at how often it happens, so someone could – you can’t have a tag applied seven times. A tag is applied, or it’s not. It’s applied, or it’s removed, whereas an event – you can say they made a purchase seven times. That actually makes sense in the context.
Events also have a payload, meaning they have a collection, almost like a JSON Blob or a collection of name-value pairs. You think about an event like “Made a purchase,” what type of values do you want attached to that? You probably want a price, may want an item title, a skew – something like that. If the event is “Visited a page on your website,” what’s a metadata you might want to know about that? What was the page? Maybe you already know when it happened? Maybe you know how many times they visited this page. You could attach that all to that single event. They’re kind of like, in my opinion, a better version of tags, although tags still have some use.
I realize that was a long explanation, but I wanna describe it like if you’re a sophisticated marketer, it could have been shorter, but I wanted to make it approachable to lay people – basically a lay person. We have a good KB article on getdrip.com, and we will link that up in the show notes.
Mike: Yeah, I think the big differentiator there is just – with the tags versus events. The tags really give you a single indicator that says, “This person fits this particular profile,” and you can’t apply that tag more than once to somebody versus the event, where it can be – like you said, somebody could make more than one purchase. That’s an event. But the tags in Drip will just by default prevent you from adding a tag to somebody more than once, because it doesn’t make sense in that particular context.
The other thing that struck me was the payload side of it, because an event can have a payload associated with it. It’s really a description of that event and all the different parameters or properties of that event, and that may be important for something down the road.
Rob: Yeah, and the way I think about it is custom fields are – they’re like a description of the person, who the person is, because it’s like first name, last name, and properties about them – maybe have their plan and the price they’re paying you – stuff like that. Tags tend to be the buckets or groupings of people, and then events are things that people do. That’s the plain English version of it.
The reason we’re talking about this and defining these things is that tags, events, and custom fields are really the heart of your marketing data. This is how you have information and the learnings about the people that are on your list, coming to your site, etc. I think we’re gonna dive in now to – there are definitely other things, other data points, but these are probably a big part of what you’re gonna wanna try to be syncing between your marketing tools.
Mike: One thing to kind of point out in terms of those things, like Bluetick has tags and custom fields. One thing that I use custom fields for is tying contacts inside of Bluetick to other applications. You’re not always using, for example, a numeric ID or an email address, depending on which tool you’re using. Some of them will use one or the other, or they’ll even have a hash of some other data value or of the email address, and it’s difficult to match the data from one tool to another unless you have that information included.
I actually use the custom field in Bluetick sometimes to attach it to some other products. For example, a pipedrive deal – I’ll add a pipedrive deal ID in as a custom field. That’s the name of it, and then there’s a value associated with it that says, “Here is ID 123,” for example, that you can use inside of Zapier or other tools to tie the data back and forth, or to be able to map events from one tool to another.
But along those lines, let’s talk about some of the different ways that you can map information from one tool to another. The first one is a manual or custom sync. When you’re doing this, really what you’re trying to do is just export data from one tool into another, and you may either be doing that through the API itself or you may be downloading a spreadsheet or creating a CSV file and uploading it. These things are brittle. That’s the biggest problem with this is that the tools themselves – they require a lot of code or engineering work to take those things and translate them and move the data from one tool to another. It’s really hard to keep up with the changes. That’s really the biggest drawback to this.
That said, it can be the easiest way to get up and running or to get an initial prototype of “Hey, how does this data sync or data transfer work?” but longer term, as you expand what you’re doing, it’s probably not a great strategy to rely on that too much because it is probably not automated. Yeah, you could create a scheduled job or a cron job someplace that runs it on a periodic basis, but that doesn’t necessarily mean that it’s going to be the best way because it is so brittle. It can fall down, and when it does, you may not even know that something went wrong or that it’s not doing what it’s supposed to until much later. Then it’s almost too late.
Rob: Yeah, unless you’re kind of at scale and you’re really gonna monitor it. I’ve written some manual – they’re like cron jobs and stuff that would sync up between systems, and it just seems like every three to six months, something would go pretty badly wrong, and I would have to investigate. I have to stop what I was doing.
It’s like if you have developers – have a team of developers and you’re maintaining a whole system, and this is just one piece of it – that’s cool. But if it’s literally you hacking together a PHP script and putting it in a directory and having it run on a cron, meaning on a schedule-basis, that’s not set-it-and-forget-it. You’re gonna need to send yourself emails when it fails. It may die. A bunch of stuff can happen with it, and so this is not an ideal thing, if you’re just running it on your own and you want a set-and-forget solution.
Mike: I think your point about having something break every three to six months is spot on, from what I’ve seen. I used to export the data from Gumroad into a spreadsheet, and then I would take that and then I had a small script that I wrote that would take that data and then upload it into Infusionsoft. Like you said, every three months, something would change, and then something would break. Then I’d have to spend time on it. It just really was not worth the time and effort. Because they didn’t really support a lot of other ways to get data in and out, it just made things harder and more difficult. It’s hard to deal with a time-consuming time sync.
Rob: The problem is as developers, it’s super easy to build this thing for the first time, and so it’s very appealing to do so. It’s kind of like, “I can just hack up a script here in an hour. There’s an API here. There’s an API here. I pull it out and put it in.” You can. That’s right. It’s not that part though. It’s the maintenance of it that’s the pain.
Mike: The next mechanism that you can look at is using a tool that’s built specifically for syncing data. The tool that come to mind right off are Zapier and If This Then That. I think that mostly what I found is that for individual events, this tends to be something that you turn towards. Zapier obviously has a huge base of applications that they work with. I think they’re up over 800 at this point. Finding an integration between one tool that you’re using and another tool is generally pretty straightforward, but the problem with doing those is that, depending on how complex your sales funnel is or your marketing funnel and what data you need to move from one to another – it’s very easy to miss or realize after the fact that you should have been forwarding this particular data over and you weren’t. Then you have to go set it up, and there’s this line in the sand drawn, so to speak, which is not – before that point, you almost have no data. You can go back and upload it afterwards using a Zapier integration and a spreadsheet or something like that, but it still means that you have to do extra work in order to get it.
I do find it really useful, to be perfectly honest. I have a lot of stuff tied in through Zapier, and it’s supported in Bluetick. So I don’t want to make it sound as if that’s not a viable route, but it can be easy to miss things – is really the point – if you don’t have your marketing funnel mapped out.
Rob: Yeah, I think Zapier’s pretty handy for marketing stuff actually. I know we use it with our own internal stuff and in our own internal marketing communications and getting data in and out. I know we recommend it to customers a lot. It kind of takes the place in the short term of a first-class integration, because we build a lot of integrations. I think we have 40-plus that are direct with Drip and something else, but Zapier gives us another – I don’t even know – hundred maybe, and that’s helpful. Then we can get reports on which are the most common Zaps, and then we can say, “Well, we should build first-class integration with that – with those folks.”
From a business owner’s perspective and you’re running your own startup, I think it’s definitely cool to have that Zapier integration. Then I think as a marketer, it can be a really valuable tool. You’re right. There is that thing of if you miss stuff, and then it’s a fiasco. They do have rate limiting, so if you hit Zapier’s endpoint – if an app hits it more than (I forget what the limit – it’s fairly low) – but if they hit it more than X amount per hour, then those things will just bounce, and so that app has to know to retry, which obviously we do with Drip, but I know there are a lot of other apps that are not doing that. There are pluses and minuses, but overall I give Zapier two thumbs up.
Then you mentioned If This Then That, which I’ve always viewed – I think it’s more of a consumer version of Zapier. If This Then That came first, and I remember some people being like, “Isn’t this just a clone of If This Then That?” It was like, “No. It’s like a B2B version.” They integrated with the apps that we, as entrepreneurs and business owners, wanted [inaudible 0:20:25]. If This Then That’s integrated with Yahoo! Pipes and all this kind of stuff on the internet that isn’t necessarily applicable to businesses. But I haven’t actually used If This Then That. I’ve only used Zapier.
Mike: Yeah. I signed up for If This Then That account a while back, because I was trying to link things between Dropbox folders, and it wasn’t – neither Zapier or If This Then That were able to look into a subfolder and monitor a subfolder that hadn’t yet been created. You can point it to a folder, but if you wanted to monitor it for files in directly that folder, it was fine. But if you wanted to monitor for a folder getting created and then files being added to that folder inside – neither one of them can do it. That’s not their fault. It’s basically Dropbox not being able to offer that.
I found the UI of If This Then That extremely confusing. I signed up for my account. I tried to use it. I probably spent several hours on it, and I’m like, “You know what? I’m done.” I literally deleted my account entirely. I couldn’t deal with it. Because I couldn’t figure out how to do anything. It didn’t seem like it gave you access to a lot of the underlying pieces of how it works. Your description of “it’s aimed at the consumer market,” that makes sense to me now, because I was just like, “How do you even offer a product like this?”
Rob: I think If This Then That has done a lot of integrations with home automations stuff. I think Zapier really has not. That says where they’ve differentiated.
There are other alternatives, of course, to these two, and we’ll link up a core, a thread when someone asks, “What are the alternatives.” There’s a big list there, if you’re interested in looking at more, but for my money, Zapier’s definitely the leader in terms of B2B and marketing data that we’re talking about.
Mike: The next mechanism you can try and use is a product called Segment. You can get this at segment.com. It used to be called Segment.io, but the big draw here is that it allows you to essentially replay some of the events that have happened in some of your different marketing automation tools or your different sales tools, and then pipe them to different places. It’s really good for doing that at scale, and because it gives you the capabilities of really just using one snippet of JavaScript, and you can turn on and off different tools in the application that you’re sending data to. And because it gives you that backlog of things, as soon as you connect it to your account or put it on your website, you then get a full history of all the previous things that have happened and can send them into a new tool.
Let’s say that you decide to move from one tool to another. Tool 2 is gonna be the go-to later on. You can always just turn that new one on and pipe all the previous data into it. I always thought that that was like a really fascinating way of doing things. They used to have a different pricing model as well. They would look at the tools that you were sending data into or pulling data from, and they would charge you more based on what those tools were. Like Salesforce, for example, tends to be an expensive tool, so it ended up being in a higher price tier even if you weren’t using it very much.
Rob: I didn’t realize you could replay old events with Segment.
Mike: I’ve not done it myself. I have seen – there was documentation. Like the last time I looked at it, in terms of how to do that stuff, that was my understanding was you could basically replay things to – basically pipe all your previous data into a second tool.
Let’s say, somebody wanted to switch from AWeber or something like that to Drip. They could take a lot of their old data and pipe it from – they used to go into AWeber – let’s say it’s 30 days or 60 days or whatever – and they say, “Okay. Take this 30 or 60 days’ worth of history and send it into Drip instead and replay it, so that that now in Drip will get all of that information.” I don’t know how far it goes back, but that was the sales pitch for it.
Rob: That’s interesting because I was going to say, “That would be hefty if they were keeping all your data forever.” That’s always the thing I thought they didn’t do, just because of the volume that they would have to absorb.
Mike: Yeah. My suspicion is that they don’t do that forever, but I would imagine that they probably have at least a semi-limited history. Even if it’s a couple of weeks, that couple of weeks could be important to you. If you wanted to just try out a new tool, it gives you a much easier way of doing that because when you sign into a new tool, especially if it’s any level of complexity, you’ve got nothing there, so you don’t really have a good idea of what it can do for you. But if you can prepopulate it with actual, live data from your own systems for the past couple of weeks – you sign up, pipe it all in, and boom! It’s there. You can actually use it and see what it would really do for you.
Rob: Yes. Segment.com is a solid tool. They integrate with a ton of things, and as you said, it’s not for the one-off moving tags and custom fields here and there. It’s an event-based system. It allows you – the original thing was that they allowed you to put the Segment JavaScript on your website, and then you could pipe it anywhere. You could pipe in into Kissmetrics or Mixpanel or (I think) Google Analytics. You can pipe it into Drip, which we integrate with them.
You could pull stuff into and out of HitTail, like they integrated with us back in the day. They actually wrote that integration, but now when you do it, I think you have to write your own – is my recollection. It’s a good tool, and it’s for masses of data. I think that it can be super helpful for getting data into and out of systems, and being able to report on them and not necessarily in Segment, but they integrate with a bunch of analytics and reporting tools.
That’s something – some people will come in. they’ll use Drip, and they’ll say, “I want all this fancy pivot table capabilities and blah blah blah. I want all this stuff.” It’s like, “We’re a marketing automation platform. We’re not a business intelligence platform. We’re not gonna build that into Drip,” but here, we integrate with Segment. We send a ton of data to them, so just hook up your Segment account, then pipe that into one of these BI tools and you’re set. You can do whatever you want. It allows us not to have to build the world into Drip and to be able to put boundaries on things.
Mike: I think using it as a data hub is extremely helpful. The downside of it is, of course, there’s a lot of complexity there, too, so you could easily spend hours, days, or even weeks just evaluating it and seeing if it’s gonna fit into your business and just spending the time learning how to use it. I found that when I first signed up for it a long time ago was that it was a huge time sync to really get up and running with it and understand how the different things worked and how it pipes data from one place to another and how you would do some of that data piping. That said, it is really powerful. You can do a lot with it.
Moving on to the next section. I think one of the key pieces of advice in a situation, where you’re trying to get all the data from one place to another is to settle on a single source of authority. That’s a phrase that I’ve used for years, talking about systems management software and trying to manage large numbers of machines, whether it’s a couple of 100 or 25-100 thousand machines all at once.
It’s very difficult to do that, if you don’t have a single source of authority for that information. Because if data gets out of sync, you need to know what is the master source where this information comes from. Who’s the gatekeeper of this?
Let’s say you got Tool 1 and Tool 2, and Tool 2 doesn’t have a piece of information, is it not supposed to have that information or does it not have it yet? You have no idea by looking at that tool or the other one, unless you’ve already decided which of those two is going to be the master data source.
Rob: Yeah. This is actually an interesting thing happening, with ESPs and marketing automation platforms – is we build Drip – I keep bringing back to Drip because this stuff’s really something we have dealt with a lot – is all this data syncing. This source of authority – I think Brian Dunn calls Drip his source of truth, in terms of the data. Or you could call it the customer database. Some people might call it a CRM, because really it is customer relationship management, but that has now been, in terms been bastardized into sales software.
What you’ll find out is if you do a lot of email marketing, then quickly your email provider (assuming it stores data like clicks and purchases and has your tags and has your events) – it can quickly and easily become your source of authority or your source of truth. That’s something we have been doubling down on as we notice more people doing that.
First it was solopreneurs who said, “Drip is where I keep all the data, and I want to get all the data in there.” Then we started seeing two and three-person companies. Now we have five and ten-person companies. Really interesting to see. We’ve [inaudible 0:28:36] down and started building more stuff to allow people to do that, and so I think if you are gonna do a lot of online marketing, that’s something to think about. It’ll probably be a CRM or a marketing automation platform that’s gonna be this customer database for you.
Mike: I think that actually brings up an interesting point that I run to – is that what is the idea or how do you identify who a person is in your source of authority? Is it gonna be an email address? Is it gonna be some sort of a generated unique identifier or something like that? Because it’s difficult when you get into a situation, where somebody signs up like they put in their credit card. All the billing information goes to that one email address, and then they sign up and they have a user account that is a different email address.
In marketing, the automation software – a lot of them, the email address is kind of that source of authority or that unique identifier for that person, and in the case of billing information, especially if it’s a one-user account, now you have two email addresses. It really is the same person, and it’s hard to differentiate between them sometimes. That’s why some people will go towards using a CRM for that, but again, there’s pluses and minuses in both aspects, whether you’re using a marketing automation tool like Drip or if you’re using a CRM. Both of them are gonna have pros and cons for that type of schema.
The last thing to talk about is how do you keep some of these data paths straight? I think there’s pretty basic guidelines about how to track the information flow from one tool to another, but the basic – you can start it out with is just a pen and paper. That’s easy to get started with, when you’re just trying to build out and map what your sales and marketing funnels look like, because you can just really quickly draw something out. But as it gets more complicated, you’re probably gonna have to graduate more towards a tool or a document or a spreadsheet that is going to allow you to put a lot more information in there.
Something that I found useful is to implement some sort of a workflow in either a desktop or a cloud-based workflow tool. There’s a bunch of them that I’ve tried. I’ve tried things like Gliffy. I’ve tried Draw.io. I’ve tried Moqups. I’ve tried doing things in Drip’s workflow tool as well, and that works great so long as you are operating within the confines of Drip. Once you start to go out of that and do things that are not involved directly with Drip, it sort of falls apart a little bit. That’s not a knock on Drip specifically.
Rob: Sure. Just the reality of it – yeah.
Mike: Yes. It’s just the reality of it. That’s not what it was for. The one I’ve actually settled on is a product called Lucidchart. Fairly inexpensive. It’s like $8 or $9 a month for one of their more advanced accounts, but you can get it for $5 a month on the lower end.
Rob: I’ve heard of it. I haven’t used it, but I’ve heard some people speak highly of it.
Mike: Yeah, it’s really good for being able to map out what a workflow looks like, in terms of how people enter your marketing funnel and how they go into another one. Then you can also have a bunch of different things wired together, so you can zoom in on one specific piece of it. Then you can just encompass it and say, “Okay, this is how people get onto our mailing lists,” and that’s like the whole workflow. Then once they’re there, you have a different diagram and document that describes how they move through the sales funnel itself or the onboarding funnel. Each one of those could be a completely different document. You just link back and forth between them.
Rob: I think that wraps us up for the day. If you have a question for us, call our voicemail number at 888-801-9690 or email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from We’re Out of Control by MoOt. It’s used under creative commons. Subscribe to us in iTunes by searching for Startups and visit our website for a full transcript of each episode. Thanks for listening. We’ll see you next time.
