 So, we used to have separate detail pages for each and every single product variant, but since there's a lot of content overlap, certainly SEO-wise, if your product descriptions are all the same. So we decided to merge them into just master pages that load the product variants via JavaScript. And we also have a product finder, which is basically a solution that they wanted to sort of install booths or on tablets, on consumer stores. So customers can just fill in some questions, and they are suggested with the products that they need to buy. This is fully configurable by Sudo, and it's just a way to show that we can make the data available to a React app. We also have the internal website search. So we noticed in Google Analytics that a lot of visitors were using the internal site search actively. So we tried to optimize it as good as possible. So we used Solar and Search API for that, and we're using, of course, Google Analytics to really look at the data and see how people are using it. So we're really trying to improve that internal website search, and it's proven to be very useful. We also have a very neat functionality here, country detection. It's not a pop-up, per se, but it is a model that is showing up on top of the screen. So this is something that shows up when, for example, you have multiple countries that have the same language. And when somebody searches in Google, they might land on the wrong country. So for example, if somebody from the Netherlands who speaks Dutch type something in Google, he might land on the Belgian website, because that is Dutch as well. Sometimes Google just gets it wrong. So whenever the IP address of the visitor doesn't match the market that is currently shown, a model like this is shown. So this is saying, okay, we see you are located in Belgium. Would you like to switch to the Belgian market and see the same content? So this is something that's very useful. There's no auto redirect. Just to clarify, auto redirects are a no-go for SEO reasons, because Googlebot, the spider, is mainly browsing from the US. So if you always auto redirect based on IP, then you'll do bad stuff in terms of SEO. So never do an auto redirect, just give people an option to switch. That module, you can see we have Belgium selected by default. That is based on the country you're located in, of course. And you can change that selection, you can accept the selection, or you can remove that model and just continue browsing. We're also keeping a close eye on the analytics for this. Oh, and also important is that there's a very complex redirect logic in place for this, because every product, the 12,000 products, they all have their own nodes. And we really have to match them. If you switch to another market, it's another node. So there's a really complex logic in place to make sure when people make the switch to another market, if they accept what is suggested here, that they land on the same page, but on the different market, on the market of their choice. So we're not redirecting to the home page, because that would be a very, very terrible user experience. We're based on a redirect logic, redirecting them to the correct page on their chosen market. This is how we're following up on that. So this is another Google Data Studio dashboard, which is connected to Google Analytics. And using this dashboard, we can really see which markets are showing the model a lot of times. If people are accepting it, if people are changing the pre-select, so really to analyze the usage of this functionality. And then we have the exception, Soudal China. So in order for you to serve, or for us to serve in a .CN domain, the server needs to be hosted in China, but we have the platform centralized. We had some challenges, which was the time zone difference. We had the three hours window, and we've discussed a lot. Most of the times, it's pushed to the next day. Also, the language barrier, because we translate sometimes a lot of stuff, and emails get bigger because of going back and forth. We had to strip all the Google, Facebook, and US base tools because we would be penalized for sure. For example, the website not being served for 10 minutes, being too slow or just blocked. And then the most complex one are the legal requirements. They have one thing called the Internet Content Provider, and it's kind of an authorization that we have to request to the government, and it ties the domain with the IP. If you change one of those, it needs to be authorized by them, and they, before, will look to the website and check if it can be proved and served in China. And this can vary a lot in China because it depends on the type of the company, but it also depends on the region, and it's really hard to understand. So as a solution, we had to trust on a Chinese partner that is responsible for the infrastructure and for the hosting, and sometimes to help us on this legal process. And in terms of the platform setup, what we did, we set up a read-only instance on a Chinese server where we up sync the data every day with one day of delay. So basically, the Chinese people are managing the content in the main platform, and then we up sync the data, and it's served on China. Also another good or fun result of what we did is that we really have a happy customer. So what we see here is an email from Herbin, which is the product owner on the side of Sudol. And whenever we release a new market, he sends us an email congratulating us with the release of the new market. So this really proves that we are working together, Dropsolid and Sudol, to make the Sudol platform a really successful project, and it shows that we're not just working for the customer, no, we're working together with Sudol to create the fantastic experience that it currently is their platform. So it's really, really fun to receive emails like that, and it's because of all the hard work we put in, Sudol and Dropsolid, to really make sure that we connect, we communicate, and we have a good result. Let's also talk a bit about website performance. So a project or a platform doesn't end, of course, when it is launched. So there's a lot of maintaining, optimizing, and improving going on. Modules might become outdated. There's releases of new versions of Drupal, SEO-wise as well. So we've talked a bit about SEO already. There's something called the core web vitals. I don't know if it rings a bell for some people, but the core web vitals are technical factors which are important for SEO. And back when we launched this platform, those web vitals didn't exist yet. So we have to really follow up on everything and maintain and improve the platform as we go along. So how are we doing that? Well, we're using multiple tools for this. First, we're using Google PageSpeed Insights, of which you can see a screenshot right here. So this is really to get a general feel about the performance score. Get some tips from Google as well. This is the desktop score for, I think, the Belgian website, but each page has a different score. Notice that this score, it might not be the Holy Grail, but of course when potential customers look at your websites, the sites you developed as a company, as an agency, they usually use tools like this to decide if your website is a good website or not because they're not the experts. Maybe you as a developer know that this score isn't everything, but your potential elites might really use this score to decide if you're the party to go with or not. So really try to improve the score. I don't only try to improve the score, but improve the website. And if you improve the website, then the score will follow. So you shouldn't try to gain the system. You should really try to improve it performance-wise and the score will follow. Another tool we're using is Google Search Console. So if you're not using this yet, I highly suggest that you do because it is a really useful tool to follow up on SEO and it's free to use. We also use GT metrics and a web page test, which is mainly to follow up on the page speed and see if any modules or plugins are hampering the website performance, especially the web page test one. This is a really, really useful tool. It's free to use, so I highly suggest that you dump your websites in there and see what comes out of it and really have a look at it. We also set up Google Analytics custom notifications. So whenever Google notices, for example, that the bounce rate went up 20% day over day, then we get an email notification for that and we can check out if something is wrong with the website or not. So yeah, all of these tools are really useful to use and to monitor your website performance and to really improve it as you go along. I could talk about this stuff for hours, but let's just keep it going. Sometimes all you need is a spreadsheet. So there's a lot of tools, but we also use regular spreadsheets. This is a Google Sheet and we are just monitoring some core data, in this case. There's data from GT metrics right here and data from Lighthouse as well. And here you can see on the left hand side, we have the same page and we just monitor it as we go along and we check out the scores to see if we're improving or not. So in a column that is cut off on the right side, we really mentioned which updates were pushed in that time period, so we can really closely monitor which updates had the biggest impact on certain metrics. For example, the first contentful paint or the largest contentful paint. This is maybe a bit too technical for most of you, but these are all core web titles, these things you see here, and it's really useful to get them all in the green at the bottom there. And the result of all that is that we have a graph that goes up and to the right, and that is what you want at the end of the day. So what you see here is a graph of the organic traffic, so not the total traffic, but the total organic traffic, so traffic coming from Google search, from Bainsearch, from Yahoo, from any organic search index. And what you can see on the left hand side is that we have a very steady amount of organic traffic. This is their old platform, as you can see in the date here, it's 2018, and as soon as we launched in 2019, the traffic started going up, which is of course what you want, so currently you're at about four times the organic traffic than they used to have, and it's still going up, so it's a very good thing. There's some key learnings and takeaways. So first of all, communication really is key, and so is expectation alignment, so really try to communicate often, communicate open, and make sure that the customer understands everything. Don't try to use difficult words, really try to explain to them in layman terms, so they know how the project is going, what you are doing, what is expected of them, and so on and so on, so really open communication, not only in business, but also in your personal life, it's really important to have good communication. If you feel that something is wrong, you need to change, because probably it's wrong. I can give you one example that happened with us so previously. We had separate tracks for development, for the service delivery manager to follow the budget, and for performance, and we felt that sometimes we worked back and forth with some shared knowledge that was kind of separated, and we promoted with Sudo, that we should have those meetings together, just to have better expectation management and communication. You should also always try to give options to your customer, so let's say you have a quick and dirty solution for something that they want, but you also have a solution that is a lot more work, but is the cleaner solution development-wise, and you should try to present both solutions to the customer and let them make an informed decision. So don't make assumptions, don't think, well, they won't go for the expensive option, they will definitely go for the quick and dirty one, just they hired you to be the expert, so user expertise to clearly explain the differences between both options, give the benefits, give the pros and cons, and then let them make an informed decision about which path they want to take. And as a team, we always incentivize everyone to pick up the tasks or pick up the tickets and contact the customer. We feel that this is really important. Of course, the people who is going to pick up the task needs to be comfortable and has the expectation it can deliver, but also, for example, if detects on or we demand like on early stages, if they detect that it's not possible, they just need to raise the flag and ask for help, the team will be there helping. And also, we don't want to create bottlenecks, everyone is free to contact the customer, as long it keeps the project, yeah, the product owner and the service delivery manager on the loop. So as Philippe just said, yeah, if you suspect you will fail, raise that flag as soon as possible. So let's say you're a developer, you've been working on a task that's budgeted to two days, for example, and after a half a day, you notice that it's going to take double, it's going to take four days. Don't try to shove that information under the rug, don't try to rush it and think, yeah, I will probably make it if I push it, if I put it in an effort, and then at the end, it seems you didn't make it after all, and you have to say to the customer, when you already spent two days, well, we're going to need two more days, he won't like that. So really try from the moment you notice that you might fail or you might just need more time, just communicate that to the customer and work towards a solution, how you can fix it. Just don't try to hide any information because that will cause distrust and you definitely don't want that. Also try to have a mix of different types of work in each and every sprint. So try to have a mix between maintenance work, back-end work, front-end work, visual changes, because we made the mistake in the past that at a certain period in time we were working a lot on maintenance tickets, we were doing a lot of back-end work and improvements, but really if you went to the website now and two months ago, you didn't see any visual change. Although a lot of things did change and did improve, when some stakeholders from Sudal went to the website, they didn't see any change. So they rang a bell and they said, what are you doing? And even though the main stakeholder, like the product owner, Herben, he knew what we were doing, some other people at the company, which is a big company, Sudal, they might not know that we were doing a lot of back-end improvements or performance improvements. So even though it seems like a small thing, like even some colors that change or some elements that change position on the front-end, just try to have a mix of all those different types of work so everybody can see that work is being done on the project. When local markets, well, local markets, especially the newcomers, will challenge, we have the experience that they will challenge the platform and they will require new features or improvements and we gladly accept that because they are experts or on their own country and sometimes they have really good ideas and we try to fetch them and to make it available for the whole platform. Also keep in mind that the result of small improvements, they will compound over time. So especially when we're talking website performance-wise and page-speed-wise, if you do a small update like enabling GZIP or something, it won't have a very big impact on your page-speed but if you continually invest in doing small improvements, then the result will show in the end. So this is called a theory of marginal gains and in the cycling world, to make it full circle, in the cycling world, it's heavily used as well. So really trying to optimize small things, get small improvements, small gains in the long run, they will really show that the website improved a lot. So even if you push a small improvement and you don't notice any big difference, keep in mind that if you continually invest in small improvements, then it will pay off. And in the end, you see a real big difference if you go to the website now versus one year or two years ago, it's performance-wise. It's way better even though those small little improvements you might not notice them, but they do pay off. And for me, the most important one is never deploy on Fridays. We tried to deploy especially on Wednesday and we were able to do it for four years. And even on Mondays, we try not to do it because we like to be prepared. We only had one exception, which was subtle China. The ICP feeling was delayed a lot of times and the people on China put a lot of effort and the expectations were high. So we kind of opened an exception because the model was aware of the risks and we felt we should do it to make them happy and we did. It was the only exception, really. Every time we deploy a big feature, it's usually on Wednesdays. So what is next? So for Sudol, we will continue to release new markets. We have a couple of them or more than a couple to join the platform. We have a big feature to release. I'm sorry not to say here, but they need to announce internally first, but it will have. We will continue to do the continuous improvements that we are doing now with content and performance and we have to soon update to PHP 8 and update to Drupal 10. What's next for Drupal? So we're very, very excited to announce some very, very high level Drupal top notch stuff here today and for that I would like to guide you to the trees notes tomorrow at the auditorium. Yeah, that's all be there. And if you want to see a different perspective, there will be a session tomorrow about the multi-markets vision in Drupal. That's mostly it. I would like to thank you all for listening. If you want to get in touch with us or with Dropsolid, you can come visit us on the floor. We have a booth. Our contact information is on this slide, so you can just take a picture of this or you can just go to bit.ly slash Sudol story and then you can download this entire presentation. So thanks for listening. Do we have any questions, any burning things if somebody wants to know, wants to find out? There is some question here. I will give you the mic. Thanks, very simple one. Since you have multiple domains, multiple languages, multiple everything, I'm curious, did you engage Drupal multisite or you approach it somehow differently? It's a hard question. So basically we try to adopt some country modules, but we had to do some custom coding to glue everything because mainly Drupal, it only has content negotiation. So you don't have more, sorry, language negotiation. You don't have more, so you have to have some kind of tricks to make sure that Drupal understands which market are you serving and which language are available on that market. It's really hard to explain because it's very technical. I'm really glad if you want to join me, I can explain. But I have a question for you. If we can make a session about this, would you attend? Because we can make a session about this. Probably we'll take the same amount of time, but we can do a session and explain our vision about this. It's my everyday concern, yeah. But are you okay with the answer? Yeah, yeah, okay. Thank you. Any more questions in the audience? Yes, over here. Okay, thank you. If you had to start everything from scratch again, what would you do differently? Are you speaking in terms of development or? We will do it, and I will explain why. So when we started back in 2017, it was two years after Drupal was released, everything wasn't stable or we're not mature enough. So we are still digging some stuff from the past and we are still fixing some issues. So I believe if we would do it today, I think we will have the same result and we will work the same way, but we wouldn't do the same mistakes. I can give you one example in terms of solution. So when we started, media was not a big thing. So we used File Entity. I'm not glad to say that because we have a lot of problems still and we now are doing the media migration, migrating File Entity to the media. Of course, if we do it now, we will do on media, but at that time we had no solution. So I think in terms of that decisions, Drupal was not mature enough at that time, so we had to adapt. But now knowing what we would result, I think we would try to achieve the same thing to have the same result. Yeah, another thing I think we would change because it's one of the key learnings we learned in this project is that we now combine our bi-weekly meetings and we combine performance and budget and development tickets. And as Philippe said earlier, those tracks were previously separated. So the person involved with optimizing performance or analyzing SEO was not following or was not in the same meetings when it went about budget or when they were talking about actual development stuff. So we noticed that we needed more communication and more openness internally as a project team. So we merged those meetings into one and that is really a key learning and that is something that we would really do from the start for every new project. Okay, I hope that answers your question. Any more questions? I think I saw somebody at the back earlier. Yes, I will give you the mic. Thanks. Just first I want to say that I would be also interested in that session if you would discuss more the markets and the languages and everything. So that'd be great. I can try to do for example the next Drupal Developer Days. That'd be great. Everyone that wants to be more, you are welcome to join and I'm happy to discuss it. Okay, thank you. My question would be more about the client. It seems that you really had a reasonable client. How much did you have to educate them yourself or did it just happen that they had a person with a lot of experience or how did that go? Because I've seen same issues with small companies, to large enterprises, completely unreasonable expectations, want everything tomorrow and that kind of things. Yeah? Yeah, hi Paulina from FFW. So I would be interested because you mentioned you're also working Agile which would imply an autonomous and self-organizing team. So what experience do you have with that? And also somebody asked in the app, did you consult Scrum Master? So how is this all set up working for you? Yeah, it's kind of related, so maybe you can cover both. Yeah, I can explain. So basically we work Agile and we have a Scrum Master. So we kind of do the planning and of course based on the amount of work we have, we just plan it. So the customer, we just define with the customer what are the next things you want to work. And that gives us more or less an amount of work. Then we try to, with the Scrum Master, we try to plan it on the sprint and we work on the sprint with all the resources available to make sure the tasks are completed. And then the customer, for those tickets that are assigned to the project, he can be involved. We just ask him for example, once it's Q8, we ask him, can you just do the UAT and accept it? We will be deploying on this day. So it's the same way of working as Agile. The only difference is like the customer is a little bit more detached because we work with multiple projects and it will not be possible to have all the customers on the sprint and doing retros and doing stand-ups. So basically that's why we have a PO, internal PO for each project and that PO is responsible for communicating with the customer. Maybe to come back to the original question as well. So we really have a very good project owner at the Sudall site as well, which makes a very big difference. And I think in here, if you notice that the project owner on their side, their side, your customer side, is not that good or you're having issues with communication or with expectations, as you said. I really, I would like to go back to the first key learning we talked about which is communication is key. And if you notice that it isn't working, you should be able to flag that and say, hey, this is not working. We're running in some communication issues. There's some expectations that are not being aligned. So early on in the process, you should try to clear that up. So you're not working on the project for three months and then you have to change your whole way of working. So as soon as you notice that something is not working, openly communicate that and try to fix it. And yeah, maybe not every customer will be able to fix it, but maybe a switch of PO on their side is possible and really a good PO on their side is real, you really need that because that makes a very, very big difference. So if something doesn't feel right, just flag it as early as possible and try to fix it. I just want to add that we all learn a lot from the beginning. It's a relationship. I think it's more than four years, but active development, we all learn, the customer learn, we learn, but we are very lucky because the customer, well, in this case, Gerben, is the single point of contact. So everything that needs to be handled for Sudol, it passes by him. So it really helps a lot. So we don't have to speak. Of course we speak with multiple people, but then to decide if we need something from Sudol side, we know that we can rely on him to make sure everything goes as expected. Yeah, you really need a decision maker on their side because we also had customers in which they started arguing amongst themselves. And then you're just in there for no good reason and you think, well, why don't you clear this up internally and then we'll talk and give our input. But you really want a single point of contact, somebody that will make the hard decisions and yeah, communication really is key in that. Does that suffice as an answer? Okay. We have one more question. I think it's going to be the last one because we're out of time. First of all, there is a live questions and answers on the application. I thought they will be read first, but nevermind. It's more like a technical question there, but my question is, you guys mentioned that there might be some developers who is starting to do a kind of a ticket. You know, okay, after two days, I know that I have to take two more days to finish it. Do you have any processes like estimations like, I don't know, presales for a feature or like a team lead person who is an Ohio level and who knows what the customer wants and doing the slicing of the tickets and the less the lower level developers will eventually take these tickets, well described and then do it. I think it's a kind of a nice solution to have in a kind of a huge project like this because it's really huge and it's like a monstrous one. So you need to somehow stable it and maintain it. So that's why I think there's not something wise to allow anybody to start doing something medium to complex without any estimations or research or something like that, if it makes sense. I can explain you. So basically we have the meetings with the customer and I'm more of the technical contact with the customer. We try to understand what they want. So we do an estimation and we estimate and we estimate the effort and sometimes it's harder but we have to do it. And then we do refinement and then we can rely on the team and normally to the refinement we rely on the most expert people and we just refine the ticket and say what needs to be done. Of course you have tickets that are more complex and less complex, more certain or less uncertain. I'm not saying when I said pick up any task of course we don't expect like a junior to pick up a big migration. And of course we are aware of that and the one he wants to pick we have to speak with him. But for example if we feel like it's really important for him to work we have a ticket estimation but if we feel like he needs to start what we do is we have extra time just for learning and he can start working. And if he doesn't feel comfortable he asks for help then we can decide. We have decided a couple of times has a team including the person. It's not going okay I don't feel comfortable I need someone else to pick up on the ticket. We just want to give the opportunity and make sure people can choose and be responsible and accountable for their decisions. Of course this is very pretty but we are not allowing in commerce like everyone to pick very complex tickets if they we know that they can deliver but we want to give an opportunity and we want people to learn because otherwise if you try to protect people they will be continuously doing the same thing. And now with the new resources and the world of talent we also need to push people and to incentivize them to work. Okay I think we're out of time if anybody still has questions feel free to catch us outside of the room here or just come to the drop solid booth where we'll definitely hang out. Thanks again. Thank you.