Hello, everyone, and happy new year on behalf of the Amplitude and Willow Tree teams. Welcome, and thank you for joining us for our virtual event today. Today, we're going to discuss the top 10 digital analytics mistakes with the goal of really helping you inform some decisions as you're moving through FY23 to help guide you along those decision-making processes. And we have some experts here with us. And with that, I will pass it off to our presenters to introduce themselves. Hi, everyone. My name is Adam Greco, and I am a product evangelist with Amplitude. I've been in the digital analytics space for about 20 years. I've been through 1,000 or more digital analytics implementation, so I'm really excited to be here today and share some of the common or top 10 mistakes that we see organizations making. And I'll hand it off to Jeremy next. Great. Thanks, Adam. My name is Jeremy Stern. I'm Senior Director of Analytics and Optimization at Willow Tree. Willow Tree is a digital product consultancy that builds digital products for all sorts of companies out there, and me and my team help make sure they're measuring the information they need to measure success of these products and optimize them over time. And I've only been in the industry about 10 years, so not quite up to Adam's level yet, but hopefully still have some insights to provide. And yeah, we're just hoping as we kick off the new year, maybe you made New Year's resolutions to get your analytics house in order, or just using maybe a slow first week back in the office as an excuse to just really take stock of what you're doing and just maybe focus on your analytics program and give it a little love after being distracted at the end of the holiday season. So with that, we'll get in the first item on the list. Which is just at the highest level having a lack of formal analytics ownership at your organization. There isn't one right place that analytics should live in every company. Maybe you have a dedicated analytics department, maybe it's a product team, marketing team, it could even be IT. You can figure out what works best for your org, but ideally it's someone. Someone is kind of where the buck stops for analytics at your company. If it's everyone's job, it's no one's job. And that can lead to a lot of the other issues we're gonna talk about today. Yeah, and that kind of dovetails to the second item that I wanna talk about is really kind of lack of departmental coordination. So as Jeremy said, sometimes at a lot of organizations we see that there's a lack of ownership around analytics. In many cases, we even see a little bit of a fight between different departments about who really holds it. And lately I've seen the biggest ownership battles have been between product teams and marketing teams. And just a little history on this, for many years the digital analytics function was started in the marketing department. Because digital analytics actually started 20 years ago when it was all about seeing how your digital ads were performing on a website. But as things have gotten more sophisticated, we've started to see that product teams are using digital analytics to improve apps just as much if not more so than marketing teams are using it to look at their advertising. And so over the last couple of years, we've started to see a little bit of a shift of ownership from digital analytics being in marketing to product. Now at some companies, as Jeremy mentioned, there might even be a third team, like a data team that owns it. But I think what's really important is that you have to have sort of coordination and you don't wanna have kind of a wrestling match between the groups. And one of the biggest mistakes that we see organizations make is that one group decide we're gonna use an analytics tool on our website, but then they might even use a different analytics tool, say in an app or on a mobile app. And that's because these groups aren't really coordinating. And when that happens, you basically have two analytics tools at your company. And now you have kind of different sources of truth and it makes it really difficult to understand what numbers are right and what numbers are wrong. Another downside of not having coordination around analytics is that you might have marketing teams that are basically looking at acquisition, but they don't really look at the data related to engagement or retention. And then you might have the product teams that are looking at the engagement retention, but not really looking at the acquisition. And in the most extreme cases, we've actually seen organizations that have competing KPIs or North Star metrics between different departments that really cause problems. Just to give you one example, when I worked at salesforce.com, I was in the marketing group and I did marketing digital analytics and my North Star metric was cost per lead, but then the product team, they managed our free trial experience and they were looking at how many people went into a free trial and then actually became customers. And their North Star metric was trial to paid conversion. But what was interesting is there are many things we did in marketing that actually helped us get a better cost per lead, but they actually negatively impacted the product team's North Star metric of getting trailers. For example, I might get a lot of students who wanna learn about Salesforce or CRM who fill out forms, which makes it much better for cost per lead, but then those are unqualified people using our free trial, which hurts the product team. So we're starting to see that now marketing and product teams at all different departments have to start working together and figure out what are the metrics that they wanna focus on where if the metric goes up, both teams or multiple teams are actually happy. So a lot of information there, but that's just all around departmental coordination. So the next one I'll talk about kind of related to this is what I call the incongruent analysis model. Now, when you're doing digital analytics, there's a couple of different approaches you could take to doing analysis. One approach is taking what I call the centralized model, which is anyone who wants a dashboard or report or analysis done, they submit a ticket or they go to a certain centralized team at the organization and that team does the analysis, does the reports, does the dashboards or whatever and then gives it back to kind of the requester. The other model is more of a self-service model, which is anyone can go in and use the digital analytics product, do their own reporting, do their own analysis, come up with their own insights and their own conclusions. And then some companies try to have kind of a hybrid or a mix between there. But I've seen a lot of organizations that the culture of the organization is incongruent with the model that they've chosen. So for example, product teams, they tend to really like the self-service model because they like to be hands on, roll up their sleeves and basically, tag their own data, do analysis on their own data, come up with their own conclusions. In many cases, marketers or large like Fortune 500 companies, they are a little bit nervous about giving everyone access to data or they just can't train everyone effectively. So they kind of gravitate more towards a centralized model. But if you're a startup, a centralized model may not work because it could actually put extra barriers and put no longer durations that it takes and puts the people further away from the data they want. So the advice here is to really take stock of your organization and determine are you kind of more of a centralized approach, more of a self-service approach and make sure that that fits your culture and the people. Because if you have people who don't actually want to do analysis or use analytics every day, then you might want to go towards a centralized model. But if you have people who do, then you might want to go towards self-service. And I think this is probably true of a lot of the points we make, but the right model for your company probably will change over time, right? So this might be something where as you are a startup, you do have one model, it works well for you. And as you grow, as your organization grows, and as your maturity in using analysis and data grows, it might be worth taking stock and revisiting and wondering like, is it time for us to centralize? So even if you've had this process internally a couple of years ago, it can't hurt to revisit. Yeah, and one last thing I'll say is if you are at a very large organization, it could actually be that you have both. There could be some teams that really want a centralized model and some teams that want a decentralized or self-service model.  So next one I'll dive into and then have Jeremy chime in is around the lack of strategic business requirements. And this is probably the common culprit across all types of organizations. In the digital analytics area, we tend to see that many organizations love to collect data, but they don't oftentimes take the time to identify why are we collecting data? What data should we collect? What are the business requirements or business questions that we're hoping to answer? I jokingly call this kind of the shoot fire aim approach. You basically are kind of doing all of the work, but then you're not actually sure what you should be doing. And as a consultant prior to joining Amplitude, I was a consultant in analytics for about 10 years. And my full-time job was going into organizations that had kind of messed up digital analytics programs. And I would analyze all of the data they're collecting. And most, I say about 95% of the time when I asked them, can you show me what are your business requirements around analytics? What are the questions that you hope to solve? They either didn't have it or if they had it, it was five years old, they never kept it updated. And so I would actually go through all of the data that they're currently collecting. And I would do this process that I called reverse engineering where I would then turn it into the form of a question. I used to joke that it was digital analytics jeopardy. And then I would show them the list of the business questions that could be answered based on the data they're collecting. And I kid you not, 50% or more of the time when I showed them the business questions, they would say, hey, half of these questions, I don't care about, why are you saying that we need to answer these questions? And I would go back to them and say, listen, I'm not saying you need to answer these questions. These are the questions that you can answer based on the data you're collecting. And the ironic thing was that a lot of times if I would go to the same organization and say, hey, I think you should get rid of half of the data you're collecting, this seems stupid. They'd be like, no, we can't get rid of that data. But then once I turned that data into questions and said, do you care about these questions? They'd say, no, I don't care about any of those questions. So I would then go back to them and say, okay, so therefore I can get rid of any data that is being used to answer these questions or if the only reason that data is there is because of this question, I can get rid of that data. And then they would say, no, can't get rid of the data. So it was kind of a weird phenomenon, but it is really important to kind of start with the end in mind. Yeah, just last week we had a call with a new client and they had a lot of events they were tracking and we were asking similar questions about the why and they said, we get so many ad hoc requests from different teams, there's no way we could keep up and actually document why all these events are getting tracked. It's all about speed and just making sure we get them in there. And then so we pushed back and said, well, makes it hard to audit for a lot of different reasons. When you have such a piecemeal implementation, they said, well, it's not piecemeal, it's very strategic. And I think that framing the analytics jeopardy is a really good way to showcase that for folks. So I think I'm gonna steal that idea. And kind of related to that, when you have these longer implementations that build up over time, over years, over different stakeholders, an easy mistake to make is to never revisit your tracking requirements and your business requirements. Ideally, we're always treating analytics as an iterative process. Over time, your business questions are going to change. One of those questions you uncovered might have been extremely important to the business two years ago, they got an answer or maybe the product shifted and that answer doesn't matter anymore. Stakeholders change and something that has a very high priority for one executive might not matter to their replacement. And so you just don't wanna end up with tons and tons of events of properties that just don't matter. And so setting some sort of recurring cadence for your organization to look back over everything, ideally check them against those business questions, see if those business questions matter and call things that don't make for a cleaner implementation and make it easier to onboard new folks to your team. They make it easier to identify if you have an issue come up as opposed to when you just have these sprawling legacy implementations, it just becomes harder for everyone to do their job and every step of the process. And if you are really disciplined and keep a list of the business questions in some sort of spreadsheet, then what's really nice is that you can revisit that every six months and you can kind of knock off questions that aren't important anymore. And if there's data that is only there for that business question, you can get rid of that data. And I also recommend that if you do make a list of your business requirements or business questions that you also add a priority next to them. And one of the things that I like to do is look at the top priority business questions and then use that to map to the data elements that are supporting those business questions. And those are the data elements that I wanna really, really make sure I have good data quality and we'll get to data quality in a little bit as well. And as you're doing tracking, you might know from the start this data is only gonna be relevant to us for the next six months. Whether it's a one-off event, just something where you know a certain portion of your product is only going to be relevant for this calendar year, for the summer months. And once you've learned what you have, once that feature is retired or that section of your website is kind of removed from your nav, maybe you can remove some of those events. And if you ahead of time say, we only need this through September 31st, that makes it easier to set a reminder for yourself of like, okay, when our engineers have time, maybe we can remove some of this tracking. Yep, exactly. And that kind of segues into our next common mistake is general implementation missteps. And there's a couple of key things that we see that people make mistakes around implementations. We touched on this a little bit, is just over implementing and just having way too many events and properties.  But what people don't think about is every data point you add to your analytics implementation actually does have a cost because you have to identify like, where's the data coming from? You've got to do tagging or, you know, some sort of coding through an SDK or JavaScript. You then have to figure out the data quality. You also have to teach people what it means. You have to figure out which reports it should be used in and so on. And so a lot of people don't realize how expensive every data point is. And I like to joke that in many cases, if you're spending X number of dollars a year on digital analytics between the team and the product, and you divide that by the number of data points you're collecting, like you could almost jokingly see, like how much it costs per data point. But I think having too many data points in your implementation makes it harder for users when they're even just building a report to be like, hey, there's like 50 properties here. And if there's only 10, then it's much easier for them to understand. And I don't think that, in some cases, I think that less is more when it comes to digital analytics implementations. I'd rather have an implementation with maybe, you know, 15 events and 20 properties that are rock solid, really important that answer really good business questions versus just tracking everything and having all of this data that you're not sure if anyone's using or not. And I think having the business requirements that we talked about previously is a good guard against over implementing because it makes sure that you're not implementing any data that doesn't tie to a prioritized business question.  Now, there's different schools of thought around auto tagging at amplitude as a product analytics vendor. We generally are not huge fans of auto tagging. There are some cases where it does make sense, but auto tagging is where you're basically just kind of opening up the floodgates and just walking the DOM or using technology just to track every single data point that possibly is clicked and so on. In general, we find that this causes more problems than it solves. It definitely is easier to implement because you don't have to be prescriptive and have to, you know, specifically say, I wanna track this event or this property. So the prescriptive approach sometimes takes a little more time upfront, but when you do auto tracking, you end up with just a lot of information then some administrator has to go in and label all these things. And then if you make changes to a website or an app, it possibly could break some of the auto tracking and then you have to kind of fix the data. And a lot of times people start to lose faith in the digital analytics implementation. But there are vendors that we even work with that do do auto tracking or auto tagging if you absolutely can't get development resources. But in general, if you are gonna do auto tagging, I recommend that you do that and then eventually find the things that are really important to your implementation and then make those more prescriptive because you'll end up with better data quality than you will with auto tagging. So those are two of the implementation missteps that I've seen and I'll hand it off to Jeremy. Yeah, and one other point on potential risks of over tagging, which could be a whole additional webinar is the privacy implications as, you know, fortunately the industry is starting to focus more and more on good data hygiene and good privacy practices. It's good to be able to explain why you're collecting pieces of information about your users. And when you're just hoovering up everything possible, it becomes a lot harder to answer those questions when maybe legal comes and wants to know why are you collecting these five pieces of information about every user. Ideally, you know exactly why it's tied to your specific business question and everyone can leave that meeting happy as opposed to having to go do a deep dive for the next three days to unearth everything that you auto tagged. And the last misstep we'll talk about going all the way back to Adam's point about a lack of departmental coordination is just when different departments or teams within your organization aren't aligned on the taxonomy or on definitions of metrics. So this could be when your web team and your native team aren't talking to each other as they write their taxonomies or if you have similar flows across a handful of different products in your portfolio. A big issue is just impacts the ease of understanding of your data if someone has to learn net new what conversion rate means on the web versus on the app. It makes it harder to onboard new folks. It makes it harder to sometimes do valuable analyses about how your web and users are different or how users of different products in your portfolio behave differently in different situations. And so just again, everyone talking to each other everyone making everything as clean and as aligned as possible make everyone's job easier. Yeah, and one horror story that this reminds me of is I was working with one of the largest retailers in the world really, it was I believe a Fortune 50 company and they had implemented on their website a full digital analytics implementation with all the events and properties that they wanted. And then a couple of years later a different group implemented their mobile app once they created a mobile app. And what was interesting is about 70% of the events and properties they were collecting were the same, but the mobile app team they just went off in their own world and they never even spoke to the web team for some reason. So they tracked basically 70 to 80% of the same data but they put them in different kind of variable slots or variable names, which meant that it couldn't kind of be rolled up and you couldn't see aggregated data. And I got brought in as a consultant and I literally had to make a spreadsheet that said, okay, in this project, it's called this in this project, it's called this and they oftentimes had similar but not exactly the same name. So I had to kind of verify is this really the same thing? And then the mobile app team and the web team had to decide which team was gonna basically lose all their historical data and basically have to kind of readjust so that they were using the same events and properties both web and native app, which was just unbelievable. You'd think like, why would anyone ever do that? But it does happen out there. And I ran into a situation. We had a client who they had a very lengthy registration process. It was, let's say 10 pages or screens long and the conversion rate, the completion rate across web and native were very different in ways that didn't really align with what we had learned from talking to users from the other pieces of the data. Just when higher level executives saw a rolled up conversion rate across those two, the numbers did not make sense. And we dove into it, asked questions and we figured out that one team considered the flow to start on screen one. The other team considered the flow start on screen four because they're like, well, it doesn't really count until we get this piece of information from them. And so at the end, everyone just saw a conversion rate. Everyone just assumed these teams had talked to each other and they must be using the same definition. And of course, the numbers didn't align. They were measuring completely different things. And it took someone coming from the outside and asking extremely detailed questions that they thought were honestly a waste of time because they're like, we know what we're tracking. We know what this definition is to unearth those differences. So a recurring theme for teams to talk to each other. Yeah, and then analytics not being just embedded in your overall processes. The biggest issue I see here is just waiting until the very last minute in your release cycle to implement analytics. In an ideal world from our perspective, as you develop a new feature, as you build a new screen or a new page, add on the analytics for that page, add on whatever interactions, whatever new user properties you learn, as that page is being developed, test those as you are testing out that page. And then ideally when that page is finished being built when everyone's confident in all the data, everything's tested, that all can be merged into your main project and we can treat that feature as fully feature complete, including the data. What we see a lot of the times is they push analytics to the end. They say in the final sprint, we'll go back and we'll track everything that we've built for the past eight months. And I think to be honest, it's more likely to lead in errors because just going through now and tracking every single relevant button, every single relevant interaction all at once is a little more tedious than doing it as you're building that thing as you're most familiar with how that flow is working. It makes it a lot more tedious to test because it's not part of all of the edge cases of that specific flow. You're just only looking at the analytics kind of in a vacuum. And the biggest risk of pushing analytics to the end is it means that when you start bumping up, it gets a deadline, analytics are gonna be the first thing that gets cut because we need to ship. We can't ship if the checkout isn't working. We'll figure out how to measure the checkout later. And that might make your PM happy for that last sprint that you get to release out, but then inevitably the first question you will get from some executive is, how's it doing? And then you can't answer that question. So the easiest way to make sure you aren't in that situation is to make sure that you already have analytics in the app three months, four months before it goes live. Yeah, and this happened to me over and over again when I was at Salesforce, everything you just talked about. And we did agile sprint methodology and we basically kind of changed to make sure that there was a swim lane for analytics because it had to be involved in the beginning of the project, not just at the end.  And at that point, they would say, well, after we release, can we go back and put the analytics tagging? And I would basically say no. I'd be like, listen, if it's not part of the release, like then you don't get it right away. So when someone asks, how is it doing? How is the new redesign doing versus the old? I don't want them coming to me and saying, why is there no data here? I'm gonna refer them to you. And I kind of had to like almost punish people a little bit. It's to the point where some executive would say, why do we not have the data? And I'd point them to the person who cut it out at the end and then that person kind of learned their lesson and then they didn't have, we didn't have as many of those problems, but it is really frustrating. And one extreme case that I had at Salesforce is we had someone who kind of in the mad panic right before the thing released decided to try to put the analytics in and the actual tagging of analytics in one case actually broke the experience. And then they were all, everyone was mad at our team, the analytics team, and we basically were like, hey, they were the ones who decided to not do this the right way, put it in at the last minute and that definitely increases risk when you do that because a little bit of code here and there can break experiences. So definitely agree with all that. Next tip we want to kind of mention is what we call using the wrong tool for the job. Now, there are a lot of different technologies out there as many of you have seen kind of the brinker, 5,000, 10,000, Martek stack slides. And I think there's a lot of people out there, especially product teams who get a little bit confused on what is the right tool for the job when it comes to analytics. So the first mistake we see a lot of companies making is that they're using what we call a traditional marketing analytics product like an Adobe or a Google analytics to try to do product analytics. Product teams have different needs than marketers. Marketers are very focused on acquisition. How did someone get to my app or my website? And they don't go super deep in engagement and retention and tracking features and buttons showing all the types of reports that product analytics vendors really have built up over the last 10 years. Now you can use marketing analytics products, but in many cases it's kind of like trying to do that from product analytics is equivalent of trying to put a square peg in a round hole. And so I have many talks I've given over the years with folks about why you need to use the right kind of analytics product for the right job. One of the things we're doing at Amplitude right now is trying to make it so that our product can do both marketing and product analytics so you don't have this issue. You could use one product for both and that's just a big focus for us. But another problem that I've seen is a lot of organizations and product teams get really enamored with business intelligence tools Looker and Tableau and Power BI. And they basically say, well, what if we just collect all the data we need, shove it in a warehouse and then we just use a BI tool on top of it to see how everything is doing. Now the problem with that approach is that BI tools are really good at kind of high level summary information reports and dashboards, but they don't go super deep.  You're not gonna be able to de-dupe unique visitors very easily. You're not gonna be able to look at flow diagrams, build really cool segments or hold different attributes constant like you would in like a sequel. So there's just a whole bevy of reports that product analytics vendors have kind of perfected over the last 10, 12 years that you're gonna miss out on. And when I see companies that try to get by by just saying, we're gonna have a data warehouse and a BI tool, they oftentimes can get some of the information they need, but what they don't realize is the opportunity cost of all of the deep dives of data that they're missing out on by not having a true product analytics product. So if your organization is either using a marketing analytics tool or a BI tool, you might wanna have some conversations about is this the right tool for what we're trying to do or at least explore to see what are the things that you can do in product analytics that you can't do in marketing analytics or BI. And honestly, those same things you miss out on by using a BI tool instead of a product analytics tool. I've also seen in a few cases for companies trying to use like performance monitoring or crash reporting tools as their analytics tool. I think having good crash reporting is very important. Crash analytics, New Relic, all those sorts of tools, like they're valuable, they don't replace product analytics. That's not what they're designed for and you will very quickly run into gaps. You can get most of the top line vanity metrics you might need. You'll be able to see total visits. You'll be able to see maybe some sort of user level like identity resolution stuff, but as soon as you wanna start answering complicated questions about segments and about flows, it's gonna fall apart. We had one client who their procurement team told them we have one analytics tool. It was a performance monitoring tool. And so we tried to figure out how we can make that tool work for them. We said, hey tool, can you do flow reporting? And they said, not an aggregate. If you look up any individual user, you can find that user's flow. And that's it. There's no way to even add two users together, let alone find any sort of patterns. And again, these tools all have purposes. They work a lot better when you use them for what that initial purpose is. Yeah, and one thing I'll add to that is we also see companies who say, you know what, we're really good at SQL and we could do everything we need with SQL. We actually had a little demo at our company where we basically had our best SQL person try to answer a question that is like, how many people came to this funnel, went to this step, this step, while, you know, when they came to this step, they had to have done this. And I think it took like 15 minutes for someone to write the SQL to do that. And then we showed them in amplitude how they could do that in about 30 seconds. And so sometimes the answer is, yes, you can find a way to do it in SQL, but how many people at your company can do it in SQL and how much time are they gonna spend doing that versus using something that was purpose built for that? Yeah, and then another issue in terms of when well-intentioned product teams sometimes bump up against their procurement organizations is a lot of teams can fall for the mistake of assuming that analytics are free. These tools are free. You'll never have to pay for these. They grew up using free Google Analytics for the past five years. And folks high enough away from the actual data just go, Google Analytics is free. Why would you want us to pay for amplitude? Why would you want us to pay for anything? This is one of the few tools that we have that's free and they don't realize that either, maybe when they were at a much smaller scale that worked for them, but now they're bumping up against limitations in terms of numbers of hits or numbers of users based on the tool or just in terms of overall functionality, you're hitting walls, the type of analysis you can run, the level of complexity of the questions that you can answer. And it might be a large hurdle to get over initially of just the mental idea that this is something that's going to be very valuable for organization. We'll come back to this later, but something that is going to drive profit, it's worth making an investment in that tool so we can actually use the data in the ways that it's meant to be used. Another issue, this is a little bit of a pivot from kind of the analytics tooling itself to ways people are using dashboards. It's important to think of when you're building a dashboard on top of this data, what is that dashboard for? We've written into clients that every possible business question they've thought of, so every question in the list Adam came up for them in, they want the answers to all of those questions in one dashboard that maybe will scroll for a couple minutes to get to the bottom or is 20 paginated pages. And at that point you lose the value of a dashboard that you can open up real quick, get a health check, see how things are going, move on with your day, or look at quickly, notice an anomaly and then go back to your data to dig in further. But just thinking through what are dashboards for? Are they for doing one-off deep dive analyses? Ideally not. And so figuring out what are those things you want to be able to see on a glance on a recurring basis versus what are things that when you need to know you can go into the data and find it. And then finally, sometimes product analytics overall isn't the right tool for your job. I think we can all fall into the trap of this data is so powerful, any question we have we will find an answer in the data. But a lot of quantitative analytics will tell us what users are doing, it's not designed to tell us why. And so you might see you have a lot of drop-off on the third page of your site. You might see a new redesign, negatively impacted conversions, and you aren't sure why. So then figure out what tool do you need to actually get hypotheses as to why folks are dropping off. So maybe it's a session recording tool. Maybe it's pulling in user researchers to actually go talk to the users, do surveys, do interviews, do focus groups and actually say, hey, we've noticed people having trouble with this one page, can you tell us how you're experiencing it? But just don't think when you have a hammer, everything's a nail. No matter how good your data is, sometimes you have to go talk to real people to actually figure out what your users think and need. Yeah, and I think that's really important. Just going back to some of my days as an analyst, one story I could tell you is when I was at Salesforce, we had like, I think it was like a 17% conversion rate of someone looking at a form, which was pretty big on our site and completing it. And one of the things we couldn't figure out is why were they not completing it? And we had all sorts of theories about, oh, well, we're asking for too much personal information and so on. And eventually we basically, if someone went to the form and then navigated away for 10% of them, we would pop up a quick little survey and say, here's the top five reasons we think you may not have filled out this form. And then there was an other. And we asked our executives to tell us their opinion of why they thought people weren't filling out the form. And every single one of our executives was wrong. They all thought it was because we were asking for phone number and asking for email address and people weren't comfortable sharing that. But the number one answer that we got and it actually started as many people filling it out in the other. And then we added it as a viable kind of radio button option was that they didn't know enough about the product yet to fill out the form. Like they weren't educated enough. And so that was a huge learning for us. And we actually added some videos and some information on the form so that they could actually, while they're right there, learn a lot more about our products. But sometimes the data won't tell you that why. And the other thing that I'm excited for you to mention this is one of the things that we're doing at Amplitude right now is we're actually integrating session replay right into our product. So we have partnerships with a couple of session replay vendors so you can go into Amplitude and find out kind of where the problem exists. And then you can actually go watch just the people who have that problem through this partnership. So really excited about that. And I totally agree that sometimes you've got to kind of mix the yin and the yang and the kind of what the data can only tell you so much. You know, you can be the best analyst in the world. You still can't understand that why until you kind of get the qualitative into the quantitative.  So next one we'll talk about is data quality. We alluded to this a little bit earlier and there's not too much to say about this because everyone agrees that they should have really good data quality when it comes to analytics. But some of the mistakes or tips that I'll give you is I see a lot of organizations that when they first do their implementation they spend a lot of time verifying that all the data is correct. Then the minute that they get sign off and that the analytics implementation is done then they kind of forget about checking the data quality. They don't periodically spot check it. And as they add new things to the implementation they're not oftentimes as stringent or strict as they were during the initial implementation. So again, if people use a digital analytics product whether it's a marketing team or a product team if I call it the three strikes rule if they look at the data and it looks bad or maybe data just stops and then kind of starts again later or there's gaps in data if that happens more than once by the third time that happens basically people lose faith in the analytics implementation and the analytics team and they just stop using the data. So this is one of those things it's like they always say about your reputation it takes a lifetime to build but it takes like a second to lose. You need to really focus on data quality and make sure that you have either a people or a process in place to make sure that you're periodically making sure the data is accurate. And one of the things that people use in our product and amplitude is we have kind of a way to do root cause analysis or anomaly detection so we can alert you if there's cases where data looks like it's way beyond kind of the standard deviations. So make sure that you take the time to check those out and see if that's actually something that's really happening or if there might be a tagging issue but I don't know Jeremy any other kind of data quality things from your perspective? Yeah, just one like very specific zoomed in example but hopefully people can extrapolate from it is one thing I've seen is when you do an initial release of a site and it's English only and then later you go back and localize and we inherited a site from another agency and we looked at their analytics and they had let's say the first 10% of their page views had English names and then the next 10% had French names and the next percent had Chinese names and those were the same sets of pages but they were just dynamically pulling in the page title and unless you had a very well-studied analyst who knew a whole lot of languages it was very hard to aggregate performance across all those different languages and that was not an intentional plan they didn't have an intentional plan they just set up their initial tracking they did a lot of testing of it and then at some point just localized everything to Chinese and just assumed it would still keep working and it did that data wasn't inaccurate it just was increasingly hard for them to use in the way they were hoping to so things like that just taking a second to go back and look at your data makes it easier that's happening. They had built reports on the English language names so they just a lot of those reports just didn't include any of that data that wasn't in English so it took them a while to catch it. Yeah, cool. Okay, so kind of last couple here one I like to talk about is what I call the failure to document and kind of take action on what I call aha moments. So if you think about it the whole reason why you're using digital analytics or whether like let's say you wanna make your app better you wanna make your product better you're not just going in there to do reports just in dashboards just to do it you're doing it because you want to learn something you wanna have the data speak to you and tell you like, hey, here's an insight here's something that you learn now product teams they're very familiar with the aha moment the aha moment is when someone's using a product and it just clicks with them like why this product is awesome and I can't live without it but we oftentimes don't take the time to do that in digital analytics but every time you're using a digital analyst product you're always kind of querying, segmenting and a lot of times you don't realize it but you're actually learning a lot but a lot of companies don't document this they don't share it with their colleagues and they don't say, hey, I just learned five cool things and they don't communicate that with others which means that other people have to learn those things or they just get lost. Now, like in amplitude we've tried to make this a little bit easier by having things like notebooks where you could add kind of free form text and you could talk about it and you could embed learnings right there but there's definitely more work that analytics teams need to do and one of the advice that I would give all of you is come up with a way whether that's a spreadsheet or confluence or something where if you learn something really interesting if you have an aha moment, document it and find a way to share that with other folks and if you think about it the most number of aha moments if you come up with 50 aha moments you should be able to go to each one of those and they don't do you any good unless you actually take action on the aha moment. So for example, if you're doing a conversion funnel and you realize that I'll make this up first time visitors convert way less than return visitors and you can see that consistently that's a good learning but it doesn't do you any good if you're not saying, okay well, how are we going to change this so that first time visitors are converting at the same rate as returning visitors what is the difference? What is it that we need to do for first time visitors to get them to convert at the same kind of pace as return visitors? And so documenting aha moments the cool thing you can do is say, listen every month or every quarter I want the whole team to make a list of the key things they've learned and then let's look at each of these and make a goal of saying which ones should we take actions on? Which ones should we do? Because once you take action on it then you can make whether that's an AB test or you're changing a feature or adding content then you can actually measure the result and so you know that old expression you know if a tree falls in a forest but no one's around to hear it doesn't make a sound well, it's the same thing with digital analytics if you learn something new but you don't share it with anyone and you don't take any action on it like did you actually ever learn anything or did that have any impact in your organization? And very few companies I go to any product team and I say, hey, can you show me the list of maybe the last 50 things that your team has learned by using data that you know through your digital analytics product and usually I don't get anything they're like, well, you know, Joe learned this and Joe learned that but it's all in their heads. So find a way to document that and share that. And I think that leads to kind of my next point is that you have to treat digital analytics as a profit center instead of a cost center. Most organizations are treating it as a cost center. It's like, hey, we spend money on the doing analytics on the team we spend it on digital analytics vendors like Amplitude and it's just an expense it's just something we have to do but that's a terrible way to think about it because the whole point is that you're collecting data so that you can learn things, have these aha moments then turn those aha moments into actionable things you're gonna do, test new things, try new things and hopefully those actions then can be quantified. And this is the big learning here is that most product teams aren't quantifying what they're learning by taking actions on their insights but if you quantify that, then you could say, you know what, we spent X number of dollars on our team and Amplitude this year but we saw a return of this much. And if you do that, then you'll never have to worry about justifying your investment in your analytics team or your renewal of an analytics product. And if you need additional tools or you wanna increase the headcount of more analysts you'll always be able to do that because you're showing a return on investment. But treating analytics as a cost center is just a shame because there's so much money in that data you just have to kind of go from aha moment to action to ROI. And that's something that very few product teams are doing but I highly recommend that you do that. So that was our top 10 list. Hopefully there's some of those maybe if not all were helpful for you as you think about 2023. Jeremy, anything else you wanna chime in before we hand it back over to Gretchen? No, I think that was a great ending point. Just hopefully take what you learned today put it into practice and prove your value to all the people you need to. Awesome, I'll give Gretchen back over to you. Thank you so much, Adam and Jeremy. That concludes our presentation. We hope you found today's conversation helpful. As we close, I wanna thank everyone for your interest in learning from these speakers. Have a great rest of the day and we look forward to connecting with you again soon.


Thank you for coming to listen to my talk. I'm sure you came especially for this one. No need to answer. So I'm looking at the unfurnished burials of an early Anglo-Saxon cemetery, Worthy Park. First of all, I'll just do my acknowledgements. I'm a Australian National University who have been kind enough to let me study there. There's School of Archaeology and Anthropology, my former supervisor and now colleague Mark Oxenham, and the places where I examined the teeth of skeletons, Duckworth Museum, Southampton University, Dover Archaeological Group and the Dover Museum. So thanks to all of them and of course thanks to the organisers of this session which brought me all the way here and I'm very excited to be here. This is the Anglo-Saxon cemetery, a map on the Anglo-Saxon cemetery of Worthy Park, Kingsworthy Hampshire. It was excavated in the early 1960s and is dated approximately 450 to 600 common era. It contained or excavated were 105 individuals from 94 graves and amongst those of eight poor men or as I call poor men they have no buried without surviving grave goods and eight poor women. Now I didn't excavate this cemetery nor did I actually examine the paleo pathology of the skeleton that was done by Calvin Wells and most of the pictures you'll come you'll see have come from the published report by Hawks and Granger. My contribution is the analysis of the meaning of these poor graves and what we can see from the health and disposition of these individuals. Oh and okay the blues and ovals are the poor men and the greenish ones are the poor women so they're sort of scattered throughout no real special location for them. Now here are all the poor men or the poor men or six of them that could be, I'll show you the other two later that haven't been aged. So they have been, most of the skeletons from this cemetery have been reaged using the methodology of cave and oxenum to identify the elderly in this cemetery. So the age here is not going to necessarily match that in the published report. So there the men here are the women. As you can see they still lived quite a long time some of them. Now these are the three skeletons out of the 16 that have been excluded and you can see why because basically we don't really know that they were poor individuals so it's just legs or feet or little bits of so they could we cannot be sure they're poor individuals and of course there's not much of their remains to to use for you know to look at their paleo pathology either so they've been knocked out of this analysis. To introduce early Anglo-Saxon burials this is a pre-Christian cemetery. They have a highly gendered burial ritual so in this case women tended to be buried with brooches with beads jewelry items that perhaps represent beauty. Men not all men of course were buried with weapons usually a shield and a spear sometimes they get a sword sometimes even two and things like knives pins buckles pots can be buried with males be males or children as can other items like wrist clasps and strap ends you don't want to talk about them when you're drunk but yeah and so the male grave would sort of tend to highlight a martial warrior type status but we're not looking at those people we're looking at those buried with no goods and as you can see from the graph the tall grabs are the people buried with goods and the smaller ones without and yeah you can see that in general the older stage category is reserved for people buried with goods females and males the average age of death with women with goods was 46 years and those without goods with poor women was 40.1 years so that's I haven't done a statistical test on that to see whether that's significant or not but it is a fair difference now strangely for the men the average age of death of poor men is 46.7 and men with goods is only 41.8 now I suspect that's because if you see the the male graph the 19 to 29 people with goods for males is very high and I wonder if that relates to wars battles fights of the sunday night in the pub or whatever but it perhaps is an activity that the male poorer members were excluded from now the oldest individual in this category is a woman and she was really aged to 65 to 74 years I mean she was old so it's not surprising she shows lots of pathological lesions and you can read through all of those I'm not going to try and pronounce them all here when I'm in the state of nervous and I've got a little bit of coffee left now if you look at now this this particular graph comes from three cemeteries um for so it's Worthy Park plus Great Chesterford and Mill Hill are all similarly dated early Anglo-Saxon cemeteries and so they're combined people without goods so the hyperplasia you can see that people with no goods suffered at almost at twice the rate of those without um quibera orbitalia and osteoarthritis trauma the poor people had more of it but surprisingly for teeth they had fewer abscesses and fewer anti-mortem tooth loss and fewer caries now this is for the poor women um so you just wonder if they have been excluded from a karyogenic view none of those statistics were statistically different but they were different um I'm gonna as we go through this talk I'll introduce you to various poor people so this old fellow he lived he was the oldest poor man or one of the equally oldest lived 55 to 64 years approximately his grave was deep and you can see it's quite spacious as well he's got plenty of room around him um he's got um some fair bits of trauma on him um perhaps the original reports suggested he'd been in a sleazy brawl presumably on a Saturday night um he and being old it's not surprising he was much afflicted with arthritis um and all sorts of things and he had very well-developed musculature which sort of suggests hard work um now for the men um the total number of lesions and all sorts of things this is just the worthy park men I think I've got arrows here um for the most part the um poor men did worse than the wealthy I don't think I can call them wealthy men the men with goods um so leh is well 53 point I don't know whether I've stuffed up that um but 50 that's a big difference there but I think it may be part oh so I'm getting through yes well anyway largely more lesions um some things different okay oh more arrows and there's only one male individual from this cemetery with quibra or or batalia which is is an interesting fact and this is him he died between 45 to 54 years but the interesting thing about him he was born without his um right right arm or sorry sorry the right left one of those one arm and um shoulder completely missing um he's got injuries to infractured face etc sword injuries um and has been you know quite ill at times but he and his skeleton shows changes that suggest he's come to to get used to having only one arm and now the grave size of um these individuals um on the whole people with our foods were buried in smaller graves now if you can just look at that picture which is not um worthy part but you can see the comparison of one of the smaller graves to one of the larger graves and it makes a big difference that lady was pretty well squashed in there um again for the men the grave size um in in all the dimensions depth with height um volume um the poor men have smaller graves than the rich men again I use that term and another thing I looked at was what I call awkward burrows so but burrows that are a bit careless you know the feet might be squashed in at the end not exactly lying comfortably maybe thrown in any other way um so five out of the 12 of the poor women in the three cemeteries obviously have awkward burials and that's 41% whereas only 15% of the women in grave in graves with goods now number 43 there is also buried prone um and she may possibly she may have a vision hands tied I can't say that for sure but her ankles are certainly together and her arms are sort of in front of her like that so it's possible they were tied um and I think I've said all that but basically um this is a statistically significant result that um old women were buried women without goods were buried awkwardly um another we're just we're running out of time so that's another poor old man um and another poor old woman the other running out of time um so in general I forgot to do the analysis for the men in the awkward grave so I can't talk about that but in general we found that the men had a very hard working life they were subject to lots of violence and a little effort was expended on their graves and of course these graves are mostly undatable because Anglo-Saxon graves are largely dated through grave boots you know were they slaves were they native British I mean these are sort of people who more notice needs to be taken of in the archaeological record um now the poor women also are buried with less care and effort and more likely they have fulfilled pathological lesions but their teeth were better than their letters and they did they have you know what's figured were they given more trauma but not as much as their men folk suffered and when I was thinking about this in the shower the other day this is the picture that came to my mind you see here a man he earns the place he's ready he he doesn't care what anyone else thinks he's there ready um if anyone came and um disagreed with him he'd tell them what's what now the women sitting next to him they're accommodating him they say yeah don't worry about me that's all right I'll squash over here and that even today is the sort of thing there's especially people like older I'm not old at all okay I'm still young young people like me have grown up with and it's sort of automatically assume you know people like don't push buttons and I'm just wondering if that was the case in early Anglo-Saxon England the women had tough lives but they weren't they didn't have the trauma they've treated badly thrown into graves prone awkwardly so they were punished um so that's my thoughts on that and there are my references and I think my timing is not too bad


Hey, this is Brett and this 2015 Ford F350 Crew Cab Long Box Dually Lariat FX4 is stock number 12709Z. We are here at Summit Automotive in Fond du Lac, Wisconsin, you're new and used heavy duty truck headquarters this 2015 Ford F350 Crew Cab Long Box Lariat has the 6.7 liter power stroke diesel engine this truck has been fully safety and inspected by our service shop per the state of Wisconsin inspection process it has a fresh oil and filter change all the fluids have been checked and topped off per the state of Wisconsin inspection process and this truck is 100% ready to go it is super clean all the way around and we are going to go all the way around in this video inside underneath started up and take a look under the hood as well white platinum tricote metallic is the color and we shoot all of our videos in 1080p 60 frames per second so if you have HD capabilities on your computer or tablet smartphone or television I highly recommend turning them on right now because it is your best way to check out the quality condition options and cleanliness of the truck before seen in person and if you like the video and how we do things here at Summit Automotive consider clicking the link in the upper right hand part of screen which goes to our YouTube channel is a subscribe button then click the bell notifications and you'll get updates every time we do videos of our new news inventory here at Summit Auto this one comes with the 17 inch polished aluminum rims and it has BF Goodrich rugged trail TA tires these are LT 245 75 R 17s and they have probably about I'd say 60 to 70% of the tread left probably more like 60 percent frame and underbody for being a 2015 is an exceptionally nice clean condition you can see it does have the rancher shocks part of that FX for off-road suspension package driver side front fenders and excellent condition the front bumper and lower valence are in excellent condition as well it does come with the factory fog lights and the chrome trimmed grill the hood is in excellent shape I do apologize for the noise we are currently building a new showroom right outside this facility so there's just a little bit of construction noise going on it does have the clearance lights or cab lights up top passenger side front fender is in excellent condition as well and the passenger side rim no major scuffs or scrapes on there now as you go down this side of the 2015 Ford F 350 take note of how clean the body is how reflective and mirror like that paint is we take these HD videos so if you are far away or even if you're close by and just cannot make the trip down but you're still interested in purchasing the truck you can still see the truck hear the truck and have confidence in the vehicle that you're looking at before you even get here so when you do get here there's absolutely no surprises and you can make a smart and informed buying decision from wherever you're at and if this video helps you make that decision let your salesman know that you saw the video that it was helpful and that Brett sent you very nice down that side this back room is in excellent shape as well and the back tires have just about as much tread as the front tires frame and underbody is exceptionally clean does have the camper package and whenever you're looking at underbodies of trucks you always want to look at these box rails because that's the first thing that'll rust out on this particular type of truck and these are absolutely perfect and very very clean underneath and it's like that all the way underneath has all the remaining factory exhaust and the body of the truck is in excellent condition little rockers cab corners are in excellent shape and this bottom color is called caribou so it's white platinum over caribou metallic comes with the factory chrome step bars duly tubs all look really good get the FX4 off-road package and the chrome tipped exhaust coming around to the back of the vehicle the rear bumper is in great shape didn't see any denser dings and it does have the backup parking sensors full towing package which includes a receiver hitch four pin and seven pin wiring the tailgate is in very nice condition as well it does have the tailgate step assist fifth wheel and gooseneck prep package and it does have a gooseneck hitch back here and you get seven pin wiring back here as well note that it does have the nice spray and bed liner and two tie-downs there there's your tailgate step assist and the tailgate shuts nice and solidly as you go down the driver's side just as clean as that passenger side very nice and clean on that duly tub the box is in excellent shape I didn't see any denser dings and for full disclosure this back rim is in excellent condition as well driver's side doors look really good does have the door code entry we do have the code for this truck and if you ever wanted to figure out what your code is on your 11 to 16 super duty in the upper right hand part of screen is a video I show you how to find that heated mirrors built-in directional signals these power scope out power fold in and I'll show you how that works in a second inside the lariat package gives you the tan leather interior there are no rips there are no tears on the seats they're in very nice condition does have weather tech floor mats auto headlamps tilt telescopic steering wheel power pedals power windows power locks and power mirrors and it does come with the Sony sound system and show you that these mirrors do power fold in and both sides are working nicely I always like showing so that you know that everything's working nice the telescope feature works when you have the ignition on so that's the next thing we'll do here check up miles radio and everything that this truck has to offer on the interior so you can see that this one has 27,963 miles you get the nice digital display there and some because cluster is very nice and clean show you that those mirrors are power scoping in and out nicely does have the leather wrapped steering wheel bluetooth and audio controls on the right cruise controls and information center controls on the left does come with the six speed automatic transmission with the optional tap shift this one has the my Ford touch radio comes with the factory navigation system CD player AM FM and Sirius satellite radio capabilities and then you have your climate controls here which include your heated and cooled seat buttons and your dual climate controls this is also where your backup camera shows up and you can see that that is working nicely down here you have your traction control system turned off four-wheel drive factory exhaust break dual climate controls and your factory brake controller this one also comes with a hundred ten volt 150 watt plug-in has the sync system to connect to your Bluetooth cell phone and the passenger side floor mat and seat are an excellent condition as well the headliner is very clean and it does come with the power sunroof so this is actually a Lariat ultimate package because it has nav and sunroof the power sliding rear window buttons and your sunroof controls as well as your map lights up there we'll take a quick look at the back seats and then we'll start it up and take a look under the hood back seats are just as clean as the front seats no rips or tears back here it does have the power sliding rear window with the built-in rear defrost it does have a lockable storage container underneath the back seat which locks with the ignition key and then you get floor mats back here carpeting is really nice and clean it does come with a hundred ten volt hundred fifty watt plug-in back to the interior here I don't think this truck's ever been smoked in smells very clean as well and behind these back seats is your factory subwoofer and your latch tether anchors side curtain airbags on this truck and these back seats are heated on the outboard side do you get the child safety locks on the back doors and the bottoms of the doors all look very very clean on this truck probably a southern truck would be my guess there's your tire and loading information and then your vins sticker all right we'll start it up and take a look under the hood starts right up no check engine lights or anything like that and I would personally like to thank you for checking out the video today and hopefully from this HD video you will have been able to verify the quality and condition and cleanliness of this truck all the way around inside and out and underneath and I can truly say that this is one of the cleanest truck side video in a couple days under the hood we have the 6.7 liter power stroke diesel engine engine base very clean runs very smooth once again this truck has been fully safety and inspected by our service shop for the state of Wisconsin inspection process has a fresh oil and filter change all the fluids have been checked and topped off this truck is 100% ready to go there is your emissions sticker and I would highly recommend this 2015 Ford F350 crew cab long box Lariat ultimate FX4 in white platinum over a caraboo from a quality and condition standpoint super nice truck you won't be disappointed in this one and to see more pictures of this truck or one of our other 450 new and used cars trucks SUVs minivans Wranglers you name it we got to go to that website right there www.summitauto.com full pictures and descriptions of every single vehicle from two locations all at summit auto.com and if you'd like to check out more HD videos you can go to youtube.com slash summit auto remember to like subscribe and share on this video and all the videos that you see there click the bell notifications and you'll get updates on the videos we do each and every day here at summit auto fact in a second you will see link to subscribe to our YouTube channel in the upper left to link to more F350 videos like this one the upper right link to this vehicle on our website in the lower left and a link to one of our latest YouTube videos in the lower right click those check us out and we're super excited to help you with this ultra clean like new 2015 Ford F350 crew cab long box Lariat ultimate FX4 in white platinum track code over a caraboo brown and metallic thanks again for checking out the video remember to like subscribe and share


Did you see how everyone suddenly stepped away from the table then? Good morning, welcome to film my run. So today we're not running, we're just volunteering. We're at Dornay or Bovney or Bovney? Bovney, we're at Bovney aid station. I've got the job of streaming the grass before we put the aid station up. So this is what goes into setting up your aid station before you actually arrive to get your food. But a massive thank you from us at Centurion for giving us your time because we cap it on as a thanks for your help. So I'm now in my Centurion volunteers' top. The aid station is pretty much set up. We're just going to make sandwiches and put, you know, some food out on the tables. But the gazebo is up, the chairs are out, the tailwind is filled and it is 20 to 12. I don't think we're going to see a runner until about one o'clock. All right, Chris, how's it going? Do you want an aid station or not? Yeah, it's just a drink. OK, all right. Yeah, you've got about one hill outside of Reading. That's all you're that's all you're going to get, I'm afraid. Have you got crew anywhere? Yeah, Emily, yeah. OK. You've got some muscles? Muscles. All right, OK, no worries. That's, uh, no, this is my mate Craig. He's done me before on the arc, so he's all good. But I mean, crew's not exactly a big feature of this race. No, you'll be done in 15 hours. Oh, good for you. Right, so that's the first two runners in and it's 1.30 in the afternoon here. Zoe Murphy is next in. And then call out what she's like, good out there. Good day, like temperatures, good everything. Let's hope it doesn't get any hotter than this. This is perfect. Yeah, this is really good. Anything else? No, good. That's Zoe in the lead. Four hours and four minutes for 30 miles. Feeling OK? Good. Oh, you're going home then. Don't be tempted to stop, will you? Well, I was joking. That's probably where I get lost in my disorientated in your hometown. So it's quarter past two. We've had quite a few runners in. I'd say we've had about 30 or 40 runners. No, maybe not 30 or 40. 20 or 30. About 20 runners through a gaggle of runners, a centurion of runners. We've put the other gazebo up because it has got very warm now. I fear for some of the runners in this heat. If you ever consider doing a centurion race, this is the kind of food you'll get these days. Look, we've even got cheese and marmite sandwiches, although Zoe has put marmite and cheese like some kind of Neanderthal. Like some kind of Neanderthal. How are you feeling, Ken? Not too bad, getting a bit tired. Can you remember what number 100 this is for you? How many hundreds have you done now? Centurion. Well, any any any hundreds? Any hundreds, I've done 88. 88 hundreds. So you're going to go for the 100 hundreds? I don't know. So this guy here is Ken Fancer, he's a centurion legend. How's it going? James, just tell me how many 100 miles you've done all together now. 35 so far. 35 so far, brilliant. Well done. Good job. Don't be scared. Don't be scared. How many behind him are you? 34. Well done, buddy. He's just eating. Typical. Enjoy yourself. Have a great day. Bye, Kerry. Right, I'm now eating the cheese and marmite sandwiches that I made. I just made that. Oh, did you just... Sorry, Zoe made the last lot. They taste, they taste. So we've got about 20 runners still to come in. We're winding down now. It's just before quarter past four in the afternoon. We've got quite a lot of help. Some of the helpers came from race for the aid station, which is the aid station before this. This is Paul Spooner. Paul Spooner drives the bus of despair. Nobody wants to sit on the bus of despair with Paul. If you DNF from this race, Paul will drive you back to the finish line. We're now all picking at the food.  And it has been known, it has been known that the odd volunteer may have a sandwich or a cookie, or two. Did you see how everyone suddenly stepped away from the table then? How are you feeling, Daniel? Better than I was. Yeah. I was ready to DNF at 11. Is the heat getting to you, Emma, or are you feeling... Oh, wait, the heat always gets to me. Yeah. I'll tell you the best place to drop, Oxford. That's the best place to drop. Keep moving, yeah, keep moving. Well done. So Emma is the final person at the aid station, it's the final runner coming through on the Thames Path 100. So we can pack up now, just about, I think. Well done, everybody. Good job. You can carry them bin bags or this stuff here. It's like we were never here.  Meh. Meh. Great help, really, really helpful. Alice was super on it when the runners were coming in. He was, actually. They saved minutes outside on top of it, making sure everything was topped up.  And then at the end, it all gets loaded back into the van to take back to Centurion HQ up in St Albans. And this happens for every aid station. There are 12 aid stations on the Centurion Thames Path 100.  You certainly didn't realise. So it's worth bearing in mind when you're running along the Thames Path what goes on behind the scenes. So we've had a lovely day here at Dorney. We'll be back. I'm sure we'll be back and do another volunteering session again sometimes. We don't do this enough. We really should get back and do more volunteering because it's a good thing to do. So from us here at Dorney, thank you very much. Bye-bye.


This study compared the incidence of gestational diabetes, pregnancy-related hypertension, pregnancy hemorrhage, preterm birth, and small for gestational age between pregnant women who received Tdap vaccination as part of the maternal immunization program in Brazil and unvaccinated women. The results showed no increased risk of pregnancy-related or neonatal adverse events following maternal vaccination with Tdap. However, these findings should be interpreted cautiously due to limitations inherent to retrospective observational studies.


Nina Simone, legendary musician, social justice champion and global inspiration. But the high priestess of soul had humble beginnings and the place where it all began is threatened. Hi, I'm Brent Leggs with the National Trust for Historic Preservation. We work to save historic places and right now we are working to save Nina Simone's childhood home in Trion, North Carolina. This three-room house might not seem like much, but it's here that Nina fell in love with music and learned to play the piano. It's here that she first experienced racial discrimination that would shape her life and commitment to racial equality, and it's here that she began to find her voice in art and in activism. Here in this modest home is where it all started. Today, with your help, we can make sure that her unique voice continues to inspire and motivate people through her childhood home. The house is currently vacant and disrepair and lacking any interpretation or preservation protection. Work is underway to restore and protect it, but we need your help to cross the finish line. When you donate to the National Trust campaign, you'll help fund critical restoration work in Nina Simone's childhood home. And depending on your donation, you can get exclusive Nina Simone inspired perks, including t-shirts, enamel pens, prints, and postcards that will let you show the world your love for her music and for her message. Help save the place where Nina Simone began and become a part of her remarkable legacy.