The Architecture of Analysis: How to Approach Your Customer Journey Analytics Data Model

Transcript

Hi, my name is Brian Hao, and for my presentation for the Experience Makers Scale Exchange, my topic is the architecture of analysis. And it’s really about how to approach your data model for CJA. So as far as the agenda, we’re going to be going through foundation principles about how core concepts in the experience data model on the Adobe Experience platform side, as far as schema transformations, impact CJA. I’ll also be doing a deep dive on the schema data types that are present on Experience platform side, and how those then manifest in customer journey analytics. So we’ll cover flat schemas, arrays, and arrays of objects. And we’ll cover how and when and where you should use each effectively. I’ll also be going through the manifestations and ramifications of the container hierarchy in CJA. And that’s really about just understanding how your event session and person level analysis apply and have implications against your dashboarding and reporting and analysis efforts. And then finally, we’ll end on just practical implementation concerns, right? Some real world strategies so that you can optimally design your Adobe Experience platform, schemas and data models and objects, and how those have through lines to your CJA data model architecture.

So a bit about me, I am a senior product manager at Adobe focused on customer journey analytics integrations. I’ve also written extensively on the Adobe Experience lead blog about CJA and Adobe Experience platform. I’ve also speaking at summit and support on product documentation. So really excited to join you for this skill exchange. I really believe in the community and being a contributor and learning from each other, and looking forward to going through the presentation and hopefully widening our skill set and understanding this together.

So first, I’d like to start with just the AP and TJ data landscape overall, I think this is a really important kind of baseline understanding to start from. And as you might be aware, like the Adobe Experience platform really forms the, you know, integrated ecosystem with CJA. So there’s both a interconnected aspect as well as a sourcing aspect to the data that you have in, you know, that you bring into ingest into AP, then turn into AP data sets that then are brought into a CJA connection. So just to cover some of the terminology and language and concepts, right? So we have XDM schemas and AP data sets. Those are really the starting point for your data that you bring into CJA. Those define the data structure. That’s where all the sourcing of data from into CJA is based off of that is probably formed in union at a CJA connection level. That’s where those linked AP data sets are brought into CJA and maintaining those same relationships that we established through our AP data structures and schemas. Then off of those connections, we build what are called CJA data views, right? Those are customized views of those connected AP data sets that we’ve connected at the connection level. And then finally, really the last stage, and this is where most of the end users of CJA are working, right? That’s the CJA analysis workspace level. So that’s where freeform, you know, a table analysis is occurring, where people are building dashboards, visualizations, and where the data analysis is happening. So there’s really this nice, you know, both the synergy and both the symmetry with what do you do in AP, how that then manifests at the various levels in CJA, first connection, then data view, then analysis workspace, and kind of the underlying project and databases for those sourced AP data sets as constructed and as built and as ingested and designed in the Adobe Experience platform. So again, just a survey of kind of the whole data landscape that is making up what your CJA instance is allowing you to do for reporting and analysis.

So bringing it back and kind of bridging those worlds is what I want to attempt to do in this talk is really just how those XDM schema manifestations and how that implementation impacts CJA. And there’s really three critical aspects of data scheme and management that come into play. And really this, this is max everything, right? So data organization, how data is processed, how analysis can happen in CJA. That’s all really shaped by these aspects. And it does really require like a methodical approach to your data architecture and your schema design. So really schema, you know, has wide ranging impacts and implications. So I would emphasize that CJA practitioners really must consider, you know, how your data structure translates across different analytical contexts, how you can maintain data integrity and always ensure that data usability is top of mind. So really this presentation, I think, you know, speaks to three different types of audiences even. So you may be, you may be more AP focus, right? You may be the architect or, you know, the data engineer who’s, who’s injecting the data into AP and designing your schemas and your data models. That person, you know, maybe they don’t have as good of a through line to what the manifestations are in CJA. So hopefully this presentation will help those types of users and those power builders, so to say, on the AP side, understand CJA a bit more. You also have your CJA admins, right? So these are the people that are really the bridge connector between the work that’s done on the Adobe Experience platform and then making it realized and a value in CJA. So I think there’s some really important concepts and understandings that I’ll cover in this presentation that will aid really those, you know, administrators of your CJA incidents that are kind of working across both worlds from a sourcing perspective of what was built in AP. And then again, kind of rebuilding with those building blocks again in CJA for reporting and analysis. And then there’s a third group, right? So if you’re an analyst and maybe you’re just doing analysis in CJA, you have another administrator that you rely on or another architect, you’re kind of end of the line, right? But it still is important. And I think really valuable to have those understandings again of what you have to work with, why it’s shaped a certain way and, you know, how your analysis should be performed and operated on based on the data model that you’ve been provided. And maybe there’s even some feedback, right, that you can provide to your administrator or your architect or your data engineers about, you know, specific analysis that, you know, you want to do or specific reporting that you want to do and how that’s shaped by the data that you have in AP as sourced into CJA.

So really the challenge is, again, what we’re solving for across all those levels and considerations is complex, you know, XGM schema data structures have to have, you know, a CJA friendly transformation. And I can’t stress that enough, right? So even though we get the data into AP, even though it adheres to maybe the XGM schema, if it doesn’t bring itself to CJA in a way that, you know, reporting analysis can be done to meet business objectives, it’s not going to be a good idea. And if it’s not going to meet business objectives and perform the right analysis or reporting, then, you know, it won’t be as of high value as it could have been right. And so really the levels that I’m going to touch on this presentation is array data specifically needs special handling. And, you know, when to maintain relationships will go into that. There’s also just proper understandings of when container level kind of implications come into play in CJA when you’re doing multi-level analysis based on, again, how your data structures are aligned from your AP datasets and also just reporting performance optimization. So, right. How can we maintain the right data integrity and data levels that we need from AP and how to work the right way in CJA? So really it’s just this last statement, right? It’s the Adobe Experience Platform XDM schema to CJA transformation, right? And it’s that relationship between the raw data structures and that conversion to analyzable components while maintaining relationships and allowing for that multi-level hierarchy, you know, respect and insights for analysis purposes.

And so the three critical aspects for success that I’ll cover are really just the flat data structure nature of CJA. This is a just inherent, you know, very important aspect to understand and know. And that’s just how that flat data structure is processed and displayed in CJA. And that really is the foundation for, you know, the storage of the data that you built in AP and then brought into CJA, how that data can then be accessed and then how the analysis can be formed in a way that’s not just a flat data structure. And, you know, executed against in different contexts. Then we’ll cover again, the more complicated use cases around arrays and arrays of object management. So this is mastering, you know, when XDM data is in an array form or is in the object field or array of objects. You know, the criticality around that implementation and the governance around how that data is collected and maintained from a relationship standpoint all the way through to again, how you would work with that in CJA. And then we’ll cover really just bringing it all together, right? This is the container hierarchy, right? This is the levels that you can work with in terms of your analysis in CJA and understanding how the CJA container levels influence your analysis, right? So that’s a really vital point because it’s tying together the architectural framework that your entire implementation is kind of bound by into a way that you can do reporting and analysis in CJA, you know, in an organized way with the right interpretations.

So just to visualize again, these are the three schemas that exist that CJA supports today. And these are, you know, built AP side on that experience data model schema framework. And so the main one that I touched on right is that flat schema, that’s the top one. And the way to think about this is just it’s really just individual field analysis. When you have basic metrics or basic dimension structures, this is the most straightforward use case because you have basically a one to one relationship to your data model values. And then how those turn into components. This works perfectly fine for a large variety of use cases when you have just basic event tracking kind of parameters.

Then kind of a level down from that in complexity certainly is the array schema. So the typical cases for this would be when you have, you know, lists of related items, recurring patterns, when you have multiple fields that you want to relate dimensionally, both to the same level, but at the same time you want to maintain, you know, a list format for them. So a lot of this, you know, comes into play when we’re dealing with things like categorization of content, maybe or products, content tags. Basically, anytime you have multiple related values is when this array schema data object data type will occur. Then we also have the array of objects. So this is the most complicated data type and it comes into play again in our most kind of complicated use cases. So the main one, I think, is like anything to do with products where you have, you know, products that need to maintain object data integrity at a per product level. But at the same time, you also want to, you know, attach other values or other object metadata to that product. So in cases like order details, product purchases, very complex customer interactions, right? This is the array of objects is our most complicated data structure and it has the most power in terms of preserving those, you know, very specific object level for each object property relationships.

So you can build again AP side with direct CM schemas and then have manifest into CGA depending on the application and the use cases for your, you know, your data needs and your analysis and reporting purposes. So just to cover in more depth, the flat schema one. So what happened in CGA is even though you have data that, you know, from a data model and schema perspective might be nested, right? So in the use case of one works, it’s certainly a nested object. It’s not flattened entirely or the most flat view, right? What CGA does is it has a flattening process. So it creates components while maintaining the same hierarchical relationship that you’ve constructed with your data model and your schema in AP. And it uses what’s called a dot notation process. So the original structure is preserved and it allows for this lineage to your data model and your schema at the same time. Since this is an array is not an array, it’s not an array of objects. This is just flattened and kind of maintained at the same level for, you know, analysis, you know, general analysis purposes as captured in the event. So this the multilevel analysis here, right? We have different aspects to this, you know, customer profile schema here, you know, and then there’s a user metrics, further nesting of it. And then we have the actual like specific values that we capture, right? And so in this case, like preference score high would be a dimension engagement value would be a metric and the visitor rank would be a dimension. And these are all at the same level, right? So there’s no like sub levels or hierarchy per se, because they’re all just kind of captured through this flattening process with the maintenance of the dot notation and original structure at the component ID level in CJA. So this is a good example of I think that the most typical use cases, these will be the foundation for most of your components in CJA, but certainly important to understand kind of how it’s constructed and how the flattening process works and the ramifications through from AP to CJA.

So now we’ll get into arrays. And we have the two cases that we covered before, right? We have simple arrays. These are when we just have essentially a list of multiple values. So this particular example is like a category array. That’s a very common use case. Essentially, each array and element can become an individual dimension for analysis. And they will pertain kind of on an individual basis, you know, against as captured that given event. So certainly use cases for this, depending on, you know, your, your setup and your AP data structure, but important to understand, like when this kind of application should be applied and come into play. And then again, we had the most complicated one, right? The array of objects that we discussed before, right? And so this is where order details at a product level, where we have very specific requirements around maintaining the data integrity of, you know, the specific aspects of interactions with the product, right? In this case, someone is, you know, purchasing a headphones, a purchasing to quantity at a price of 149.99. We also have some metadata around that specific product itself. And so this allows for you to have like multiple, multiple related dimension. But like each object property is maintained as its own dimension and has preserving kind of sub relationships to the additional array of object elements that we’ve captured here. So really understanding when do you play these kind of, you know, uniquely per the use case. And again, upstream in your AP schema and your AP data sets is really important and critical because it plays a huge role and then how you can work with it and how you can shape it in CJA.

Moving on to CJA and kind of the implications here, there’s really three kind of currently supported types of analysis in terms of levels of analysis in CJA. And so covering these, there’s the event level, right? So this is individual interactions or touch points with specific timestamps per each event. Typically, these will be, you know, your page views, your purchase events, form interactions, you know, very specific interactions, you know, per event row, per timestamp level analysis, right? And so this is really the granular building block of how you do customer behavior analysis in CJA. A level up from that is really the cohesive collection of related events for a given person on a defined session basis. So this will group, you know, sequences of interactions that per your, you know, data view settings are, you know, what collect into a given session for a given person. And that’s what combines to make, you know, specific session level analysis available.

Then further up from that, again, is that person level view.

Aggregating all the activity for a given person by their sessions and the events that make up those sessions to that individual person ID in CJA. So that really provides a complete spectrum of, you know, behavioral analysis and patterns that you can analyze in CJA. So just visually to show this, we have the event that is then nested into the session, the collection of events make up the session, and then that collection of sessions makes up the person. And that’s really the three levels of today we support in CJA that you could perform analysis on.

So just to tie everything together, we have this whole life cycle rate of XCM schema transformation where we have the AP raw data. That’s again, their starting point for our data model and our schemas and the data sets. And that could encompass, right, those flat data structures, arrays and array of objects that we covered. Then we have the AP to CJA transformation process. That’s the system that processes the data through with the transformation while preserving those relationships and data integrity that you established in your kind of AP source data sets. Then that is turned into a CJA connection, right, which is the transformed data sets, you know, unioned and brought into a single connection. Thus enabling multi-level analysis. And then we have the data view level, which is essentially just a view against a given connection that analysis performed using those three main container levels. So the event, session and person container levels that we just covered.

So just visually kind of to show it, you know, it starts really on the upper left where we have that raw data. And just to touch on again, we have in some cases where the data model is, you know, containerized at a level where it can be flat processed. And it just kind of works and it’s, you know, kind of straightforwardly one to one transformed right at that data schema into a data set and CJA connection level. Then we have arrays, right, and an array of objects. And that’s where that relationship preservation is a bit more complicated, but it’s still maintained and still manifests from, you know, as constructed in AP in your XDM through to your CJA connections and your data views. And then the right side, again, is just that data view level, right, where we have all our configured components at a dimension and metrics level from, you know, the AP source data sets that we’ve set up on that left side. And then that manifests in the container level structure that we have with events, sessions and persons. And you can see we have that nesting relationship, right, where events are within the most granular building blocks are kind of by themselves. But then in sessions, they are made up of collections of events and then persons are made up of collections of sessions underlying that, you know, on an event basis. And really, then we end up with that CJA analysis context that is very important and very critical to our understandings for, you know, utilizing the platform in an optimal way.

So just some strategies for handling arrays in CJA given kind of the constraints that we have with the container levels as well as from a data modeling perspective. So, you know, you can filter, you can use standalone filters when you have an array dimension as kind of the main element that you do in your analysis. There’s also really powerful capabilities potentially with the right fields. So you can create custom fields and have custom transformation rules for very specific array elements and turn those into individual components per your analysis needs. You can also stack components. So you can combine multiple dimensions and have like this composite analysis in your freeform tables when you have arrays. There are some just constraints or limitations to be aware of, though, and it’s really that like individual elements when you’re working with arrays have to be filtered individually, right? There’s limited conditional logic that will work across array elements on kind of a variable basis. And there’s not really native like array specific operators at this time. So just be mindful when you’re using that array data structure in AP kind of the reporting and analysis implications of what you have to work with in CJA just because there’s not really like cross element analysis capable within arrays. You kind of have to work with each individual element in of itself and then, you know, work through your use case that way. So again, leverage derived fields, potentially calculated metrics in some cases, sequential segmentation is also pretty powerful here, but really just use your workspace components creatively and have an understanding of, oh, I’m actually, you know, I’m dealing with an array data structure in this use case. So I have to be mindful of the implications of that, of how that’s coming into play per my container levels that I’m working with in CJA.

And then just as far as like overall implementation best practices, you know, really choose the scheme types that work best for you from a complexity standpoint per your analysis requirements, like making sure that you preserve those relationships between each element in the right way. And again, have that line of sight to once it actually makes it to CJA and is turned into the component. And as a building block that you can use in your analysis, how is that actually going to be usable and understandable and relatable to these cases that you have for your reporting and analysis requirements? I think a lot of upfront planning really needs to be kind of on the architecture side, right? So really consider the trade offs in your data structure complexity. I think, again, it’s great to have container level understandings of like how this will manifest when you’re building those schemas and those data sets in AP through to CJA. And if you need like kind of hierarchical connectivity, just be aware of those analysis implications, right, that we covered in the array and the array of objects use cases. And really, so it’s a balance, right? There’s a balance between the analytical capabilities with kind of data structure constraints, right? So maybe the data structure is coming in a certain way or at source is constructed a certain way. And so just be aware of those constraints and understand kind of the techniques and when to use native dimensions versus maybe some derived field or component level parsing of certain values or elements in your data schemas. And really, I think also just future scalability is important, right? So make sure that you’re designing data models that both need immediate needs, but also meet their future growth. So I think being iterative and maintaining flexibility as much as possible is a really key aspect of best practices around your AP and CJA implementation long term.

So just ending on some takeaways, really, I think understanding just the flat schema structure is where everyone should start off with. I wouldn’t tackle or cover complex arrays, but if I didn’t need that use case or array of objects, I think they’re really powerful. But at the same time, they’re really for advanced use cases and implementations. And just understanding the flatting process in and of itself is a very critical aspect of maintaining the right mindset and operating principles from AP to CJA. Again, extensibility is huge, right? Make sure your schemas can grow with additional fields and objects in the right way. Make sure that you version your schemas so that there’s not conflicts or major issues when you evolve them over time. I think complexity is one of those tricky aspects that you have to balance, right? But using the simplest schema that meets your requirements, but at the same time, sometimes complexity is required. So just optimize for your specific use cases. Huge one that we covered extensively, right? How will that data model perform across different event, session and person container levels, right? Those are the three main analysis levels that we have to work with in CJA. So just understand the implications of those capabilities on reporting performance and working with the source data is huge, right? And then also just plan for the limitations, right? Understand what the current array handling constraints are. Understand when I use an array of objects and I have a very specific analysis use case, how can that be performed in CJA? And really just design with flexibility in mind about how you can do the right reporting and analysis given the current platform capabilities. And then lastly, just establish clear policies for schema changes and governance and documentation. I think that’s also really critical, especially for your most complicated use cases. Having just that organization wide awareness of when to use certain aspects of the data in specific ways or when kind of more complicated nuances come up is a really critical aspect for, you know, optimal usage and correct reporting performance and accuracy.

All right. And with that, I think we’ll move on to Q&A.

Thank you, Brian. That was a great explanation of the different data types and how to work with them in CJA. Let’s take a few minutes for questions. If you have questions for Brian, go ahead and pop them in the Q&A chat now. But we already got some that come in. So Brian, in analytics, costs were based on server calls and multiple report suites or virtual suites did not add costs. In CJA, does having multiple data views on the same data set affect costs? Yeah, so that’s a great question. So CJA operates from a license rose basis off of your connections, not off the data views. So you can, data views kind of are akin to what virtual report suites were for Adobe Analytics. There’s no additional cost to them and you can have multiple data views off the same connection, again, at no additional cost. The costs in terms of what your license and what the billing metrics are against are entirely based off of the rose that you bring into a given connection. And you can all have different connections for different use cases, different data views spun out of those. But on a data view basis, there’s no additional cost to data views themselves.

Awesome. So two arrays, question about that. How do you code array of objects in the form of a data element? Yeah, so that’s going to depend on, again, what your specific implementation is like. But from an XDM standpoint, there’s basically just affordances in the XDM schema definition and the kind of design language on XDM where you define an object, you define an array. And then as such, you basically populate that data structure against it as such. That’s how that works.

Got it. Here’s the foundational one for you, Brian. So the question is, it’s AEP or Experience Platform that acts as a single source for CJA to work, meaning all data is spread across different data sets that need to be ingested into AEP to analyze in CJA. Is that correct? That’s correct. Yeah. So CJA sources all of its data sets in terms of what is composed within that connection from AEP. So the data sets have to live in AEP first, and then they kind of make it their way through the connection process to CJA and the CJA lake house. But they do have to be established in AEP first. The data structures have to be defined AEP side and then data populated against the schema’s AEP side and then brought over to CJA. So they do have to kind of exist first in AEP, which provides a lot of opportunity for transformation or if you need to do data manipulation AEP side before you ready it for usage in CJA. That’s possible kind of to do offsite from CJA, so to say. Yeah. And there’s a follow up for that question. So would that also mean that a person needs to have some level of knowledge in AEP to use CJA? So really this depends on kind of what your role is. If you are and I have some blogs I wrote about this, both the crash course for analysts and crash course for CJA product admins. So if you’re just an analyst and you kind of don’t have access to some of the administrative functions or the configuration or integration functions, you’re really just day to day involved with building projects, building workspaces, providing analysis, findings, performance reviews. I think it’s good to have some knowledge of AEP just so you can kind of speak the same language as the rest of your team, but you won’t be necessarily kind of in the inner workings of the configuration or the integration across AEP and the connections and the data view management. If you’re a CJA admin, even if you’re only kind of involved CJA side with connection configuration and data view set up, those are your primary kind of functions as a product admin for CJA, I’d say. It’s still good to have AEP knowledge. Obviously, depending on your team, you may work across both. You may have other team members that are more focused on AEP and then you kind of partner with them. You may do some of the work directly and then see through it both on AEP and CJA. But yeah, I feel like foundational knowledge is really good in this case just because the connection and being able to bridge those two is so important as well as just for future project and evolution of your implementation. So definitely would recommend having understandings and working with those team members if you have people that are dedicated there to make sure you’re aligned and speaking the same language across your implementation. Yeah, absolutely. So follow up to that here is another question. So what resources would you recommend for mastering a flat data schema? So flat data schema is really the most straightforward one. I think it’s one that probably people have most familiarity with from kind of like a web analytics background. In that case, it’s really just determining what should be a dimension, what should be a metric. And CJA affords a lot of flexibility there because it’s at report time determined based on your data view component configuration settings.

And really, if you don’t need the complexity of arrays or arrays of objects, you don’t need to go there. And I mentioned that in the webinar. So there’s a ton that you can do just with the flat schema to get really powerful reporting. A lot of the work there is really just front loaded on in terms of when you trigger those events, what they’re composed of, the sequence of them in relation to each other, that type of information. Obviously, what values you hydrate or set in those dimensions and metrics as well. But those are really the key points. If you don’t need to go to the level of complexity to some of the more advanced use cases, there’s still a ton you can do there. And there’s still a lot of value that you can drive through that level of schema support. Yeah. So what are your thoughts about customers using a global schema for CJA? Can they do that? Yeah, that works potentially really well depending on your use cases and the data set you bring in. If you have like a unified combined notion of your content map, so to say, and various levels to it or the hierarchy of your content, and that can be applied across different platform contexts or web versus mobile versus other contexts, that could really work well. Obviously, CJA thrives and it’s really powerful when it has common schema language across different data sets, certainly on an identity basis that’s critical as much as possible. And then in other cases, if there’s commonality across being able to set a dimension that contextually can carry across data sets in different contexts for where that data is captured, then by all means, that’s the best course of action. Because then in CJA, you’ll be able to, you know, as a unifying, you know, analytics solution across those touch points and across those data sets, that’s a really powerful aspect of the solution. So definitely try and do that as much as you can where it makes sense. OK, here is a reporting question. So analytics, unique visitors and CJA people metric are not tracked the same. So looking at year over year data can be tricky since CJA can count people uniquely across device interactions, whereas analytics counted, you know, cross device interactions as different visitors. Is there a percent difference benchmark to gauge? So this is one of those ones where it really depends on the specifics of your implementation. The reason why is because CJA on a data set basis as you bring it into a connection relies on a declared person identifier.

So that person identifier, if we’re talking like Web data, could be your ECID and then therefore could match relatively closely to your web analytics data set. However, if you’re moving or you have other data sets that are more based off of like authenticated or known users and type of authenticated user ID or customer ID, there could be some big differences depending on, again, the nature of the declared data sets that you bring in versus like what you’re comparing them to. And that’s how the person accounting can differ from like unique visitor accounting in those cases, especially if CJA contains more data sets that have more people declared and you know, you need on a person basis to people versus, you know, kind of a source data set in isolation. So the way you can check this is you can actually run you can run checks AP side since those data sets have to live in AP can use query service. And you can do you can basically do like counting accounting of, you know, for a given time period. But, you know, is the is the identifier present given that I’m going to declare it as such against that data set in CJA? And then that’ll give you a sense of like the overall counts. And then you can compare to Adobe Analytics. If you’re just comparing like an Adobe Analytics report, sweet weather, the looks data set to what exactly that same data should be in CJA. The best metric to actually compare to is your events data, because there could be differences in session ization or again, person declaration, like I just covered that just aren’t going to be inherent to, you know, CJA calculating things differently in the economy differences. There’s also some other product differences. But yeah, the event spaces, you know, because events are composed, that actually gives you the best sense. Oh, am I dropping events? Is there some difference in terms of the coverage of events? Those type of factors are really good to look into for sure if that’s something you want to kind of baseline against. Yeah, that’s a that’s, that’s a great idea, especially using query service potentially to validate data set. Yes, yeah, that’s a huge one that it’s not available for Adobe Analytics, but it is for CJA and AP and just having that option and tool in your toolkit, I think opens up a ton for investigations. Actually, I mentioned that as a CJA product admin, it’s a great skill set to build up and have in your arsenal. Yeah, absolutely. Another one as far as comparing analytics to CJA. So in analytics, there is a finding product method. Can we also implement finding product method in CJA? There is there’s an equivalent. It actually works very similarly. And it’s something that you can determine at at the component layer level in your data view settings per component. So it’s a it’s like a binding mechanism that works the same way. And if you have product finding methods, where it products, the product string Adobe Analytics essentially was an array, the only array actually in Adobe Analytics available to use. You can function the same way in CJA. So there is kind of like light for light functionality, but it’s even more powerful because it’s kind of at report time determined. So you can kind of configure things post your implementation settings. And since you have more array options available to you, array of object options available to you, you can set it in more places and have it work in more places, depending on how your data is structured. So yes, that is one that has kind of CJA fashion equivalent is like how I like to phrase it. But that is an option. And it works really powerfully similar to how probably that can be in Adobe Analytics. That’s great to know. Um, does it make a difference while defining an object and data collection if a business is using the analytics data layer or a CDL versus a different end? Is there any difference in defining schemas? Um, I think it they should be fairly equivalent. Like, I, again, it depends on exactly what the use case is. So it’s hard to give a blanket statement around that. But I Yeah, as long as you’re able to define it and have it translate and come through with, you know, the right values set against how you want to track your data, then I feel like it should operate the same way. Yeah, but that’s that’s a tough one to kind of, yeah, blank.

Yeah. Um, okay, so this and this is kind of a how to organize our data. So considering license usage, if what is better, if I have three data sets, data set A, B and C, is it better to create two connections? So connection A, B and connection B, C, or create a single one and then segmenting through data view capabilities? Yeah, so this is really an exercise and just kind of use case vetting, I’d say, because it really just depends like how coherent are those data sets if they are union together? And does it make sense to have them in the same connection working against each other unions in the same way and having obviously, the data view basis be based off of a connection that contains, you know, B or C or A or B, whatever the combination thereof is. You are, again, the licensing is based off a connection. So if you have redundant connection, so to say, where you have A and B, one connection, B and C and another, you know, since the connection basis is the licensing, definitely, you know, the basis for the licensing, you know, that would be the basis of it. So I always recommend people try and get by with kind of as few connections as possible. Obviously, that’s very use case dependent, you may need to stand up data sets and multiple connections that live in multiple connections. And there’s valid use cases for that. But I would rely on on the power of data views. And again, only bring in the data to a given connection, you know, if it has utility and value from a unioning standpoint, foremost. Yeah, that makes sense. For sure. We have time, I think maybe for one last quick answer. So for CJA B2B edition, if we’re logged in using if we’re using a logged in ID as the primary key, how far back can we expect the hits to be stitched for a user who was previously anonymous, and then became known by logging in since the EC ID persists for some time. But how long does the hit data persist for stitching? So the way so I guess I’ll answer this in two parts. So there’s there’s person based stitching, which I’ll tell you, I know this is a B2B specific question that has two different flavors field based and graph based. There’s basically different frequency and look back window principles behind that. That’s and I have a blog post that goes into this again for the person based method. That’s how that’s determined. B2B will work in similar fashion. I think it’s to be determined exactly what those options are. But I know for a fact that they are definitely looking at longer windows just due to the nature of the B2B buyer and consideration process, as well as for attribution to same handling. So there will be some affordances that allow for a longer window for those type of use cases, I would say overall, for sure. Cool. Well, we will look forward to that. Thank you so much, Brian, for spending time with us today. Yeah, no, thanks for having me. Great to see everyone. Thank you.