Image Request URL not containing any data

[TetikelSarp]

In my organization, there is one specific funnel which is missing all data from the steps on web. The server call (custom link) is visible in Adobe Exp Platform Debugger, Omnibug and the extension Debugger for Adobe Analytics, and has 200 status on the network tab. All the eVars & props that should be there are there on all three of these debuggers. However, the Image Request URL for the server call is missing all of this data. The query string is limited to "?p.&debug=true&.p" whereas for the other server calls, the string contains all the prop and evar values. When looking at the related call on the network tab, I see 2 tabs under "payload", the first being "Query String Parameters" and the second being "Request Payload". The "request payload" string contains all the data, but this data is not in the query string parameters and is therefore not delivered to AA. See screenshot below. Any suggestions for why this is happening would be appreciated. Feel free to request more information. Thank you.

[yuhuisg]

What you're seeing is correct, actually, and your data as shown in the Request Payload screen should be reflected in your AA report.

Browsers generally send data to servers via GET or POST network requests. (There are other types, but these are two main ones.) GET requests are the ones where you can see the query string parameters in the URL. POST requests are where you can't, because the data is normally sent in a "payload". POST is commonly used for sending form data, which can't be all included in the query string parameters.

GET requests have a limit on the amount of data that can be sent in them. Different browsers have different limits, but it's usually a few kilobytes of data. So if a GET request is used to send more data than is allowed within the limit, then the browser fails to send the GET request. Obviously, that's bad for tracking. So AA uses POST requests to send beacons that have a lot of data to track, and that's when you see the Request Payload screen.

Unfortunately, the AEP Debugger is not able to show the data in Request Payloads. It really only shows the data in query string parameters only. That means it can show the hits from GET requests with query string parameters for all of your tracked data. But when AA sends the beacon with the POST requests, then the AEP Debugger is not able to show the data in the Request Payload. (You can normally see this happen with Download and Exit Links that are tracked automatically.)

As mentioned at the start, your tracked data from both GET and POST requests should be captured properly by AA nonetheless, and so your reports should be correct. If you're not seeing data, then it could be because there is some tracked data from the POST requests that is not recognised by AA, and so the entire Request Payload is rejected. In that case, you'll need to investigate the data that you're tracking to ensure that you're tracking valid values (normally text strings or numbers only).

[Jennifer_Dungan]

@yuhuisg has covered this really well, but I will add one thing... using GET vs POST method is a normal part of Adobe's processing... if the URL string is under 2000 characters, it uses GET... if it's over 2000 characters it uses POST.

Both are completely valid ways for the data to get to Adobe.

I am not sure what yuhuisg means by "Unfortunately, the AEP Debugger is not able to show the data in Request Payloads." The tool does show the POST requests Payloads... more than half my requests use the POST method, and all the data is shown in the debugger.... If it didn't I would always have to extract that manually and manipulate the string to read it.....

[yuhuisg]

---

@Jennifer_Dungan wrote:

I am not sure what yuhuisg means by "Unfortunately, the AEP Debugger is not able to show the data in Request Payloads." The tool does show the POST requests Payloads... more than half my requests use the POST method, and all the data is shown in the debugger.... If it didn't I would always have to extract that manually and manipulate the string to read it.....

---

You're right, I see that now. I remember not being able to see POST requests' data (e.g. eVars, props, etc) in the Debugger, could only see a new column added to the Analytics hits with basic info about the network request.

[Jennifer_Dungan]

Maybe that was an older version of the debugger?

I know the old "Cloud Debugger" wouldn't decode exit links, but did decode all other POST requests... 

[TetikelSarp]

Thank you both for the explanation. In that case, the issue we are facing isn't that the data is missing from the Image Request, but that it is not getting delivered to Adobe Analytics or cannot be viewed in the report suite to which it is delivered. All data types are strings with only 2 of them being numbers, and the only difference between this server call and the others is the use of a number of eVars unique to this proof of concept, so I find it very unlikely that data type would be an issue. I have also triggered the server call manually by pushing an item into the array with the right event name along with 2 eVars, and that call also did not get delivered. I'll still double-check the eVars for any data type issues. Do you have any other suggestions for something else I should troubleshoot?

[yuhuisg]

Probably a dumb question, but you've setup your 2 eVars in the report suite's settings already, right?

---

@TetikelSarp wrote:

I have also triggered the server call manually by pushing an item into the array with the right event name along with 2 eVars, and that call also did not get delivered.

Can you show a screenshot of your browser console where you did that array push? Where possible, please show the values in that push that are being passed to the eVars.

[TetikelSarp]

Not at all, any effort to help is appreciated =). Yes, they are configured and all eVars are set as text string as their data type. Here's the screenshot, with the console command at the very top. eVar119 is the funnel name while 121 is the step name. Some eVars contain the same values because this funnel is tagged as part of a proof of concept by a consultancy so they used a different eVar config. When creating a workspace filtered by this funnel name, you cannot see the stepName that is pushed in this call in eVar121. This server call and others that should be coming from the Web platform are missing. The data that is there for this funnel is all coming from the mobile app, which also has steps as part of this funnel.

[yuhuisg]

Thanks for the reply and screenshot.

I noticed that your hit is being sent as a Custom Link. Have you verified that your s.tl() call has the correct arguments set with it? https://experienceleague.adobe.com/docs/analytics/implementation/vars/functions/tl-method.html?lang=... Or if you've implemented with Tags, can you show screenshots of the Set Variables and Send Beacon actions where you're setting and sending these eVar119 and eVar121?

The reason I'm asking is that though this is a Custom Link hit, the Site Section and Server variables are also being set, though those are normally set with Page View hits only. So I want to help you to verify that your Custom Link has been implemented correctly. An invalid Custom Link will cause its entire hit to be discarded.

[Jennifer_Dungan]

Server is definitely fine on Custom Links (We use this and have for over 10 years, this is the primary value under which our global suites / virtual suites define traffic to each of our sites).

While I don't use site section on our actions, I haven't heard of any issues with having that set....

[yuhuisg]

I didn't say it's wrong to include Server (and Site Section) in Custom Links. I said that they're normally not included, which led me to wonder whether something had been wrongly implemented, and that is why I had asked for more details about the implementation. Based on what @TetikelSarp has provided so far, unless AA's data collection is seriously broken, we need more information to troubleshoot.

[Jennifer_Dungan]

@TetikelSarp are you using the plugin "Debugger for Adobe Analytics"?

If so, my first suggestion is don't

That plugin is buggy... 

I've seen it:

• show multiple calls when there weren't
• show tracking calls in general, when there weren't (from a site that didn't even have adobe analytics... apparently the s object still existed when the user clicked a link that took us from site a to site b.. and this tool showed that first pv having analytics - it wasn't just the exit link... there was a separate exit link before the "fake pageview")
• have missing data in the output that was in the tracking call

Bottom line, I don't trust that tool... if anyone on my team brings me a issue found with that tool, I won't even look at it until they confirm with another tool (ANY other tool... or the network panel) (because the person on my team that kept using it, continued to bring me invalid issues all the time)...

You might want to try Omnibug, or the free ObservePoint extension....

And despite how much I hate Adobe's official tool Experience Platform Debugger (vs the old Cloud Debugger that I liked soooo much more), this tool will allow you to log in and see the resulting Post Processed value of the tracking, which for debugging is invaluable! So even if you use that only for debugging, it's worth having.

But like @yuhuisg, I do second showing us data from the tracking calls that send eVar119 and eVar121... but maybe using the Experience Platform Debugger with post processed data turned on? So that we can see what is send and how its processed.

[TetikelSarp · Accepted solution]

Sorry for the delayed response everyone. I appreciate your suggestions and it turns out that the issue was caused by a missing "if" statement in the processing rules that overwrites the value of the eVar with data coming from the mobile app, i.e., overwrite value of eVar123 with contextData. All I had to do was add an "if" that said "if contextData exists". A very simple fix that was surprisingly overlooked by a lot of the people I work with.  

[Jennifer_Dungan]

Glad you got it sorted out!

Yeah... missing if statements can kill you! And they can be really easy to overlook too.