Video: Trillium User Group - May 14 | Duration: 3636s | Summary: Trillium User Group - May 14 | Chapters: Welcome and Orientation (3.44s), Agenda and Initiatives (161.245s), Trillium Log Files (316.675s), Accessing Logs Files (438.43s), Debug Files (696.02s), Debug Analysis Tools (1005.45s), Debug Logging (1162.135s), Trillium Dynamics Performance (1418.65s), Performance Improvements (1609.865s), Performance Improvements (1766.955s), Trillium Dynamics Connector (1880.115s), Natural Language Gateway (1957.04s), Feedback & Next Steps (2048.375s), Parsing and Matching (2154.63s), Data Quality Parsing (2306s), Parser Token Assignment (2516.25s), Parser Output Structure (2677.735s), Matching and Linking (2812.98s), Matching Grades and Patterns (3060.64s), Golden Record Creation (3200.03s), Closing Remarks (3418.175s)
Transcript for "Trillium User Group - May 14":
Hello, everyone. Good morning, good afternoon, wherever you may be in the world. I would like to welcome you, obviously, to the Trillium Visa Group meeting. Excited to have a bunch of us together to discuss some of the latest and greatest developments in the Trillium world. Really excited about the agenda and the speakers that we have this morning or afternoon, wherever, again, you may be. I'll touch on that in a moment or two, but we can proceed and move ahead with the meeting itself a little bit here. Oh, just trying to move the slide ahead. Oh, there we go. So here you're gonna see a little bit of an orientation. Some of you may be unfamiliar with this platform as it's a new one for most of us here. What you're gonna see here is a a slight orientation about how to get around the and orient yourself around what you're seeing on your screen. So you can notice there that, we've highlighted that there is a, sound test, element. This is gonna allow you to hear us. So if you're having issues hearing, you can play around there and, you know, to test out your speakers and your microphone. Your microphone, you won't need unless you want to come on stage. And if you're brave enough to step up to ask a question, we will certainly help you to do that. Amanda is facilitating in the back end as well. So if you have any questions, on the right hand side there, you can see we have, you know, a q and a section, a doc section where we'll have some resources, and, of course, the chat as well. The chat, I should note, is kind of general, so everybody will be able to see everything. Q and a tends to typically go to the speakers themselves, so you'll be able to kind of ask, questions that you you want to have addressed either later on or, you know, in a more private setting there. And the chat, everybody can talk and and see everything there too. If you want to raise raise your hand and get on stage, as we I mentioned earlier on, you see that raise hand icon at the bottom. Simply press that, and we will be sure to move ahead and get you on stage. Looking forward to trying to get some folks generating some conversation, and, hopefully, we'll have some some great, questions and comments to come out of the presentations. Here you'll see, what we're gonna be seeing in terms of the actual interface itself. You can maximize the space, the window space, if you like, by simply clicking on that bottom right, square that has some some holes in it on the bottom right side there. Please feel free to use that and adjust to your taste to see what the screen that works best for you looks like. You'll see up in the top left that you can see, yourself as an audience member and the speaker. Right now, it's myself. As other speakers come on stage to give their purse presentations, you'll see their faces and videos as well. So we have the agenda today, which is very strong. I'm really, really pleased with this agenda. And a big thank you to our guest speakers who have who have taken some time to build out some of the content here. We're heavily represented by our strategic services, side today. Ranjit and Dennis are gonna be presenting around some some things that they've seen and heard from the field. So, you know, how to unlock insights from process logs and debug files, and, you know, of course, using Trillium parsing and matching, which is always a a big topic of conversation as well. We've got Bish who's gonna be going through a little bit of, the improvements within Trillium dynamics, and not on this slide, but something he is gonna be touching on. It is so new that we couldn't get it on the agenda slide. It's actually Trillium and the MCP, facility. So very much looking forward to him, actually running through some of that. Now before we get going here, I wanted to mention that we are gonna be undertaking some new initiatives for supporting Trillium users, one of which is going to be a whole host of videos that we're gonna start to put together. These are designed to help support your usage, kind of, unlock some some tips and tricks from our side that we hear a lot from our customers, and hopefully give you a lot of insight into how to make the most out of your investment in Trillium and kind of drive some awareness about some of the things you can do that maybe you haven't, thought of before. So, Amanda, if you wanna launch that quick poll, what we're going to do now, guys, is is actually get you guys to if you can, fill out some of these selections that we have available. If you want to take a few moments to look through this list here and indicate those ones that you like. Indicates the ones that really resonate with you. If you, can actually see see the poll and take a few moments now to do that. I'll also be following up with you guys afterwards who was sharing the assets of the meeting itself and sending this list out again to you then. So I'll I'll give you a moment or two to kinda look through it. Amanda, when when you feel appropriate, you can just let me know, and we'll move on into the actual meet of the, presentations today. I should note that a bunch of the presenters that you hear today, are some of the folks that will hopefully be putting some of these videos together. So you can either ask them some tough questions today or wait until they put the videos together and come back to them then. And what we're gonna be able to do is, kinda keep that poll open so you can revisit it at any point during this meeting itself. And we're gonna move ahead and get to our first presenter, and that's going to be Dennis. Dennis, if you want to, lead us off with unlocking some insights from the process logs, stats, and debug files. Sure. You can hear me, Matt? Okay. Good morning, everyone. My name is Dennis Sam. I work, in our consulting, team. And this morning, I'm gonna talk about, some of the logs that are produced when you run a Trillium process, and then also talk about some that you may not be too familiar with, like our debugs, which aren't automatically created, that you have to manually enable. So this first slide is just listing some of the output that you can get. I'm sure people that are familiar with Trillium will know about our log files. So the log files, and these are all text based files, are files that show you the start and stop time of the process. We have error files that are also created, and these show you a bit more detail about the, module that, has run. And we have statistics files, which give more detailed counts, and module specific information for a process. And then the debug file, which, isn't automatically, enabled, but it gives you a record by record echo of what's happening in a specific module. And then another file or last file here in this list is the parser exception file, which lists all the records that, are not parsed successfully through the customer data parser. And we're not gonna talk about this one too much today just because this there's enough information in this to fill up an entire presentation, and we will be doing a, a separate, online or on demand video on how to look at parser exceptions and to resolve these issues, using the parser tuner. Okay. So how do we access these? Through the UI, you can right click on any module, and then click on the, view option to see a list of any logs or stats that, are produced by a step. For debug files, it's actually a special button that we need to, click on. So at the bottom here, you have debug, and then it allows you to copy the debug file onto your local machine. So all these files are stored on the server. The ones on the left can be accessed here, but the debug file has actually has to be accessed through a separate text editor. That's why we need to copy the file down to where your control center is located. Okay. So just a couple of examples. So the log file, again, shows you the start time and stop time of a particular step. If something, happens in the step, which causes it not to finish, you won't see a stop time on it. It'll just have the this line that says opening, and then that's it. Usually, it's opening and then closing, but if there's a problem, it's just gonna be open. And then if it crashes, then you have to go, look at other logs to see the reason for the failure. And that's what the second box is here. This is the error file. So, typically, this is empty. So So whenever you run a step, the file gets produced, but there's nothing in the file. So a lot of customers when they're running, let's say, in batch, they can have some steps in their script which evaluate the logs folder for, error files, that aren't zero bytes. So that's one way you can automate, checking for errors in your processes by looking in the error file. The error file also gives you more detail, about the error. So here, it's telling me that I'm running, the relationship linker, but this field, for some reason, is missing. And this is one of the fields. This test street name is used in the, match comparisons. Sometimes errors will also be written in the log file, but most of the time, if there's an error that causes the process to stop, you can go to this ERR file, and then find the reason for the failure. Another note is that, if this is a deployed project, these, and they're running a batch script. These errors and these stat files are saved in the logs folder of the project. Sometimes there there are files in the data folder like the parser exceptions, but almost all the other logs files will be stored in the logs folder. Okay. This is a little bit small, but this is a sample of our statistics file. So this is from the US Postal Matcher. So it just echoes the start and stop stop time. You can also get the version number of your Trillium version, and it gives module specific counts. So in the postal matcher here, it's telling us how many records in this file, at the bottom, the 99.2, how many match the each, postal files or the accuracy. And then for those that fail, that just gives us counts for, each of the different, failure types. You may not be aware, but we also have an XML version, of each statistics file. So some steps, you know, the XML version is not that nice to look at because there's nothing really to put in a pie chart, but this postal matcher is good because the match levels have, up to six or seven different, values. So that's something that's nice to visually see in the chart here. Again again, this is an XML file, and it's stored in the logs folder. Okay. So the debug files, these are not enabled by default. You can enable them in the UI by going to the output settings, and there's a drop down here. And most modules will have three different things to pick from. Right? So by default, it's off, and then it's usually normal and extended. Some modules have more, like the customer data parser has an additional value verbose. And then the relationship linker also has some additional values, including analysis of window keys. So in the UI, these are in a pick list. This is converted in your STX as a numeric value. So by default, off is zero, and then in this order is how the values are assigned. So normal would be one extended to. So if you have a deployed project and, you don't wanna have to go to the UI to, set up the value and the debug and then redeploy the project, you can just go to your STX file, look for the line that says enable debug, and change the zero to whatever, debug option you want to turn on. So I'll just show you some examples of what the debugs, produce. This is a the debug for the transformer. The debug is a record by record echo of how, it's processed through each step. So in the transformer, and I just took a snippet out of this debug, I enabled the web, service transformer functionality where the transformer makes a call to an external web service. So in this, you can see all the business rules that were configured in the transformer. You can see, here in the middle, it says base address. I don't know if I have a pointer here. No. But in the base address here is the actual URL of the web service. So this is I set up a web service on my local, to get, precisely ID from an address. And here you can see, the information being passed from the transformer to the web service I'm calling, and at the very bottom is the response from the web service. So the debug is good to see if, whatever you're passing particular step is actually getting passed to that step and to see the output that is returned and how the step processes the data. So this is an example of transformer. In the customer data parser, what the debug does is it prints out, again, the input data and how each individual element is parsed or at least attempted to be parsed. So here, this first line is the name line, and you can see that there are some elements in this line which don't have, an attribute assigned. It's given an intrinsic attribute. So here it says Therese, Witt, ampersand, Devin Witt, and Alexander. The second token on this line is given the intrinsic attribute of alpha because Witt is not in our parsing tables as a surname or a first name. So when you're going into the parser and trying to figure out why a specific record is not being parsed properly, you need more information, you can go into this debug, to see how the parser attempted to parse this record. And then here's an example from our relationship linker, and I use this one a lot because when we're doing matching of, addresses or customers, whenever we find a match, we actually put that match pattern on the match record. However, when we don't find matches, nothing is actually written to the record to tell you why it didn't match. However, when you turn the debug, the matcher will print out all the comparisons, even the failed comparisons, in the debug file. And also additional information, we have, in addition to the pattern, it shows us each comparison for the two records that it's looking at, including the numeric score and the alpha grade. So when we're setting up patterns, right, we usually, well, we always take the numeric score and convert it to a pattern, but we really don't know what the numeric score is exactly because we set up a range. In the debug file, you can actually see the numeric score that's assigned. Okay. So here's an example of a failure that I was talking about. So this f this pattern here, F997, this is not stored on the record, but from the debug, you can see why two records aren't matching. So here, you can see that, we're using the standardized version of Bob, changing it to Robert, comparing Robert to Robert Robin gets a numeric score of 79, which is converted to a d, and this is the result in pattern. So this is very helpful when you're trying to debug undermatching. One thing to note is that when you turn on these debugs, it does print every record in the debug files. So they can get quite large, especially for the matcher because the matcher prints out all the comparisons. So it may be that you have a thousand records, but those thousand records are in the same window. You're gonna have more than a thousand records in the debug because it's going to print out, record one matching to record two, record one matching to three, etcetera. So be careful when you turn these on, because you may forget to turn them off and then promote it to production, and then you end up running out of space because this file ends up to be, like, hundreds of gigs or so. Another one I like to use in the debug is the analyze keys. So let's say you're running a matcher and it's taking an unusually long time to complete. Usually, that's indication that you have large windows. To analyze these large windows, you can actually turn on the debug without having to run the matcher. So all it does is it goes into the input file of the matcher. It runs a frequency on the window key for that particular step and just prints out account, for those large groups. So here's the number of records for this group. And you can specify how many, top groups that you want printed out. Okay. So what I showed you before is in batch. All the log files, stat files, debug files can also be run or produced in real time, but there are some additional and these are controlled using the dir cleanser or dir matcher dot XML files. Additional output you can have are timers for each transaction, and like, the debugs, that you saw earlier, we can print out the input and output data for each transaction. So here's an example of how to turn it on in the cleanser. At the top of our cleanser, we'll show you the option. So you can pick from these. We usually turn on the UCA trace, and we set that to r for repository dump. That's usually enough information. If you turn on a more verbose log, that might be a little too noisy because it will give you the hex values for the data, and you don't wanna be converting hex to actual alpha characters. So we usually just turn on the r. You can turn on the trace for each individual step here in their XML. So, like, here in the transformer, the trace is set to blank. But, again, usually, we find that turning on just a repository dump, you say trace equals r, is enough. And one note that, the run mode should be changed from turbo to standard. And when you change the run mode from turbo to standard, it allows us to save information in between steps. If you don't have standard, you might just get the information from the final step in this list of, processes. So here's an example of the cleanser, log, and I do use this the UCA trace a lot because when you're running a web service, sometimes you're mapping your data into the wrong fields for your, JSON, etcetera. So by turning on the debug, I can see what I'm passing to, the web service. So here I have input line as my input data. And then, again, this is just a snippet of the entire log, but you can basically see everything that, the web service produces. Even if you don't have the field in your final DDL, every field that's available from, your process, is echoed in the cleanser file in its unalterated form. So here, like, the postal code, you have this nine digits. You have the cleansed version of the city, etcetera. And then this last slide shows the matcher debug. Now one thing, which is cool about the matcher debug is that it will also echo the candidates that, are pulled for the match. So sometimes you're running a match against your web service. You're sending in one transaction, but you don't know, which candidates are being pulled to do the matching against. In the debug, you can actually see that. So, the candidate records are suffix with a sequence number. So here, I'm sending in one transaction and I pulled two candidates. And then the one and two, they echo what that candidate, has in each of the fields. And, also, you can see the pattern ID and account, for the number of, candidates. And that's it. So any questions? If you have any questions, you can put them in the chat or send the send us, notes after the meeting. That's great, Dennis. Thank you so much. Fantastic presentation. I certainly learned a lot. Didn't have any idea that there was just so much, to sink our teeth into around, the logs and things of that nature. So really, really conversation. No worries. With that, I'm gonna, pass over to Bish. Bish, if you wanna come back up on stage and, kind of walk us through the improvements in Trillion dynamics. Sure. Thanks, Matt. Just checking if I'm audible. Thanks. Alright. Hello, everyone. This is Vishwadeep Singh Gupta. I am representing the the Trillium product management team and really wanted to take you through some of the the dynamics improvement, that team has worked on. So, really great effort there as well as, a teaser, so to say, for the the national language gateway into all of the Trillium capabilities that we have. So with that, let me get started. So what we did with the the Trillium quality for Dynamics. Right? So it's an established connector, one of the few connectors that Trillium supports. Right? So we saw a 94% of time reduction on the average merge time. There was also a 64% time cut reported on the longest merge. In addition, there was 93% time saved for batch upload as well as, all of this culminating, and consolidating in in six, again, improvements, right, that we'll look at. So I want to take you, into all of these, the next slides. Right? But first, I want to start on the context of this that what really was the problem statement here. So the challenge that we really faced with the, the connector in terms of, requests coming in as well as in terms of our own inspections, it was really around improvements that were targeted of, including memory, matching logic as well as batch processing. And this was targeted towards the the overall improvement in in performance as well as the reliability of the connector. Right? So what we did as a response to that is we factored the the end to end connector, resolving connection reliability as well as rolling the the entire matching engine, specifically targeted towards the the transitive reduplication. Also, we improved how the the memory usage is is is being used, is being leveraged within this connector and optimize the the batch operations with multi threading and the bulk of vehicles. Now what all of this resulted in is, a 94% reduction rate, in the average merge time. So something that was earlier taking sixty five seconds is now, down to four seconds. Right? So, also, in addition to that, there was this batch upload duration, which was to the tunes of forty hours, and we have seen a drastic reduction there, which is in the tunes of three hours now, as well as the memory leaks, which were eliminated as part of this exercise, as well as the improvements which are provided. So having said that context, right, that what we are really looking at, let me take you deeper into each of the areas, wherein we saw the greatest impact. Right? So the first one was around the the real time cleansing. And here, what is what happened is that every new or updated record, right, which is routed through the the premium engine, through the connector. Now that was, whether it is in terms of address standardization, country identification, or, geocoding. Right? So all of these are now running automatically, which essentially means that there is zero workflow change for the CRM operators. In the area of superior deduplication, we we picked up the, the the advanced matching with the full transitivity relationship logic, and that meant that the the matching engine was refactored to eliminate lot of permutations, permutation explosions that we were seeing in the past, as well as producing reliable and, complete, duplicate clusters. Last but not the least was the the high performance batch that we saw, in in the batch area. So here, we saw approximately, the the the forty to three hours reductions that was resulted by, adding the multi threading as well as the bulk API calls. What we also saw as as a result end of this is automated match window size checks that prevented the the Tomcat heap exhaustion. Right? So overall, rely improving the the stability and reliability of the current correct. So with that, I'll just recap the what the the improvement figure looks like. So the average most time, we are seeing a a dramatic reduction of 94%. Whenever we are looking at the batch upload, there is we we would look forward to your feedback, based on your usage, and then feel free to reach out for any questions or you would like to know more about these improvements that have gone into the product. Also, in the, the reduction of the longest watch time, there is a significant improvement recorded as well as, faster, shorter, more challenging action which has improved significantly. Right? So I think all in all, we have seen lot of improvements going in and which could be really distilled into these six, login improvements. So starting with the the connection time outs, so this is essentially by reducing the batch size. Right? What we have done is we have improved the connection management. So that means that there is low risk targeted changes that completely eliminates API time out errors. Also, we looked at match transitivity as a result end of the, the the set of improvements wherein we refactored the match engine for transitive record relationships, ensuring that there are, complete duplicate clusters are identified every time. And in the same breath, the matching, permutation explosion. So now we are ensuring that as soon as they are generated, they are removed so that, we can completely eliminate the runaway, memory growth, right, especially during the large batch runs. Also, in the memory usage improvement, we, improved the the the cleanse as well as the match processes and the bounded, in memory record retention, which has completely eliminated the the heat exhaustion that we were seeing. In the account and contact merging area, we have, the multi thread link detection now as well as the bulk API calls. All of this really helped us to, cut the the forty one hour most time that we were seeing. Right? So dramatic improvement, they're hurting bringing it down to, just under three hours. And finally, last but not the least was that the don't cut crashes. Now this is nothing specific to the product, but, what we have also emphasized and tried to do on our side is adding the automated checks to break the the oversized match windows, before they really exhausted. Right? Again, for adding to the overall reliability and stability of the products. So this is, essentially what we had, in terms of the improvements. What I wanted to end on is really take you through, a sneak peek of what we are talking about. Right? So for those of you who are using this or possibly would be interested in knowing more, feel free to reach out. But just a snapshot that, the Trillium Dynamics connector is really a mediator between your OEM, your license for Dynamics, as well as the the power that Trillium engine provides. What it does is whenever a record enters, right, it will do all the the things that Trillium does. Right? So it will identify the country. It will standardize and just cleanse and prep your data. It will give it the latitude, longitude for from the geocoding perspective. We'll enrich it with the the window keys and do the once matching. Right? Some of the the improvements that we saw on the previous slides. So once it does that, it sends the the record back. The the results get saved resulting in the that either the duplicate reconciliation, via Domage or the pop up that you that is presented on the Dynamics connector. Right? So, while we have covered the the Trillium dynamics part, I just will hop on to the the Trillium MCP piece before we pass it on. So, what we have also been working on and, this is an area wherein we would really encourage you, and Matt will speak more about this in a second, to know more that how it impacts your side of the business. So we are providing the the unnatural language gateway into the Trillium functionalities. Right? So, both on the Trillium discovery side and the Trillium quality side, we have opened up tools. Now for those of you who are getting acquainted or coming up with speed, with the m MCP construct, it just gives you a a a flexibility to provide a prompt. Right? Essentially, type in natural language, and it will get give you some of the most meaningful, results or the operation that Trillium can perform. Right? So if we look at instance, for instance, getting the business rule. Right? Getting the the entity details, running a business rule. Right? So it will do all of those things as well as on the quality side. Let's say you are trying to perform a a window match or a reference match or even if you are trying to, cleanse a record. It will be able to handle those things. Right? So we have just gotten here. We'll love to speak more in the in the upcoming sessions that we'll have, but we would really love to know more how this aligns with you, how this would help you, and, of course, your side of the the AI enabled and how you are getting forward. Right? So on that note, Mad, just checking if you would like to take us forward. Yeah. Absolutely, Vish. Thanks. So just wanted to give you guys this this heads up. As we will be sending after the meeting the assets to you guys, which will include, obviously, the list that we shared before, We're also gonna share a couple of questions with you, which we'd love for you for you to answer, and just send them back via email. I think that's the easiest way because there is some free text involved. But it's really about understanding how your workflows can be positively impacted by MCP. Right? So, the questions that you'll be seeing are gonna look a lot like this. It'll be just three small questions, obviously, and it's really about understanding what you would build with Trillium and and the model context protocol. So what capabilities are of interest for you? Do you have a business scenario that you might see fit to use this? And would you actually be integrating this? Or is this something that you maybe have never even heard of before that now, and are now having to want some more information on or consider for your future business process flows as well? So I just wanted to give you the heads up, get your thinking caps on that, you know, there's no pressure to answer these now by any means, but, we'd love to get some feedback from you. Really helps us to actually understand how customers and and individuals are using and leveraging, these capabilities and helps us to actually make sure that we're fine tuning our offerings to to help support those usage cases and beyond. With that, Bisha, I can pass it back to you if you'd like, if you wanna just say a few closing words. Sure. Thanks, Matt. So, as Matt mentioned, we'll really love to hear feedback both on the dynamic dynamics piece that we presented as well as the the MCT feedback. Really excited to know how you are enabling it on your side, and, it will really help us shape our road map, shape our planning, and really continue to provide the value that Trimble Trillium is bringing to all of you. Great. Thanks so much, Bish. Really appreciate your time. Some really interesting stuff in there. In particular, I'm I'm kinda fascinated by the MCP piece. It's so new that, you know, I kinda feel like I'm kinda learning as as you're presenting, so thank you for sharing that. Thanks, man. Now, I'd like yeah. Thank you. I'd like to invite Ranjit to come up on stage, who's going to be talking about, you know, parsing and matching and and how it affects your data and how you trust your data. So, Ranjit, I'll I'll pass it over to you. Thank you. Unaudible? Alright. Okay. Alright. Trusted, my name is Rajiv Palos. I am a consultant with our, professional services team. Today, we are going to talk about, you know, how, you can create faster data through Trillium parsing and matching. We'll cover, the details about parsing, how we parse, name, address. We'll also look into how that is really important when you get into matching, how to consolidate, the data duplicates, and then, you know, create finally create a trusted data. Right? So, so that we'll we'll, start with the parsing first. So what is, you know, data quality and and, what is the common problems that you see, within data. Right? So, when you receive data, you know, you have, from different sources, you know, different formats. If you, look at the screen here, you know, you have multiple names, multiple, you would have, business names, individual names in the record set, you know, business and mixed names. If you look at those column one there, we have misspellings in the names. We have, nicknames. Some of the data might, you know, have some misinformation. Some of the records might not have all the attributes, in different formats. So, you know, so these are, the lack of standardization of different fields, misspellings, etcetera, inconsistency. So all these, you know, are, you know, common very commonly occurring data quality problems. Let's move. So what does Trillium Data Quality do? Trillium Data Quality transform data, the trust is business information. Right? That's that's our objective. It is enterprise wide data quality management system, supports any data driven corporate initiative. Right? Versatile single solution. We have multiple deployment options, real time batch. We can scale this to run, in in a big, data environment. We cleanse any information that we get, any type of data. Right? So, individual names, products, etcetera. So we can cleanse any of those information, enhance the data, correct, verify, for example, address information, you know, around the globe. We can also standardize product data, what we call it is using the parsing engine. And finally, we can also create from this parse information. We can create single customer views, which entity resolution is also matching, you know, all this, the same terms used. First, we'll talk about parsing, how to create you know, how parcel helps to build your trusted data. Right? So customer data parser, any data that we pass into a Twilio customer data parser, you know, be it the name, address, product, any names, we set those as, you know, we we pass those as lines. And we we define them as, you know, input attributes. We find when we define those as a name line, an address line, a geo line, you know, if you don't know what type of line it could be, you can also, you know, let, Trillium dis you know, find out what type of line is. If you see the screenshot here, the example, you know, on the right side, it says, what type of line each are we passing in. Right? So it's a name line, and we say an address line, and city, postcode, and the geolines. So based on what we specify here, you know, it goes through in the back end goes through our out of the box tables or information, which which we, check against to, identify, verify, identify what type of data it is, in what region this data is coming from. Right? So we have, in the back end, a lot of rules, that has come from our experience dealing with this data from different countries, different types of data. And we use that information to, to to parse or break down the data that we are getting into and put into separate buckets of, information. Right? So, the raw data that we, receive is put into different, you know, buckets of information. For example, if the name you have you you parse it or break down the name into different, you know, buckets like first name, middle name, last name. If you have a street, you know, we break it down to, house number, street name, you know, street type, and also similarly for a geo line, for example. Right? Break it down city, state, postcode. So, the parser, you know, have inbuilt rules, that can help do this. Here is an example, for how we, send data into a parsing engine. So in this example, we are passing, like, three lines. If you see, parser input line one, two, and three. And the line one is a name. Line two is a, the street information, and line three is the geo information. So we we, in this case, we know that these are the what type of lines these are, so we are passing those as name, street, and geography. So, this is what is being, you know, sent into, into Trulia. Alright. So this, is a little bit more detail into how we are parsing. So it, Trulia parser will go line by line. It takes first line, and then we we assign tokens to the, parsing engine. Right? So, if you see here, you know, we have, type and prefix, give a name 11Alpha1 alpha. So it goes and assigns different tokens to, to to the, words in the line. So if for this one, line one, the CDP assigned tokens are title, given name one one alpha and alpha. So once we have these type of pattern recognized, the parser will will, internally have different patterns, to come up with. And in this case, it, came up with, you know, title p given name one, given name two, and surname. Right? These are all inbuilt rules. So now the parser has put all this into different buckets. So, you know, if you see here, you know, a title, given name one, name two, and surname. Look through this. So here in in, line two, you know, the parser did identify here, different, the tokens assigned are house number, street name, and street type. You know? So these are, again, based on internal rules to identify these. Line three, you know, again, identified as city, state, postcode. Right? So these are underlying tables, underlying patterns, which we recognize. So this is, you know, we have been using this patterns for, you know, years. Again, that has built our underlying tables based on the changes in the address, different new postal directories, all those things that contributed the underlying tables. Now what is the output of parser? Parser output will have original attributes and additionally, it has the the recorded attributes. The recorded attributes are the parser identified tokens based on the tokens that identify what field it is. It also says what type of, what type of, data it is. If it is a person or individual data, it specifies that. If it's business data, it specifies that. That will help later in our matching process. It also creates, you know, a parser, exception files, which will help, you know, if there are any issues with the data, we have an exception file where we could go and look and then, you know, move, you know, make any changes if needed. It also output will also include review groups. Review groups, specify what type of error is on the, on a record. Right? So if there is, you know, for example, unable to verify city, street, or different types. And any different types of error, it gives you a code which, you know, you can determine, what was the issue and how can we fix those. Alright. So here is another example where, you know, we have a VWAP auction. Dennis did, you know, mentioned about this. So here's another example. Right? So this is line one, two, three. So Peggy Smith, 345, 6th Avenue, New York. So it and line types is name, street, geo, in the last line there. It is specified straight. That's the line identified. Now here, you know, it's you know, it it shows, you know, how each of these lines are recorded. You know, how line one two, line two, and line three are recorded. And, if you see, you know, name line due to room 1, it says Margaret was it is recoded to Margaret Smith. You know, Peggy Smith has become Margaret Smith. So this has standardization process and names. All the attributes are identified, different buckets, and assigned to different buckets. Review group zero zero means you have no exceptions found. It's a good, you know, format. Everything looks good. Now, getting into matching, you know, this this parsed, data is what is feeding into our matching process. Different, you know, we have, different types of records. Is it, you know, the same person? There are there are different, business names, different attributes. You know, one record might have, for example, an attribute is a phone number. The other record might have an email, which is not on the first record. Right? And and similarly, the fourth record might have some other information which is not on record one and two. But if there is anything that can connect all these, we can bring all these together Based on different algorithms, we have around, you know, 30 plus, 36 plus algorithms, which can be used to compare compare each attribute to attribute on these records. And based on some scores, we can assign what we call a pattern ID and, you know, bring those together. Also, you know, we have, a transitive d, rules, where if record a is matching to record b and record b is matching to record c, even though, you know, if a and c, we cannot find any common ground for matching, since this, a is matching to b and b is matching to c, we can bring all those together saying that a equal to b equal to c. So that is, you know, multi matching. So that is also supported, within Trillium. The whole process is in in in, in four phases. Phase one is to bring similar requests together, what we call a window key. So window key creates, a window of matching opportunity. Right? So similar set type of records and, that is the window key. The, phase two is the comparison between these records within that window. So it's attribute to attribute comparison. And then coming up, in a, next phase is to, categorize is it a pass or a fail based on, you know, how will the attributes match. It also gives up, gives you information, about, you know, the statistics. How many matches do you form? How many, what is the maximum window size? You know, how many, matches are there per, per pattern, etcetera. Right? So matching and ringing process involves, bringing off records together using the window key. And each of these comparison of the attributes gives you a score, zero through 100. You know, it could be, you know, based on whatever we define, it it it gives you a score. A score is assigned in a grade, And you the relationship, Lingr, has a UI where you could, you know, edit the scores, and the grades, etcetera, you know, so you bring up a score. For example, on a name, you know, bring up a score, you know, business name. You could, you know, eighty, ninety, 100, you know. So these are, you know, you'll see, the great patterns here. Before that, what is a window? Right? So how do you bring the records together? So window is, similar looking or similar, data where, you know, this is mainly for performance reasons. Right? We don't want to compare, one record to every other record in our in our system. So what we do is, we bring records together based on some of the data elements. We pick and choose different, you know, data elements. And, you know, for example here, if you see here, you know so the window key for this record on the left, is, you're picking some part of the ZIP code. It's a 01821. Right? So then we pick, some part of the street, and then we say one, which just means, you know, this is a person type of record. Right? So so this is from the data. So, you know, technically mattering down to a ZIP code and a street. Right? So a person, in a in a ZIP code and a street. Alright? So possibly. So then, you know, after this is a gives a reasonable volume or set of records that we want to compare, and find a match. And and, and, you know, as far as performance, this is much better. Right? You're not comparing, and then you're you have a reasonable set. Matching. So this is the, how where we, you know, configure the grades and patterns. Grades are basically scores assigned, score a, b, c, d. You know, if you see on the top screenshot there, you have different score assigned, scores assigned. And, you know, these are, you know so if you see here a, b, c's, you know, we have different patterns. Patterns are assigned for a set of scores, you know, on different attributes. If AAAs are all a's on a street name, surname, house number, apartment number, which means, you know so we get an, you know, a perfect score of, you know, pattern ID of 100. Right? So, the pattern IDs are assigned based on the score, so, it gives you a, you know, this is a UI that you could configure, you know, based on business tools you could configure. On different type of matches, matching available. We have relationship lingers. So this is basically a duplicate check within a file or a same dataset reference matcher. So you have two two sets of data. One is, for example, transaction, and you have a reference file which you have. Right? So one dataset against another one that's a reference. Multi match is a, where where you go you know, we talked about transitivity, multi match in different levels and different matches and different window keys. We try to club all those together. That's a multi matching, process. We do, two levels of matching, out of the box. One is consumer. Types of matching is consumer and and, business, and the levels are, you know, householding and individual. Right? For example, if you have a group together and household, you know, bring everybody in one household together, that's a level one. And who are the individuals within those household? Right? So that level two. That's level two individual level matching. For ex here's an example. You know, if you look at here, you know, so, they all are at 795 Main Street. So they are in the same household. So level one has the same key, 23, 23, 23. And then, you know, so, a level one match in level, two is three different people in that household. Right? So this is, you know, level one and level two match. Survivorship survivorship and merging is, you know, how to how you build a trusted data. Right? So based on the matching engine, now we know that, okay, these, these are the connected records. These are duplicates. Right? So now how do we choose, you know, the records? Right? So that's, that's what, we have different business tools to to come up with a good record. For example, here's one example. There are different records here. Now they all match from different sources, web CRM and SAP. And for each attribute, we can say, you know, what is how do we choose? For example, here, first name. You know, first name complete most complete, and and we pick Arthur. Right? And then, email, which one should we we we say best source is here SAP, so we pick from best source. This is the this is we are creating a golden record, a trusted, record from the set of matches that we have there. Alright. Can I how yeah? At least can quickly, show I'll share my screen. Should I leave stage? Okay. Share. Create share. Share. Alright. So this is an example that we are looking at. So this is a parsing engine. So, you know, we have just, you know, you know, when you run this particular example here, this is a project, and then this is a customer data parser. And then, you know, parsing engine will, in detail, show how we, are, you know, are parsing this one. So here are the three lines that we are showing, in the example here. And, you know, you can see here, you know, how these are getting, parsed. We have a, a a recode here. You know, it Peggy was recoded to Margaret and, yeah. So this is an example where, you know, this parsing engine is parsing. Parsing engine comes with out of the box rules. So these are patterns in out of the box, And, you know, these are basically back end rules. You know, these are modifiable. We can create patterns, and and that's, a tool where you could define additional business tools that you want to. This is we are focused on customer data parser, and the other one is the relationship linker. This is where we match and, you know, that's, that brings record together. You know, I have already run this project and then, the records, are work together based on window keys and then, you know, match together. Alright. So let me go back to stop sharing. Hang on. Right. Back to you. Sorry about that, guys. I stalled out on me for a second. Thank you so much for that. That was really, really impressive. Really neat stuff and learned a lot certainly, and there there's more to learn. I know that we're gonna look at this in in some of the video sessions coming up, down the road. So, definitely, we'll peel into this a bit more, and, certainly, we'll make this presentation available to everybody afterwards as well. We're almost at time, so I just very quickly wanted to go through a couple of the announcements, and and kind of wrap up the meeting today. This is, an area I always like to touch on because, you know, learning is something that we all try to do consistently and support our Trillium users is is top of mind. This resource hub is where you'll kind of use, as a one stop shop, if you will, for basically everything under the Trillium sun. So things like the online forums, you'll find the knowledge communities. There's a Trillium discussion group. You'll find specific product help with use cases, white papers, all sorts of things. There is also a generative AI functionality within the support section. So as you are typing in questions and and looking to get support from Precisely, you will actually be served up a number of articles and and past cases which may help you in advance of actually having to get to somebody. So some really strong developments in that area. Definitely encourage you guys to bookmark this. They will be in the resources that we share afterwards, so you don't have to go hunting around for them too much. We've also updated our support plans. Those of you who may be, on on a support plan will notice that we have kind of changed and added in a new level on the enterprise level. This is kind of the the Rolls Royce version, if you will, of our support. So it's twenty four seven, absolutely around the clock support. Definitely, if you're interested in this, soon to speak to your customer success manager, or anybody here precisely if you're looking to get additional support, beyond the standard or the advanced support packages which are currently available. What are we up to from the precisely side? Well, there's a bunch of things happening, in the near future. So if you're really quick, you can catch a webinar tomorrow around, agentic and AI readiness. So are you ahead or falling behind? AI is clearly on everybody's lips these days as it's being incorporated into almost everything we do. So that should be a really interesting one. And we also have upcoming webinars on the twenty sixth and, the, of course, Snowflake Summit, which we'll be participating in if you happen to be in San Francisco in early June. Some great news articles there you can catch up on and read at your leisure. And, again, of course, that resource center is front and center for you guys to take in at your leisure. We always do want to hear from you. So the ideas portal is really important for us. You can suggest either things that you'd like to see happening in the Trillium platform, or if you have an idea for anything else under the sun, we'd very much like to talk to you about use cases or anything in under the in the world, really. And, of course, we're always looking for more presentations. So we're happy to talk to you guys about having a presentation at an upcoming session as well. Finally, this is the great customer support, success support customer success team that we work with. You guys may recognize some of these faces. Definitely encourage you to stay in touch with them and reach out. They are your, champions here precisely and fantastic individuals. So definitely we'd encourage you to reach out to them if you haven't already. And with that, I'll wrap this up today. Thank you everybody for attending. A special thank you to the speakers who actually did such a fantastic job of delivering so much content in a timely fashion. As I mentioned, I'll be following up via email with, support assets as well as a couple of those questions that we'd love to get your feedback on. And, it all falls free to say once again thank you to all the speakers. Thank you to everybody for attending. And I hope you have a fantastic day or evening wherever you might be. Thank Thank you so much, everybody. Appreciate your time today.