Avatar

Community Advisor

Hi Justin.

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.

-Stew