Apps are a different beast, and we want to make them a little easier to work with. How do you currently debug analytics on mobile apps? What works and what doesn't? What do you wish was better? The more detail you include (especially examples) the better it is for us!
So, I used to work with Charles Proxy when debugging IOS apps, even if the config was a little bit hard and confusing.
But then I went on holydays, broke my phone, got a new phone, and now - to my bemusement - back at work the config is not working, I'm a little bit confused. Maybe they also changed the proxies of the Wifi at my work.
Also maybe the only doc I have is a little bit outdated :
Using Charles Proxy for Analytics | Digital Data Tactics
And cheers to the community !
I think that Charles (that Marion mentioned) is the best option.
The unique problem is to debug Android devices. On new Androids (version 7+) there is now an security protocol that prevents charles to work properly (I confirmed that with Charles support).
To solve that I had to downgrade my device of tests
So with 7.0 Android introduced new TLS/SSL Default Configuration Changes
As per the document Android 7.0 Behavior Changes | Android Developers and it's not possible to track the calls even through charles from android app..
I use Adobe debug tool to trace the call which is cool but have challenges with the HTTPS calls specially with android.
I actually liked using bloodhound, just because it allowed me focus a bit easier on just the adobe analytics requests and I didn't have to spend quite as much time searching through the various request data to find what I was looking for. The one thing that I didn't like about bloodhound was that it wasn't immediately clear that it completely intercepted the adobe hit. There were a few times I had to explain to various folks using it that they needed to change their settings if they expected their data to still record into our report suite.
Since bloodhound has sort of dissappeared I have been using Charles. What I don't like about charles is that it captures every request, not just the adobe ones. It is pretty trivial to filter but after alot of data has accumulated charles seems to slow down a bit even with a filter.
Also, the display of the data is not great, bloodhound had it much better organized which is obviously to be expected with a generic vs. a custom solution.
Hey Justin, you may want to check this out. Maybe adobe can do some kind of partnership or integration with Charles- but they got a new iOS app for Charles and you can check it out here: https://www.charlesproxy.com/documentation/ios/ and here: Charles Proxy on the App Store
I mention because I just spent the better half of my day trying to figure out why I couldn't debug with my Android with the app but could with mobile web... I wish i'd have found this forum sooner. That was a nightmare haha. Thanks Justin.
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).
This struggle is real! We are looking into remote debugging on Chrome/Safari as a Charles alternative due to corporate firewall issues. Even considered an app to listen to livsteam api (I know this is up your alley!). The challenge is when you want to see the data layer. I hope Adobe can come up with something. The lack of an easy to use option is making the implementation process for apps exceedingly difficult.
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).
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.