Fraud Fighters: How Apache Druid and Imply help Ibotta combat fraud with faster anomaly detection with Jaylyn Stoesz

Transcript

[00:00:00.490] – Reena Leone

Welcome to Tales at Scale, a podcast that cracks open the world of analytics projects. I’m your host, Reena from Imply, and I’m here to bring you stories from developers doing cool things with Apache Druid, real-time data, and analytics, but way beyond your basic BI. I’m talking about analytics applications that are taking data and insights to a whole new level. Ibotta is a free cashback rewards platform that enables advertisers to reach more than 120,000,000 shoppers through its network of retailers, publishers, and owned digital properties. When you’re dealing with e commerce at this scale, fraud detection is critical. The window for detecting and stopping fraud has shrunk to subseconds, but Ibotta has stepped up to meet this challenge and stop scammers and bad actors right in their tracks. To talk us through their real time, data driven fraud protection strategy, powered by Druid and Imply, I’m joined by Jaylyn Stoesz, staff data engineer at Ibotta. Jaylyn, welcome to the show.

[00:00:52.930] – Jaylyn Stoesz

Thank you for having me.

[00:00:54.140] – Reena Leone

So I always like to kick everything off with a little bit about you and your background. So tell me how you got to where you are today.

[00:01:00.850] – Jaylyn Stoesz

Yeah, so my career has been a bit of a winding road, so I got my undergrad in business, specifically hospitality management. So, like restaurants and food and beverage and stuff, the fun one. And I found pretty quickly after graduating that that really wasn’t my calling. So I talked to my professors and wanted to go back to school. And what I ended up doing was instead of going back for a master’s degree in something else, I ended up going to a coding boot camp. And I found that I just absolutely loved it and it was what I was really meant to be doing. So that was about six months. And then after that, I went and worked at an ad tech startup, and that was about eight years ago. And at that ad tech startup, I started in front end, so doing a lot of React, JavaScript, Node, that kind of stuff, and then moved into backend API development, which was in Scala. And then I also worked on our ad server a little bit as well. So eventually they wanted the API that I was building to include reporting data. And so in order to make that happen, I needed some BI chops.

[00:02:09.060] – Jaylyn Stoesz

So I taught myself Spark to support that function before I even really knew what data engineering was. So that was that. Eventually I moved on to my current company, Ibotta, and I started there as a platform engineer. And so on my original team, I worked on kind of a mini streaming analytics service that handled budget pacing for ad campaigns. So I wasn’t there for very long because the data engineering team noticed, and we want that, and so they ended up poaching me for that team. And I’ve kind of been there ever since and I’ve really grown a lot there and have been the tech lead for the kind of non machine learning components of our data platform group for coming up on a couple of years now.

[00:02:53.940] – Reena Leone

Yeah, I definitely understand, like, finding your path. I went to school for music business, and now I’m in tech, and I get to talk to folks about databases every day. So I definitely feel that. So, speaking of databases, obviously we talk a lot about Apache Druid on this show. So how long have you been working with Druid? Was it something you were familiar with before this current project, or did you kind of learn it in the course of this move on to the data team?

[00:03:18.780] – Jaylyn Stoesz

No, I definitely learned it over the course of this project. So we started with this use case where we really needed streaming analytics and didn’t really have a good way of doing it. And so we found Druid. And Imply, actually through somebody who used to work at Ibotta and then had since moved on to work at Imply. And they really sang its praises and said, this is what you’re looking for. And so, over the course of kind of evaluating a few different solutions, we landed on Druid as, like, a really good way of implementing the thing that we needed to.

[00:03:52.730] – Reena Leone

So, yeah. So you started with Druid and Imply versus open source.

[00:03:56.660] – Jaylyn Stoesz

Yeah, Definitely. We have a relatively small team, or at least at the time, it was a much smaller team than what we even have today. And so resources are limited and time to get this solution is limited. Like fraud is a pressing issue, kind of no matter what the circumstance. And we needed something quickly, and we just didn’t have time to stand up an open source version on our own. So, yeah, we went straight to Imply. And then the other reason we picked Imply also was their Pivot offering is really compelling. Right. So my team doesn’t want to be the one doing the fraud detection. We want to hand that off to experts who know what they’re doing in that space. And we have our analysts who are technical and we also have our Ops people who are less technical. Right. And so Pivot with Imply was a really nice offering on top of Druid. That made it a lot more accessible for that team.

[00:04:54.460] – Reena Leone

You kind of mentioned the key use case here, which was fraud detection. That’s kind of the biggest one. I know you’ve written about it in the past. I love when you said you’re fighting fire with fire. Or in this case, automation with automation. Can you tell me a little bit more about this use case?

[00:05:10.310] – Jaylyn Stoesz

Yeah, definitely. So fraud is a nontrivial problem for any company operating in the ecommerce space. And we’re no exception. So as the space and the product change over time, we identify and close attack vectors as we find them. But like everybody who handles transactions, we always have to be on the lookout for new kinds of vulnerabilities. So this is exacerbated by fraudsters who are really good at writing clever little bots to do their work for them. And since speed is a major determining factor in whether or not certain types of attacks will be successful, the fraud bots are really useful for them in doing a lot of damage in a very short amount of time. So essentially, we have to find a solution where we are faster than them. So that’s two different kind of facets, right? So the first one is we need faster anomaly detection. So streaming analytics is really important for this use case because it’s time sensitive and we need things to happen very quickly. So these queries can’t take hours or minutes even to run, because if they do, the window for preventing that damage might already be closed. So we look at statistically significant changes in behavior over time.

[00:06:28.750] – Jaylyn Stoesz

So things like how does the current state compare to the normal state over the last N windows? As well as looking at hard thresholds for certain behaviors. So like there are certain behaviors where if we see an event where somebody is doing this thing, that’s an automatic flag, right? So we’re looking at those event streams to find anomalies and cross referencing those things like running some kind of advanced analytics, combining and squashing those different kinds of behaviors together and then we’ll fire off an alert to our Ops team to investigate. So with the streaming analytics that Druid can do, we’ve been able to start doing these more complex calculations as they release things like windowing and statistical functions. And it’s getting faster and faster all the time. So as it gets more advanced, we can do more interesting stuff with it. So we get faster anomaly detection that way.

[00:07:24.210] – Jaylyn Stoesz

The other facet of this is we need really fast investigation capabilities, right? So the human investigation, like the human action aspect of this is arguably more important than the anomaly detection portion of it. So querying massive normalized data sets in a data lake. We have huge data lake, we have tons of data, but it’s slow to query it, right?

[00:07:50.550] – Jaylyn Stoesz

Because it’s all normalized. You’re doing a lot of joins, it gets really expensive and that’s a slow process and it’s particularly difficult for somebody who is on Ops, for instance, right? We’re doing a lot of needle in a haystack type of queries here to observe the behavior of individuals. And your files really need to be laid out in just the right way to make something like that efficient with a distributed processing engine like Presto or Spark. So obviously, changing your data layout is really difficult to do on the fly when user behaviors are changing so often. So relying on something like a BI tool with a semantic layer to do this, you get more flexibility, but it’s a lot slower because again, the data underlying it is normalized and you’re doing a ton of joins that are built for flexibility and standardization rather than speed. So this makes slicing and dicing and investigations really slow and it makes it really difficult to pinpoint where that fraud is coming from, right? It turns out this is Druid’s bread and butter. Specifically, it’s Imply’s / Pivot’s bread and butter. So the Pivot interface on top of Druid makes this workflow really easy and really fast for non technical users specifically.

[00:09:13.400] – Jaylyn Stoesz

So they get a lot out of it with very little effort. And this means that our Ops teams can take action off of the answers that they find in minutes rather than in hours or days.

[00:09:24.550] – Reena Leone

I mean, it makes sense because two of the core features are Druid is like subsecond at scale, right? So you’re dealing with being able to query data very quickly and then also reliability, which I imagine in this case is incredibly important. Right. And so you obviously had your data architecture kind of set up. What led you to seek out a solution like Druid? Were there challenges that you were experiencing? You mentioned speed as being a factor. Why were you looking for something new?

[00:09:55.710] – Jaylyn Stoesz

Yeah, totally. Main issue is definitely speed. So we can do fraud investigations with our data lake, but it’s slower, right? It’s clunkier for particularly someone who is on an Ops team rather than somebody with an analytical expertise and skill set. And that makes it really challenging and frustrating and sometimes impossible to do the things that they need to do in order to do their job. Right. So the speed is really the determining factor here. We have a pretty sophisticated data platform at Ibotta, but like I mentioned, it’s largely data centric or data lake centric, excuse me. And it’s not designed for rapid response. So especially at the time when we first started implementing this, we didn’t have our lake house architecture yet. So the lake house architecture, things like delta format, hive hoodie make it a lot easier and more efficient to do those needle in a haystack type of queries. But at this point, a few years ago, that wasn’t really an option for us, or at least we hadn’t implemented it yet. So we needed a different way to get really fast and flexible support for this really unique and pressing use case for Ibotta and this workflow.

[00:11:16.530] – Jaylyn Stoesz

So, yeah, it just didn’t really fit with anything else that we had at the time. And we found that Druid with Imply with Pivot was really what we’re looking for specifically, because, like you mentioned, the subsecond queries and on the front end, that drag and drop no code workflow is really what we needed.

[00:11:38.450] – Reena Leone

So, okay, you’ve chosen Druid and Imply we get it implemented. Let’s kind of talk through how has this been solving some of those challenges for you.

[00:11:46.960] – Jaylyn Stoesz

So we added Imply to our suite of data platform tools to solve this particular problem. It has since expanded into a couple of other similar use cases that are not fraud related but still follow the same kind of workflow. But Imply is really filling the gap of our rapid response tool and it’s supplemented by more traditional analytics and like BI tooling that talks to our data lake. So in order to make this viable and really fit our use cases, we wanted to keep cost low. So it was a relatively minor incremental cost on top of the already substantial cost of our data platform. Just like every other company, data platforms cost a lot and so we wanted to make sure that it was bringing more value than what it was costing. And then on top of that, like I mentioned, speed was the big thing, right? So we had to make sure that however we did it, we weren’t trying to replace existing BI tools with Druid. It’s a supplemental thing that fills the gap that we couldn’t fill before with our more traditional BI tools. So in order to do that, and we still do this, we only loaded a subset of our data from the data lake into Druid and we structured it differently, we denormalized it.

[00:13:03.760] – Jaylyn Stoesz

So we picked, let’s say a dozen events that all when cross sectioned together create a picture of what’s happening in the space. We squashed them into what we call a megastream where we just basically dump all of these events into a fire hose. We flatten and denormalize them a little bit so that they’re easier to kind of build cross sections of and then we load that into Druid so everything is flattened out. It’s joined or union together so that you don’t have to do any joins, there’s not a whole lot of shuffling, that kind of thing that you would have to do with Spark jobs to accomplish the same thing. We put it all into the same data set, we denormalize it and we build things on top of that. In addition, we also have a very limited window for the amount of time that we retain this data. So all that data is also available in the data lake, probably forever depending on the data set. So that’s where the kind of source of truth is. But Druid obviously less data means faster queries typically, right? So we keep that data set relatively small and curated specifically for the things that that team is trying to do at that time and that keeps the performance really high and keeps the solution really tailored to the problem that it’s trying to solve.

[00:14:32.610] – Reena Leone

It’s interesting you mentioned unions. I think, don’t quote me on this, anybody listening, but I think Target actually does something very similar because joins in Druid can be done. But they are just we’ll say they’re different, they’re different. I actually have a whole episode on coming out on that one because we’ve introduced some things but they’re not how you would typically do them, right? But again, if you’re looking for speed and having to figure that out, that’s like a really interesting way to kind of work around that.

[00:15:02.790] – Reena Leone

Okay, so you have this implemented, you have your data set up, your subset of data, you get the speed, what results are you seeing now?

[00:15:12.070] – Jaylyn Stoesz

Yeah, we have significantly better control over and response time to the fraud attacks that we see. And then in addition to that, as a bonus, we also have the same kind of insight into non fraud issues that we find over the course of our investigation. So much faster response time to resolution, that kind of thing. Our security team is much happier.

[00:15:38.330] – Reena Leone

Always a good thing

[00:15:39.080] – Jaylyn Stoesz

Yeah, fraud raises issues of security and compliance and all that kind of good stuff that we want to be on point about. And it’s a major priority throughout the organization. Keeping our data secure and keeping our user experience fraud free is a huge priority for Ibotta. So we’re able to do that a lot better with this system. Like I said, just because of the anomaly detection, like the automated portion, in addition to the human aspect of it, we’re enabling and empowering people to do their jobs better to keep our savers safe. On top of that, interestingly, just as far as how we’ve seen things change over time, we have much lower day to day usage of Imply by the fraud team. And this might sound like a bad thing from a product perspective, but it’s actually a really good sign.

[00:16:35.900] – Jaylyn Stoesz

Because what’s happened is because we have this really robust and flexible set of metrics that we can get from our data that we’ve loaded into Druid. We’ve been able to really dig in and investigate the root causes of things and close those loopholes over time. So three years later, we’ve been doing this for a long time and we’ve plugged most of those holes and we find them a lot less frequently. So the manager for the fraud analytics team actually said the other day, he was like, yeah, I mean, I know it looks like things are going horribly wrong because our usage is really low, but that’s actually a really good sign. And if you see a flurry of activity in the fraud cluster in Imply, just something has probably gone horribly awry, but so far I haven’t seen that happen. I think it’s a really well built and well thought out system for identifying and fixing fraud. So I guess what that tells you is that we’ve reduced the instances of these kinds of problems significantly with the help of this system.

[00:17:37.480] – Reena Leone

Hey, if you don’t need to come to us for support because everything is working great, that’s great. If you only have to check on your system every once in a while, you don’t have to be in it every day because all the holes are plugged and everything’s working. That’s fantastic. That’s what anybody would want at the end of the day for the tool, especially with something that’s so important to your business. Right. This is probably one of the most important use cases that we discuss here, along with some of the things we’re doing with safety and operational visibility and things like that.

[00:18:12.130] – Reena Leone

Okay, so speaking of Imply, I feel like this is a very Imply heavy episode, which makes sense because that is my company. You actually have recently launched on a different Imply tool, Imply Polaris. I’d love to talk to you a little bit about that. I know you started out with Imply hybrid, which is kind of basically Druid in your own AWS VPC with a database and cluster support from us, correct?

[00:18:38.310] – Jaylyn Stoesz

Yep.

[00:18:39.170] – Reena Leone

And then you recently migrated to Polaris, which is our fully managed database as a service that’s built for Druid. For those who aren’t familiar, it is kind of like you get all the good stuff for Druid, like the cloud infrastructure and the support. It’s exciting for me to talk about because I never get to talk about it on the show because I so focused on open source Druid. But I would love to talk to you about why you switched. What are some of the benefits you’re hoping to achieve when you made the move over to Polaris? I know it’s still kind of early-ish days.

[00:19:11.020] – Jaylyn Stoesz

Totally. Yeah. So the main things that we were looking for was, for one thing, even lower engineering time for managing the system. So the hybrid offering already gave us a lot of things out of the box. So like, upgrades were super easy, much easier than they would be with the open source system. Like I mentioned earlier, open source is an option, but our team is quite small. And so with that in mind, we were looking for something that can kind of free us up to manage all the other things that we have to take care of and then kind of let the real time analytics portion just hum right along. Right. So we wanted to lower engineering time even further than we already had. And then we were also looking for things like better economy of scale. So we had three separate clusters previously that were running different use cases. And what we found is that that implementation is what we had started with early on before we really understood the system. And what we found is that we can probably get a lot better economy at scale by putting that onto the same cluster and then we can manage that a little bit better with automations built into Polaris.

[00:20:22.330] – Jaylyn Stoesz

So that was really important.

[00:20:23.830] – Reena Leone

So now that you’ve gone through the POC and the migration process, how are you feeling about it?

[00:20:29.920] – Jaylyn Stoesz

Yeah, I think it was the right choice for sure. I would love to work with open source Druid a little bit just because I’m interested in the mechanics of it and kind of pulling those levers myself. But that’s not really an option when we’ve got other things to do. Right. So it was the right choice. Going with a flagship offering of a company usually is, is what I found. That’s where they’re investing most of their time. That’s where you’re getting the new features and all of that. So there were a few speed bumps with adopting a really young product, as with any product. Right. But I’m really happy with the hustle that the Imply team put in to get those things resolved. So as far as I can tell, the Ibotta teams don’t have any complaints. They’re really happy with the product.

[00:21:11.900] – Reena Leone

What were some of the biggest differences between Polaris and hybrid that you had to get used to?

[00:21:21.580] – Jaylyn Stoesz

Yeah, so I’m definitely an engineer at heart and I like knowing all the fine grained details and knowing the mechanics of how everything works. And so I didn’t have like with the hybrid offering, you don’t have as many levers as you would with a fully open source, self managed offering, but you had a little bit of that and Polaris, for better or for worse, abstracts more of that away. Right. So that makes it a lot easier to manage for folks who just don’t have the time to learn how Druid works under the hood. But it was a little bit sad for me losing that fine grain access control, but I know that it’s for the better as far as business outcomes are concerned. So that’s probably the biggest difference. And then on top of that, they release features a lot faster than they did with hybrid environment. It’s a bit more of a cohesive feature set.

[00:22:17.610] – Reena Leone

Yeah, that totally makes sense. And yeah, when we talk about Polaris, we also recommend it if you’re just getting started with Druid for that reason, instead of having to learn all of the open source and set everything up yourself. We already provide the cloud infrastructure, but you’re already coming from a knowledge base from already having used it. So sorry about that. Sorry you lost some control. But I hope that this makes things easier and more efficient in the long run.

[00:22:46.920] – Jaylyn Stoesz

Yeah, it’s the right move. I have no actual complaints. It’s just I like digging into the source code.

[00:22:55.270] – Reena Leone

It’s more of like a sorry, not sorry. I love the okay, so kind of let’s dive into it. What was the most challenging aspect of the migration?

[00:23:08.990] – Jaylyn Stoesz

Sure. Yeah. So, like I kind of described earlier, the way that we’ve structured our data is that we have a bunch of event streams, like a bunch of event data in [Amazon] Kinesis streams, and we squash them together and we dump them into the same Kinesis stream that we like to lovingly call a “megastream”. This works really well for avoiding joins, like we said, better aggregation, that kind of stuff. But it does make for really wide tables that can get a little bit unwieldy when you’re trying to port over configurations in addition to things like getting your indexing, right? Or I guess in Druid it’s called clustering. All that kind of stuff is a lot more challenging when you have those really wide and really varied kinds of tables. So getting that picked up from Hybrid where we had kind of evolved over years and dropping that into Polaris was challenging. So luckily I had a really awesome support team that helped me through that. And then also the Polaris API is pretty great for that kind of stuff. So you don’t have to do it all through the UI with a pointy clicky kind of workflow.

[00:24:21.830] – Jaylyn Stoesz

You can just curl command up a JSON config and it does a lot of that work for you. So that was probably the most challenging part is getting those really complex configurations from one place to another and then on top of that, like explaining that to my support team so they’re not just looking at it like, what is all of this? Yeah, just working through that kind of stuff was challenging, but like I said, the support team is great. So we got through it.

[00:24:50.860] – Reena Leone

Were there any surprises that you weren’t expecting with Polaris? Like good surprises? Like surprise surprises?

[00:24:58.120] – Jaylyn Stoesz

Sure. Yeah, there’s a lot of really neat features that aren’t in the other offerings. So, like, embedding visualizations is pretty cool. There’s some new visualizations that are not available in the other version and just some other kind of neat features that I really appreciate in the new one that were a nice surprise. Also, though, things that weren’t quite so much fun was just it’s a relatively new product, right? It’s a young product and so as an early adopter, we are hitting some of those speed bumps and finding some of those issues that come with any young product, maybe before other folks do. So those are always fun little speed bumps that you have to get past.

[00:25:49.500] – Reena Leone

Well, I appreciate you helping us, you know, working together on this means that we can correct those change things, reconfigure things and make the product better overall.

[00:26:01.170] – Jaylyn Stoesz

Yeah, that’s one of the perks of being an early adopter. Like, you run into some bugs and early product stuff, but also you get to help shape what that product looks like, hopefully in ways that benefit me personally.

[00:26:16.650] – Reena Leone

Did Jaylyn recommend this? Because I’m pretty sure this was on the list.

[00:26:22.650] – Reena Leone

And be like, “I had a conversation today and I have some notes.”

[00:26:26.490] – Jaylyn Stoesz

I’m sure they’re tired of hearing from me.

[00:26:30.030] – Reena Leone

They’ll be like “Reena, Why are you saying this? Why are you here? Okay, I’m kind of know in this line of like, if you had one or two pieces of advice for someone considering the move, what would those be? If they’re moving from Hybrid or even Enterprise to Polaris?

[00:26:49.180] – Jaylyn Stoesz

Yeah, I would say just generally speaking, this is probably true of other migrations too. Don’t try to make any substantial changes to your data sets or environment all at once. I have this bad habit of when you’re picking up and moving somewhere else and like, oh, this is an opportunity, like a clean slate to go do go do all of these things that I’ve been wanting to do for a long time. So like restructuring the data a little bit, like splitting streams apart because the stream has gotten too unwieldy, that kind of stuff. It seems like a really good opportunity to resolve some tech debt. It’s not, it is not a good time. Lift and shift first and then really familiarize yourself with the way that the platform works because it is a little bit different. And learn what all the features are and the cool stuff that you can do before you start making grand plans and changing everything because it just makes the migration take longer. Right.

[00:27:46.690] – Reena Leone

What you’re describing also just sounds like my personal move that I just did. So I wish I had talked to you sooner because that’s what I did with my actual tangible stuff in my house. Not a good idea.

[00:27:59.370] – Jaylyn Stoesz

Yeah, it’s a strong instinct to do it that way.

[00:28:02.800] – Reena Leone

You have to migrate. Don’t try to do a bunch of other stuff on top of it. Good call.

[00:28:09.210] – Jaylyn Stoesz

Luckily, again, my support team was awesome. They were very understanding and they got us through. So there’s that. And then aside from that Polaris specifically, I would take the time to familiarize yourself with the Polaris API because there’s a lot to offer there. It really enables you to easily develop CICD and other DevOps processes to improve governance and automatic deployment, that kind of stuff, if that matters to you. It matters to us a lot. We’re very concerned with governance and automation. So there’s a lot of things that you can do with that API that you couldn’t do previously with hybrid previous versions. So that would be another big piece of advice.

[00:28:58.430] – Reena Leone

Was there anything that you would do differently? You mentioned not changing your data sets or splitting your streams. Is there anything else? I know you’re not that far away from just having gone through the migration process, but anything else that if you could do it all again, all over again, what would you do differently?

[00:29:19.890] – Jaylyn Stoesz

Kind of just what I’ve mentioned before. I would say where it’s a really great product and it’s got some growing pains, but I think a really robust and well thought out offering that I’m really pleased with the results of. But I would probably wait a little bit longer into its product lifecycle to adopt it. We were in a bit of a time crunch with our particular situation, so we may have rushed into it a little bit. So I would just take your time and really get to know the product itself before kind of planning out how you’re going to go about it. With that said, my team, my support team at Imply was a wonderful group of people and I really enjoyed collaborating with them and coming up with new ideas for. The product to make it better and also just kind of smooth out some of those rough edges. But overall, it was a really positive experience, and I’m really grateful to my support folks at Imply for helping us make it happen.

[00:30:21.260] – Reena Leone

Well, we’re helping for being honest and transparent and working through it with us and ultimately helping make Polaris even better. So it’s always great when we have customers who are super engaged and kind of want things to succeed along with you, not just because you’ve invested in the product, but just make it better. Right. I love the collaborative spirit that’s, like, why I’m in open source in the first place. And even though this is, like, Imply’s product, I feel like there’s still that spirit. And here’s the thing. Let’s make it better. Let’s figure out the challenges. Let’s work through it.

[00:30:59.940] – Jaylyn Stoesz

Yeah, absolutely. And maybe another thing to point out is I’m an engineer, and I have engineer brain, and I think about things differently than the end users. And so in this particular situation, because of the timeline that we were operating on, there wasn’t a whole lot of time for collaboration with our business folks, and they were kind of relying on me to just pick it up and drop it and make it work, and we got it done. But I think it would have been better to kind of bring them along more so that they could really shape what it looks like rather than me having to give my best guess of how it should go. Right. So that’s the other thing that I would do differently. But like I said, overall, my stakeholders have no complaints. They really enjoy the platform. I’m very impressed with Druid and how it performs. So very pleased with it.

[00:31:56.120] – Reena Leone

Well, thank you so much, Jaylyn, for joining me. This has been, like, an awesome conversation, and I appreciate you taking the time to chat through everything with me and kind know, give me some more insight into. And it’s also fun because this is the first time I got to really talk about Polaris and dive into it.

[00:32:13.290] – Jaylyn Stoesz

Yeah, happy to be here. Thanks for having me.

[00:32:15.660] – Reena Leone

So if you’d like to learn more about Ibotta, please visit ibotta.com. To learn more about Apache Druid, please feel free to visit druid.Apache.org. And to get more info on Imply or Imply Polaris or Imply Pivot, or any of us topics we’ve mentioned today, please visit imply.io. Until next time, keep it real.