The follow is a transcript of the webinar:
Chris Dima: Okay. Let’s get started. Thanks for joining us for this webinar titled Plug and Play Analytics for SaaS Apps Built On MongoDB. That’s part of what SlamData offers. Today we’ve got Michael Melmed, who is the VP of Ops and Strategy at US Mobile. Hi, Michael.
Michael Melmed: Hi, Chris. How are you doing?
Chris Dima: Good. Thanks for joining us today and sharing your story. We also have Jeff Carr who’s not only the CEO, but the co-founder of SlamData. Hi, Jeff.
Jeff Carr: Hey, Chris. How are you?
Chris Dima: Pretty good. Just for kicks, we are in three different places. Jeff is in Boulder, where the SlamData headquarters is, and, Michael, you’re in the outskirts of New York City.
Michael Melmed: Yeah.
Chris Dima: I’m outside of Philadelphia. Today’s agenda is to make sure everyone’s on the same page with what SlamData is and to understand what US Mobile is as well, and then to talk about the story of doing analytics on MongoDB for the business, to hear what Michael did prior to finding SlamData and then what he did after. He’s going to walk us through a couple of key reports that he’s built. Then through that, to understand what the impact is, we’ll talk explicitly about it, but I think through the conversation, we’ll understand what kind of reports are being delivered to whom and what function those reports have. Then we can do some Q&A at the end. I think that’s good for a start. If you have any questions, I think the easiest thing to do is email me at firstname.lastname@example.org. I’m queuing questions already, so we’ll add yours to the mix and we will discuss them at the end. I’m also recording this. You’ll get the replay after a few days. Let’s go over here and ask Jeff to walk us through an overview of SlamData and talk about this graphic and what it means.
Intro to SlamData
Jeff Carr: Sure. Thanks, Chris. I appreciate it. Thanks to everybody that’s joining today and learning a little bit more about what we’re doing with the folks at US Mobile. SlamData was really born out of this idea that modern NoSQL databases like MongoDB store data very differently, and reporting on analytics on them can be quite difficult and requiring learning customized APIs and specialized languages and doing some other things that make things a little bit more difficult. We decided that we should try to create a solution that will allow companies to do analytics and business intelligence and embedded analytics on NoSQL databases like MongoDB the same way they’re able to do that today using a traditional relational database and to do it in a native way. The first thing to know about SlamData is it is a native NoSQL analytics application. What we mean by native is it works on the data as it exists in the database. It doesn’t require mapping or ETL or extracting and putting it into some other format, or all the different things that people have done or are doing to work around this issue. In the case of MongoDB, we actually work on the data as it exists in MongoDB, pushing all the computation directly down to the data source. We expose everything through an enhanced SQL dialect. Michael will talk about this. In the case of US mobile, this was something that allowed them to use tools or skills they already had, which was SQL, to be able to report and query against JSON or BSON-oriented data that they had stored in MongoDB.
Additionally, SlamData is really more than just querying visualization, it’s actually an analytics application builder. It allows you to build very complex, very interactive analytic workflows that can consist of queries and pivot tables and visualizations and a variety of other things, interactive form elements, all kinds of things that allow you to build, again, not just queries and visualizations, but completely interactive workflows and applications that you can then white-label and embed into your SaaS applications. If you’re building an application on MongoDB, then SlamData bolts in simply and easily and becomes the entire reporting layer in a matter in minutes. Today we’re focused on MongoDB, but we also provide coverage for some other popular NoSQL databases like Couchbase, MarkLogic. We also support Apache Spark for people that are doing stuff in Hadoop land. That’s basically what we’re going to look at today. We allow you to, again, report and slice and dice and do all kinds of visual querying and reporting on MongoDB data as it exists in the database. We also allow you to leverage the full power of SQL behind the scenes. What does this really end up meaning in one slide? It’s about faster time-to-insights, less overhead, basically saving time and money. A majority of our clients today are people that are either going through some cumbersome ETL and mapping process to get the data into a relational form and put it into either a relational database or something like Redshift or something like that and then use a legacy API tool, all of which cost time and money, or there are companies that have built something custom and are just tired of taking care of it and having all the maintenance, all the enhancement requests that come with any kind of analytic. People are always asking, “Can you add this? Can you change that?” and valuable developer and engineering time is being spent on that. In the current market, what we see is companies spending lots of time on mapping, cleanup, ETL, custom development, extraction, and then less time on actual analysis. With SlamData, we eliminate all of the mapping, cleanup, ETL, custom development, and allow you to focus on actually delivering analytics and real reporting to your end users. Like many things, it’s all about saving time and money.
Get Updates And News From SlamData
With SlamData, we eliminate all of the mapping, cleanup, ETL, custom development, and allow you to focus on actually delivering analytics and real reporting to your end users. Like many things, it’s all about saving time and money.
Chris Dima: Okay. Thanks, Jeff. Michael, tell us a little bit about what US Mobile is and where it’s going.
Intro to US Mobile
Michael Melmed: Yeah, sure. US Mobile is a wireless carrier with nationwide 4G/LTE network reaching more than 300 million Americans. When we launched a couple of years ago, our goal was to free customers from expensive, inflexible phone plans with long contracts, and instead give you the freedom to create your own plan so you can always get exactly what you want. If you check out our plans page, you can see that you’ll be able to create almost 400 different plan combinations, so you can always find the most affordable plan to connect to your phone or tablet or car or alarm system. Our average customer pays $15 a month, so I encourage you to go check us out. There’s a really good chance that you are paying way too much compared to the amount of talk, text, and data you actually use, even if you use a lot of data or a lot of talk. Oftentimes, you don’t need unlimited of everything. That’s where you can really save a lot with US Mobile.
Chris Dima: Okay. Can you talk about what your role is there?
Michael Melmed: Sure. I am the VP of Operations and Strategy. When I joined the company, I was leading up product and analytics. In both roles, SlamData has been quite important to me. In my role now, obviously I’m touching every aspect of our business.
Chris Dima: Okay. What kind of growth has the company experienced? Where were you guys?
Michael Melmed: We’re definitely one of the fastest growing new carriers in the country. Just in the last year, we’ve tripled from 10,000 customers to over 30,000, and we’re only growing faster and faster every day.
Chris Dima: Okay. Can you give us some idea of the size of the company in terms of people? Because this is reporting, and you’re doing it across the company. I think that would be helpful context.
Michael Melmed: Yeah. All in all, we have about 40 employees. It spans in different departments, from the management team, finance, marketing, business development, product, design, engineering. We have a very large customer support team, which we make available 24/7. It’s always important that we keep that team up to speed on everything that’s going on, so they can provide the best service.
Chris Dima: Okay. Great. That is good context. This next slide’s nothing really to look at, but this is where you help us understand a little bit about the type of data, the size of data, and what you did in your first version of reporting. What’s in MongoDB? Can you describe a little bit of the data, what you’re capturing and what you need to report on?
Transitioning from SQL Server to MongoDB
Michael Melmed: Sure. In fact, I’d even go a little bit back before that. When I joined US Mobile, we had a SQL database. It was a language that I knew very well and was very comfortable with, the tools and the reports and things that I could create. It was only a few months later that we migrated from SQL to MongoDB. That was conceptually good with me, but it was soon a bit shocking that all my tools were obsolete right after that, and the MongoDB query language didn’t seem to have all that much in common with SQL, and yet the advantages of MongoDB that I thought would be there with less joins and more efficient access to data didn’t fully pan out. I still needed to join data, I still needed to write complex queries in a way that I was struggling to do when we first made that transition.
Chris Dima: Yeah. I’m glad you bring that up. Jeff, maybe you could expand on this a little bit, but that’s the trend, where developers rule the roost. They’d pick the technology and then sometimes businesses is left expecting the reports.
Developers First? Where Are My Reports!?
Jeff Carr: That’s right. The common theme we see in the market today is that developers, in companies large and small, are choosing new databases like MongoDB because it helps them build the applications they’re trying to … Better, faster, more efficiently, they can deliver more flexibility, more features in a quicker time frame. There’s just a zillion reasons why developers are choosing them for very good reason. Unfortunately, the analytics department or folks usually end up bearing the brunt of that, because they’re typically not involved in the decision to move to a NoSQL database; they just end up on the backside of it, having to deal with analytics and reporting and, as Michael pointed out, having tool sets that just aren’t matched for that. They end up in … It’s a bit of a rock and a hard place.
Chris Dima: Michael, what were some of those original reports that you’re running on SQL that you liked, what were some of the key things that you’re looking for, and what were you using to do the reports?
Michael Melmed: Yeah. As a wireless carrier, our database was pretty robust. We had millions of data points from customer data, device data, order data, usage data, and there are only so many reports that our engineering team could build to put in our admin portal. There is limited amounts of data that we could have in any GUI or front-end reporting tool that we might have connected to our website. Really, I was doing all types of ad hoc analysis and frequent or periodic reporting on sales, usage, lifetime value, just all types of reports that would span every department. Even though I was very comfortable with SQL, there were still some pain points in that I’d run a report once and then I’d export that to Excel and manipulate it there and send that out to a member of the team. Then whether it was hours later or a week later, ultimately that report would go stale. Since I was really the only person in the company who is going directly to the database, other than the engineers, I was in pretty high demand to go and get that data again and keep it current and refreshed for any of my colleagues who needed that data.
Chris Dima: Yeah. Maybe, Jeff, I’ll just go back to this image for a second. You and John, John De Goes, the CTO and co-founder, looked forward and realized that you could compress some of these steps and keep it all in a platform or a solution so that you weren’t getting the data and then going to a different system and manipulating it and going to another system to share it. The history of companies in technology for the last 20 years has been putting together a report is five people’s jobs, but now SlamData brings that into one solution. You want talk a little bit about what you observed in the market that.
Genesis of SlamData
Jeff Carr: Yeah. I mean I think part of building our solution, and what we still see in the market and most of the people that find our solution, again, they have some cumbersome multi-step process that they’re using to deliver reporting today, whether that’s a combination of mapping and ETL or whether they’re doing extraction via native queries and then dumping that into some other form or tool like Excel or something. I mean these are all different ways people are doing it and, as Michael just pointed out, they’re not real-time, they’re not working against live data, they’re in need of constant updating and maintenance and messing with them. We said, “No, you should be able to have a tool that can query and analyze and create visualizations and share those and embed those in your application simply and easily just like you had in the relational analytics world for two or three decades.”
Chris Dima: Right. Okay. Where were we? We’re talking about this. We discovered or discussed what you were doing, the reports. Maybe it’s time to talk about … Well, let’s explore the segue for second. You had these reports, Mongo goes live, now you’re looking and you’re frustrated and you’re faced with, what? Learning Mongodb query language or asking one of the developer’s to take this on. What was the straw that broke the camel’s back to go out onto the internet and look for MongoDB analytics?
Analytics V1 On MongoDB (Tried and Failed)
Michael Melmed: Yeah. I was relying on the engineers. It certainly would not have been doable for us. We have a lean team, and their priorities are development and not as much on the reporting end. We wouldn’t want to slow down our progress for reporting. It was clear that we had to find another tool that would allow me to get access to the data that I needed. I started off with different tools like MongoChef and Robomongo. I don’t remember the exact point when I found SlamData, but it felt like a light switch was turned on when I saw that I could keep using my SQL skills and still get access to the database.
[clickToTweet tweet=”…like a light switch was turned on when I saw that I could keep using my SQL skills & still get access to @MongoDB” quote=”…like a light switch was turned on when I saw that I could keep using my SQL skills & still get access to @MongoDB” theme=”style3"]
Chris Dima: Okay. Well, it seems like a good time to turn it over to you to share a couple of the reports that you have created and talk us through them. Let me stop my share and let me turn it over to you. Let’s see.
Michael Melmed: Sure.
Jeff Carr: Looks good.
Chris Dima: Okay.
Demo of SlamData At US Mobile
Michael Melmed: Okay. I just have a few sample reports to share here. I have many more than this, but I wanted to pull a few that would help demonstrate how I’ve been using SlamData. The first one is a report that I used with our product team to pull out data specifically on our customers who were using AutoPay as a feature. We made a big eBECS change that we hoped would have an impact on the likelihood of people using AutoPay. We can jump to that report right now. This one is fairly simple. I have date range as variables that I set up so that ss I change these dates, June 9th to 19th, I can see what percentage of activations during that time period were using AutoPay. We actually did the change on the 18th. If I push this out beyond there, we can see we went from the 30% range to over 50%. The nice thing here is that I was able to share this with our CEO, with our product team, and the report could be accessed at any time. These date ranges could be changed daily to go in and see the impact of the change. I have down at the bottom these different tabs where you can see week-by-week our activations, our activations that included AutoPay and then the percentage of those activations that include AutoPay.
You can see very clearly the difference that we had. Really, both elements of this were important because being able to see weekly where we were before as we were making the plans for that change and where we were afterwards was helpful, but also even in two, three days after the change, we wanted to see the impact right away, and looking at weekly data wouldn’t necessarily show that. This was really helpful for everybody involved and it was really easy to setup as well. For each of these decks or sections … I’ll just back up here a little bit. I’d often start with some markup to create variables for date range, write some SQL utilizing those variables. In this case … Let’s zoom that out a little bit so you can see it … I was getting the exact number that I wanted to display in the report, but I could use a chart functionality within SlamData to make it bigger and easier to see. I did the same thing with these bar charts here at the bottom, setting up the data and then mirroring from tab to tab, so that only at the end was I changing what information would be reflected in the charts. It was really doing the work once and then replicating it a couple of times after that.
Chris Dima: Okay. Those underlying cards in that deck in the upper right is like a mini-workflow really custom to what US Mobile’s doing and what you wanted to visualize. I imagine once the product team identified this, then … Can you talk a little bit about the iterative nature of developing this? You could start off with some ad hoc queries and you iterated until you found the data, and then built it out visually. How long did that take and what level of expertise did you have to….?
Michael Melmed: I’m very familiar with where the data is in our database, so it often doesn’t take as long to figure out what data I need, but when doing this … It is a bit iterative. I do spend some time figuring out what variables are going to be important to this type of report. In this case, I only did these date ranges, but if I wanted to be more granular about what types of customers are using AutoPay, I could have done that. I could have put in a form, which allowed the end user to see people who are on AutoPay with data-only plans or talk, text, data plans. I could have allowed, if we were going to do anything from a marketing perspective, reaching out to customers who are not on AutoPay, I could’ve put in a query and a download link to access a list of customers who are not on AutoPay who we might want to reach out and communicate our changes.
Chris Dima: Okay. As the author, you set this up. Can you talk about how you share it?
Michael Melmed: Yeah. When I share any of these reports, I’m just flipping the deck up here on the upper right, and often I’m publishing and sharing this link within the company. We have a single sign-on authentication with Google, so there are only a few people in the company who have access to the editable versions of these reports, but when I share it with some of my colleagues, we don’t have the permissions to edit, that’s not a big deal for them because what they see is just … They still see these form elements, the data still pulls directly from the database in real time when they run the reports.
Chris Dima: Okay. Back to the stack and the workflow that you mentioned, SlamData allows you to really do as much or as little, totally customize the report as you see fit. You could make it a little interactive, a lot interactive, and change it based on what the feedback is that you get from the users. Have you seen that in other solutions? Is that something that you introduced to the reporting that US Mobile offers its teams? Did you have that in your first version?
Michael Melmed: No, especially this interactive, do-it-yourself for my colleagues, that was something that we did not have before. It wasn’t even something that, when I first saw SlamData, was the selling point. That was really the SQL, being able to keep using SQL, but it’s certainly grown to be an extremely important feature of the tool. I can jump ahead to this other report that I created for our business development team. This is entirely interactive. Our biz dev team needed to identify customers who are using US Mobile for non-standard phone devices. We have customers who use our service in alarm systems, GPS trackers, pretty much any kind of connected device. The team wanted to see who is using them, what they were using, and reach out to some of those customers so that they could learn more about those use cases and possibly create partnerships that we could expand the business with those other types of devices. I created this report where, again, they could look at how recent the customers in terms of when they first activated, the status of their line, whether they’re active or not. Then there’s a search field. Right now I have alarm and I can see the different lines that are being used in different alarm systems, but if I was the biz dev team, I could change it to GPS and it would instantly change the report so that they could see the different people who are using our service in their GPS devices. Then the biz team often use spreadsheets or other lists of information for reaching out. I was able create this little download button where whoever’s in the preview list here would be downloaded into a CSV and they could take it from there.
Chris Dima: Can you tell us what the biz dev team was doing, I don’t know, eight months ago or prior to SlamData? What kind of report did they get and did they complain a lot, or were they getting enough to do what they wanted to do and now they’re fully equipped to pursue biz? Is that…?
Michael Melmed: Prior to this, I think either one of two things would happen, either there would be a very specific request. They would say, “Can I have a list of all customers who are using US Mobile in GPS?” and I would pull that information and send it to them. If they needed updated information, they’d have to contact me and I’d have to pull the information again for them. It’d either be that, where they would not have all that other information around alarms or any other types of devices that they might want to pursue, or they would give me a really broad request, like, well, all names of all lines for all of our customers. Then I’d be pulling a very large CSV file and sharing it with them. Then they would have to slice and dice it and Excel as they needed. In this case, they’re able to quickly change it, quickly see how many people are in any given filter and just explore what they need when they need it.
Chris Dima: What was the response with that team when you delivered this? Were they part of the iterative process or did you break this out and say, “Tada!”?
Michael Melmed: This was a bit iterative. I’m pretty sure I did not have that download button initially in there. That was something that they quickly pointed out that just having this data in the report was not the end point for them. Luckily, that only took me five seconds to go and add that button to it. The other thing that came out of this, because this was one of the first reports that I created for them, was that quickly there were a whole bunch of other ideas about what kind of information they needed and how interactive that reporting could be on that information. It actually led to a whole bunch more requests, which, ultimately, is a good thing, even if it’s more work for me to set them up.
Chris Dima: Yeah, yeah. As people spend time thinking about optimal business intelligence, business analytics reporting, it’s like music to our ears that it was a collaborative process. You build it and then it scales to meet everyone’s needs. That’s the way it should be done. We’ve all experienced the pain of waiting for the IT department to do the update and waiting. It’s time to move on from that. Can you expose a little bit about the construction of this through the cards? Then we’ll move on to the third.
Michael Melmed: Sure. You can see at the bottom all these docks with quite a few cards that are involved here. I’ll just go all the way back to the beginning. Similar to the other report, I was starting with some mark up. In this case, I have the date ranges as well as the status of those lines. Then I have my SQL query. Then I previewed the data just so I could have an idea what it looks like. Sometimes I utilize cash if I have a bunch of different queries and the same report to make things a little more fast and efficient. Then I have my search function. Finally, I have the data. All of these different sections are creating a mirror at any point in the process. I created a mirror setup at the search function so that I could see the search, but then continue on with this deck to show the data. Then this download one would just be going a few steps further to setup download. It could name the file and show the download button. That’s how easy it was. When the team came back and said, “Can we export this to Excel?”, it was that quick to make that change.
Chris Dima: All right. Let me ask you about the skills that you’ve developed to be able to do these things really quickly. I don’t remember setting up any specific training. Was it easy to learn SlamData and to be able to pull these reports off?
Michael Melmed: Yeah, it was really easy. I definitely spent some time in the docks when I first got started. In fact, I think I spent quite a bit of time reading the docks even before I actually got it connected, so I was pretty clear on how it all worked. It’s pretty user-friendly in terms of being able to see what functions are there. Some of the ones that didn’t quite make sense to me, just clicking on them and experimenting with them made it pretty clear how it worked. One of the functions that I use frequently, which I mentioned, was the mirror. That was something I didn’t get quite off the bat, but I think it was in one of the videos I found online that I noticed that that functionality was being used and then immediately thought of all the different ways that I could benefit from that.
Jeff Carr: Yeah. I think it’s worth pointing out here that Michael’s not a developer. Today the world of NoSQL on MongoDB analytics is a developer world because at a bare minimum you’re writing to their APIs to at least extract data, if you wanted to just try to extract to CSVs and throw it into Excel, which is obviously not a great solution since that’s what Michael’s company was doing prior and obviously not having great results. That’s one the key elements is that SlamData is designed to be used by normal people, product people and analysts and marketing people and people in a company that aren’t developers.
Chris Dima: Right. That’s a good point. I was thinking myself about the nature of the real-time and how it’s worth taking a second to explain that when the report changes, that a query is executed on that data as it is. The results give you near real-time insight into what’s happening. That is not possible with other solutions. Can you talk a little bit about that, Jeff, that that’s something that SlamData worked years on perfecting that ability to understand the data upon mounting the database? It’s magic to most people, but maybe you could take 30 seconds and explain that.
Jeff Carr: Sorry, I was trying to keep the background. I was just saying the core value of the solution is that we understand the data as it exists in MongoDB. It doesn’t require mapping and extraction and flattening and all the other things that are required in order to use a BI tool, QlikView, Tableau, Power BI, things like that. Those are great tools, but in order to use them with something like MongoDB, you have to go through a tremendous amount of preparation and work on the data. Again, it involves extracting it and flattening it and mapping it into a fixed schema, which is not the way MongoDB is designed. The biggest value with what we’re doing is it’s allowing people to save all that time, effort, and money that they would spend doing mapping and flattening and things like that. Then, as I said, open it up to normal people. Non-developers can now start doing things, and you’re not going to have a product person or a business analyst doing ETL, building an ETL engine to pull data out of Mongo. That’s just not going to happen. We’re opening up the world of NoSQL analytics to regular business people.
Chris Dima: Okay, great. Michael, this is the third report you’re sharing. Can you tell us who’s using this and why you’ve built it?
Michael Melmed: Yeah. Our company launched just a couple weeks ago a new product, which is the unlimited wifi plan, which allows you to connect to over 30 million wifi hotspots around the world, as well as get connected on inflight wifi on all the big airlines, both in the US and abroad. We launched this product on a really tight deadline. Our engineers were working pretty much around the clock to meet the deadline to launch it, but that meant that they didn’t get to spend as much time working on our admin side and exposing the information that, let’s say, our customer service might need to troubleshoot any issues or identify information as customers might be contacting us. This was something that the day after we launched, we noticed people were coming to our team and asking how to switch their wifi plan from one device to another or they needed to re-enter their voucher code.
[c[clickToTweet tweet=”SlamData offered a really, really quick way for me to expose that data and share it with the team” quote=”SlamData offered a really, really quick way for me to expose that data and share it with the team” theme=”style3"]p>
That information was in the database, and unless we had our engineers build something for them to get it, SlamData offered a really, really quick way for me to expose that data and share it with the team. In this case, I was able to create a report of our wifi orders, showing just the statuses so we could keep track of how many of the plans have been activated, how many were still pending, how many, if any, had been canceled. Then for customer service team, whenever they got a call, they could go in and get the information that they needed about the subscriber. In this case, I’ve hidden some of the key information, but … Oh, I think I’m not connected anymore … if they put in the information that they needed there, they could find that user and they could turn off or turn on, whether they were looking for … Let me refresh … canceled users and find the data that they needed instantly, even if the customer had just signed up a minute beforehand… That was something they were able to use the minute after I created it.
Chris Dima: That’s almost touching all departments — It’s like a multidisciplinary approach to reporting that sometimes focused on marketing or business development, product management, customer service, even engineering, all the way to the executive team.
Michael Melmed: Yeah. In fact, in some cases, I might create something like this. That might give the engineering team a breather so that they can… The things that are really important that we do need in our admin built in, custom-built, they can have a little bit of time to be able to figure out the best way to do that while I’ve created really an app that can serve in the interim.
Chris Dima: Yeah. This demonstrates what we started in our marketing to identify as a data application or analytics application builder. This is not your report or a charting created off basic rows and columns; you’re attacking the data and sculpting it, creating the right view and then building interactivity around it to meet the needs of the end user. Let’s talk a little bit at a high level, as we’ve seen these three use cases, and understand a broader context. When you think about analytics and business intelligence for the business, are you getting materially better reports than you did prior to SlamData?
Michael Melmed: Yeah. I think without a doubt. I mean we still have reports that I built that are not interactive, and they might serve as dashboards or trend lines for the business or ad hoc queries, where the information is just pulled and shared as it is, not necessarily configured, but the ability to do both, and particularly the ability for that information to be refreshed whenever needed, gives us a lot more flexibility and allows us to keep a lot more consistent eye on what’s happening with our business and the data that we have.
“…but the ability to do both, and particularly the ability for that information to be refreshed whenever needed, gives us a lot more flexibility and allows us to keep a lot more consistent eye on what’s happening with our business and the data that we have.”
The Impact of Using SlamData: Before and After
Chris Dima: Okay. Can you talk about the contrast between the before and the after in terms of distribution and sharing? Has that added, enhanced the discussions, enhanced the understanding of where the business is right now? Because we put a lot of time and effort into building out that ability to share and even embed.
Michael Melmed: Yeah, absolutely. In many cases, especially with the interactive features, I’m able to share a report with any team, it could be the finance team, and give them a few options for it to be interactive. That actually leads to fewer questions coming back to me because they can see, when they change certain elements of the report, what the impact is. That helps them understand what they’re looking at better than if I just send over an Excel sheet. This has definitely made, I think, everybody more informed about the information and what’s being shared by me.
Chris Dima: Okay. That is super helpful. Off the cuff, what kind of time savings are you achieving? Have you done an estimate, or are you now doing advanced reporting that maybe it’s taking you additional time, but giving you a lot better results? How do you quantify a return on investment? I guess that’s a better question.
Michael Melmed: It’s hard to put a number on it, but I would say that, in general, the process of querying and building reports is something that I continue to do on a daily basis, but the important change that’s happened has really been that I’m building new reports, I’m looking at new queries on a daily basis rather than setting reminders to rerun reports every day, that amount of time saving that I’ve had from being able to create a report once, share it with a team member, and then not have to think about it again because they are the ones who are refreshing, they’re the ones who are filtering or exporting the data as they need it. That could be on my plate on a daily basis if it weren’t for some of these sharing features that SlamData has.
but the important change that’s happened has really been that I’m building new reports, I’m looking at new queries on a daily basis rather than setting reminders to rerun reports every day, that amount of time saving that I’ve had from being able to create a report once, share it with a team member, and then not have to think about it again because they are the ones who are refreshing, they’re the ones who are filtering or exporting the data as they need it. That could be on my plate on a daily basis if it weren’t for some of these sharing features that SlamData has.
Chris Dima: Okay. We remarked some time to talk about some future use cases, but we have a bunch of questions. I want to make sure we get to those before 3:00. These questions might be for Jeff or you. The first one is how much prep work went into getting the schema right? If it changes, how do you keep up with those changes? It’s probably … Jeff, do you want to take that one?
Jeff Carr: Well, sure. I think either of us could take it because Michael’s doing it, but SlamData determines the schema dynamically. There is no prep work, there is no effort at all. We connect to the database, we determine the schema dynamically. As the schema changes, we adjust as it adjusts. There’s no work to do there. That’s why we eliminated all that mapping and ETL and that kind of stuff.
Michael Melmed: Yeah. I would just add when we added our wifi plans, it was just there one day. There was no setup or thought about it in terms of getting it into SlamData.
Chris Dima: Okay. Michael, you’re not actually embedding in an internet yet, but, Jeff, embedding is a huge part of SlamData. Can you talk about how that works?
Jeff Carr: Yeah. Any report that you create can either be shared internally via link sharing, both securely or just via a regular link, but we also allow you to essentially one-click embed this inside an app and then securely expose that to the outside world, to potentially hundreds of thousands or even millions of customers, depending on the nature of your application. As a new developer, you’re not out there building secure APIs and all the kinds of things that you would do if you were trying to build this custom from scratch. You just simply click and embed it into your app and it becomes a live report inside of your existing SaaS application.
Chris Dima: The next question is is it multitenant? Can you describe some of the product features around that? Jeff?
Jeff Carr: Yeah, sure. It’s fully multi-tenant. It’s designed specifically for companies trying to deliver SaaS solutions, data products, as we often refer to them, to large numbers of customers, which can be both individual end users, consumers, if you will, or even just individual corporate clients. If you’re building a healthcare app and you’ve got 50 different hospitals using it and they all need to be able to access your data securely, we provide that out of the box.
Chris Dima: Okay. This next one could be either. Do you run this on production? Let’s ask Michael. How do you set this up? Are you hitting your production database, or something setup for analytics?
Michael Melmed: When we first launched it, I just want it up and running as quickly as possible to test it out, so it was on production. Then we setup replica so that we could lighten the load a little bit.
Jeff Carr: Yeah. For anybody that’s on the webinar new to Mongo, one of the nice things about it is you can create replica sets really easily and very quickly. Setting up a dedicated replica for doing analytics is a popular way to use a tool like ours.
Chris Dima: Okay. The next question is how does it work different relative to ETL flattening, the schema that gets outdated?
Jeff Carr: Sure. Well, I mean it, by definition, eliminates that. When you’re doing ETL, you’re basically extracting the data from the source. In this case, MongoDB. You have to go through and create a process to flatten that all into a fixed schema and then move that to some other location, whether that’s relational database or Amazon Redshift or something like that. That is work and you have to invest in an ETL software and you have to maintain all those mapping. Every time that schema changes, and that’s very common in NoSQL databases like MongoDB, then your ETL mapping breaks. If you talk to people that have done this, they’ve spent a lot of time maintaining ETL mappings because every time the schema changes … Or the example Michael gave a minute ago, if you open an ETL process, when they added those wireless plans for their new product, you would’ve had to go back and rebuild that ETL process to account for that. We make all that go away. We just account for the fact that those new products, or the new wifi plans, became data in the system and they’re there and available for us to query.
Chris Dima: Okay. Michael, maybe you could weigh in. What’s the difference for your business, for a SaaS business, understanding data or detecting changes in the business right now versus three, four days lag? Is there a big business value having it now?
Michael Melmed: Yeah, there always is. I mean we have a pretty complex business that is providing talk, text, and data, now wifi service round-the-clock, and the data that we have in our database needs to be there round-the-clock and in real-time. Just the nature of our business requires it even though before SlamData, we didn’t necessarily have it.
Chris Dima: Yeah. I think in terms of your customer service, I mean that always has to be real-time. People are buying and changing and asking for support. If you don’t have real-time data, then you’re out of sync with them. The next question: why is SlamData solution a better option to get these analytics? Is it ease of development or the changes to schema … ? I think this is some we’ve touched already, but maybe approach it more simply. Jeff, how do you want to take that? Why is SlamData the better option to get these analytics?
Jeff Carr: Yeah, because there are several reasons. One, it doesn’t require developer resources. That’s one of the biggest challenges today is, and I think Michael touched on this earlier, companies want their developers focused on adding core features to their products and their solutions, not writing queries and hooking up charting libraries and building all kinds of custom reporting software. That’s not as value-added. I mean, obviously, reporting is important, but that’s just not where they want to spend their resources. We allow non-engineers to be able to do the kinds of things that Michael just showed very easily. I think that’s a key element. We also just in terms of how quickly you can do it. We’ve shown some examples. We didn’t show this today, but in the case of MongoDB native queries, sometimes those queries are literally hundreds of lines to do relatively simple things. We replace that with a handful of lines of SQL or even a visual query. It’s about really getting the right resources focused on the right tasks. It’s about time-to-value or time-to-insight, when you think about analytics. Then it’s about future flexibility as well, too. If you’re building something custom, not only are you using developer resources to do that, but then once you’ve done that, you’re stuck with it. You’re maintaining that forever. Every time someone needs a change, somebody’s going to have to go back and start digging around. We’ve built all that plumbing and infrastructure for you in the SlamData app, so that if you need to make a change or make an addition, you just do it in a matter of minutes. I think Michael demonstrated that several times in his reports that he showed us, where he was able to go back in and add a new feature or a new capability in a few minutes. It’s really those things. It’s about resources, it’s about time-to-value, time-to-insight, and then future cost of ownership, if you will.
Chris Dima: Okay. That covers the questions. We have two or three minutes left. Let’s go back to what we had planned, which is to ask Michael what are some of the things that you’re looking forward to addressing in the next 12 months from a business intelligence standpoint? What do you want to start seeing in the reports? What are you going to pursue?
Michael Melmed: I know for us that it’s been great having access to all this data in MongoDB, but we do still have data in other places, whether it’s our legacy SQL database or elasticsearch, or even some tracking tools like Google Analytics are Mixpanel, and being able to connect all of those data sources with the data that we have in MongoDB would be something we’d be looking to do over the next few months or year.
Chris Dima: Okay. In some ways, it was a loaded question, but we also discovered that it coincides with our roadmap and really our other use case in opposite order. A lot of people come to SlamData for this particular use case, which is exactly what you just described. Jeff, maybe you could talk a little bit about that and maybe mention some things in the roadmap that you even make this more faster and easier?
Jeff Carr: You bet. There’s a few things that are exciting coming yet this year. We’re always adding support for new data sources. Today we support the NoSQL data sources, I mentioned before MongoDB, Couchbase, MarkLogic, as well as Apache Spark, but we’re also adding this year support for PostgreSQL, and then we’ll continue to add support for additional SQL sources as well. Then one of the common use cases that that allows is for people to basically be able to combine data from multiple different sources, as Michael was just pointing out, and then create essentially what we call a data hub as a way of getting that customer 360 or product 360, or just creating that global view for your company.
Chris Dima: Okay, great. That takes us to 2:59. I’d like to say thank you to everybody who joined as attendees and also to Michael in US Mobile for being so thorough in your sharing for us and for our community and, Jeff, for your time and for building this product that’s unique in the market. Everybody who’s registered or attended will get a replay. I’d ask that you share it across your company. If you have any questions, send them to Chris@slamdata.kinsta.com. I think that’s it. Jeff? Michael?
Jeff Carr: Yeah. Thanks for everybody. Michael, we really appreciate your time.
Michael Melmed: Yeah. Happy to be here. You bet.
Chris Dima: All right. Thanks. Take care, everyone.
Michael Melmed: You bet. Bye.