蜜豆视频

Transcript

Okay, while people are entering the session, welcome everyone. and good morning. Hello, actually, I don鈥檛 know what鈥檚 the time.

However, thank you for joining today鈥檚 session, Telespace Adam Best Practices for Analytics and CJ Immigration. My name is Nicole Napicone and I work as field engineer in 蜜豆视频. With my team, we work closely with 蜜豆视频 customers to have them use 蜜豆视频 solutions and let鈥檚 say use everything they can in order to fulfill their requirements.

So first, thank you again for taking time to be with us. And just a quick note before the meeting starts, today鈥檚 session is being recorded and a link to the recording will be sent to you after the session is ended. Also, this is a listen-only webinar, so you can do questions, of course, in the chat and we will have a question and answer, let鈥檚 say, section in the webinar in the last 15 minutes so we can start to cover your questions. But of course, feel free to come back to us if you have additional questions after the webinar. So in this slide, in the slide Maricie is showing, you can see that we have other webinars in our calendar. I will pass the link in the chat so you can register to respond to these are all led by our colleagues. And as you can see, there is a lot of focus on CGA. So let me take the link.

Okay, these are for the first three and the other.

Other webinars have been held and you can watch the recording of course, they are even, let鈥檚 say, published on the 蜜豆视频 documentation if you can search for webinars so you can retrieve all the webinars too. So today鈥檚 session has been prepared by my colleague, my dear colleague Maurizio, he works with me in the 蜜豆视频 Ultimate Success team. So in this slide that is presented a little what the Ultimate Success team does with 蜜豆视频 customers. So Ultimate Success is 蜜豆视频鈥檚 engagement model designed to ensure our customers to achieve their most critical business outcome through the usage of 蜜豆视频 solution. So our team works hand in hand and let鈥檚 say it鈥檚 the best step with the customer that purchase the 蜜豆视频 solution and help them have a high value realization through the usage of this tool. So as part of that model of the Ultimate Success, we offer Success Accelerators. These are specialized services aimed to jump or accelerating progress towards customer business goal. So Ultimate Success and Accelerator provide a partnership combined with some actionable solutions, solution troubleshooting, solution review, migration readiness, et cetera, in order to, let鈥檚 say, focus on the customer specific business request and specific, let鈥檚 say, moment in time that needs to be addressed. Okay.

Let鈥檚 wait for other that we can kick off the session and I leave the word at the presentation to Maurizio.

Thank you very much, Nico. So let鈥檚 wait a minute or two and then we can start. Meanwhile, I鈥檓 sharing today鈥檚 agenda and the migration from analytics to CJA is really an interesting, long journey. So we鈥檒l try to keep on a high level, not giving too much technical detail, but for sure we need to discuss a little bit on multiple levels, business, technical ones. So we鈥檒l try to keep and leave sometimes at the end of the session at least 10 minutes for your questions.

But yeah, one minute more and then we can start.

Okay, I think we could start.

And as said, this is our today鈥檚 agenda and we will start with an overview on what CJA is and how it works. Then we鈥檒l spend some time talking about the teaching feature of Experience Platform and CJA.

Then we will focus our core topic today is for migration readiness. So what to do and which are the best practices to be ready to run this migration.

And we鈥檒l spend some minutes discussing three main use cases. And the last part of the presentation will cover how to import and best practices on how to manage and import historical data, the ones that are still in analytics and need to be available in CJA too. Okay, so let鈥檚 start with what CJA is and how it works. So CJA could be usually presented as an evolution of 蜜豆视频 Analytics, but it鈥檚 much more than this. Actually, we have the powerful abilities of the workspace. We could create powerful reports and focus our analysis on data collected from multiple touch points. And this is the main reason why CJA is much more different from analytics. We will see the main difference in a while, but for now let鈥檚 focus on the idea that Customer Journey Analytics is focusing not on the single track event, but on the full journey of our user, of our customer. So not only a single touch point, but we could combine data that came from many different touch points, such as the mobile devices, web, but also totem or call center or your CRM or anything else that could share their data. And all this information will be bringing together, merged together in order to give you the chance to see the whole journey of our customers and users between all these multiple touch points.

And yeah, as said, we have the powerful workspace based on the same interface we already know from analytics, but the data inside this workspace will came from all the multiple touch point linked together with the merge tool and feature we鈥檒l discuss later on. And so we could, for example, create a different report and analyze these more data from many different point of view, focusing on different part of the journey or different information, such as the one that came from the devices or the one that came from CRM or just cross the two of them.

So this is a very high level architecture on how CGA works and it鈥檚 implemented. On your left side, you will see the data that need to be ingested inside the platform. And you can also appreciate here the very first and main difference between analytics and CGA. In analytics, data came from our sources directly into the repursuit, one multiple repursuit, doesn鈥檛 matter, but are ingested directly inside analytics tool. Here, CGA is not the real target of this ingestion of the data. Data aims to the platform and they could came from many different point, as said, could be from client via SDK, mobile, web, or via server side via API, but could also came from third party data lakes. When the data came inside the platform, they will be stored in a agnostic high level structure of data inside the data lake and here will be sent to CGA via connections. So when we move to CGA, we create a live copy of data from the data lake, from the data inside the platform and these data are just re-engineered, re-thinked about many different point of views according to the business need. And so we will discuss later on what are connections, what are data views, and how this data could be analyzed in order to answer to business requirement that are our main focus. But to be a little more precise, we can imagine of data that flows one by one to the repursuit in analytics and so this could create a hard to implement way to analyze cross devices or cross platform data, while in CGA, all the data collected will flow directly in more specific environment and mixed together.

Another main point of analysis between the, to analyze the difference between analytics and CGA are how the data are processed. We already know that analytics collect those data, the data before being written inside the repursuit are passed through different rules, visitor rule, processing rule, marketing channel processing rule, and when all those algorithms end their live, the data is carved in the stone of the repursuit and cannot be manipulated. These are the main difference. Customer journey analytics is processing the data at the same time you run the report itself because the source of the data are totally agnostic, are a copy of the data lake data and can be manipulated and reprocessed at the same time you are running a report and you could also change the structure of these data views and I鈥檒l show you how in a very short way. So some new terms and concept and some difference between the terminology. So we got brand new ideas and concepts such as the data schema and the data set that have not a real one in analytics and then we have the data views that can be, think about the way we are looking at the data. So could be the virtual repursuit, then we got the component and this component of the one we find also in the structure of the repursuit or virtual repursuit. So meaning dimensions, matrix, segments, and so on and the main terminology changed about the different containers. We used to think about a hit, visit, and visitor in analytics and now this concept are migrated to event, session, and person.

So let鈥檚 start talking about the identity services. So how these information are merged together when they came from a different kind of sources. We know that analytics is based on the ACID or first party ID and this is the main identifier that allows us to reconstiliate the tracking data that came from different server calls so we can know that a specific user based on his cookie has visited a specific page, clicked on the CTA, streamed the video, and so on.

We could use the same concept also in CGA. We could have the same kind of analysis based on this single cookie ID but the most powerful feature of CGA is that we can choose a different ID that will merge together data that came from different sources.

So how it works, CGA. We will start and mention the agnostic schema of data that is based on the XDM schema. You can see here an example in this schema, these are the ones that are the main base of the dataset and inside those dataset we will have a structure and an agnostic structure of data fields, field groups mixing our, for example, reusable building blocks that can be added to multiple schema in order to extend the functionality. So for example, we could include customer demographics or purchase details or behavioral data and we can combine all together.

And this is the part inside the platform. Then moving to CGA, we start creating connection and connection allows us to merge together different datasets. The tricky part is to find a common ID that allows us to merge this data but we can have a specific dataset, for example, from the data that came from the web, another dataset based on the CRM data or call center data and so on. Once we merge together all the dataset and we create a connection, we import the data from the data lake to CGA we have already pursued it if you prefer. These data views can be one, two, multiple and can be manipulated in real time directly by you before showing this data inside the workspace, for example. And this is the magic of CGA. We can change the settings of the data views on already collected data because the data are agnostic and are stored in the data lake, not in CGA directly. So we could just change the structure on the fly.

And once we are happy with our data views, we can move to the reporting area, we can use the workspaces, we can create a mobile scorecard or we can extract those data, send data, share data, export PDF, export to BI or use the report builder.

Okay, let鈥檚 move to the stitching concept. And we need to make a distinguish between the stitching inside AP and CGA. So in AP, stitching allows us to create a refined profile. So every time new data comes to the platform, these fragments of data could be stitched together thanks to this feature and create a combined profile of all those fragments that came from different sources. In CGA, we talk about a merge of two or more data sets. So once we found and we choose a person ID, so a strong identifier that is commonly known for each row of each data set, we can merge together this data and create this whole huge journey. But for sure, not every time we have a strong ID inside every single row. And this is why we have inside the platform the field basis or graph-based stitching. Field-based is as said, based on the field and it鈥檚 deterministic and it depends on having a strong ID on each row.

Otherwise, we can move to graph-based that is both deterministic and probabilistic. And it鈥檚 really useful for complex and cross-channel device journeys because the platform try to recognize the user and merge together, stitch together those fragments.

And this feature, reply backfill, is really powerful and make really the difference between analytics. You know, for example, that when a user in analytics surf our website via AC ID anonymous identifier and then proceed with the login and a new ID is set, for example, a first-party ID, we could be struggled trying to find a way to merge together this information because the ID is changed. Reply backfill in CJA allows us to recover this information in the previous rows, in the previous record and stitch together the same user after the login with the anonymous one.

And here you can see the two different stitching, the field-based and graph-based and all the elements will be stitched together in this graph-like interface. Really useful to understand which kind of identifier makes the profile itself.

Okay, so this basically ends our session on an overview of CJA and we can move to what we have to do to be ready to migrate our analytics to CJA. So we mentioned a lot of time and for sure you already understood that the identity is the most important part because we need to be sure to have a specific strong identity identifier that will be available on each data set in order to create the merge. So the person ID need to be strong, available and for sure does not have any PII.

So hashing PII data could be a good idea and we need to be sure that the ID will be same format, same length and strong enough to be present everywhere.

Second phase, we need to align variables, dimensions and matrix. So when we move to analytics to CJA, one of the main concern is to have the same EVAR, props, events inside CJA but this is not how it works in CJA. So first of all, we need to have a strong map of the structure of our report suites and if we have a multiple report suite, be sure that the structure is the same, otherwise we could think about a gray period in which we are moving the structure of one of the report suite in order to align them all or we can move to the data prep feature in order to map variables when they are mapped to the XDM schema in order to have the proper data from the different sources to the right field inside the schema and this is also the good point where to mention that the low traffic issue in analytics, we don鈥檛 have this limitation in CJA.

Marketing channel are another really big topic and there鈥檚 a lot to say so we can spend too much time on this one but I want to focus on two, three crucial topics around the marketing channel implementation. First of all, in CJA, we will not have anymore the first page of visit function because we don鈥檛 know exactly when the first page is visited because we talk about the first hit of a session and the session itself can be manipulated. You know that in analytics report suite, this visit lists 30 minutes of an activity.

In CJA, this limit could be changed according to the business needs. It could be reduced or could be expanded.

Another main is the override last channel feature that can be unchecked in analytics. We used to uncheck this feature for direct channel, for example, or to internal traffic. We don鈥檛 have this feature anymore. I will show you how the marketing channel will be configured in a minute or two but we have some work around and one of these is to add some flag field in order to recognize traffic that came from internal referral, for example. But the main reason is that we need to think within the business team if this feature is really useful or not.

Does they really matter to know how many conversion event can be related to internal traffic? Usually the main one are paid search, social media, natural search, and so on. So this is one of the reason why the marketing channel are changing in the last years.

And also the expiration is handled in a different way. We say that marketing channel are processed via marketing channel processing rule. Every single hit before being written side reposuit is passed through the algorithm of the marketing channel processing rule and every single hit is associated to a specific channel. We don鈥檛 have this limitation anymore because we can focus on many different aspects of our customer journeys. So we could change the way we think of the attribution of the marketing channels. And these channels will be managed via the rapid field. And we鈥檒l talk about that in a second.

One of the most important thing and one of the main reason why analytics and CJA cannot be 100% equal is that the report time processing of the CJA. We already mentioned this. We don鈥檛 have any data carved in the stone in CJA, but thanks to the backfill stitching, for example, the visitors could change during time as soon as the backfill job runs. And it could be run once a day, once a week, it depends on the business need. But this is one of the reason why we could have different value for the number of person in CJA from unique visitor in analytics. We need to choose a acceptable range of this delta.

Usually 10% is acceptable about page views, for example, based on a specific touchpoint or during the funnel, 10% is commonly an acceptable range.

After that, we need to identify the segments and the calculated matrix that are really critical inside our analysis in analytics, because most of them could not be totally compatible with CJA. So we need to focus on the business need again, and again, focus on the needs. And then we need to recreate the most critical component, define the definition, and then recreate them in CJA according to the new needs. And this is also a good idea to eliminate and delete old component that are not really useful anymore in order to have a clean starting point with CJA.

Okay, let鈥檚 move to three main use cases we identified for the migration. And the first one is the migration from the legacy implementation. So we have the app measurement library deployed in our environment.

We need to migrate first to the Web SDK and then to CJA. The second use case will be, we already have a Web SDK implemented, but the XDM schema is mapped the same way we used to map even props directly setting one by one values with a reposuit structure component. And we needed to detach these one-to-one association and create an agnostic XDM schema in which store our data that will be the base of our new component in CJA. The last case is the most beautiful one, more easy one, is starting with an already agnostic XDM schema.

We used to have this implementation, for example, for mobile SDK in which you use to map the context variable to the EVAR props in the event via processing rule, the reposuit processing rule, but we could have also this in the Web SDK.

In that case, we are sending a data object with an agnostic payload, keys and values, and these keys will be mapped via processing rule to the reposuit component. In that case, most of the job is already done. We already have the XDM schema. We for sure have to review just to be sure that everything is fine, but then we can move directly to CJA and start creating the data views. So these are the main steps in detail of what we have to do to run this migration process. And in the first column, I just reported the list of the three different use cases, because not all of the steps are needed for all the use cases, but you can just see in the schema below which step are needed for each of them. So let鈥檚 start with the planning phase. We need to create a solution design that contains every dimension and matrix we will need inside our new environment. And this is a good starting point to review the component and map the component starting from the data layer as a state of true of our page, of our environment. We could map this structure in the new XDM schema. Once these steps are done, we could create the schema or multiple schema if we have multiple touchpoints and not compatible between them.

Usually we suggest to create an tenant object in which store the whole data layer data as a state of truth that we pass through to the platform, to our connections.

And if we needed to migrate the historical data from analytics, we also need to add the analytics experience event field group in order to map the old data to the new schema.

Let鈥檚 move on. Create the event data set based on XDM schema or to a CSV if you already have this kind of file available. Configure the data stream, creating your data stream if you don鈥檛 have one, if you are migrating from legacy to Web SDK or modify the data stream and add the platform as service, configure data set and XDM schema. Then best practices says better to use launch, former launch tags and configure the extension to map all the settings and configure the communication between the mobile or Web SDK to track data. But for sure, if you have a different tag manager, you could use your own. It鈥檚 not mandatory, it鈥檚 suggested, but not mandatory said.

With that done, we have to deploy the alloy.js library that could be done again via to tags extension or directly via JavaScript.

One final suggestion inside our touchpoint, if you already have triggers that files rule to send data to analytics, best to use the very same rules and trigger to fire data to the platform, from the platform to CGA, because this reduce the gap between the data collected from analytics to CGA. If we implemented different kind of rules, different kind of triggers, it could be really tricky to be sure that all the data will be sent to the platform. Will be similar.

And now we can move to CGA finally, and then we have to create connection, define the data views, configure the component inside the data views. If we have, we could migrate all the analytics project or spaces to CGA, remapping them. And finally, don鈥檛 forget to define the constant management, the user assets management inside the admin console. So this is a very high level list of steps, but now I show you best practices for the main of them. So this is, for example, a template to create a solution design. This is a schema we could follow.

Focus on the object, a description that could be really readable and understandable for everyone that need to get access to the solution design, a reference of the data layer, so we can say every time we can know where to find the source of data, and a mapping in the XDM schema. And then where we should find this information and some reference to where this information were inside analytics.

This is a solution design template. Ask your professional services mate, and it will provide a copy of this template.

Okay, then moving to XDM schema, we need to create a new schema. We could have different kinds of schema. The main, the most common one is the haven鈥檛 experienced event schema that is mainly event as we are collecting them to analytics user doing something is an event, a page view, a link click, a download, are these all event, but we could have a profile schema to collect information of the users or different kinds of schema, such as the lookup that are very similar to the idea or we were working on with the classifications in analytics. So for example, tracking code or product IDs and so on. And this is how the schema appears with a list of nodes and sub node where all these data will be stored.

Okay, this is an example of storing a page name information, a string inside an object, the name and the page info, and all these are inside the underscore tenant object as mentioned before.

Once that moving to the create a data set and you could choose to create one or multiple data set. It depends on if these data are compatible or really different between them. So maybe we need better to have multiple data set, but for sure we must have the strong ID in order to create and the merge, the stitching inside the connection.

Once you create those data set, you could also choose in case you are importing data from outside, from a CRM, for example, or any third party, you could choose to enable or not also partial ingestion, choosing a percentage of threshold. So if for example, some of the data are not 100% available, the ingestion will not fail, but all the available data will be ingested in any case.

This slide referred to our best practices on using tags launch. And the important thing to know here is that we could enable the option to migrate the identity from the visitor ID service to the web SDK. Just remember that ECID in the web SDK implementation is not generated the client side by dedicated library, it is generated by the edge network once the server call is sent to it. And another main point is that we need to manage the consent in a different way respect we used to do with the legacy implementation. So we could manage the consent directly on each tool, analytics, target, visitor ID, and so on. Now we have an all or nothing manager.

So the consent could be alwed, blocked, or stay in pending if we are waiting for the user to upset our cookies, but if we need to manage the consent on different levels for different tracking, for example, I don鈥檛 need to ask consent for tracking purposes, but I need to get consent for personalization in target or to fire 30 part pixel marketing pixel tags. And so you could maybe implement a 30 part library to manage this or a custom one, doesn鈥檛 matter, but you need to manage these manually. And one of the option are to change the user ID the firing condition of each rules in order to have the rules for trackings, always firing, the information to be sent to target firing just if the user has upset the right level of consent, or you could not work on rule side, but on data stream side. So you could create multiple data streams and add different tools to the different data streams for example, platform procedure, yay, to all of them, target just to one of them, 30 part to one of them, or create some mix of these and then override the data stream ID based on the user consent. So for example, you could store the information in a data element in launch and then change the destination ID of your image server calls.

Once we create a CJX connection, we need to have clear in mind the analytical goals, because as we will see shortly, we can create multiple dimensions and change the setting of this dimension on the fly and manipulate the data. We can create them multiple times if needed, but we need to be focused on which are the targets we need to achieve. And then this could be useful to be set in the technical documentation. So in the business requirement section, for example, we need to be sure having the same identity or to define the strategies to merge these identities together.

The schema need to be consistent. So we need to have a clear naming convention in order to recognize the element鈥檚 name or structure, knowing where to find these information, because when we created the component, we will get access to the schema and we need to know where the information we need are stored. So for example, if I have to collect information about navigation, I for sure have to store page name, page type, for example, URL or profile, customer profile type, customer level, blah, blah, blah. I need to know where these information are stored.

Once you set the backfill, don鈥檛 start backfilling everything, but it could be really, really painful to manipulate. So let鈥檚 start with a short amount of time, one week, one month, for example, in order to validate those data and then scale on more historical data later on. You don鈥檛 have to be afraid of changing the backfill width window later on because the data are always there in the data lake. We are just changing how many days of those data we are saving inside CGA.

And so once we are ready, we can extend this backfill data range. And for sure, one of the main point is to be sure to make available of the marketers just the data they really need. So if they are working on marketing campaigns that require information on the last two month, we don鈥檛 have to ingest and import one here time date, for example. And so we can also create a multiple data views in a different backfill range.

And then, monitor it, iterate again and again and again. Always monitor it, those data, to be sure they are properly reflecting your needs.

CGA data views. So we can change the way these data views are set. So we could change which kind of data are available inside. We could create a data views with just a couple of dimensions. We could segregate this information to allow specific local team to get access to the data they need to get access, for example. Or you can create a different data views, one focused on the marketing channel and other based on the cross-channel information in order to have more data related to the profiles, for example.

We can always apply segment filters or change the duration of the sessions. We can also create a data view with extreme short or long sessions in order to have a specific focus on specific journeys, for example.

And for sure, we could also change the person ID in the different connections. If we have multiple data that came from the data lake and have different lengths on this kind of data.

Once we are going to create the component, you remember, for example, from the report, so that we are able to change the expiration of an Ivar. So we could say that a specific Ivar will expire as soon as the user convert. This example is common for the product variable and the purchase event.

Usually the expiration event is the end of the visit and we can keep this kind of implementation. But the powerful component creation process in CJA allows us to manipulate this information. And we can also add multiple times the same element, creating a multiple version of the same dimension and matrix and change both allocation and expiration settings. So for example, I can recreate the entries and exit matrix, entry page, exit page. I just have to put inside my dimensions area the page name and ask CJA to show me the first value or the last value of the session.

And we can also change the attribution. So we could manipulate with not standard allocation, the attribution of the matrix to the session. So I can set the first touch, last touch, participate, blah, blah, blah. And we can change these in the workspace exactly as we used to do in analytics, but we can also create a multiple version of the same matrix changing the attribution here in the data views creation.

And for allocation, and this is the magic, I can do the same for the variables, the dimension. So I could keep the most recent value, the first collected value. I could duplicate the same dimension multiple times and change the persistence of these information. So if I don鈥檛 apply any settings, I鈥檓 basically recreating the old traffic dimension. So I will see the value related to that dimension if this information reached the data lake in the same server call of the matrix I鈥檓 using into the data table. Otherwise I can change the persistence and have last, first, blah, blah, blah.

We cannot change this setting inside the workspace. We can change the setting just inside the data view settings, but we can change these even if the data view have been already saved, and if it鈥檚 already used for some reporting. So you can change on the fly the settings and see in no time how this reflect to your data inside your reports.

The private field, we mentioned talking about marketing channels, and here is where we talk a little bit more about this. The private field is a really powerful tool. We can create a new field starting from the data collected inside the data lake. We could apply a number of already out of the box template to create, for example, marketing channels, bounces, exit, download links, et cetera, et cetera. And we are available multiple functions. So case when concatenate, the duplicate, lowercase, we can manipulate those data and create a brand new dimension starting from the one you already have collected.

Almost done. If you need to import historical data, we can create a source connection inside the platform. And once that is done, we need to choose how many months of historical data we want to import starting from one month to a limit of 13 months. And these are the best practices before migrating historical data. So first of all, I need to validate the CJA data. How? I start collecting data in IP CJA. I will confront a couple of months of the collected data from CJA to analytics and see if we are inside the acceptable range of differences. And once that is done, we can activate the backfill of analytics data. If we work on a dev environment, it鈥檚 okay. We have less data, but it works pretty good. If we have worked on production environment to have a full range of data, we need to apply a filter segment in order to avoid seeing double data for the time of the two tools that were working together.

And if you need to migrate all the workspaces project, that you can do this, just mapping the old element from the reposuit structure to the new CJA schema. And most of them will be migrated automatically. The other ones will be mapped by you one by one, and then you鈥檙e good to go and open the old project inside CJA with the new data.

Almost there. Just to have a quick list of steps to run this migration, I won鈥檛 go through that. We already discussed it, but these are the main steps and which team should be in charge of covering it. And there鈥檚 one last thing to do once we are ready with a big goodbye to analytics.

Okay, in this presentation, you also find a quick appendix with some critical information, I don鈥檛 wanna go through that and we鈥檙e there.

Nico, do we have any questions? Okay, that was good. Not for now, if you have any questions, you can put into the chat.

So we can use these final minutes to answer.

Marica, sorry, if you can launch the poll section, it will be, yeah, thank you, in the meantime.

Okay.

Okay, so if you can please answer to these quick questions. And I think that if you don鈥檛 have further questions, so technical questions that we can analyze in this moment, I think we can say goodbye to you and we will share, of course, the deck and the link of the session.

So it鈥檚 just one minute to be on the stiff part and then we will close the event.

Meanwhile, let me thank you, all of you, for attending this webinar.

Okay, fine.

Okay, no other questions. So I think that we can close the session.

Wait, wait, wait, there鈥檚 a question.

How can we validate the historical data is completely loaded in CGA? Okay, it鈥檚 a long one. I鈥檒l answer in this slide. I鈥檒l add the slide for this question and you鈥檒l find in the final version of the deck.

But you have a monitor inside the platform, basically.

Thank you very much. Okay, thank you. And for the slide, yes, they will be available after the session, yes.

Okay. Thank you and have a nice evening, everyone.