 Boston, Massachusetts. It's theCUBE, covering HPE Big Data Conference 2016. Now, here are your hosts, Dave Vellante and Paul Gillins. Welcome back to the Boston Waterfront, everybody. We're here at the HPE Hewlett Packard Enterprise, Big Data Conference. The hashtag is Seize the Data, so check that out. And Ava Donaldson is here. She's the software engineer and data architect at iContact. Ava, welcome to theCUBE. Thank you. So, we love to have data architects, software engineers who really can help us understand how practitioners are applying technology to solve problems, business problems. But tell us about your role, data architect and software engineer. What do you do? So, the reason that I have both of those titles is because I was originally brought on as a software engineer. So, iContact said we have business problems, we need to solve, and we need to write a whole bunch of little teeny tiny applications to solve those problems. Maybe tell people what iContact is. Oh, we do email marketing and marketing automation. So, eMarketing in general, and we assist with that, making sure that you can get your name out there in the electronic marketplace. And then also figure out what happened to all of your marketing after you did all of that. Follow. So, I was brought, so now back to the story that I was telling you. I was brought in to answer certain business problems. At least that's what they told me when they interviewed me, right? So, we need you to write one application or a couple of little applications that will help solve these business process problems. Okay, so I was a software engineer. Absolutely, I was a client server, transactional database software engineer, and that is what I was brought in to do. When I started to ask, and of course to solve business problems, what that means is I need to first do some business analysis. We have problems we need to solve. What are those problems? So that I can make sure that whatever I'm doing, whatever I'm building, whatever I'm using, I'm making the right choices to solve the problem. So, once I did that business analysis, once I asked the right questions, once I went down that road, it became really, really clear that they didn't need an application. They never had. We have plenty of little applications, and then I started to look, we have these lots of little applications, and we're not eye contactors by no means the only company out there that does this. This is pretty typical before people really understand the power of business intelligence, is to write an application that all it really does is give you one report. And what they needed was reports. That's what they needed, right? So, I walked in and said, you don't need application, you need BI. What you have is BI. You said that, and they kept you on. No, wait, this is important. It's important because what is the opposite of business intelligence? Business stupidity? Exactly. And blindness, right? And it's really blindness, so that's a joke. But the truth was it was blindness, and it was a misunderstanding of what it was they were really looking to do. And it was to answer questions, and the only way to do that was to get data insight. Now, are you talking about reports for the company, or are you talking about reports for the customers, or both? For the company, right? Insight inside of our institution and what it is that we're doing. So, when I started to look at that and convince them that this is what you need, you need reporting, you need access to dark data. The data was buried in logs and all kinds of other things. When I started to convince them of that, what I realized was I was going to have to take a different road. I was not going to just be able to be a software engineer. I wasn't going to be able to just write an application, a web server application the way I always had. I was going to need to look at that data. We had logs that we needed to bring in. We had databases that were not structured to answer these big data problems, and we had enough data that we couldn't just pull it out of our databases and answer it, right? Because we were looking at terabytes of data. So you can't just say, this is what we're going to do. We're going to pull it out. We're going to answer your question right away. And the data, because it was so big, was indexed in such a way that it answered very, very specific problems. The application gives a beautiful overview of an individual message and individual send. Gorgeous and really robust. But the application couldn't go beyond there because the tables had been structured to do that. So I needed to answer the question not only of an individual client overall, but the whole enterprise overall. And it meant basically kind of changing career paths a little bit and becoming a data architect, understanding data warehousing. In a way I never had had to before. So a sort of self-taught data architect? Absolutely. By doing? Yeah, because I had to solve a business problem. Absolutely, yeah. And let me ask, what was, what problems did that create? There's this lack of insight. What kind of operational inefficiencies or lost opportunities did that create? So the real question that was being asked at the time that I came in was part of that exactly to answer that question, was part, what they wanted to know about was, so we have a shared sending infrastructure which is very, very typical of email marketing companies, of ESPs. What that means is when you send a message, it's going to go out on the same IP as another client's message. Now we pool that based on what you do and whether or not you're, whether you're, what kind of account you have with us, et cetera. So it's not that you're sending with everybody else, but you're sending with a subset and you're sharing that. So what we need to do is we need to make sure that we can find the people who are sending email that nobody wants and stop them before they ruin their sending reputation of the people who really are legitimate and are having their users opt in. Because what happens is if we send out spam, like really our sending spam email that nobody wants, then the ISPs will block us and then the legitimate guy who really is doing it the right way, who's only sending email to people who are interested in the product, their email won't go out either. So we need to stop those bad guys. But we didn't want to just stop the bad guys. We also wanted to see, well, are there trends or their patterns or the things that we can see that will help enable the good guys to make them even stronger and beat out the bad guys in the first place. So that was the question, that was the problem. And because we couldn't see the data across the entire enterprise, we could not answer that question. So how do you determine, like, what's the threshold of bad versus good? Is it some percentage of people who opt out or complain about spam or how does that all get- If you complain, if you get spam complaints and that threshold is very, very low. So if you're receiving spam complaints really almost at all. Like one. Well, it depends on how many you're sending to you. So it's a percentage. Let's say you send out 50,000 emails. And a couple of people complain about spam because they can't remember whether they signed up for your newsletter. So I'm going to be honest, I don't remember the exact threshold at which it- I mean, it sounds kind of draconian, one or two. I mean, you would think it would be hundreds would be an indicator. One or two is pretty bad right away. Really? Yeah, because we're not necessarily going to see every single complaint. And if you even have one or two, it probably means that they didn't opt in. Now, we're not going to kill you right away because of one or two complaints. We're going to let you know you're getting complaints you should probably pay attention to that, right? That we've always done. That individual client level. But we can find you faster now because of the insights that we have in the big data. So what do you prescribe in that case? So you got to say you got a 50,000 person house list. And you get a couple of spam complaints. What do they do? Do they ask everybody to opt in again? So not just for a couple. No, because then you basically spam. Let's say it's hundreds. Let's say it's hundreds. If it's hundreds, yes. That's absolutely what we do. We can agree on that. One or two, maybe not so much, but hundreds, you got a problem. Yes, you have a problem. So what would you do in that case? Say you got a, you have a data quality problem. Well, they do, right? Yeah, not you, your customers, right? So at that point, yes. We have an opt in process. So we ask that the customer send an email that says, we have you as a subscriber to this list. We need you to do a secondary opt in. Okay, and at that point. If the users have not. But that's bold, right? Because the customers at that point might say, I forget I'm going to go to another. I'm going to go to Mailchimp, you know? Does that let me do anything? I can't let you anyway, right? I mean, that's part of, so one of the huge things that we pride ourselves on at iContact is deliverability. Is that your email's going to make it into your inbox. We're very proud of that. So it's high quality. It's part of your value proposition. Absolutely, right? And if you're not making it into the inbox, then we have all of these metrics that we can explain why that's happening. We have a report card now where we can show you, see this send, this is the one that's hurting you. Or this pattern of sending, because you're sending too often or you're not sending often enough. Or your list came from somewhere that wasn't any good. So that then we have, we partner you with a success manager if you're a small company, if you're a premier account, then you'll get a strategic advisor that will help you get your cadence of sending, make sure your message is really, really good so that you can get those clicks, right? Because really what you care about in the end is, did my end user either read the thing, open it, and did they take an action? Was there a call to action? Did they do something? Did they get it, did they open it, and did they do something? And ideally, did I sell something at the end of that, but that's not your problem. That's right. We don't get that information back. So how did you go about solving this problem? You've got all of this data, this send data, these different accounts, you have to munch it together and kind of figure out what's bad and what's good. How did you structure that? How did I structure the data to do that? So there are several data points that we collect. On email messages, the sender ID, the recipient ID, so I'm still stuck in the report card thing so I'm going to come out of that and I'm going to rethink about how did we really find the bad actors. So one of the things that we had not had insight in, we had log files that had all of this where the email message is going, and ways that we could go and see how many times did you send to the same recipient, which we couldn't do in the database before because we couldn't see that you were sending to 90% Gmail on every single one of your sends or you were sending to the same email address six times in four different folders. So certain patterns that we were able to determine that this says that you're cycling your list, you're deleting your list and you're reloading it which means that anybody who attempts to unsubscribe can't be unsubscribed because you've just put them back on again, right? If you're cycling your list and it was much easier to find that list cycling because we could see that the same sender was sending to the same email address with a different recipient ID over and over and over and over which we couldn't see before because the data wasn't, anyway, wasn't even there. So that was the ability to bring in the log files to be able to parse those log files out and put those into Vertica. So that was part of that. Then another thing was we could get, because we have the MX record on the, when the email is sent, we have the MX records. So we have a lot more detailed insight because we have access to those logs. One of the things that happens is that there are blocking institutions that will actually block the email, right? So I'm not, from now on, this domain is no longer receiving any email from this IP. So when those blocks happened, it used to be really, really hard for us to tell who it was who had caused that block. It's a lot easier for us to tell that now because we can see the MX records, we can see the exact time of send, if there was any delay, et cetera, that kind of stuff that we just, we didn't have insight into. Now when people do bad things with their email campaigns, is it generally out of ignorance or is malice often a problem? You would like to believe that it's just ignorance. And sometimes it is. And I would, that's why we have strategic advisors and success managers, right? Because there are people who really just, they don't get it. They want to send to their customers, so they send and they send and they send and they send and they send and they send and then after a while, the customers are like, you are irritating me. That is a large part of it, but that kind of customer isn't going to cause a block. The one who causes a block knows exactly what they're doing. So you had to boot some accounts off of your service then? And we absolutely do, yeah. Because it's not right, it's what we provide, what we pride ourselves on, like I said, is that inbox placement and that fantastic customer service. And so we want to make sure that we're partnering just like other companies want to. Our clients are our partners. So we want to partner with people who are proud to say, hey, we support the wine shop on the corner. We play well with the Leukemia Society of North Carolina. We want to be able to say these are clients we are proud to work with, right? And that that furthers who we are too. I don't want to say I worked really hard with a guy who tried to illegitimately sell you a drug. So, of course, there are business consequences of that. I mean, those people pay bills like everybody else and that's got to be difficult. But I'm interested, I know a lot of people who'll be watching this are in the marketing world and do a lot of email marketing and still the number one B2B marketing tool and they really want to understand the mechanics. I mean, can you walk us through, how do I avoid getting stuck in that spam cycle where my stuff is not even being seen? So the first thing is choose eye contact because we have an awesome inbox placement. Obvious. Yeah, yeah, yeah, yeah. And then, so I'm not a strategic advisor. I can tell you, based on these reports that I've helped create, what metrics we use to answer the question. But the best thing is to take a look at your sending practices, how much you really want to communicate. Make sure you're really communicating it. Another thing is just think about when you get an email, how do you respond, right? When you get an email and there's all that information, right? You might read like the first two sentences and then kind of scroll down the bottom. So think about how you're putting it together if you're really communicating what you want to communicate. Think about your subject line. Almost, if it says RE something, right? How do you respond? When you see something that says RE, you never even talked to them. You go, you clicked a little checkbox thing and you go spam, right away. So you don't want to be the one who makes that happen. So think about how you architect all of that, how you put together your message so that it's something somebody wants to read. So what are those metrics that you use and how much of that data do you put in the hands of your users? You operationalize? Yeah, so the metrics that we use are your open rate, which is how, what percentage of your emails actually get opened, your click rate, which is how many, what percentage of your emails actually get clicked on, and bounce rate, how many never make it to the inbox, right? Never make it to the other end because you have a bunch of bogus addresses. Open rate, click rate, bounce rate, unsubscribe rate, how many of your people unsubscribe? Complaint rate, that's a big one, and we weight that very, very, very heavily. And then finally, we have a proprietary score that we apply, which is called spam and unsubscribe to open rate. So all of the ESPs will give you an open rate, how many of your emails were actually opened, but we take that one step further and we remove the spam and unsubscribes from that to give you a true opened-to-actually read rate. Oh, okay. And then we take all of that, we put that together, we have proprietary algorithms to put that all together and give you a score between 100 and zero, and then you get an A or an A plus and you're sending. And you give me little benchmarks to see how I'm doing relative to the average? Mm-hmm, yep, and then if you're a premier client, you get those on a regular basis so you know exactly how you're doing. And then you give me recommendations to improve that. Exactly. Do you have any success metrics? I mean, what's been the impact on the business of all this work you've done? Of putting in the... Of cleaning up your accounts, basically. So it's actually been in maintenance mode and I don't know that we've seen direct impact with this latest scorecard release yet. We may very well, and if we have, then I wasn't involved in the finding of those metrics also. So that's another problem. Once I released that, once I was involved in the building of that project, I largely handed it off. So now there is a very tiny VI team that maintains it and I'm off on another project already. Vertica is your primary database? Or is that right? Vertica is our data warehouse. Right. And where we run these, the more advanced analytics out of. So all the scoring that I was just talking about, all the advanced algorithms, that all comes out of Vertica. The, our primary databases, like our transactional databases, are MySQL for one product and SQL Server for another. Okay, but the EDW is... Is Vertica, absolutely. No, there's no sort of traditional EDW in place. It's Vertica. It's Vertica. Yeah, absolutely. How did you get into this? Are you a CS major? No. So tell us the story of how you got into tech. How I got into tech? We're always fascinated by women in tech and what path they take and why there aren't more. So I majored in cultural anthropology. When I was a little girl. Yeah, my, I took a very like, I tried something totally different. When I was a little girl, I decided I wanted to be the first, so I'm also Jewish. So I wanted to be the first Jewish and first woman president all rolled into one. I was gonna do it, right? And then this most recent primary I thought was very ironic for me. You had one of each. Right? They weren't rolled into one though. So it was still... Well, they kind of are being rolled into one from a narrative standpoint. They're like, I digress. So that was my goal in life. That's what I wanted to do. And so I became very politically active in college. I chose cultural anthropology. I wanted to understand my people and I wanted to understand the world. I wanted to bring peace to the world. This was my goal. I had traveled with a group called CERVOS. They're a homestay program international. You can Google them. They're still out there doing their thing. Where you would stay in people's homes. And the idea was that the more people you knew, the more people you met, the more they would seem like people and we would create peace. And I was like, oh, I'm gonna grow up. I'm gonna be a diplomat and I'm gonna make that happen. It was a great idea. I was full of idealism. I was. And I was a college full of this idealism and I started to travel overseas more. I mean, I had a little bit as a kid. I was very, very lucky, very blessed to have that ability. And everywhere I went, first of all, was thrilled to be an American woman. It was very difficult to be a woman anywhere else in the world that included in Western Europe, particularly as an American one. So I was proud to be an American. I always wanted to come home. But I learned also that people really don't wanna like each other. They like not liking each other. It was very eye-opening to be in Yugoslavia soon after the war and to listen to the Bosnians and the Serbians talk about each other as if they were different people speaking the same language. To my mind, what sounded to me like the same language. And it was difficult for me to accept that, but I was like, okay, I'm not gonna create peace. Not only that, the more people I met, I was like, well, maybe I can't really help people either. I'm gonna stop. And I don't wanna live overseas because I like home and I miss my family. And I wanted a career that I felt like I would be able to raise my own children and have a career at the same time. My brother had had a very successful career, built himself a very, very successful career on the help, he started on the help desk and he moved up. I knew I didn't wanna go back to school. So when I came back home from being overseas, I returned home and I decided I wanted to be a software developer. That's what I was gonna do. I was gonna be a programmer. So I was freshly landed, as they would say, off the boat, except it was an airplane. I don't know why we still stay off the boat. So I landed from Bulgaria. I had been a teacher in Bulgaria because that was the latest thing I had done said I'm gonna be a software developer. And you just taught yourself how to code? Pretty much, yeah. I mean, I took a job, I was very lucky. I got a job at Washington University Medical School on the help desk and I was willing, I mean, I was like, so it's not that I had never, my brother was able to build that career also because my family had owned a small business that we had computerized in 1980. So computers were a part of my life. I mean, I was writing software at 10 years old because we were solving business problems. So one of the things is that I tout myself not so much as a software developer or a data architect or an engineer. I am a person who solves business problems. That's what software did. What we were able to do with our business and the way we were able to take it because we were able to software enable it in 1980 was huge. We had insight at that time and I'm talking about honor snack vending. So we had a lot of numbers. We needed to know what our shortages were, how drivers were performing. There were all these statistics that we needed. And when we computerized that, it was awesome. So you were trained as a young girl. I was. That's okay. Yeah, so it wasn't new. Like computers weren't new. It wasn't like I just all of a sudden went, oh, I know what I'll do. I'll go, I've been, you know, I've been sewing skirts and now I'm going to go be a software developer. So I had the skills to get on the help desk and I knew enough about, like she said to me, if your computer is locked up and it's windows, what do you do? I scroll, I'll delete. And then I told them I wanted to be a developer and I threw myself at any project that anybody would give me because I was in the central help desk at Washington University Medical School. I had a lot of contact with a lot of people. I was dedicated and enthusiastic and it turned out also, I mean, I feel like I should be more humble, but I was good at it. And it came very, very easily to me. Like even in college, every once in a while I take a computer science class because it was just for an easy A. And I had the professors at the time say, you know, you should major in this. I'd be like, no, no, I'm saving the world. World doesn't want to be saved, I go back to this. Did they tell you that? How about becoming a data architect? For those developers watching who might want to become data architects, how did you learn? So again, it's never been an issue of, like I was never learning, the only time I was ever learning specific technology was when I made that decision to become a developer and I picked visual basic. But in this case, I just had to solve a problem, right? And I looked at the pieces available, the tools available. I read as many articles as I could. I talked to as many different people as I could. I went to user group meetings. I went to data analyst meetups. I joined TDWI. I just reached out to anyone who has done anything like this. What did you do? What made it work? I looked at the tools that we had in-house. How can I use these tools? If it means that I need to sit for two weeks, I asked my boss, can I sit for two weeks and figure out what this thing even does? We had Pentaho. Nobody was using it. We had a guy who walked out one day and went, you're gonna make me have to go into Pentaho as if it was like a bad word. But Pentaho is a powerful tool. Pentaho's awesome, yeah. And I was like, what are you talking about? We're trying to get insight into data. You've just shut down my insight with that. So I used Pentaho because it was what we had. And then I read Kimbell's book because you can't be a data architect and not read that book. And yeah, just then I was very lucky because I had a very specific problem to solve. One of the biggest issues that I see over and over again in my colleagues, now that I'm in the big data world and I talk to big data people, one of the biggest issues I see is this pattern of we want big data. And so they go and they build a Hadoop cluster and they like do stuff with it but they don't know what they're doing and so there's just a bunch of stuff in a cluster somewhere and it's a cluster. And I didn't have that. I had a very, if you have a specific business problem that you want to solve and you start there and I'm an agile believer, you start small, right? You say, I'm going to solve this problem. And once I solve this problem, now that I've solved this, look, look, we already built a leg or we already built a foot. Can we put an ankle on that foot? Can we put a thigh on that foot or whatever? What's this part? The calf. Can we put a knee? Can we put and build it like that? And that's what we did. And because I had that very, very specific thing, it was easy for me to show I contact the value of data and then easier still to get that data in the hands of our clients. There you go. So it's not working, it's networking. Solve business problems and have passion. And avoid business stupidity. Thanks, yeah, brother blindness. Thanks very much for coming on theCUBE. It was great to meet you. Appreciate your story. Thank you. All right, keep it right there. Paul and I will be back with our next guest. We're live from Boston. Right back.