AEP Web SDK Troubleshooting, Assurance, and Tips and Tricks
Join us for an insightful session with Garrett Hartley as we explore tips and tricks for troubleshooting common AEP Web SDK workflows. This session will guide you through key steps for validating your implementation and introduce effective troubleshooting methods to overcome common challenges.
Our primary focus will be on data collection for RTCDP and Adobe Analytics, while also addressing frequent issues with Target and Analytics implementations, Event Forwarding, and datastream mappings.
Whether you’re just beginning your migration to AEP Web SDK or are an experienced user, there’s something valuable here for everyone! Don’t miss out on this opportunity to enhance your skills and streamline your workflows.
Hello. Hello and welcome everyone. Thank you guys for joining today’s tech sessions. My name is your turn. And just a couple of housekeeping notes before I let our presenter take it away. We encourage and hope you all ask questions throughout the presentation. In the Q&A chat available in the right corner where the presenter speaking. However, rest assured that the last five minutes or so of the presentation are simply dedicated to answering any of your additional questions. Lastly, a link to this recording will be emailed in about 24 hours and will be available on Adobe’s Experience League website. To do wish to view it again or share it with your colleagues? Well, if there aren’t any further questions, I will go ahead and pass it to Garrett.
Okay. Thank you. Don. So excited to have everyone here today. I recognize some of these names in the chat. We’re going to be going over a bunch of different, you know, tips and tricks for troubleshooting web SDK.
You know, common issues, common flows. The different tools that are available to you.
And we’re going to be doing kind of a I think there will be something for everyone. It’ll be a little bit higher level. Like we’re not going to get into any specific use cases or, actually troubleshoot much stuff, but there’s going to be a lot of demoing. Sharing my screen and, excited to get into this. Just waiting for these slides to come up. And, after the after we do the presentation today. I’m going to have a additional resources document that’s going to have a lot of the documentation for what we’ll go over, as well as any of the code snippets that I share. I’m going to have those in there. So don’t worry too much about like taking too many notes. We’ll be able to get that information out to you after. And the follow up email. And I’m trying to think if there’s any other housekeeping.
We’re going to be going over different web flows as well as mobile flows for troubleshooting and if it if it doesn’t upload, then I can just share. Let me see if I can pull up the PowerPoint.
I could just pull up the PowerPoint and share. Oh, here it is. Okay, great.
So skip past this little mugshot.
Okay. So first we’re going to go through web data collection, the various logs that are available through assurance. And the debugger and kind of demoing how those are connected. Also going to look at capturing Har files, which is going to be the the client side receipts is kind of what I’m calling it. It’ll show all the network requests sent from the browser and before it gets to edge, because in the world of Edge and Web SDK, what you see from the client side is not so much what you get.
It’s going to hit edge and then it’s going to forward a request to the various downstream products from there. And assurance is going to be the big help for seeing that. Then that the Har file is going to be just the client side network requests. And then we’re going to go over a couple client side functions that are useful in troubleshooting with the satellite object, opt in all the way functions. Then we’re gonna look at mobile data collection logs. So those are your verbose SDK logs and assurance as well. We’re gonna I’m going to demo kind of like how you set that up. Not super in-depth, but more so to give you an idea of what’s involved, because I know a lot of people on the call aren’t going to be the mobile developers setting up those logs. But to give you an idea for the amount of work required to get them set up, and if if you don’t have a mobile team prepared to, to give you those logs when necessary. Now, and I encourage all of you to kind of like take this information to them and get that set up so that when you do need it, you’re you’re prepared to do that.
Then we’re going to look at just a couple tricks with data collection tags for looking at, the un minified satellite object, kind of how you can, you can poke and prod the satellite object to get more information. And then at the end, we’ll talk about a couple of the, edge flows that are unique to edge, like event forwarding. Some of the, target and analytics interactions, and how, how you can prevent bounce, increase and, things like that or decrease actually, that’s a problem people get when they migrate to web. Sometimes their target and analytics stuff.
Target hits will get sent to analytics and it’ll cause a big decrease in bounces. And app validation, all of those are just common kind of common issues that we come up that that come up and that we can help troubleshoot and support. And there’s good tools for troubleshooting. All right. So I kind of already I talked about these these logs.
Just to reiterate Har files are client side. And they used to be you know, in the world previous to edge, they would be as complete a picture as we could hope to see when troubleshooting. But now that the interact and collect calls that are being sent to edge don’t represent the exact hits sent to analytics or other downstream products. We need those assurance logs and it’s awesome that we have those. Those are going to show all of the actions taken server side, to get your data where it’s going downstream.
And I think we’re going to jump into into demoing this here. So on the screen, I’m, I’m going to show this in the demo, but on the right screenshot you can see how you download a Ha file. I’m going to I’ll demo that and also show you how you can view them in the browser. And then on the left that’s a general picture of what an assurance session looks like. You can see there’s these three columns with the these little cards in the middle. The first ones representing the hit received by by the server or sent to the server. Then the hit received an edge in the middle, and then the downstream products that that hit went to. So all of this would not be visible in a in a Ha file. But we’ve got assurance for doing that. And yeah, I’ll, I’ll share my screen and we will we’ll just kind of walk through what that looks like here.
Okay. So this is my silly demo site with all these. Oh it’s it’s not showing it here. Goodness. Okay, now, my silly demo site with all these old phones.
We’ve got interact calls going through here. These, you know, these hits and, you know, in the network tab here are going to show what was sent on the hit to the data stream. This config ID is your data stream ID. So in the data stream UI you could go find which data stream this is going to. And.
I’m not sure there’s much more to cover here at this point. But I want to show how you download this Har file so you can. It’s this button here will export the har.
Oh, I actually want to comment on this. I’m in the analytics world you be familiar with, like searching for Beastmaster or. Yeah, business for your analytics calls. You can search for interact. But I prefer to use this. This is what’s called your base path. It it is customizable, but by default it’s E. And most, you know, it’s not really common to have a use case where you change this. And this will show you all your collect calls and your interact calls. So that’s a little, little tip or trick.
And I guess I’ll just say the difference in the interact and collect calls because that’s a question that comes up is, you, you’re going to have an interact call is going to use the fetch type and the collect calls use a ping. So they’re useful when you’re navigating away from the page. If you do the document unloading and web SDK, it’ll change this type to a ping. And it’ll be a collect call. Some, some flows will do a collect call by default. But that’s high level. The difference and how they get processed is exactly the same. It’s just, technically how it’s sent. The difference between a fetch and a ping there. So, yeah, filtering on a UI, but let’s download a har file here. I’m going to save it here already. I’m going to replace this. And then I wanted to show you. So after I’ve downloaded the Har file you can just in Chrome really easily see that Har file by I just open up a new tab. Come here to the network page. Clear this.
I don’t think that will matter. Let me let me do that again. I’m usually it’s just blank.
Well you you can just drag this over and also drop har files here. You drop that and you’ll get the, you know, it’s going to load that session that you had on the previous page. So that’s just a you can use other tools like Charles Packet Analyzer or there’s another third, you know just apps you can you can use to view the Har files. But this is the most convenient way to just see it. Right here how it showed in Chrome to begin with. Now I want to show assurance. So that covers the kind of client side troubleshooting this is useful for. Let’s say you your trouble. You want to make sure your launch calls are putting the correct, values on the correct CM paths. And then you can you can see what was sent. It’s I’m going to show you how it was processed. Client side. You can verify what was the event type on the hit, things like that. Trying to think if there’s anything else here. One thing is the visitor ID you, you can see your ID. Let me come. Here to cookies. You can see your conductor. Cookie will be in here. And I didn’t double check this before, but maybe I have something set up funky here because I’m not seeing it here. Let’s look over here.
Oh. I think it’s because I loaded the har file. Maybe that’s not showing it. Do you want to show you guys this? Yeah. Here’s your conductor, cookie. This has your MD on it. It’s just in this, like, hash. It’s a base64 encoding. And so I’ll. I’ll, I’ll often just to get the image. I’ll just use like, website to, to decode that. So I’ll just show that for example. Try not to go down too many rabbit holes here, but this is a common question. So here you can see the mid on other hits. So on some hits you can see it in the payload.
It’s usually under meta state and then entries here. So you can see that cookie value as well here. But then you would you’d need to base 64 decode it to see the actual middle. And then those are the typical flows that I’ll look at at a ha file. Now I’m going to pull up the experience Cloud debugger here. Let me close this session so that we can connect.
So I’ve, I’ve got I’ll put a link to the, the debugger extension and, follow up notes. I imagine a lot of people here are familiar with it, but if you’re not, this will this already is giving you information. Like when I’m connected to this page, it shows that, down here. And I’ve actually got it locked. You can lock it to that page so that if you change tabs, it I won’t change. But once I’m here, you can see this is telling me my data stream ID, it’s telling my me, my org, the edge domain. Just the library version. There’s just general information here. It’ll show you kind of the horror that this is going to mirror what the heart requests or the network requests are showing, but then the real awesome feature here is these edge transactions. So you have to connect. It’s going to ask you to authenticate. I’m already logged in so now it’s just connected. But now when I come here and send a hit it’s going to show you know, that hit. And then all of the server side processes associated with the hit. And I’m going to come back to this. I don’t want to go too in-depth here because we’re going to look more at this later, but just showing here how they have it labeled client side edge network and then those upstream, products. So here it’s going to analytics target. I’ve got a server side forwarding event forwarding property attached to this data stream and then also to AP.
So that’s kind of a visual representation here of what’s happening server side. And then another cool thing you can do here is that this links to assurance in the assurance UI. So this web debugger session here that I started at 1048 is, is an assurance log. The debuggers displaying it. But if you if you click on this little link box and here it’ll take you into the actual assurance UI. This is and data collection and app I think AP will display it and data collection. You’ll have a link on your side rail here. And these are all of those hits happening. This session is stored. You can look at all of your previous sessions here. And so all of these that say web debugger were opened using the extension.
And this is this view is a little difficult to parse, at least for me. The there’s this event transactions over here, which is going to mirror more what you see in the, extension. I don’t know that everyone is familiar that this is available also here, but that’s that’s a really nice little you know, this visualizes more what those hits are. And then down here, you can, this is giving you a timeline. You can kind of click through here to, you know, to browse around the different hits.
The other thing I wanted to show here really quick is just the assurance UI is in, I found this a little counterintuitive at first. All of these options here are configurable. So click configure down here. You can you know you can remove which things you can see here. Some of them are more some of these options are more applicable for mobile.
Like but you can if you if there’s something you expect to see and you don’t, it’s probably because it hasn’t been configured here.
Like this for example, is going to show a bunch of really good stuff for mobile and, and we’ll show that later. But in the web context, it doesn’t have that.
And I think that’s enough for this section of the, of the demo. We’re going to come back and in a little bit and look at how this looks in the web flows.
But I’m going to stop sharing and we’ll, we’ll try to get the, the PowerPoint back up here. It looks like it’s loading. Okay. So yeah, that’s that’s the assurance and hard files kind of when you want to use each one and the information available.
And just be aware of those tools and, you know, supports going to ask for stuff like, you know, hard files and assurance logs when we get support tickets. And it just it’s a crystal ball into into seeing what’s happening here. So it gives you the clearest picture. Okay. So these are useful library functions I’m just going to talk about right now I’ll I’ll kind of demo them a little bit later. And there’s going to be documentation that has even more functions available to you. And we’re going to send that out in the follow up.
So underscore satellite the these all of these functions are things that you would type into your JavaScript console on your website. Underscore satellite dot underscore container is going to show you, JavaScript represents a JavaScript object. That is your tags property. It’s going to have your, your build date, your rules, visible data elements. All of that stuff is visible on that JavaScript object. And that can be good to confirm what build your production library, your production sites actually loading confirm that the rules you expect to be firing are are actually there. Things like that. And then my the other kind of like go to function is this underscore satellite dot get var which will just give you the value of a data element. There’s a bunch more functions available on the underscore satellite. Library.
These are the two I find going to the most because the data element will just give you the value of that data element when you type it. So let’s say you’ve got a rule that is using a data element, but it doesn’t have the values you expect. You can always check the data element, make sure the value is there and then run that rule. And that will give you an idea of where the disconnect is. Is it the data element was never set properly or does it sometime in the rule lifecycle change things like that.
Adobe not opt in is useful. This is really actually useful. More for the if you’re not using web SDK and you’re checking consent, there can be some overlap with how web does consent. But this is a that’s a, that’s a troubleshooting function that I don’t I don’t know if a lot of people are aware of. And then there’s these alloy functions as well. The get library info is going to give you information about consent on using the web SDK or using alloy. It’s going to give you the different the version of alloy, different configurations that you’ve set on it. And that that function is just really useful to get a snapshot of what how WebEx configured and what it’s how it’s functionally in the site. And then this second function, just the alloy send event, you’ll notice like it’s the most generic thing possible, there’s no data, there’s no xdm. But when I just want to make sure whether K is on the page and I want to send an A, I just want to send and interact call. That’s what I’ll use. Very similar to if you’re familiar with the with app measurement and you want to do just a simple Ascii call, this is kind of the equivalent of what I do for that.
And we’ll, we’ll demo we’ll demo those a little bit later on here. Now we’re, we’re getting into the mobile data collection. So and the, the logs for mobile the in mobile you can still capture Har files and those are still useful. They’re going to show the network requests that your mobile implementation sent. But additionally in the mobile environment we’ve got verbose SDK logs. These are logs that are enabled in the actual code on the app.
The it’s not expected that you would have your verbose logs enabled in like a production app, but when you’re troubleshooting and you’re working with your mobile development teams, you really do want to use these logs and and have them configured to be able to reference when you’re troubleshooting any issue on your own. But as well as reaching out to Adobe, these verbose logs are going to be logged by the SDK as it takes actions on the device, so they give a clear picture of what’s happening on on the actual device.
I’m not going to like, go into an in-depth demo of how to interpret the verbose logs or things like that, but I am going to, in the demo show what’s required to enable those, so that it gives you an idea of the necessary work for them.
Similarly with assurance. So we’re going to we’re going to connect. We’re going to attempt to connect an assurance log with the mobile. I’m not a I’m not a mobile developer. And and some of the mobile stuff gets a little finicky. But I’m going to I’m going to demo what that looks like. And then necessary steps again not going really into depth trying to show you how to do it right now, but just giving you an idea of the work required to set that up. And yeah. So I’ll stop sharing this and we’ll go into the demo. We’ll start with looking at that, with the mobile logs, and then we can look at those, functions.
Okay. So I’m going to first start with.
Looking at the, how do you set up the assurance. So I’m going to open up Xcode here.
And and actually I have this up right now. So for enabling the verbose logs we’re going to have this documentation in the in the follow up. But I’m doing iOS and you just need to have this, this in your, initialization code that’s in the app delegate file. So if you’re not a mobile developer, this is going, you know, probably going over your head as much as it is mine. But the main point here is, to enable these verbose logs, it’s it’s just one line of code. So it’s not a, it shouldn’t be a really big, project or take a lot of time for someone that has a development environment available to them for troubleshooting your mobile app to enable these for verbose logs.
And these logs, when are, when they’re enabled, are actually going to they’re just going to show up here like in your console logs here. So you can see all this information this is giving like what was sent on the hits. Different actions taken by the SDK and, you know, timelines and timestamps for all of that stuff. So this is really, really useful to have those verbose logs. And again, it’s just it’s just one line of code that said, like if you’re more of on the analyst side or you don’t deal with mobile, it’s completely possible you don’t have an Xcode environment with the app running. And that likely would take more work for your mobile teams to provide you or set you up with. Or maybe they won’t be able to do that and they would need to run this. But at the end of the day, this lets you know the work involved so that when you’re working with them, you can have the expectation that for getting these verbose logs, it’s it’s really just enabling this, SDK setting. Okay. Now moving to the, the assurance logs. So there’s a couple configurations you need to do in the app itself for configuring this, the deep link. So first you go to the scene delegate file.
And in here you need to configure this to allow for this assurance. Deep link to work. There’s also an assurance extension that it’ll install. But there’s here’s one setup. So this is a chunk of code that you just, you know, it’s basically copy paste, then inside your project. So in your actual coding environment, there’s some configurations to make.
So project signing and capabilities, you have this bundle identifier. And then there’s one other step here in info URL types. And this is where you put your URL schema that you then configure also in assurance. So to get assurance working there’s environment configurations. And there’s also some code that needs to be updated. So you definitely need your mobile team helping you set this up.
But once you do I’ve got this configured already and it’s connected. Well, we’ll try to start a new, a new, connection here too, but let me bring this over. Okay. So here is my simulator. I’m going to come in to assurance.
And yeah, this is the mobile one.
So you can see how like as I’m interacting with the app, there’s more the you know, the assurance logs are happening here. So this is everything, you know. 1101 this is everything that happened when I added to cart.
Everything that happened server side. And again, you can look down here at the event transactions. You have this view to see, you know, what downstream upstream resources it went to, how the hit was received. While we’re looking at this too, I’ll show like there’s, let’s put the extension versions up there.
So you can look at this. It’ll tell you every, you know, all the extensions. So this is the latest and your version. So clearly I’ve got an out of date tutorial I’ve done here. I haven’t updated these extensions. But there’s a lot of just really useful information that’s just at your fingertips once you have assurance setup.
And I think that’s good for this. I’ll go through the flow like once you do have it set up and we will will hope that this works.
Because there’s, there’s some there’s some nuance to this, and I haven’t figured out all the ways that it it can go sideways. I’m going to create a new session to start. And I’m just going to do like demo three here. This is the base URL that I used. I followed the Luma tutorial that just like this is just, you can do this Adobe will it has this tutorial to walk you through this test app.
And this is just the base URL they use. Then this is going to give me deep link that. Then I’ll come here. Copy that. And then on the simulator I’m going to go to Safari and just paste this link so we can see that. Let’s make sure this is the same length. Yeah. And then we’ll go it’s going to open up a pop up here and say open this page and the Luma app will open. And then it didn’t do it. It should pop up the, the.
A pin enter I think it I think it’s not doing it because I think I need to probably close this, this emulator because I already had one connected.
That’s just what I’ve been noticing. But if we will give it one more try here, if we don’t, you know, like Marty and Mikhail on the call, they’re they they’re a little more familiar with helping people troubleshoot these, these issues. But if you run into something like this, don’t hesitate to open a ticket with us, and and we’ll help.
Mostly for the purposes of this demo, I want to I think this is useful to, to show that, you know, if you don’t see it, it it might not be that it’s not configured correctly. It could be configured right. There’s just some nuance to these simulators. And, getting this working. So I’m going to try just going straight here without opening the app. Do this once and this will.
Here. Oh, it’s it opened the app. Here we go.
Okay. Yeah, I don’t know. I don’t know what I don’t have here, but what you would expect is the this pin to show up in the session details. You get like a little a little piece where you, you put in these four numbers.
I noticed this just as I was trying to do this. And again, I think it’s this nuance of the simulator and, and maybe there’s people on the, on the call right now screen screaming at their screens, you know, saying what I’m doing wrong. But, at the end of the day, these assurance logs are totally worth getting and getting familiar with.
When we get mobile issues, when we get support tickets for mobile, the expectation of our engineering teams to be able to reach out to them is that at a minimum, we’ve got these verbose logs and assurance logs, because you can you can see and appreciate like the full scope of information that that provides them.
And that that’s, that’s the best way they’re going to be able to help.
Oh, this is funny. I think it’s still connected over here. This is what’s going on. Yeah. So these those hits are all going through to my other session. So I’d probably have to close this anyway. I’m not going to dwell on that, but, we’ll we’ll move on now to troubleshooting the, I don’t know if everyone’s catching that. These are all showing. 1105 so this is showing it’s still connected to this session as why we didn’t get that pin to pop up. Okay. But moving on. We don’t want to spend too much time on that. I wanted to just show here you’ve got. Your underscore satellite object. This isn’t going to give you you know, this is kind of difficult to parse. It’s got some stuff. Build info, property. But if you do the underscore satellite dot underscore container, this is a little more streamlined to show you your build info. This is was saying earlier, it’ll show you like your rules, the names of the rules, the actions on them, if there’s any conditions, the events. So it’s it’s not going to I mean, obviously looking in the, in the data collection UI is going to be more useful, but this can at least give you a quick idea of, okay, I expect X rule to be running. Is it loaded on the page. Similarly data elements would would be listed here. I don’t have any on this property. But if you’re having issues seeing the data elements, you can you can see those there. The oh I don’t have experience cloud on here. Okay. Yeah. Because this is my webcam. Okay. I’m not going to demo the, the, the consent stuff where we will put that that documentation. The biggest thing here is if you didn’t have your, Like, if you weren’t seeing hits going out, then this is going to, the, the opt in categories where you can check if analytics is opted in, etc. and or target or other products. And if this is returns false like you would do. Adobe dot, and is approved.
And then you’d put in like analytics for example. And that would tell you, okay, analytics is not opted in. And then you can, approve it. And you would see those hits going out. Let’s do a let me pull back up this. This slide so I can show I want to send just like, an SDK hit here.
So I’ll come back over here and clear this.
If I wanted to just make sure, like, a hit was being sent, I can just do that. And here’s here’s a hit. So I know that alloys on the page and it’s sending you know, you can see like the default XLM it will send. So coming back here that was just that really basic. This is my like testy call for example. And that’s useful for for troubleshooting. Just whether web SDK is sending. And then let’s look at the, library info on WebEx. So this is giving you the version. It’ll give you these settings.
Here. So this will tell you like I’m default consented in debugging is not enabled. Here’s my data stream ID. So just a lot of a lot of useful information here. Using that.
And I think that covers all of the like kind of useful functions that we end up using. And again, there, you know, alloy has other functions you can use. And we’ll put that documentation and, additional resources. Okay. Now we are going to go back to the, slides here for a second. And we’re we’re getting close to kind of the last section of the presentation, which is going to be these kind of more, more, more little tips and tricks that are, that are useful that that come up, as well as some specific flows for troubleshooting, like event forwarding or app validation, things like that. So this this slide is just showing and I’ll show it later in another screen share. We’ll do one more screen share. But this there’s this environment file that your app references and that’s actually hosted. And and your app will make a request there and pull information from that file. But, it’s not super common knowledge. Or you can go view the contents of that file. It’s hosted at assets at Adobe dtm.com domain. And you just you so that’s just showing you go to that domain, put the environment file ID there and add dot Json. And that will load. And you can you can see different configurations for your mobile app there.
And then below here in the text for seeing the unmodified data collection web file, you’ve got your embed tag that you would get and data collection and put on your web page and in the source URL there you’ll see development document JS. And the second second section here is showing if you delete that dot document, you’ll get an unidentified version of your satellite object code. And that’s that’s also really useful for just ensuring what is on the page. And you can search. You can just do like a control F in there and, and see the rules that are on your page and the data elements and, and things like that.
It’s a useful tool. And if, if, if you come up against a scenario where that would be useful, hopefully you can remember this. And, and this is, available to you.
Okay. So the, the next thing that I’m going to go over in the demo too, but this is showing how you would, how we often troubleshoot event forwarding stuff. If you’re less familiar with event forwarding it, the configuration looks really similar to tags. It’s also in data collection. There’s properties. There’s rules, there’s conditions and actions.
But these event forwarding properties are I should say, event forwarding is an aid like you. It is an additional skew. So it’s possible that your organization doesn’t have access to it. But if you do, the use case is any hit that goes to edge will trigger the event forwarding rules and the conditions will be will be used to determine if a request will be sent to third party APIs. So it’s often used for like Twitter or Facebook, like meta pixels, different things that you want sent server side based off of hits sent to the edge. And over here in the screenshot you can see the there’s this logs section and we’ll, we’ll go there. This does a really good job of documenting and showing the various server side forwarding or event forwarding requests. It’ll show you the actual API requests that was sent. And here you can even see it. It’s showing like a response for a one, because my my credentials were incorrect for the Twitter API. So this is super useful when you’re troubleshooting your event forwarding, integrations, you know, likely these event forwarding configurations or sending the completely third party to Adobe. And you’re kind of at a point where you’re you’re troubleshooting your API request to these third parties. But if you’re just looking at the event forwarding UI, you don’t have any insight as to what Adobe’s actually sending over the wire. But using assurance and connecting through here, you can see it. And it’s it’s a very you know, and especially in this logs UI, it’s a really easy thing to read. So this is typically where we come for troubleshooting those event forwarding things. And we’ll, we’ll look at that also in the demo. Okay. And then the last kind of let me make sure this is the last one. Yeah. Validation errors okay. So there’s there’s the target flow that I mentioned earlier. I’m going to show how you can troubleshoot this. Again this is like there’s a whole documentation about your target page top and your analytics page bottom hits and how they interact in web SDK. If you’ve already migrated to web SDK, it’s completely possible that you ran into an issue with this. And, target hits, you know, hits that you expect to just be used for the target product being sent to analytics as well is the is the problem. But with this, feature, you can prevent target hits from going to analytics and, and actually all that it is, is if you have type decisioning proposition fetch and we’ll link this documentation. Then this tells analytics to drop that event and and not forward it to analytics upstream. I’m going to show in surance. And then the debugger where you can confirm those analytics or those target hits aren’t going to analytics. There’s like a dropped hit parameter. And that’s a very useful little piece of information. And then finally another common flow with edge that we see our AP validation is so if you if you’re not CDP customer, you you’re you’re familiar with the schemas and how you can mark certain fields on the schema as required. And if you’ve enabled streaming validation for those hits, then they will be rejected. If the, you know, if you’ve got a required parameter that has, incorrect type or isn’t present, then you’ll get these validation errors and I’ll, I’ll kind of show how you can use assurance to, to troubleshoot those. So I’m going to stop sharing or I’m going to start sharing here. And this will be the final little demo we do.
Okay. Smiles are we showing now.
Okay okay.
So to start let’s actually do the the event forwarding scenario. So I’ve got configured a, an event forwarding environment. I’ll just really quickly show that. So this is what that would look like you’ve got then for adding different properties here. I actually think mine’s just called demo here.
You then will take this environment ID here, configure that on your data stream and then that tells edge any hit that goes to this data stream should run these rules. And I’ve got just, I’ve got that Twitter rule with the broken credentials. And then, another really simple rule here. So this is just so simple. Webhook site. If you, if you hit if you just send a get request to this URL, then it’s going to send a hit here. So I’m going to just show when I, when I send a edge hit. Over here I’ll refresh the page. Then we’ll see a, we’ll see this pop up. If I can get this to show. Yeah.
All right. So here a send and interact. You know, I send some interact hits, and then these were created by event forwarding. Now, if we want to troubleshoot those we can go into assurance. And I, I look at this logs edge specifically when I’m looking for event forwarding stuff. Just because this this UI shows it a little better. And here you can see my request to that webhook site.
It had a 200 response and that’s how we saw it show. There. And then if we were to come down to the Twitter one here, you can see I had a 401 response and it’s telling me I had an invalid or expired token. So that’s really it in a nutshell. If you’re troubleshooting event forwarding, stuff assurance is super useful. Specifically, this logs edge section.
Okay. Let’s see. Event forwarding. Now thinking about this scenario where you’re sending stuff to RTC, CDP and you’ve got validation errors for that. I would, I would use these this edge transaction section because you can really ease or an assurance you can use that view. I would come down to here where you’ve got you’ve got your, you’ve got this is showing the hit to RTC, CDP and then this is showing the validation I actually, in preparation for this, had a hard time breaking the validation because I’m a little less familiar with how you enable that.
But pretend this this broke. What would be really useful is you can just come in here, look at your, your schema path and how, you know, the, the axiom that was received by edge and and determine, okay, did did these required fields get sent. Another another section in here that you would look at is I would actually look at hit received and look at Zdm here. So this whole this all is another view that will really easily show you what, what you sent. But if we did get a validation error, this would, would tell us the path that wasn’t that wasn’t present or was invalid.
And then you could easily, you know, compare that to what was sent on the, the hit received by edge and the SSM there. So that’s, that’s typically how we do that. And then the last thing I wanted to show was these hits that are.
Marked as target hits. That decisioning proposition type is on them. And so analytics isn’t going to record those. The the simplest way to see those is you go to I think yeah it’s here you go to hit received and then you want to go down to messages to the, to the.
Where is that here.
I thought it was messages, so I put mine out here.
I look at a different hit. It might be.
Okay. I thought that was here, but I can show it over here. So if you go to analytics, hit, it’s going to be right at the top here. This is so this is a dropped hit.
This is you know, I don’t know that people know about this, but this is a really useful way to confirm that your top page, top page bottom is working.
You just go to the analytics, hit on the upstream resource and look at these attributes here. And if you see dropped hit true that means it’s not going to the hit will be dropped in analytics. So for example if we look at this one it’s dropped hit false. So that means the type was out there. And I thought you could confirm that or I’m sure you can over here somewhere. I mean, if we look at the Zdm.
Where is that? It’s come back down to this one at the end of the day, without fail, and come to analytics hit and you’ll see that, I want to see the actual type on here, though.
Yeah. Here’s event type decisioning proposition fetch. So that’s why this one shows dropped.
And I think that wraps up the, the demo for these additional things that just tips and tricks for troubleshooting with assurance.
We’ll just go back to this wrap up slide and I will we can look at more questions that if any haven’t been addressed in the chat. But yeah, we’ve got Marty, Mike, Michael and I here. You know, we’re we’re really focused in on on data collection issues. That’s primarily the tickets we work on. So if you haven’t worked with us, we’re we’ll be happy to take any tickets, any any follow up questions that you come up from up with from this session. The key takeaways, though, are to use assurance. I’ve been really like hammering that, obviously there’s so much information available there, and I’m sure there are troubleshooting tips and tricks that even you could, you could share. The you know, this isn’t an exhaustive list of things you can do with assurance, but I hope it gives you some idea of its usefulness and what is available to you when you’re troubleshooting.
And then also for client side troubleshooting, you’ve got those verbose logs. Ha. File. All of this stuff is going to help make a clearer picture of what’s going on and and help you troubleshoot.
Yeah. Do your best to rule out the potential problem areas. Just like because we have these client side and these server side functions, if you can identify that your issue is something client side or something server side, that’s going to help so much in in our troubleshooting and aiding you as well as your own investigations. And again, yeah, please, please reach out to us. We we’d love to help. And and we’ll just take any more questions. I’m going to I’m going to look at the, the chat here and just see, see things that haven’t been addressed. Okay. Martin asked why is there a differentiation between interact and collect calls? I kind of going back to what I was saying earlier. I know that the the technical difference between them are ones using a ping and one is using the, yeah. The fetch and Ike, let me give you this document unloading code or, document unloading documentation. This is going to explain the use of it’s not going to call out collect specifically, but it’s going to call out the usefulness for why we might use a collect call. And largely it does come down to this, this difference between an interactive fetch and a ping.
But this documentation will it’s really good reading and really interesting actually. It will it will help you. Let me try to apply on this.
I assign it the question myself so I can reply. Oh, I ordered it. Oh. Okay. Is there a way that I can. Okay, I’m just going to put this documentation in the general chat. So this is everybody can get this. It’s a document on loading that’s going to help you, understand like the difference between these collect calls and fetch in a really in a nutshell, when you click a button, when you click something on a page, the navigates to another page. So you’ve got like an internal link to your site or you’re going to a different site. There’s a split second where you’ve told whether to send a hit, and the doc and the document is unloading, or the web page is unloading. And in that window, if the web page hasn’t completed the the network request over the.
Yeah, just sending that network request, it will cancel it.
If it’s a fetch, if it’s a collect call, it will wait for those to complete. So in a nutshell, that’s kind of the usefulness.
And you’re when you use document on loading. True you’re going to get that’s when you’re going to see collect and set of interact.
Okay. Gabriel had this question about consent. Is it possible to set generic consent with set consent? I’m going to pull up that said consent documentation. We didn’t go really in-depth on this, but I will call out while we’re on the topic that Ashley treats consent much less granularly than, I’m just going to this is useful documentation, so I’m just going to reply to everyone with this. But, Yeah, experience platform gave you a lot more granular control over experience ID service, I should say sorry, give you more granular control over consent to different products. Edge is a little different because client side, you really only have you’re only really sending the edge you’re not sending to downstream products. So the consent is much more all or nothing. Now you can you know, you can control default consent.
But you can’t really control granularly the different products and the consent to those. So I think that I think that, Gabriel, I hope that helps address what you’re saying there with general consent or generic consent. At the end of the day, that’s really all you can do with consent is it’s it’s more of an all or nothing.
And then you can you can set a default on that. But if you have follow up questions on that. Yeah. Please, please open a ticket with support and we’ll dig into that.
Okay. I’m going to read this one by Jeff. That’s not answered yet with Individual Solutions implementation for mobile SDK. There is the Adobe Underscore MC query param added to the analytics call. How is that translated to mobile SDK using edge for processing and forwarding to analytics and C-j to allow stitching mobile in-app web native hits. Okay, there’s a couple things here. I’m not I, I understand the general question, but I’m not exactly sure I know what what we’re talking about here. I think we’re talking about mid and maintaining those consistent on separate calls.
So in in mobile it’s still going to use the mid it’s going to generate in mid in local storage. That’s going to be specific to that user and device and that installation of the app. If you update the app then that Mid will stay the same. But if you were to delete the app and reinstall it, you’d get a new mid. But then it let’s say you have flows where you go from mobile to web and you want to keep, consistent mid. Then we pass that in the query string parameters, by adding those to the URL that links to the web page, that will tell the web page to use the mid and the query string parameter, and then ideally maintain a consistent mid across those, specifically for edge and forwarding to analytics and a C.J won’t necessarily use the Mid as your person ID.
That’s the C.J kind of uses a different stitching model. And I mean it can use the ambiguity but that’s configurable in C.J. So anyway Jeff I hope that I hope that kind of addresses some of the topics and the general idea of what you’re asking there. I do think, there’s probably more to unpack. And I would say open a ticket and we’ll we’ll work through the details on that with you. But there’s but the definitely when you’re talking about analytics and CJA and maintaining kind of the same visits across there, there’s a bit of nuance there. And it’s, it’s a little more just related to how C.J. does things.
But the Mid will be set in a data set, CDP data set that would be referenced by C.J., and the edge hits should send the same mid to the data set as it does to analytics, so that the IDs should be the same between the two. Whether C.J. is using that for visitor identification is a that’s a little trickier to know.
Okay. Jonathan asked. How do we troubleshoot the delivery API with API integration? This is a good question that I don’t know the answer to. Off the top of my head here I am guessing that delivery API still hits edge. Let me check.
Like if at any point in delivery API you configure a data set or a data stream, then it would be hitting edge. And theoretically you we could set up an assurance log for that. But that’s something I would need to to dig into. I haven’t I haven’t run into that issue before.
But most likely kind of I’ll just say in the back end how these assurance logs work is there’s an ID in the request that when edge receives that request, it notices that ID and then it records to the assurance log. So let’s Jonathan, definitely open up another like a ticket with us to look into that. But I’m just a little less familiar with the the delivery API. So like a target flow. But if it’s hitting the data data stream, then we should be able to get assurance logs, which would be the way you troubleshoot it. Otherwise you probably just have to look at the API requests and responses. Let’s look at some other ones here. I’m skipping over the ones that been answered.
And if we don’t get to all of these, please, please reach out on a ticket. So we’re using Interactive Edge call API for target server side testing. The empty calls are getting recorded. An API for CDP like analytics. Would it be possible to exclude events fired for target getting in a CDP? Okay, that’s a that’s a really good question. And I would kind of abstract it a little bit specifically from the target server side testing.
I because I know that this is I think this is a problem that’s come up, especially if you’re like using profile in our TCP. There’s, you know, there’s rate limits on requests that can be sent to profile and things like that. And I know that I want to say the, the short answer sound car is that is no. But I do know that CDP is like this is it’s a common flow to have hits that that are being used in other products that you don’t necessarily want in your CDP data set.
I know there’s things you can do with client side overwriting your data set, like you can have multiple data sets or, sorry, multiple data streams configured to go to different data sets.
So theoretically, you could have a data stream that’s used for some target flows versus a data stream used for some CDP flows.
That I think is is a workaround that people have used in the past. But I know that there’s conversations happening with our TDs within CDP for for kind of segmenting out these, requests. And if you make a ticket outlining your, your use case, we’ll, we’ll be able to do some investigation and find out if your specific use case has a solution with RTC, CDP. I’ll, I’ll just say like we’re building our expertise as a as it relates to other products. Are everyone from Adobe on this call right now has more of a background in analytics, but we’re we’re here to answer questions for all these other products. We just need a little bit more time to to dig into them and get you a, a satisfying answer.
Then, okay. Chuck asks. We are using the variable width data versus the XLM schema and, launch to pass analytics, which is great. I that that data object is so much more, intuitive than the XLM. I think. I haven’t had a chance to find a place to append the identity map object to this variable type. I can only append analytics or target related data. Okay. So yeah, that’s a good that’s a good question. So the identity map is only going to be used by our CDP and downstream from our CDP. Like C is analytics and target shouldn’t have any like product dependency on the identity map. So I actually expect not to be able to map it in the data object. The data object. Similarly, similarly to why you wouldn’t have identity map on a hit generated by app measurement. If that makes sense. So, app measurement doesn’t send identity maps, so data isn’t going to have a mapping for it because ultimately that data object is used to generate hits from your website, hit that look like hits generated by app measurement. So I hope that that’s a bit of, like negative answer in that it is saying, analytics and a target shouldn’t be using identity map.
So, so data object won’t, need to map it. That said, you can send both Zdm and data.
I believe Zdm takes precedence over data.
But if you send, you know, if you’re sending your data, your analytics data on the data object and identity mapping zdm, those will still edge will still process those. And and the downstream products that would use identity map on Zdm will still get them.
And I’ll, I’ll type that out here.
Okay.
Looks like we’re getting most of these here I’m looking at. Okay. Rachel asks. I have two launch properties, one using a measurement, one with weather. So. Okay, I save the echidna and Eva. It is sometimes unspecified with the web SDK and you’re sending it in the on before send callback or however it is always set with the app measurement property. Has anyone else experienced that? I will say that I’ve seen, I’ve seen issues like what you’re describing, Rachel. And typically with the, web SDK you’re using that like get identifiers function I think is what it’s called. And that function is I, I’ve seen it not I’ve seen people report like timing issues with that function. It’s basically it’s, I think that your best bet is to and maybe you’re already doing this. And if this isn’t speaking to your specific use case, totally open up. A ticket. But what I’ve suggested in the past and and seems to have fixed some of these issues is you save the amid and like, I mean, you can tell you can create a launch data element to read from a cookie value. So you could you could set up something to read the ID from a cookie value. Or you can just set the data element with custom code, but set a a longer storage time for that data element. So in launch there is the option to to save data element data and local storage for example. So I’d expect that if you if you are using the get identifiers function and it’s doing that every time in the send event callback, there could be some timing thing going on there. Like it’s not returning the, the, IDs fast. And you could set that via data element client side and keep that over time. Similarly, you could probably do something with data prep where you read the ID from somewhere else that’s on the hit.
And then set it where you want it on your xdm. So those are kind of my my two ideas. There. I will also say that it’s just.
Okay. And I think that might be.
Yeah. Okay. It’s a I see what you’re saying there, Rachel. So you are using a data element, and it’s from ESRI service.
Okay. All right. Okay. Sign to Mike okay. So I’ll, I’ll follow with Mike on that one. We’ll we’ll look we’ll look at that one our child.
All right I thank you it on we’re we’re pretty I think we’re good to wrap up. If there were any questions we missed please just open a ticket and and we’ll we’ll work with you.
Perfect. Thank you so much, Garrett. And thank you again, everybody, for joining us today. This is a really informative tech sessions. Just another reminder, an email will be sent out to all of you in 24 hours with the recording to this video. Thanks again and we hope to see you again in our next session. Bye. Thanks.