Welcome to "AigoraCast", conversations with industry experts on how new technologies are transforming sensory and consumer science!
AigoraCast is available on Apple Podcasts, Stitcher, Google Podcasts, Spotify, PodCast Republic, Pandora, and Amazon Music. Remember to subscribe, and please leave a positive review if you like what you hear!
Kyle McNamara is the President & CEO at Graphable. He has 25+ years in the software industry as a full-stack web-application developer and architect, as well as in enterprise analytics, software sales and technical pre-sales. Working in venture capital-funded startups to Fortune 50 technology companies, he has created and led teams of all sizes. Recently he managed the IBM Financial Services Cloud/Analytics Architect team, followed by launching Graphable.
Transcript (Semi-automated, forgive typos!)
John: Kyle, thanks and welcome to the show.
Kyle: Hey, thanks for having me.
John: Yeah, great. My pleasure. So, Kyle, the reason I asked you to be on the show is that as many of our listeners now, I am a real advocate for graph databases and I consider Graphable and should I say, parent company, sibling company, GraphAware, what's the relationship between these two companies?
Kyle: It's a sibling companies.
John: Sibling company. GraphAware to be among the preeminent graph database consulting companies. And I think of a lot of exciting technology. I thought it would be really good for our listeners to hear from you and talk about some your capabilities. But before we get into that, can you please kind of take us through the history of Graphable and maybe even just your transition out of IBM into the graph database based? Think that I'll be very interesting.
Kyle: Yeah, that sounds great. So about two years ago, we had a unique opportunity to start Graphable. We came out of the analytic space, both me and my partner, Will Evans, and I just saw a real opportunity to bring some quality partnering with customers. You know, one of our sort of go to's is like we're going to always deliver on time within budget, really sort of being the kind of customer service oriented partner that's just hard to find. And that's kind of how we started, just two of us. And then we grew it and grew it within the space of a year. We had a kind of a unique opportunity to start partnering with GraphAware. And actually we joined forces with them, even became equity partners and ended up being a really, really amazing opportunity because they were so focused on graph databases. And we've been focused on analytics specifically and together we had a really good recipe. The thing that we realized was graph databases really are the future of analytics. Not every kind of analytics, but the really difficult, most valuable kind of analytics that we want to do going forward. You know, everything from analytics on unstructured data to structured data joining those things together, especially at scale. And so bringing those two companies together was sort of a really good match. And so that's kind of the history of it. And, you know, we're 40 plus people strong worldwide spread out around the United States. And it's just been a real pleasure to see this business grow and thrive even in a tough economy like right now.
John: Interesting. I actually didn't know that history. So was Will at IBM as well?What was Will's title at Graphable? Is he the VP?
Kyle: Yep. So he's an equity partner and the VP of strategy and innovation. And yeah, he was actually doing analytics consulting prior to this. I just spotted somebody who was a real natural talent with lots of capability beyond what he was doing. And so I asked him to join me in the startup.
John: So you founded then this analytics company and then you ended up partnering with GraphAware, which is a European company. Is that correct?
Kyle: You got it. Yeah.
John: And so for there was awhile there where you were leading, I mean, the company the organization were leading was the kind of North American branch of GraphAware for a little while. Is that correct?
Kyle: Yeah, that's correct. We actually operated under the GraphAware brand as their Americas presence, as our federal military practice grew, we realized we really couldn't be majority foreign owned. So we just transition that a little bit. Kind of started operating under the name Graphable, but really the same synergy and relationship and presence as far as representing GraphAware in the America's exist as it was before.
John: Yeah. So the same technology, for example the Hume's?
Kyle: We got it the Hume platform.
John: Okay, well, maybe now we should talk about the Hume platform because, you know, as I think I've taken you through as we've sort of I mean, the way everyone should know that and this is no kind of secret or anything, but Aigora and Graphable have a working relationship where something I'm very interested in is helping to bring the technology that companies like Graphable provide into the sensory consumer science space. Your Hume tool is in my opinion, excellent at taking text data and you might call it granulizing or atomizing it down into breaking apart the different, well, first off, you can have sentiment analysis, the topics that are being discussed in the, for example, an online review or a social media post. Can you take us through a little bit? What is this Hume technology that Graphable provides? You know what does it do?
Kyle: Yes. We are really passionate about this Hume platform, because it's helping to answer questions that were previously unanswerable at scale, especially on unstructured data. If you think about what comprises the Hume platform, it really started basically on the pattern that we kept seeing emerge over and over again in customers. And we just decided to start productizing that because it became so obvious that people had these needs. And there's a series of components in that platform. I can just walk you through those R of sensitive , but everything from, say, taking the subject matter, expertise of individuals and transferring that to a machine, right? Even your big fortune, you know 500 Fortune 100 companies, even though they have larger teams and machine learning teams, data science team seems like they really don't have very sophisticated ways of both operating on how to get that subject matter expertise out of the heads of their, you know, their lawyers and their product managers and so forth into the machine. And so we created a capability called inlabs where you can actually do that in a team based environment and not lose the context by having it living in Excel, right? So doing entity annotation, entity linking. Basically, if I translate that, it means taking the unstructured data and giving it meaning context in life that can be used further in analytics in the rest of your, you know, your analytics contexts and requirements as a business. So lab is the reason in component, but it really has a whole bunch of other capabilities, including graph schemas, doing orchestration, so say I wanted to pull from five or ten different sources. I want to then pull on or actually invoke various algorithms that I've already created. A publicly available algorithms, do different processing, have different targets, say I to go off to a graph database, I wanna go off to elastic search, with an index I can do all of that and orchestration. Those includes things like NLP machine learning both IP and expertise, enrichment, really strong visualization and then taking actions on those visualizations. That's sort of the capabilities in a nutshell. It ends up being a whole platform for managing graph, managing your structured and unstructured data and creating a knowledge graph in the middle of it all.
John: Okay, so there's a ton of stuff we have to unpack there. So first off, let's just take a step back and talk about what is a graph database for our listeners who maybe aren't familiar, maybe they're used to, I would say typically, you know, in my field, I find there's either two, well, there's kind of three modes of operation. One is people have data and all sorts of forms on all sorts of computers, and sometimes they have got data inside notebooks. That's the kind of data in the wild form. Then you have sometimes organized Excel spreadsheets where you've got or Excel workbooks, where there's some degree of organization, you've got folders that contain workbooks. And then I would say a level up from that, you will occasionally encounter relational databases where people have gone through the trouble of putting their data into something like a SQL. Some variation of SQL like PostgreSQL, or whatever, any of the various flavors of SQL Server that are out there. But how would you describe a graph database to someone who's not really very familiar with database technology at all?
Kyle: Yeah, the way I've kind of boil it down is it sort of comes down to intent and magnitude, right? Still just data living you know somewhere but as far as how it relates, you know, one to the other in terms of like different records that are in that database. When you think about traditional relational or excel, you talk about basically rows of data that you're gonna try to relate back and forth to different other rows of data. In a graph database, it doesn't really care about all of the data. It cares about how one thing is related to another. It's about, you know, connectedness between things. And that's why, you know, earlier I said it's not for every use case, but it is for a lot of use cases that were previously very difficult to do. Because, for example, if I want to do recommendations as a classic, right? Or if I want to connect up, you know, ingredients across my entire billion dollar business, and how do those things connect across products and how those things connect to even customers or how do I represent incredibly complex sets of relationships? Well, in a traditional relational. Very difficult in a graph. It all it cares about is the connectedness of that. And so the structure of it is really optimized of one thing being connected to another. Not every bit of information about that one thing. So you've got that's sort of the intent and then the magnitude, the other side of that is, you know, certainly you can do some of these things in relational databases or excel, but you can't do it at scale, right? And so that's where I see Graph being uniquely, and that's what captured my interest. You know, more than a year and a half ago as I was seeing graph databases basically coming like a tidal wave. And that's really been proven true over the last year if you look at Gartner's predictions and everything, it's basically opening the door to answering questions about connectedness between the data at scale. So that's graph database.
John: Yeah. That's interesting because I definitely see the same trends when I think of, you know, SQL database. I think, okay, this is a very logical way to essentially organize rows of information, like you said, and figure out what are the, you know, how do those rows of information relate to each other? Now, it's interesting that actually the relation of relational database doesn't correspond to the relationship between rows. It's the relation is actually the table.
Kyle: Yeah, you're right.
John: Yeah. But with a relational database, it is kind of like a very precise bookkeeping for sure that everything you got this entity relationship diagram, you know how everything relates to everything else. But there's a lot of structure there that in my experience, you end up fighting when you're trying to use the database. It's kind of like the database won't get out of your way. You have you're trying to find, you know, the people who, you know, it's true. You know, suppose you just have a question like, okay, you want to pull together for our listeners. You might want to do some investigation into what have been the attributes that we have evaluated and different product categories. Maybe you're looking for kind of patterns. What kind of a larger scale? You're trying to some sort of machine learning where you'd like to figure out, okay, what are the attributes that are most important when it comes to predicting some outcome? And you've pulled together much of a bunch of data from a bunch of different studies. What ends up happening is that you have to, if it's all in a relational database, you have to do a lot of work to figure out how all of the data that are stored in these different tables are related to each other and sometimes write a very complex query to pull out that data from the database. Whereas with a graph database instead of their being, it's interesting because it's like there aren't many tables in a graph database. They're just pieces of information and they're connected according to ways that you've determined are important. So maybe you can talk to our listeners a little bit, Kyle, about what are the advantages of this approach once you get rid of the tables and you just have pieces of information that are connected. Why does that matter? Why is that a better way in many applications of interacting with your data?
Kyle: Yeah. If you think about even starting at just the syntax, like the what you're writing out as a query, it's basically two to three times the syntax to pull out the same information out of a relational source. So right there, you're optimizing how you're even talking to the system about how to get the writing out. And that's because the data structure, one thing being connected to another, is already optimized for the purpose of getting connections out of that database. So that's a huge thing. We're also not storing all of the data in there, right? We're also just storing the things that matter to connectedness. Now, you can further connect that later, right to more data. But since the thing that we care about in the graph world is how things are connected. You have , you know, an economy of scale there as you're scaling a graph analytics use case. So between the syntax, between the optimization of the data itself and then the efficiency is kind of the last thing. It's not just that my query shorter since the data is the data bases formatted in a way that cares about connectedness. When I run that query, I can get, you know, massive amounts of relationship information pulled back in microseconds because the database is purpose built and designed to return relationships and connectedness. Is that make sense?
John: Yeah. That's interesting. I kind of gets back to your intent. The idea that I mean, okay so a couple of things, one is the intent, the other is the flexibility. The fact that you don't have to like with usually with a relational database. You have to figure out ahead of time what are all of the relationships we're trying to capture. And you put it in your yard diagram and then you have to then import your data. What I find and maybe you can tell me with your experience as well that building a graph databases about how flexible. You should have some basic idea of how you plan to use the database, but you can start bringing data in. And if you have a new data source, it's not usually a problem to accommodate in term, all you have to figure out is how is the new data related to the data that's already in the database. And then you can connect it up. So for me, that's a huge advantage because within sensory science we have lots of different types of data. And sometimes it's even hard to anticipate what type of data we're gonna have to incorporate in the future. So maybe you could talk a little bit about some of your experiences building databases for clients. What is that process been like? How do you typically, you know, Graphable goes working with a new client, what is the process typically for you all as you get a sense of what data do they have? How do you design the data model? And then how do you start building a database for them?
Kyle: Yeah, it's a nice kind of approach because it's very visual in the sense that you can have a business conversation, whether it be the technical people or business people we're talking about what's the thing we care about the entity. It can ingredient. It could be, you know, compound of some kind. It could be any part of the puzzle that you're looking to unravel. And you're basically going to put these things up on a whiteboard. That's typically how we start things out. And then you're going to talk about this where it's a little difficult to talk about the kind of relationship between these entities. Right? Is, you know, is an ingredient does it belong to a product, for example? That's a kind of relationship. And you're going to really map out all of these different relationships between these entities that you have a sense of where this is going to go. Now, that's great, because great starting point. But you referenced earlier the flexibility of it. Even if you've missed something, it's very easy to say, hey, I've got this new set of data. And yes, it does participate in some of these relationships, but there's also new relationships and I'm going to easily add those in after the fact. And that's one of the beauties of it for sure. You're not disentangling all of this referential integrity of a relational database to try to get something done. You're just saying I have a new relationship on this new set of data and it's participating in three others. I mean, that's how we start and that's how we iterate actually that database out as a starting point. Oh, somebody forgot a data set as always happens. And then we just add them very easily.
John: Yeah. Right. So, yeah, the flexibility is definitely a big deal. The fact that you've defined the relationships in a way that's meaningful to you. I find that means a scientist can more easily write the queries, the queries make sense to a scientist. But something that you talked about, I think another topic we should cover for our listeners is structured versus unstructured data. That's maybe not a term. Maybe some of our listeners are used to that language. Can you explain a little bit how you know, I mean, I see this actually is more as points, you know, continuum but your thoughts on structured versus unstructured data. What are some examples and how should they be thinking about these two ways of characterizing their data?
Kyle: Yeah. So, yeah, you really could think about it on a continuum. A lot of times people will hear the terms structured, semi-structured and unstructured. Who knows where the break points are between those things? Because you could have what you could call structured data, might be a product name. But in reality, that could be a long, longish name that could be considered as unstructured, depending on the context in which it shows up. So we're really talking about we say structured, really talking about numbers and, you know, short dimension names, things like product name or things like some kind of entity and employee or you know, those sorts of things that would fall more into that structured arena. Unstructured is getting into a little bit longer pieces of data. Also, it's also the context, like social media. A lot of that is just plain old, unstructured. It's never going to be coming from another database. You're gonna be harvesting it from very open forums where, you know, it's just a pile of text essentially. Two other kinds of things, like, hey, I've got a PDF article that is a you know, maybe it's like a food science article that I've, you know, or it's a database of food science where I'm harvesting that information to try to aggregate or try to pull out key information related to product development that I'm doing right? And that's kind of a cool example, because if you take the idea of like, okay, I'm going to do something net new here or a variation, and I want to take all of the previous research to date around this particular topic. But there's no way to read thousands of articles and really process that. Well, a system like Hume using that unstructured data can really map out that data in a way that's then usable to the machine. And then in turn, you can run analytics on it. That surface, what you need to know to kind of stand on the shoulders of that previous research without having to spend years reading all of that.
John: So a certain element of taming the data, like unstructured data in some senses became...
Kyle: It does. And, you know, you think about different sections is there's a title, there's an abstract, there's the body, there's paragraphs. All of these things are meaningful. And what's interesting and, you know, from like a math perspective, these things are not represented as text anymore in the database. They're represented as a numbers. So a value and meaning of the whole article, parts of the article, the title, the abstract. They're encapsulated in numeric values called vectors. And that means that you can really start to operate at lightning fast speeds in the graph database comparing values which encapsulate in code meaning. So it's kind of, you know, as far as using it in commercial context is relatively new. We're talking within the last years as far as people actually using this in production scenarios outside of, say, like, you know, classified environments. And so, you know, yeah, that's the unstructured side piles of data. Encapsulating meaning, breaking it down, giving it form.
John: So it kind of takes me to my next question, which is about NLP, which you've mentioned. So can you, for our listeners can you talk a little bit about, you know, what NLP is and why is it relevant to graph databases?
Kyle: Yeah. NLP or natural language processing sometimes referred to as natural language understanding. You know, this is really the data science around, you know, putting form on unstructured data. So, you know, I would describe it as both the development of algorithms, like there's algorithms called Doc2vec and other paragraph2vec. All these different things, right that are encapsulating capabilities to identify pieces of meaning essentially in unstructured data. And that aspect of it there's also the process aspect of NLP, which is just because you have an algorithm you can run, it doesn't mean that you're going to get what you need to get out of it. Anybody really interested in NLP that the key measures are accuracy and recall? In order to drive those measures up, you really need to optimize your approach. And the approach could vary based on the source and kind of data you're working with. So you know what we've found and we have a team of NLP researchers basically who are, you know, PhD's in related concepts. And you know, they basically spend a good amount of time like we're working with a big Fortune 50 company right now. And the name of the game is essentially trying out algorithms, different combinations of algorithms, applying algorithms at different points of the process. I talked about the orchestrator capability in Hume. You know, you can basically say, I'm going to invoke this algorithm here, but then if I applied two other algorithms at a different part of the process, we actually could drive them here and recall really significantly. That's sort of it's not an easy field. Right? This is why it hasn't necessarily gained mass traction. But the value, because everybody has piles of unstructured data, they're just not changing the value is huge.
John: So if our listeners were, for example, to have a call center data or they've got Yelp reviews or they've got maybe even menus might find this category to an extent. But they've got this unstructured data that has to do with basically consumer facing. I oftentimes see also there's this continuum between objective data and subjective data, which to an extent kind of tracks along with the structure versus unstructured. So if they've got this kind of open ended data, I mean, you could also focus group data interviews, open ends on questionnaires, then your tool could help them to understand what people are talking about kind of at scale. They've got a whole bunch of these reviews and they want to try to figure out what's being discussed in these reviews. Is that the sort of thing that you're talking about when you talked about NLP?
Kyle: Yeah, absolutely. We actually have an interesting use case. We're talking to a cruise line about something very similar to that, where, you know, the reviews of their third party vendors really matter. You know, think about all of these different cruise lines out there. They work with tons and tons of contractors who, you know, if one is not really working out, you know, well, how can I go about tracking that information down? Very hard to do so. And there's just many, many examples like this. You want to harvest reviews about the food being served? You want to harvest responses to, you know, basically market tests around new products coming out. How would I do that at a scale where I could actually, you know, put some analytics around it and then turn that around from all that unstructured data and be able to take action. So, yeah, in this example, we can say the labs capability, we could take, you know, your subject matter experts who normally would have been processing this by hand and teach the system, how does this entity related to that entity? How do we link these things together? It starts to transfer that expertise to the machine and then that machine run in a cyclical fashion on the data as it's being ingested. Right? And then you can actually start to run the analytics on it to say what patterns are we seeing? What's connected? What's surfacing, whether it be from social media or from other sources, what's surfacing as meaningful? Yeah.
John: So you can have that at the one end. And that's what I love about graph database, is that that isn't the only information that we typically have in sensory and consumer science. So if you have that, then of course you have sensory measurements on those same products for which you're getting this kind of Open-Ended information. And then, you know, as you go back in the structured direction, you've got analytic, chemical, you know, physical measurements and formulation information. And so do you see then a graph that as a good way to cap like I personally definitely agree with this. But what's your take on how a graph can connect all those different pieces of information together?
Kyle: Yeah. I mean, this is the beauty of it, because now you have the ability to you know have encoded all of these bits of meaning out of your unstructured data into this graph database, as it what are called nodes or entity in that graph. And you've got a commingling of your structured and unstructured data. So you might be able to say, yes, I've got structured data around a particular compound, but I've also pulled out those same compounds from an article or a set of articles. And those things are now connected just by definition, they're connected in the graph. And so, you know, I might be doing something related to that structure, data research on this compound and how it interacts with other food components. And then all of a sudden, you know, I've got I could surface 50 articles that are specifically related to that one compound. Right?
John: Right.
Kyle: A lot of power.
John: Okay. So we actually are amazingly almost out of time and I always find incredibly quickly this call go by. I would ask a nerdy question just from my own self-indulgence, which is that, you know, we don't have to go into too much detail. But I'm just kind of interested, personally when I've used graph databases, what I have found is there an excellent way to store different types of data in the same place so you can easily pull tables that would be hard to get together otherwise that you can do the work once of organizing your data and then you can basically reap the benefits forever with any question you might care to ask about your data. You know, you could figure out easily what you already know. But when I did the analytics, almost always I pulled the table and I analyzed it outside of the database. What future do you see for doing analysis actually inside the database? Is there a real benefit there, would you say? I mean, is it something that we should be thinking about instead of this paradigm of just using the database as kind of infrastructure? How do you see that? What's the future of analysis happening inside the graph itself?
Kyle: Yeah, that's a great question. So on the one hand, we've actually written connectors to graph databases to sort of pull out the information to standard analytics tools like Domo, Tableau and others where kind of referring to like what you just mentioned but there's so much more that you can do. So as part of our Hume platform, I'll just use that as an example. We've got this graph visualization capability. One of the challenges with the sort of traditional views of graph databases. There are these things called forced directed graphs. They sort of are this massive collection of bubbles that are very difficult to sort of understand how I'm going to dig in and get value back out. So one of the things that we've been focused on is really creating and providing visualization on top of the graph natively where it's really context aware. So in this instance, we're talking about, hey, I want to quickly search for a concept, have that concept be displayed as the starting point in that graphic realization. That alone is a great way to start actually getting value right from the beginning. But then also we've added in these things called actions, which are your ability to encapsulate styles of interaction, I would say, or patterns of interaction with that graph database. So, for example, you know, I might say I might right click on a node and say, show me all of the nodes that have similar taste profiles to this one node that I'm clicking on. And it'll instantaneous whether millions of nodes. I instantaneously render that for me in that native graph UI. So I think all kinds of potential, just with those two things. And then when you start to look at some of the advanced actions that we're seeing people implement, you know what If I want to say a certain level of the graph, run an action where I can say invoke community detection algorithm. Right then immediately returns across billions of nodes, the communities that might not have been detectable, you know, visually or even through any traditional analytics tool. But now I've done it instantaneously with an action on the database. So that's another sort of view of what's possible now. And then the last thing is really just running straight machine learning on the graph database. One of the things that Google identified, I think, was January of 2019 and there's a great article about this was that, you know, that the previous, say, 10 years of machine learning were not as effective as they could have been. And that going forward, a good part of machine learning really needs to happen on some network science basis. Right? So networks of things or graph databases essentially is what that means to drive up the value that needs to be driven out. Our chief scientist, Alessandro Negro, he's just about to release his book, Graph Powered Machine Learning by Manning. And that is the whole point of this, is that there's sort of a new day in data science machine learning on graph. So running machine learning behind the scenes. If we have time, I have a quick story I'd love to share. It's about another cruise company we're talking to where they had actually had an interesting scenario where they were doing like a multi-year fuel buy in Alaska or something like this. And it was ultimately at the wrong fuel grade because where they operate in another air of the worlds in Norway, there was legislation that was just passed saying you have to operate at a higher level of fuel. And so that was like a real use case where, you know, you've got multiple in multibillion dollar company, you've got multiple sources that are just not connected. And it was what if we could have machine learning running on all of our unstructured data, email articles and different things happening inside my company as a kind of, you know, brain? Right? And if you can find that weak signal now, because it's stored as a graph, if you could find any surface, that weak signal to an executive and say, hey, you know, maybe this is important, but it really could be, you know, ahead of it actually happening. Well, now you've got a chance to really move the needle on the business. So I just love that example, because that's another way that you can apply machine analytics and machine learning on a graph sort of running in the background at all times.
John: Interesting. Okay. I'll think about how to apply that in sensory. But I think it's no doubt that the technology is extremely capable of stuff. It's very interesting. And I would say at the very least, you've helped me to understand that to step up, pulling the data out of the graph and analyze it is unnecessary that things can be happening in real time inside the database. Alright Kyle, we are out of time. I usually wrap up by asking few advice that they would give to a young sensory scientist. I guess maybe since you're a little more in the technology space, what's the technology that you see coming? When it comes to knowledge management that you think people should really be paying attention to over the next couple of years?
Kyle: Yeah, I would say, you know, knowledge graphs as a concept have been around a while. But the ability to actually produce a knowledge graph with your unstructured data has been something that has been slightly out of reach until very recently. I would say within the last couple of few years, even. So thinking in terms of, you know, how could I create competitive differentiation for my business with a knowledge graph at the center or for an area of the business, is going to be really creating like a digital twin of your business is really gonna be to be one of the greatest things that has happened in technology in decades. I sense this year and a half ago when I first started kind of understanding what was happening and we took we made a bet on it and that has proven to be true. Gartner said it's going to grow like a hundred percent over the next five years and that is actually happening. So I would say pursuing this in your context is in your industry context is going to be really really critical.
John: Yeah, I definitely see that. The idea almost this digital brand that it's like everything your company knows, but it's connected and alive in a way that's useful.
Kyle: Yeah. It's the way that you can actually use it.
John: Yeah, definitely agree with that. Okay, Kyle this has been great. So people want to get in touch with you, what are the best ways to reach out? I know you're on LinkedIn. I think it's actually you and I originally connected. Do you have other avenues? We're gonna put everything in the show notes so you don't have to spell things out. But what would be the best place people would be in touch you?
Kyle: You could drop by on our website and you can e-mail us from the emails that are listed on the show notes and yeah, anywhere you want we've got a number on there that you can call us as well.
John: Okay, I'll put a link to your LinkedIn profile page so people can connect with you as well.
Kyle: Perfect.
John: Alright, this has been a great, Kyle. Really appreciate you taking the time to be on the show today.
Kyle: This is a real pleasure. Thank you.
John: Okay, great. Thanks a lot. Okay, that's it. Hope you enjoyed this conversation. If you did, please help us grow our audience by telling your friend about AigoraCast and leaving us a positive review on iTunes. Thanks.
That's it for now. If you'd like to receive email updates from Aigora, including weekly video recaps of our blog activity, click on the button below to join our email list. Thanks for stopping by!
Comments