How to Automate & Scale Amazon Seller Central Reporting

Foreign. So hi everyone. Welcome to the Second of Reason Automation's monthly office hours. Thank you so much for joining us. Last time we did a sort of open ended format of doing frequently asked questions, just addressing some common questions that we've seen from our customers and prospects as well as other folks in the reporting space and data space. But this time around we noticed we're starting to get themes of questions so we thought we would would present topical something more topical this time around. How to automate and scale your Amazon Seller Central reporting. We've come up with a few different frameworks for helping reduce the ambiguity of this process because we know it's a little crazy. As we walk through this today, I'll be doing most of the talking and presenting, but if at any time you have questions, please feel free to drop them into the chat. We're going to look at every single one and after I'm done speaking today, we'll hopefully have time to address everyone's questions, but if not will follow up individually with all of you. All right, so at a high level we all know Seller reporting is hard. It feels like it should be easy. If you're ex Amazon like we are, it feels like it should be as easy as writing a SQL query, getting the data out of a database and into whatever tool that you're using. And yet that's absolutely not how it works. We found that although there are many, many, many different ways that folks try to solve this, they fall into three main buckets. One, either you're using the default Seller Central reports that come out of Amazon's platforms. And at this point I think we're all intimately familiar with the pain points as well as the positive points of those dashboards. Second, you might be using someone else's dashboard, whether that's somebody else that has an E Commerce platform that you plug into and they do a bunch of price optimization, content optimization, or whatever else it is, or it could even just be a simple analytics dashboard, but it's someone else's. And I think the reason that you're all here today is you've landed on the third bucket, which is that Seller Central is not working for you, somebody else's template isn't working for you, and now you need to build a custom solution. But it's not entirely clear what all the components are that are necessary to make a minimum lovable custom solution. And it's hard to create a realistic budget for understanding what all that's going to cost to implement now and maintain in the future. So we've introduced a pretty simple framework here for helping folks approach this at a high level. We think it starts with choosing your data sources, you know, working backwards from the customer. What do customers of this report care about? What analyses are you ultimately going to want them to see and what conclusions do you want to help them draw? Whether this is your internal team members that you're helping equip with the, you know, the dashboards and internal tools that they need to perform weekly business reviews, or you're creating client facing reporting that you know your your clients will ultimately use to self serve the components required. So we know that there's a whole bunch of different elements, whether it's, you know, getting data out of system, to how are you storing the data, to how is that data visualized and all of the supporting services around that. Some visualization options we know that oftentimes the first decision folks get hung up on is which which software system do I use to actually build my reports in? We call that visualization and although it is an important topic, notice it's third on this list. We'll walk you through some of the most common options and our take on them. And then last but not least, how do you plan for the costs and budgeting for implementing a stellar reporting framework? So, starting at the top with data sources, our most common data sources. You know, obviously starting with what you're getting out of Seller Central, almost every money is doing some sort of reporting using sales and traffic, inventory and returns based data. This feels like the minimum lovable set of reports that you need in order to make a usable client dashboard that allows someone to deep dive progress week to week. There are multiple different types of reports for each of these data types within Seller Central. For example, for sales and traffic, there's at least five or six different detail reports that we know of in Seller Central that cut things by, e.g. child ASIN versus by SKU. There's a whole bunch of minutia about how those tables are different that we won't go into in this session. But needless to say, it's important to be thoughtful about which particular sales and traffic data source that you're actually using when you build your reports. Same thing with inventory and returns. For example, if you're an FBA seller, you probably rely heavily on your FBA inventory age report, which shows a current snapshot of what you have in the barns, where they're located, where in the network they are, and status and aging, et cetera. But because it is a snapshot, it doesn't have any historical data. Whereas there is a historical inventory report available in Seller Central that has daily historical inventory levels that are not differentiated by network location or status and therefore aren't as useful for doing things like forecasting or understanding your in stock rates. But you have to choose one or the other other common data sources all of the Amazon Advertising I know many of you are already working with organizations or platforms for PPC optimization or something else. So I won't go too deep into Amazon advertising here. But needless to say, if you want to incorporate that, you need to get a pipeline for it. Another one that folks often don't consider out the gate are catalog enhancements. And what I mean by this is basic Seller central reporting includes all the data that Amazon has available and makes available through their ui. But whether you're a manufacturer, a reseller, or an agency helping other brands, you likely have access to data that helps you slice and dice the business or organize the catalog in more meaningful ways than Amazon does. For example, you probably have products grouped by your own types of categories that are completely different than what Amazon's customer facing categorization is through browse nodes or even their cat and subcategory categorization. From the financial accounting standpoint, this allows you to if you think about this at the beginning, it allows you to think about how are you getting that catalog data into your seller platform and your reporting and analytics. And then last but not least, we know that folks are not only selling on Amazon, or maybe there are some of you. I've never met one yet, but most of you are working in multiple channels and Amazon is just one source of your data. And so you need to think about whether or not you're trying to incorporate all of your data sources into this one reporting pipeline, or if this is going to be just Amazon, if it is going to include your other channels. Things to think about are other retailers, distribution channels, and even your DTC sources. Once you've got your data sources lined up and you have a good sense of what the data you want to present is, now you need to for each data source, think about how you're going to get it into the system, transform it, store it, and present it. And so at a high level, here are the required components. First is a data pipeline. This is literally how do you get data out of Amazon system or whatever system and into your analytics tool. At the most basic level, this can refer to you manually downloading reports out of Seller Central every day and importing them into Excel. At a more complicated level, it Might include something like our service at Reason Automation, where we are automatically doing that for you and translating it into database tables, and then a whole bunch of stuff in between. The second major component you need is called an ETL tool or layer. ETL stands for Extract, Transform and Load. And this one's a little bit of a complex concept because ETL is often built into other tools. For example, Excel has an ETL layer built into it, Tableau has an ETL layer built into it, et cetera. And so oftentimes you're using an ETL tool without even knowing it. But it is an important thing to think about, because if you're doing manual downloading for your data pipeline, then your ETL today is actually you as well. What you can think about that as is if you're manually downloading all your reports out of Seller Central, you're probably doing some massaging and combining and transformation of that data to get it to the right granularity, the right time periods and in the right format for you to actually use it in Excel or whatever other tool you're using. That process is exactly is essentially the ETL process. You're just doing it manually, and there are plenty of tools and platforms that automate it. Third, you need to think about storage. Where does this data live? I think that if you're used to working with small volumes of data, storage is easy because most software allows you to store some amount of data in it for free. Excel natively supports roughly a million rows of data, Tableau supports roughly 10 million, Datum Studio supports roughly 10 million cells, ET cetera. But you need to think about how you're going to store that data beyond that. So, for example, if you're starting to work with brands that have a very significant amount of data, or you're combining data sources from not just Seller Central, but your advertising pipelines as well, or especially if you're managing multiple brands, you're going to start to run into the natural limitations of those tools right away and need to think about enterprise level storage and things like Redshift or another SQL database, et cetera. Then last but not least, the piece that everyone gets focused on is what is the tool that we're actually going to use to present the data and build reports and visualize for our customers. This could be everything from graphs in Excel and charts in Excel, all the way to free automated tools like Data Studio, all the way to costly but extremely powerful platforms like Tableau. But this is just the first level. These are what most folks think of when they think about the components of what goes into building an analytics and reporting platform. In reality, there's actually a bunch of other pieces that go into it in terms of work required and we'll touch on this. It's a little harder to quantify because there isn't like a price sheet with a bunch of providers for these things, but we'll try our best to help you estimate these as well. So setup, what do we mean by this? This is all of the work involved in actually getting new platforms and services configured, in designing your report templates and your dashboards in Power BI or Excel or whatever it is, iterating on those things and making sure that they work properly. This often takes a whole bunch of time up front. Report maintenance refers to any work to actually maintain the report that your customers interact with. So if a filter breaks or somebody wants a new feature, they want to see the data displayed in a different way, they want a different graph. Someone has to do that work. Pipeline maintenance. So this is really asking the question, who fixes things that break? How responsive do you need those people to be? Do you need them to be able to support you in a guaranteed time frame or not? If you're doing manual downloading, of course this is all on you. But if you are paying for a service, oftentimes you have a whole bunch of different options. When it comes to included maintenance, this could be anything from zero maintenance. There are a lot of very inexpensive API connectors out there that just connect to the market the MWS API from Amazon and dump the data into a spreadsheet. And if something breaks, you're on your own all the way to more fully managed services where you have a phone number and an email address with humans who will respond to you within a guaranteed time frame. Next is platform maintenance. So thinking about not just the pipeline, how is data getting from point A to point B or the visualization layer, how is the data getting presented? But then thinking about this holistically. So who is thinking about the future of this platform for your company? Who thinks about how to manage users and what access that they get? Who is responsible for onboarding new folks at your company? Who is responsible for helping new clients get acquainted with the platform? All of that comes into the maintenance piece. And then last, that bleeds into training, which is, you know, how do your end users get value from this reporting that you've built? How do you ensure that it's not just a really large sum cost that people say that looks cool and then never use in their day to Day workflow. There's a huge amount of training that goes into getting value from these pipelines, not just for yourself, but for your customers as well. All right, visualization, this is the one that I get the most questions about. So we're going to do a little bit of a deep dive here. You've probably seen there are, especially in 2021, dozens, if not hundreds of options out there with names like Domo, Chartio, Qlik, Sense, et cetera. And there's new ones popping up every day, and then there's big ones that get acquired, like Looker, et cetera, et cetera. And the most common question I get is how the heck do I make a good choice between all these things and how do I group them up so that I can even understand, like, what the broad choices are? And what I can tell you at a high level is unless you are a BI expert, your choices are going to come down to these five almost every single time, because everything else has a steep learning curve and that ultimately ends up sending people back to these five choices. So we'll focus through these today. So, starting with Excel, what do people love about Excel? Well, we all have it. Everybody has it. It comes as part of Microsoft Office, and most people have Office at every work machine that they've ever used forever and ever. And because of that, everybody's familiar with it. Even though Excel is a very complex piece of software and has a very high learning curve over time, it's pretty easy to get started with, and everybody has some experience with it. Most people know how to edit a formula. Most people know how to create a graph. In addition, spreadsheet programs like Excel are super flexible. You can have data in one cell, a formula in the next cell, a completely different formula in the next cell, and then a graphic in the next cell. And Excel doesn't care. Whereas more polished BI software like Data Studio and Power bi, it's a lot harder to get that level of customization and granularity. Excel is extremely well supported by virtue of its age, not only officially through Microsoft channels, but there's a billion Excel experts out there, whether it's paid folks and consultants or free YouTube videos and other educational resources online, which is amazing. And so if you're the type that likes to learn on your own and you're willing to roll up your sleeves and just learn it, build it, Excel is a really great place to start. And actually, even if you plan to use another program, we often recommend customers prototype in Excel because it's so easy and flexible to Build in. And last but not least, Excel has built in ETL and Data Storage. Earlier, when I was explaining etl, I mentioned that you probably already have experience with it through some other software that you're using. In Microsoft products. There's a tool called Power Query, and that's their ETL layer. Power Query is an extremely powerful second layer that operates behind Excel that essentially allows you to bring in data from a whole bunch of different sources, combine it, transform it, exclude it, filter it, et cetera, before it ever hits Excel. And by using Power Query, which is free and built into Excel, you can overcome a lot of the limitations that folks usually run into with the program. For example, if you're using Power Query, you can import more than a million rows of data, no problem, as long as you're transforming it somehow and not trying to send a million rows into Excel. This means, for example, that I can pull in 20 million rows of ASIN level daily level data in history and then combine it to create monthly views in the Power Query layer and extended it to Excel. And I'll never run into a data cap. However, what are the bad sides to Excel? First is that it's hard to maintain. Anybody who's ever tried to create and run Excel based reporting knows exactly what I mean. At Amazon, this was our default for years. You would build something in Excel, build a whole bunch of very complicated pipelines to maintain it, send out copies to everybody and hope that nobody breaks it. If you're very brave, you might host it in SharePoint and hope nobody breaks it there, but they always do. And then anytime you want to make an update, you have to go and find every single disparate copy, make sure that those are all aligned, fix all the data feeds that feed into it, et cetera. And of course, Excel is legacy software. It was built around the desktop. And so compared to more cloud native solutions, it's a lot harder to share content and it doesn't have any cool built in user access control. If you want to share an Excel workbook, you're probably just going to email it to somebody or drop it in Slack. All right, Google Sheets. So a lot of folks think of Google Sheets as just being the cloud version of Excel, but it's actually quite a bit different from our perspective. It is free and it is cloud based, which it has a lot going for it. And much like Excel is flexible in the same way, because it is a spreadsheet, you can do the same data formula, another formula, et cetera, next to it without a problem. And as A bonus, over time, Sheets has become a lot more powerful. And so a lot of Excel skills transfer. This didn't used to be the case. It used to be that Sheets had maybe like a 50th of the formulas and functions that Excel did. And so you had to hack your way into a lot of the same functionality. Now they're oftentimes indistinguishable from each other. However, what Sheets has that Excel doesn't have is it has Google's account management and user control built into it. If you've ever used a Google product on your own, and who hasn't, you're familiar at this point with how your one Google account controls access to like every single Google product that they have. Whether it's Docs, whether it's Google Play and you're playing games on your phone, whether it's, you know, Data Studio or something else entirely. You can leverage that same sort of account management paradigm to control who within your own organization has access. You can create user groups, you can even use this to share with folks outside of your organization. And because almost everybody already has a Google account, it's relatively easy for folks to kind of grasp. And it's a familiar interface. So what are the bad sides to Sheets? It is hard to maintain, just like Excel, although it is cloud based, so you have less of the weird splintered versions problem. But it doesn't have an ETL layer. Unlike Excel, Sheets doesn't have an equivalent of power query. And so anytime Sheets has a problem with a data type or the volume of data, or you want to combine data, it all has to happen within Sheets itself. And that means you have a bunch of limitations. For example, Sheets often has a hard time parsing what type of data something is, for example, date, time, combined columns. Excel will interpret them very, very readily and allow you to format them as a date as a time. It'll allow you to change the format of the time. It'll even allow you to change time zones sheets, unless the date time is formatted in a very, very specific way, just errors out. And it says we don't know what this data is. And it doesn't give you any help on what the data, what the error is, or what's wrong, and it doesn't help you fix it. The only way that you can actually deal with that is to use regular expressions to actually transform the data. And if your eyes just rolled into the back of your head, as I said that, don't worry, you're not alone. So that's a major Blocker for Sheets is that you kind of have to get technical to get around a lot of the edge cases and you have to operate entirely within that one platform. All right, Data Studio. So Google actually released a free report building cloud based tool. If you've never used it, it's actually pretty cool, really easy to get set up. You can plug in a data source, including Reason Automation in seconds. It takes about 30 seconds to a minute to get a new data source integrated and you can be building graphs and visualizations almost immediately. The first time I used Data Studio, I was able to build a report that was not terrible looking and meaningful in an hour and a half. And that's been an experience that most of my peers have replicated. Just like Sheets, it has the same sharing and access control, which is really, really awesome. And because it's Google, it integrates directly with Sheets. So you can use Sheets and do a bunch of calculations and formulas and stuff in that layer and then pass that to Data Studio pre computed if you'd like. However, major problems with Data Studio one is again, they don't have any TL layer. So if you want to be able to transform data or combine data at scale, you need to use another service. Another one is that there's no change control. And what I mean by that is if you make a change in your Data Studio report, that change reflects immediately. There's no concept of things like saving versioning, you know, saving a backup or a template version. It's extremely difficult to manage these things. I've helped a couple of different organizations manage Data Studio implementations and they very, very, very often break their reports by accident. A big portion of what their internal administrative costs are is just somebody making sure every week, checking all the reports to make sure nobody's deleted one by accident. And if it is rebuilding it, and because it's Google, they have very poor supports. You can't get anybody on the phone. It's really difficult to troubleshoot because unlike an established provider like Microsoft or Tableau, Google hasn't had a bunch of time to create meaningful error messages or troubleshooting guides or documentation. So oftentimes when something breaks in Data Studio, it'll just tell you, oh, error. The data set isn't configured properly and it won't give you an error code or anything else to kind of deep dive on. Whereas with Power BI, the equivalent error would tell you, oh, this is error 147,296xb. Look up that code. If you call Microsoft at this number, they'll tell you xyz and here's a bunch of terms for you to Google in case you want to do this work yourself. Speaking of Power bi, this one happens to be our favorite, just because it's the only tool that we think supports massive, massive data without a huge upfront investment. Power BI is published by Microsoft. They have a free tier available called Power BI Desktop. You download it and you can build and manipulate reports from your machine forever for free at no cost. The only time costs come in are when you want to publish online and share. We like Power BI because it's Microsoft. And Microsoft, for better or for worse, is really, really good at enterprise. They understand what enterprise pain points are, they understand technologists and they understand business users. And so everything about Power BI is oriented to those decisions. It's very granular. So you have the ability to scale Power BI's costs and support up and down. We have people that are paying as little $10 a month for their Power BI implementation for one to two users, and people who are spending as much as $3,000 a month in order to run fully automated reporting that runs multiple terabytes of updates for 200 plus client facing dashboards every day. And you can do anything in between as well. Much like Data Studio, it's really easy to just get started with a report in Power bi. Just add a data source and start dragging and dropping stuff and you can build a report really fast. And unlike Data Studio, it has really strong feature support and growth. Right now is actually the last day of Microsoft's build conference and Power BI was one of the keynote highlight products that they were talking about for all of 2021 and 2022. So this is a huge area of investment for Microsoft as a company and they're constantly releasing new AI and ML stuff. However, major weakness of Power BI is because it is a legacy Microsoft product. Much like Excel, much like PowerPoint, there's no built in access control. You don't have a good way to share it with selected users and only with those users. And because it isn't cloud native, it is desktop oriented. Everything that you build starts on the desktop. It's pretty tough to build a report in the cloud first because it is Power BI and Microsoft that means Windows. If you're a Mac user, you might be out of luck on Power bi at least for the next year. Tableau. Everybody is probably familiar with Tableau at this point because they're the big name and they have been for a very long time in the BI space because of that. Much like Excel, they have a huge amount of support in the market. They have a huge, huge ecosystem of supporting services providers, et cetera. The product itself is extremely mature. This is like the seventh or eighth iteration of the thing. And so they've learned a lot of lessons. It runs really smoothly. And in particular, if you're a power user and you have a team that has a lot of BI skill, it's hard to beat Tableau. It's the only platform that has extremely deep data science tools and allows for advanced modeling compared to a bunch of other, the other platforms that we're talking about here. And it's the most user friendly, I think of like the deep data science options earlier when I mentioned that there's a whole bunch of other names that we're not going to talk about here. Oftentimes those are highly specialized niche tools. If you are, you know, depending on what programming language that you know or the specific type of analysis that you want to do, Tableau is like the halfway point. However, downsides to Tableau, number one, it's super expensive. There isn't. It's hard to say what the minimum cost of Tableau is because they don't really give you a holistic pricing model on their website. But the cheapest I've seen somebody get away with Tableau is about $1,000 a month total to implement it internally and equip all their users. The other major problem with Tableau is that it's centrally managed. What that means is that if you implement Tableau, you almost need to have a BI expert hired at your company whose primary job is managing your Tableau implementation. And that person is going to be responsible for making sure that everybody's stuff works properly. It's really hard to distribute Tableau management responsibilities to the individual end users. All right. And last but not least, budgeting. I think I need to stop saying last but not least. I've said that like eight times now. Note to self. So it's really tough to estimate because so many different tools range from free to many thousands of dollars a month depending on how much data that you're piping through. But our goal here is to really give you some high level numbers to anchor off of. And you know, if you look at this and you and your immediate reaction is huh, that doesn't feel right to me. Then I think we've done our job properly. Our goal is just to give you something to react to and use as a benchmark. So coming back to the same framework that we showed earlier for the components I'm going to show you rough costs by component, starting with the data pipeline for seller central. Not thinking about all the other various data sources that you might be interested in. We see this pipeline range from anywhere from 100 to $500 a month, depending on how much data you're pulling in, what else is included, how much additional manipulation is going on, what sorts of granularity that they're doing, and how frequently it gets updated. At the most basic level, you're looking at API style connectors. There's hundreds of these available. If you Google Seller Central API connector, you'll find them all. And I won't bore you with the details. Those tend to be very, very inexpensive all the way to higher end managed services like something like a funnel. Funnel IO will start you at about 500 bucks a month and scale up from there. Second, your ETL layer, assuming that it's not already built into something that you're using, it's going to run you 100 to 300 bucks a month just for managing it at a baseline level. The nice thing about ETL is that it scales very nicely. So if you're incorporating multiple data sources, there isn't a linear increase in this cost. It's going to stay at about 100 to 300 bucks a month up until you hit maybe 1520 plus data sources. Data storage so thinking about how much does it actually cost you to store your data in for example, redshift bigquery for Google or what do you call Azure? This really, really, really gets variable because the storage costs depend on how fast do you want the storage, what volume of data are you pushing through your storage, how readily accessible do you want it to be? Storage companies often offer you two prices depending on whether you're going to access the data regularly versus deep storage for backups, et cetera. At a baseline level, if you're doing really, really basic low volume of data storage, it can be even less than 100 bucks a month. But typically we see this come in at around 150 to start for sellers, all the way up to 1500 bucks. And then visualization this ends up looking like a per user cost because almost all providers do the per seat licensing model. If you look at tableau, it's like 70 bucks a user. For other companies it ends up being more or less depending on what exactly is involved. And then there's other sorts of backend costs that get baked into that, like a server license, etc. The most that we've seen this cost is about 200 bucks ahead for Internal people. That's on the extremely expensive end. This to give you an idea on the low side. Power BI Pro is 10 bucks a month and Google Data Studio of course is free. Next, you have a whole bunch of costs in these sort of like shadow areas of the work involved. So setup. You should expect to spend 40 or more hours in getting your system established, configured, quality assured, doing your research on which solutions to choose, working with the implementation team from your solution providers in order to get things set up, et cetera. This can really, really quickly scale past 40 hours, depending on how custom the reporting you're doing is, how complex it is, et cetera. So this is often an area where we encourage folks to do the work in house, do the first drafts of what you want to see, et cetera, yourself, because all that data is locked up in your head as the business leader or as the person managing the reports. And then you can save yourself a ton of time on iteration here. Next, big bucket is on report maintenance. So what we mean by that is who keeps the reports and visuals updated? If somebody says, hey, I want to see a different KPI in this chart, or hey, we want to change this visual to something completely different, you know who is actually responsible for doing that on your side? On average, this takes 10 to 20 hours a month of skilled labor of some kind. Next, is pipeline maintenance, in plain English. Who fixes things when they break? How responsive do you need that person to be? Like, do you need to be able to get them on the phone and have something again, have them respond to you within an hour or two? Is email okay, 24 hour response time? Do you need those response times to be guaranteed with a service level agreement? All of those things cost money. And then completely separate from all of that is platform maintenance. And this is sort of like, aside from the getting data into your systems, aside from making changes to the reports, there's this macro managing the entire analytics platform. So like who owns seller central reporting for your company and what does that involve? This involves things like presenting outcomes to your leadership and helping them understand why this is valuable and a good use of everyone's time. This includes managing users and permissions. So when new employees come on board at your company, how do you set them up for success? How do you provision access when data sources change at your company? How do you set that up and configure it over time? How are you building scale mechanisms and automation to do that quicker and faster for yourself and for your peers, et cetera? And this dovetails into the last Bucket of training, which is, you know, how do your end users, whether it's an internal peer of yours or a customer, actually learn how to get value from the thing that you just built? Because without any training, oftentimes what we see is people build these amazing dashboards, send out an email saying, look, it's released. And then their teams say, great. And then a month later they look at their usage metrics, nobody's using anything, and they're spinning their wheels, spending a bunch of money on a thing that isn't adding value. When in reality all it takes is just a little bit of introduction handholding as folks get used to a new system and giving them some specific examples of things that they can accomplish. So here's one example, using a couple of providers. So if you've never heard of Funnel IO, they're an API connector that works with a whole bunch of different sources. Their pricing starts at 500 bucks a month, and that includes not just the data pipeline, but also an ETL layer. They do support Seller Central for that 500 bucks a month. So you would need to then take that data and store it somewhere. Assuming that you're working in BigQuery and Data Studio, roughly 150 bucks a month. Again, this is super variable depending on the size of your business. So this is a very rough estimate. And then on the visualization side, Data Studio itself is free. So you know, all in 550 bucks a month at the, you know, paid to a vendor. Cool. Seems reasonable. Where the shadow costs start to come in is in all of these labor hours. And so we don't have a good way of helping you estimate the costs here because there are so many different ways that you can pay for this. Are you going to find one person like that one unicorn human being who has all these skill sets and wants to work for your company and you can pay them a salary to do it. Cool. Are you going to find, you know, a set of team members on upwork to do this? That's another option. Are you paying consultancies or other organizations to work on it? That's yet another option. Then of course, there's us. I would be remiss if I didn't talk about our own solution. So at reason, assuming that you are using Seller Central, we actually take care of all of the data ETL and storage for you. Essentially what our mental model was is we're business users. Until we built this business, we didn't know what the heck ETL was and we didn't want to have to Think about it, we just wanted to get data out of Seller Central and into a freaking reporting tool. And so we said, let's take care of all the stuff and let people choose a visualization layer that they want to use. And we go the extra step of providing a free Power BI template to help folks get started with visuals. Because it's all inclusive, it's a lot easier for folks to budget out. Our highest cost SKU for Seller Central is 400 bucks a month, but it actually scales all the way down to 100 if you want. And then the actual hour estimates, we're able to zero in a little bit here because it's our own product, so we're cheating a little bit. But setup is relatively straightforward because we're doing a ton of that setup for you. You don't have to set up your own pipeline. You don't have to do any ETL configuration. You don't have to pay for set up or integrate storage. That's all part of our process. You do still have to do your own report maintenance because we are letting you choose your own visualizations. But that's a relatively contained amount of time. Because we're giving you templates to start. Because we manage your pipeline, you're not. And because we're doing so much of this management for you, the total platform maintenance gets reduced quite a bit. That's really all we got for you today, folks. I hope that that was helpful at a high level for mapping out some of the tools, services and major pain points that we've identified as folks think about engaging and building Seller Central reporting. That said, we know that we're not covering everything. We would love if you would want to chime in with your questions and we'll stay on the line for a while. Please feel free to either chime in or drop your questions in the chat and we'll respond to them as they come up. Got a question from Gabriela. Any Power BI training that we'd recommend? There's a couple, actually. It's not less about Power Bi, more of a power query training. Joe, what's that guy, that YouTube channel that you love so much? Mr. Excel, I think is his name. He's. Yeah, I think it's mrexcel. Hold on, let me. Hopefully it doesn't start playing really loudly. So there's a YouTube guy named MrExcel. There's a whole bunch of other really established YouTube channels for power Bi and then there's a couple of websites that have really, really good reference material on both Power Bi Visual Design, as well as some other languages like Dax and M. One of them is called Dax Do, I believe is the website. It's just an incredible reference of every single possible piece of programming language that you might need, with references back to other ones that you might already know. I'll be sure to send out when we send out the recording of this, I'll share some links because I'm drawing a blank on what the specific URLs are at this moment. Excel on Fire is one of the guys that has really good training, very good step by step videos, and he's very eccentric in his presentation, so he takes very dry material and makes it actually quite entertaining as well, but super helpful. All right, we'll hang out for another five minutes in case folks have more questions, but if you don't have any, thank you so much for your time today again, we'll email out a recording of this as soon as it's available from Zoom, and don't hesitate to reach out to me or Joe if you have any questions. I'm Andrew at reasonautomation. Com. Joe, is Joe at. Yeah, talk to you soon.