So What? How to Get Started With Data Portability

Well, hi everyone. Happy Thursday. Welcome to So What The Marketing Analytics and Insights Live Show. I am Katie, joined by Chris and John. How's it going, guys?

Hello. Not even trying the high five this week. This week we are talking about data portability, uh, specifically how you get started. Uh so we're gonna talk about what it is, how to assess your vendors' data portability, um, and what to do when your system doesn't have data portability. So, data portability is exactly what it sounds like.

It is the portability of your data from one place to another. So think about uh using third-party systems like social media platforms, CRMs, email, uh, marketing automation, you know, all that good stuff. How do you get the data out of it when you need to? Not just for reporting, but what happens if you change systems or suddenly that particular company uh who has the software they go under or they, you know, merge with another company or whatever the situation is. The question that isn't addressed enough is how portable is the data.

It's not addressed enough when you're doing those upfront requirements when you're assessing what system should we be using. So, so you know, we often go through the five P's, which Chris, I'm guessing is where we would probably want to get started today when talking about data portability. And before, you know, before you choose a system, or if you have a system that's already been chosen for you, you want to go through the five Ps, which are purpose, people, process, platform, and performance. And within there, you should be thinking about data portability. So, Chris, where would you like to, you know, jump off on this conversation?

Let's start at the very beginning. Well, so what is the purpose of data portability? Sometimes it's you're changing vendors, right? That's that is probably the most common use case for markets. Like, hey, you know, we're we want to save some money on our CRM.

So we're moving from Salesforce to HubSpot or from HubSpot to Sugar CRM or whatever the case is. But that's probably the most common purpose. But there are other purposes for data portability. Um, some of them maybe you want to inspect your data. You may you want to use your data in different systems.

Um, you may want to just keep a copy of your data because in a world where you so much of our stuff is in the magical cloud, sometimes the cloud goes away, and then you're like, I have nothing. Right? Anyone who's ever like unsubscribed from a streaming service is like, oh yeah, that's right. I have none of my favorite shows anymore because I unsubscribed. It all just vanishes an instant.

Whereas those of us who are old and have gray hair have like binders of CDs and DVDs delaying, are like, okay, if I unsubscribe from everything, I still have my pile of plastic discs. It reminds me of when the cloud first became a thing. I was working at a company where, you know, God bless our director of IT at the time, he was trying very hard to educate the rest of the leadership team on the cloud and what it meant for our data, because we were working with sensitive data, HIPAA compliant data. So there was a lot of considerations. And I just remember all of the leaders, like for the next three months in meetings, like, oh, so you know, well, we're gonna have the cloud.

So it, you know, we're just gonna put it in the cloud. Well, it'll be in the cloud. So, you know, when are we getting the cloud? Well, how do I get access to the cloud? So, where's the cloud?

And it just it became this buzzword bingo game of how many times in a meeting was somebody gonna say the cloud. So I appreciate you know, you bringing up that example because I think, you know, while this episode is not about, you know, cloud security and you know, data storage in the cloud, I do think is an um it's an important part of the conversation as we think about data portability. There's a wonderful t-shirt floating around the IT community that says there is no cloud, it's just someone else's computer. It's exactly what it is. Um, so purpose is though obviously the first place to figure out what it is you're trying to do.

The most important part of data portability, believe it or not, is actually the people. And the reason for love it. Love it. The reason for this is because there's different levels of data portability. So let me give you a few examples.

Um, data portability means essentially, can you get the data out of the system? Right. And so there are some examples. This is a Google takeout, for example. Very simple.

It says, Hey, is push this button, get your data, right? And many social networks have this with uh they are in fact, most companies are required to have something like this now, thanks to GDPR, the General Data Protection Regulation of the EU. One of which says a user may at you know any point request a copy of their data. California implemented this, Virginia implemented this, and a few other states implemented this as well in the USA and various other privacy uh regulations around the world essentially say you've got to be able to get a copy of your data. Sometimes it's easy.

Push the button, get the thing. It's like you know, it's like putting coins in a gumball machine, this stuff comes out. Sometimes it's not that easy. So, for example, with WordPress, if you want to export your WordPress data, this is the uh admin panel for the MySQL server that sits underneath WordPress. Like WordPress is this fancy web interface, but underneath there's infrastructure.

There's the typically the Apache web server, there's the MySQL database, and then there's the PHP programming language. And this to get your data out of WordPress, if you want to get the whole database, you have got to have a person on staff, maybe you may not be you, who can do that, who knows how to use MySQL uh or or its its variants. There are other forms of data export where you may be able to easily get the data, but the data is not in a format that you're comfortable with. So, in for example, in Google Tag Manager, you can say, I want my I want my container, I want it to get my tag magic container. You hit that export button, and what you get is a big old JSON file, right?

Which is great. This is this is the data, this is the good stuff here. However, if you can't read and work with JSON data, this is not so helpful. So that that second P of people is so important because if you don't have the well, I guess you have to assess who do you have on staff? And what are their levels of skill in working with data to know what your data portability options are.

John, let me ask you this question, because you've worked with a lot of vendors throughout your career. I mean, I know we all have, but and I'm interested in your perspective. What do you think is the reasoning behind making it so difficult for a user to get their data out of a piece of software that they have, you know, subscribed to. Oh, yeah, it's lock in. I mean, that's, you know, by design, right?

The the goal is to, yeah, exactly. Handcuffs, as Chris is showing there. You know, there's no upside really for a vendor to make your data available in a format that's easily transferable to a competitor, right? There, there's literally no value. Um, and so unless they have some kind of uh, you know, altruistic streak, and that's part of their mission statement, it literally a C level team cannot get approval to do it, you know, because you're basically giving away your market share and competitive advantage.

So yeah, the the only way you kind of get into it is usually everybody wants to integrate to things. And so whatever the integration infrastructure is also exposes at least some of your data. And so then you can you can get around that. But yeah, and it's a tough thing too, because depending on the platform you're on, right? You may have features that nobody else supports anyway.

So getting that extra data is not going to help you unless you're building your own system because you can't that data can't be used by any other systems out there. So that's another thing that makes it complicated. Um yeah, you can go down rat holes of like, well, just because you copy this data from one CRM system doesn't mean you can just directly load it into another one. You know, you might have to remap things and depending on how those data objects are set up, it can create a whole slew of headaches that may even be, you know, not impossible, but it's like it would be cheaper to hire somebody to just key in the data than figure out how to, you know, work around that and where to go. Yep, it's all about locking.

Um this, by the way, is something really important if uh because this is something that we do pride ourselves on uh as a consulting company. If you're working with any kind of agency and they require uh they that agency requires you to use their credentials, their logins and and stuff like that. Um they're essentially locking you in. They're saying like you won't be able to get access to your data without us and things. So you know one of the things we're very clear about in all of our consulting engagements is uh we're gonna use your stuff so that if you do at some point choose to not do business with anymore, you're not being held hostage by us because it's it's a pain uh to to deintegrate.

And also it's just I mean it's it's it's not illegal, but it sure is kind of slimy. We're not slimy. Not on most days. Um so the third one is process, which is how do you get your data out? What is the process?

And in this, so it let's use a a less common data portability use case. Let's say, huge surprise, we want to use our data with generative AI, right? We so we want to be able to move our data from the systems it's in into a into generative AI somehow so that we can make use of the data. So the question is what kind of process is involved in exporting the data, then what sort of process is needed to get the data ready for generative AI, and then what's the process for getting it into generative AI and getting it to generative AI to do something with it? I hit the crispen button.

I say, hey Chris, we got to move our data. Good luck. And this is where process and platform get intertwined. So you will have you have okay. Well, what platform do we have or working with?

What's the generative AI system that's the target platform? And what data formats does it support? So for example, chat GPT supports, you know, you're typically your like your Microsoft Office style files, you know, or documents, Excel documents, PowerPoints, PDFs, et cetera. Um, Google Gemini supports uh all that, plus Google Drive stuff, plus uh different programming formats, audio and video, Anthropix Claude supports again most office documents and things like that. Are they all through their APIs, their application programming interfaces, can support just direct streams of data, typically in in one of two formats, either JSON or CSV.

Most of the time with APIs, it's in JSON format stuff. So part of the part of the process is figuring out what have you got from the export side, and then what does the import system accept? And if what's coming out of the system is incompatible with the what's coming into the other system, you need to have something in the middle that translates between the two. Yeah, I mean, this is why it's it's so important to do your requirements up front to figure out why do I need to do this thing in the first place? Um, and that's where you would have your set of user stories.

So as a persona, I want to sew that. So in this scenario, I could see it being, you know, as the CEO, I want to look at my CRM and marketing automation data together so that I can do a more robust attribution analysis. Um, or I want to look at my CRM and marketing automation and website analytics and revenue data so that I can do some sort of marketing mixed model. And that's where you're like, okay, great. That sounds lovely on paper.

That sounds like a really good idea. How the heck are we going to get all of that data? And we've run into this. Um, we've had enterprise-sized clients who've wanted to do things like attribution models and marketing mixed models, which I feel like is a really common use case for understanding the requirements for data portability, where they said, I have all of these different systems. I want to put together a marketing mixed model, or even I want to do uh a CDP, a single view of the customer, uh customer data platform.

And so what you end up having is all of these different systems that don't necessarily talk to each other. So now you have to dig into the data portability of how do I get the data out? Once I get the data out, what do I have? And then how does it match up to the six other systems that I plan on using to do an analysis with? And then once I get the data out, where the heck do I put it?

Do I put it in this magical mystical cloud thing that's above my head, which is really just John's computer? He's taking all of your data. Or, you know, do I have some other like SQL database or whatever the thing is? And so, you know, Chris, it feels like just such it feels very convoluted. And I feel like the more we're trying to simplify it and explain it, the more tangled it gets.

It does, but that's why having the user story and the five P's is important because it at least guides you in the in the right direction. So let's look at a very practical example. We're talking really about Google Tag Manager, right? So I let's say I have my Google Tag Manager instance, and I know uh, you know, there's this there's some stuff in here that's that I'm pretty sure is is not great, right? So how would I you how I use data portability to make the job of cleaning up my tag manager instance easier?

Well, you'll notice there's two features import and export container. I can I can go into that, I can say, well, what version of my container do I want to export or do I want to import a container? By the way, importing a container is kind of a here's a bit of a trade secret. If you are a company that uh does a lot of tag manager stuff, you can set up a test container or sample container of your best practices, export it, and then when you work with a new client, just import your new container right into their instance, and boom, you've got all your best practices uh in one shot. It's a huge time saver.

Um so in this case, I hit the export button. I've got myself a JSON file. Woo! Now, here's the thing about today's generative AI models. They are extremely good at understanding formats like JSON.

They have been programmed and trained on ridiculous amounts of this style of stuff. So I can go into a tool. I'm gonna go into Google's Gemini 1.5 model, and I'm gonna start off by saying, let's talk about auditing Google Tag Manager. What are the best practices? Right.

Um, if you have not uh if you want to check it out, uh there is a whole download for uh for this general process of of getting us uh a tool prompted very quickly. Go to trust insights.ai slash power questions. You can get the one-page PDF totally free. Don't even need to fill out a form, uh, and you'll get some of these questions that we ask the uh language models to improve their performance rapidly. All right, so I've gotten I preloaded a lot of the the knowledge about just what constitutes a good you know good practices for a tag manager.

So I'm gonna say great. I'm going to provide you with the JSON export of my Google Tag Manager container. Using these best practices, please audit it. I'm gonna hit file, do it upload here, and gonna drag in my JSON file. Now, this is a this is a beefy up says oh it has it ran to an error extracting from the file.

I did not like that. All right, let's try this. Let's make a copy of that file and call it a text file instead. This is part of data portability, knowing what's what your systems can and can't handle. All right, so go back to our file import and bring in now this lovely text file.

There we go. 64,000 tokens of information later, and now we're gonna have uh the AI studio just try and read this thing and based on its knowledge, hopefully come up with some recommendations. Says based on the provided export, here's an audit version control is zero. You have some good version control problems. Um naming conventions are inconsistent, right?

So we've got uh tags that don't have good naming convention. Trigger logic is good. You have multiple thank you page triggers. Whoops, uh oh, that's bad. Um, there's some third uh some third-party tags.

So what it's done is in a very in very short order, we've taken using data portability to get data out of one system, add to a bit of reformatting, reformat it as a text file, and then put it into a different system to make use of it. And it and the recommendations here like, hey, you've got a bunch of tags that are paused. If you don't need them, get rid of them. So this is an example of where where that data portability really comes in handy. So one of the questions we get a lot uh from our customers and from our audience from our uh prospects is what questions should I be asking a vendor if I'm considering their software?

And so obviously, data portability is a big question, but what are the specific questions around data portability that people should be asking? Or what is what are some things that they should be looking for? Because I feel like you know, if you're doing a demo of a piece of software, you're not necessarily getting all of the information you need. Um, you know, so you may see like export an export data button, but if you're doing a demo, that may not be enabled for you. So you can't really see like what you're getting.

So, what are some of the questions that somebody who's evaluating a vendor uh should be asking about data portability? Tell me the process for exporting all my data in one shot. That's the question. Because most vendors will say, Oh, we don't support that. Like, okay, why not?

Um, and of course, you know, that goes back to John's answer is they don't want to make it easy for you to leave. Um, for example, if you are in the Hubspot CRM system, it is a royal pain to export your data from that system. You can do it one page at a time. Um, you know, you have to export your contacts, you have to export your company, you have to export your deals, you have to export your notes and all that stuff, and even then it will take some time. They they say in their documentation, oh, well, you can just use the API and just you know export uh stuff like that, which you can do, but their API is also not a whole lot of fun to work with.

And it requires a very high amount of technical skill to do that. Um I feel like, well, and with that, I feel like there's they don't give you all the information when they say, oh, you can just export it through our API. So to your point, there's a lot of technic technical skills involved. You also need to know how to develop against an API in order to get the data out and know that what's coming out is everything. Um, you know, I think that that's one of the challenges right now with Google Analytics for is yes, they have an API, but it doesn't give you everything, or it times out, or it's different from what you get in the actual Google Analytics 4 interface.

To a degree, so if your Google Analytics instance was set up well, um, there should be the automatic backup to a big query database. That uh is your one that is your one-shot export because you can take a big query database and just dump the thing as a in as a SQL file. It is gigantic depending on the size of your site, and it has a very high bar of technical skill to do that, but it at least the option does exist. If you just say, okay, just give me my database, I'm leaving now. Um, other systems, no, you can't like you can't even do that.

There's it's just the option's just not there. What do you think, John? If let's say you were evaluating uh vendors and you said, How do I get all my data out? And they said you can't, like what what would obviously you would have a like, oh, what the hell reaction, but what where do you go from there? What if you've inherited the systems, you know, their legacy systems?

Like, what do you do? Yeah, well, that there's a lot of poker that goes into that, right? Because like the first thing you have to think about as an exec is like, do I even want to raise this question? Because if your managers and the boss and the board and everybody are like, yeah, we have to have this, and you know that there's no tools out there at all that do this, you're just opening up uh, you know, Pandora's box of hell for yourself. Um, but uh some other easy ways to get out when is it Chris was saying, ask about you know a full export, have them send you a file to tell them you want a sample file so you can see it and see how it's structured and what the layout is.

And then the other one, yeah, an even worse Pandora's box is the API, right? Because everybody's like, oh, we have an API, we integrate, that's cool. But then you get the instructions for the API and you dig in, you're like, oh, wait a minute. Like it, you know, there's 37 fields in each of these entries, but you can access five of them and you can't write to any of them. And you know, there's all these, and the and God forbid, worse you get burned.

I've I had a company where we got destroyed where nobody had mentioned that, oh, by the way, each API call is like two cents, you know. And since you're exporting the whole database, that's going to be, yeah, and it doesn't allow you to batch the queries. It's single, you know, every single dip. So we end up getting a $20,000 bill for you know dumping some data when you're, you know, the product is $850 bucks a month or whatever. Like that happens.

So yeah, it's uh it's uh full on buccaneer pirate adventure trying to get this stuff straight. So the big question, what do we do when your system doesn't have good data portability? But it's a system that you've been required to use, it's a legacy system, it's a it's a system you chose and didn't realize the data portability was going to be important. Like, what do we do? It depends on the system.

Most modern software, there is some kind of underlying database. And to John's point, you maybe just say, hey, look, either send us our files or we're canceling our contract. Um you can generally find an engineer somewhere in that company, like, all right, fine, here's the SQL database export. Just don't tell anyone we gave it to you. Uh the other thing is, and we covered this a few shows back, is have systems in parallel so that you have a fallback.

So, for example, yeah, a few episodes ago we look at exporting your universal analytics data using a couple different tools. We looked at the Matomo uh web analytics system that runs in parallel with Google Analytics. So if you want an easier version of web analytics to work with, or you want to control the underlying database itself, um, you can do that. Those would be some good options. If you have to work with the system you've got, look for what export features it does have.

Like generally, most business systems will have some kind of spreadsheet export somewhere, or a file type that is that is generally compatible. So Excel files, CSV files, JSON files, etc. And to John's point, if you have the technical skill to do so, you may want to use that vendor's API because it may actually save you time if you have the skills to do so. So, for example, Google Analytics 4 is kind of a pain in the butt. Google Analytics does have a really good API.

So, one of the things that we do is we have a script that goes into the API and just yanks all the source medium codes out of it. Um, because we want to be able to see, like, okay, well, what could what of our our UTM tracking codes? What's good, what's bad, right? Are we doing things well or poorly? And we can produce charts from that.

That runs against the GA4 API because yes, you can do this in Explore Hub. It's faster if it's a piece of code that can just run on its own, yeah, just schedule it to run once a month, and you can take a look at it rather than have to mess around in the web interface. And more importantly, as we were saying earlier, you may be you may want to be uh take this data out of here and bring it into something else. So, one of the things that I have in this particular piece of code is it then takes the data and dumps it out as an AI query, right? So it takes the actual data, restructures the data, and turns it into a query that can take and go and copy and paste right into a system like Google's Gemini can say, okay, let's take this um, take our data.

This is an example, another use case of data portability, um, and it's gonna spit out the things that we're doing well with tagging, the things that maybe we're not doing so well with our UTM tagging, um, and then some recommendations like hey, here's some things that you should do. So, this is using an API now to grab the data, using some intermediary code to transform it, and then putting it into an AI system. So, those those are to say the options. So, are there ever any scenarios where data portability doesn't matter? Data portability doesn't matter if it is entirely your system.

Like if you built it from the ground up. Right. So long, long time ago, I built a CRM by hand in PHP and MySQL for a company I was working at in financial services. Portability didn't matter because it was our hardware, our software, our everything. I had to run the freaking server in the server room and you know, make sure the air conditioner was working in there.

So that was a case where we owned the whole thing. We were and it was so hyper customized there was pretty much no chance of ever moving it to any other architecture. Did anyone ever need all of the data besides you? Uh uh not by the time I left. It's a hot it's possible that that that did happen after I left the company.

Um but because it did get acquired a couple of years after I left, but I don't know if if the parent company acquired it said, hey, give us your data, and they're like, we don't remember how to get into the server. Yeah, exactly. You don't have a risk with that. You you were like the one-man army on that once you're gone, it's like good luck. Mm-hmm.

Is there ever a scenario where data portability doesn't matter when it's not yours, when you've not built it yourself? If the data is unimportant, if the if if the data just doesn't matter, right? If if it's if you can discard it and just start fresh, then yeah, portability doesn't matter as much. And there are cases where sometimes that's just what you want to do. So you may, for example, be working with a vendor, say, doing, I don't know, your uh your Google Analytics account, right?

And uh you're like, you know what, yeah, our company's pivoting, we're starting over, we're just gonna start with a fresh new account. We're not even gonna try to bring over our past data. We talked about that with universal analytics, right? With universal analytics data portability. Does it matter?

If you've had GA4 running since it came out in October 2020, you have four years of back data. The value of that much older data, other than for curiosity's sake, probably not super high. So the importance of data portability out of universal analytics may not be that important. Now, if you're in financial services and you're required to keep 10 years of data, then yeah, in that case it does matter. But you know, going back to that older episode, that's a case where the data portability really doesn't matter for us.

And if you want to catch any of those older episodes, you can find them on our YouTube channel under the so what playlist. So go to trustinsites.ai slash YouTube. Um, John, do you ever have you ever been in a scenario where you've signed up for a piece of software just to use the features of it and then said, but I don't care what what data it collects. Oh, yeah. You know, the the vertical for me right now is text messaging, right?

Well, I'm using a vendor and the features I get in there, I can't get from any other vendor without paying like 10 or 20x. So it doesn't matter that I can't export it because I don't have any other options, you know, it's that are nothing. So I have to eat it. Um and then yeah, I don't know. One thing too, I don't know if we want to get into this, is even if it's completely locked down, right?

If that data shows up on a screen somewhere, there are tools you can use to get that data out of there. You know, in fact, I I worked for a company that did a lot of stuff in the medical space, and you know, because of the nature of all these products, there were no APIs, right? Nobody wants you to be able to mess around with your heart rate while you're in uh the critical care unit. And so they had a whole team that created a suite of software that could read screens and do all kinds of scripting stuff to basically scrape data and gather data in an automated fashion. So, you know, that's a whole nother um chapter to this story is you know, if there's data in there and you want to get it out, there are people who can get data out of things, and especially if it's a web-enabled um product.

Fun fact most of today's modern multimodal models can read screen captures very easily. So you can take a screen capture of something like say your phone's home screen and programmatically feed it to a tool like Gemini or Chat GPT and say, transcribe what you see on screen and it will do it for you. Sounds like a lot of work though. So again, so I guess it kind of really does go back to defining your five Ps and really understanding what is the purpose of data portability for this particular piece of software. So you may say, you know what, the reporting that I get out of it, not being able to manipulate the data, not being able to do your own analysis, but the reporting interface that I get from this piece of software is good enough.

I am never going to need to export the entire database and save it somewhere else. That may be fine. If you find yourself in the scenario where you're saying, I need to get all of this data, um, you may go through those different scenarios where you're like, what happens if I change vendors? Or what, you know, whatever the scenario is, then data portability may become more of an issue, more of a risk that if the software that you're choosing doesn't have it, that could be a problem down the line. Um, and then you may, you know, find yourself using something like an SMS messaging system where you're like, I don't care.

As long as I can use the thing, the data doesn't matter. So it really comes down to you running through the five Ps, making sure that you're doing your user stories to figure out your why, how, you know, how are you going to measure success so that when you are choosing vendors or working with vendors, or you know, you have existing software, you're really trying to understand am I going through this exercise of making sure I have data portability because it's a box I need to check, or am I actually going to do something with the information? You know, so as Chris mentioned a few episodes ago on the live stream, we talked about migrating your universal analytics, your GA3 data somewhere into your GA4 data. And for us, we determined that that level of data portability didn't matter. We didn't need that data, but we first had to go through the five Ps and go through that exercise to figure out, you know what, other than you know, someone like Chris who has that natural curiosity for the data, it's not worth the effort and the resources that it would take.

So I would really encourage you before you say I have to have all that data, really make sure that it's something that you will be using down the line. And one uh final piece on this, if you are building software, you also want to be thinking about data portability from the very beginning. So as soon as you start gathering requirements for the software, you have to think about A, what kind of data portability should there be? And B, and B, how do we want to account for that? What kind of how do we want to deal with that?

So for example, uh last year, uh uh one of the things I was trying to do was replicate a piece of software that used to be uh available as a service on the web, and the company that made it went away. Um and this is a piece of software that essentially looks at a web page and tries to figure out all the tracking codes that are on, like what kind of software does it use? Does it use Google Analytics? Does it use Adobe Analytics? Does it use Marketo or Paradon, et cetera?

And we wrote a piece of software to in Python with the help of generative AI to essentially replicate that service. Well, one of the big questions was how do we want to store the data? What kind of data do we want to have available things? And what we end up settling on was we settled on uh having it right to a SQLite database because this is uh, you know, sort of one big repository, but also have the option to say, well, I want it also as a CSV file, things like that. So part of system design has got in your requirements has to be like, well, what format should the data be in?

Um, is it something that's standardized that other systems can work with? And then uh how do we want to make that available? So I chose SQLite because it's it's literally a single file, but it is compatible with pretty much every data science and AI system in the world. So there isn't a single tool out there that can't take that data and work with it. And that was a key consideration of the software, but you have to be part of your requirements gathering process to say, well, what do we want to do with data portability?

Makes sense. Final thoughts, John. Yeah, it's uh think long and hard before you talk to anybody else in the organization about what you want to do with this. Have your own strategy locked in because it can completely spin out of control and get ugly. But by the same token, too, do at least try and come up with it.

Yeah, I guess that's the biggest the the real question. Is you want to have a uh rescue plan unless it's way too dangerous to have a rescue plan. So answer that question. And for vendors, you know, when you're when you're doing vendor selection, that question of you know, is there you know one click export of my data? I think that is a super valuable question to ask a vendor.

And in your consideration process in your scoring rubric for how you evaluate RFPs and vendors, that should be a consideration. Is how how easy is it to get to my data and what level of technical skill do I need to to process it once I get it. Makes sense. Do your requirements, figure out that stuff up front before you get locked in. Exactly, because once you're locked in, it's very hard to get out.

Um all right. If that's all, then uh we will see everyone next time. Thanks for watching today. Be sure to subscribe to our show wherever you're watching it. For more resources and to learn more, check out the Trust Insights Podcast at TrustInsights.ai slash TI podcast.

At our weekly email newsletter at TrustInsights.ai slash newsletter. Got questions about what you saw in today's episode? Join our free analytics for marketers Slack group at trustinsights.ai slash analytics for marketers. See you next time.