cathym3173229 Super helpful context and yes it is something we are looking very seriously at. How are you thinking about doing remote debugging in Chrome/Safari?. Is it a wrapped web view or something different?
Justin - this is the type of process we are considering for those who can't use Charles. We've done it before and it works but not very easy.... also Android requires code to be added as well (which has to be removed prior to go live -- so an extra point of potential failure).
Another thing (as i noticed there was mention about difficulty with android debugging)- I actually use this app in the chrome store and it uses a "reverse tether" via usb. It made it sooooo much easier debugging with almost any tool- because it literally would let me use my pass the requests to my computer. It was so easy all I had to do was download the app, set up the desktop app for it, and then just plug it in and was ready to go. I tried finding one for iOS and that's how I stumbled on the new charles app. I think the idea of the reverse tether is a more universal approach and may help your team if they haven't considered or tried that. Here's the app I'm talking about that I use on my android: Reverse Tethering NoRoot Free - Apps on Google Play
The only thing that was a pain was when I was at home, trying to connect to an intranet via VPN, but when at work it was a piece of cake to connect to the wifi at work, and when externally testing super easy as well with the exception of trying to internally test something for a site in pre-production (when remote).
That is a cool way to do it. Thanks for sharing. Very helpful.
I'm just seeing this thread and thought that I'd add my two cents if it's not too late.
1) Debugging mobile AA calls is certainly a pain-point. It always seems to end up getting solved with some network proxy tool, be it Charles, Fiddler, Cloud Middleman, or other 3rd party solution. Adding complication is the fact that there are often more network layers to negotiate like VPNs. On top of that, we most always have certificate issues to deal with before we get to the point of actually seeing the network call as it goes across the wire to an Adobe Collection Server somewhere.
2) Set-up issues aside, looking at network calls when validating an analytics implementation is not ideal. For me, it has always been an added mental burden to shift from a document telling me that we need to set a bunch of variables (eVar10, eVar20, eVar22, eVar23, prop4, prop7, prop55, event12, event22, event24, pageName, channel, blah, blah, blah) to a network call that has values set in a mixture of context variables (c.*) and "s" variables (s.*) all called by different names than the destination and all in seemingly random order. It's just painful.
3) A much better scenario would be a system (provided by Adobe) that would allow you to see a real-time view (segmented by your device identifier (IDFA for example) ), of your analytics calls as they cross the wire into Adobe stable storage. Ideally, you could configure how you wish to see the variables (eVars from low to high, events from low to high, props from low to high, etc). Ideally, you could see your beacon at various stages of processing (Unprocessed, After processing rules, After VISTA, etc.). Ideally, you could see the transformation of a variable from raw state to stored state on the same view.
This would save countless hours of unproductive time. It would enable quicker issue identification. It would help bridge the communication gap between AA Analyst and Mobile App developer.
I've read a couple places on this forum that it's difficult to sift through the hosts in Charles to find the analytics calls....
mlively One trick I use to clean up the Sequence view is I right click on a desired host (usually the analytics host) and select Focus. This organizes the view by placing all other hosts in a folder called “Other Hosts”. Then when I am testing the analytics tags, I'm not bombarded with seeing all the other traffic occurring. See Charles description here: https://www.charlesproxy.com/documentation/using-charles/focus/ .
Additionally, ankits77860132, I thought you could use Charles with 7.0 Android devices if a new Charles config file is added to the application. See documentation here: https://www.charlesproxy.com/documentation/using-charles/ssl-certificates/ . I haven't done this before, but this documentation makes me believe it is possible.