Developing Mobile Applications is hard. Period. As a company offering Mobile Applications, you need to go to great length to develop Apps that don’t disappoint or annoy your customers, let alone engage them. New versions have to go through tedious testing, both from you and Google or Apple before any changes can be rolled out to your users. This is why accurate measurement of your Apps is crucial to making them successful and delivering value to your customers.
But this introduces a whole new layer of complexity. Now your developers not only need to make the App work but also need to implement Analytics into it. This can go two ways: Either they follow your tracking concept to the letter while not understanding the methodology and purpose behind it. Or you try to involve them more and make them understand why things are done in a specific way and how correct Analytics provide value to the company.
I think it’s quite clear that the second approach is the more mature one. It helps to propagate your mission and align the business with your goals. But now there is a new challenge: Testing the Analytics implementation has to be democratized to your developers. They need a way to get immediate feedback on how the App behaves in regards to Analytics, so they can fix any obvious bugs. This also helps to free up resources on QA and increase development quality.
There are some possibilities for developers to monitor Adobe Analytics requests in an App:
- Using a proxy like Charles or Fiddler. This involves monitoring network traffic and has become increasingly difficult with newer versions of Android and iOS due to security improvements.
- Using the Project Griffon Beta. Adobe has recognized the need for easier debugging and developed Project Griffon. It is a bit like the Experience Cloud Debugger for web and involves some changes to the code of your App. It is still in beta at time of writing.
- Utilizing Debug Output while development. This is the most direct way for your developers to get feedback. They will look at log output during development anyway. Logging is enabled with “MobileCore.setLogLevel(LoggingMode.DEBUG);” with the new Experience Cloud SDKs or “Config.setDebugLogging(true);” on the 4.x SKDs (or the iOS equivalent).
Since the last method is the most intuitive and direct way for developers to get feedback, we will focus on that way. Once Debug Logging is enabled, Android Studio or Xcode will print Log lines in the console, telling us what’s happening in the SDK. An Adobe Analytics logline will look like this:
2020-02-25 16:33:18.891 17802-17867/de.awesome.app D/ADBMobile: ADBMobile Debug : Analytics - Request Queued (ndh=1&ce=UTF-8&c.&a.&CarrierName=Android&AppID=Awesome%20App%203.0.0%20%282020022001%29&RunMode=Application&OSVersion=Android%209&TimeSinceLaunch=177&Resolution=1080x1794&DeviceName=Android%20SDK%20built%20for%20x86&.a&server=Awesome%20App&user_status=free&menu_link=menu%3Dnavigation%20header%3Blink%3Dhomepage&page_site_section=homepage&content_world=none&test_group=none&device_properties=online&user_loginstatus=loggedout&content_findingmethod=none&user_id=free&page_name=homepage%2Findex&previous_page_name=none&.c&t=00%2F00%2F0000%2000%3A00%3A00%200%200&mid=90182730886246084307961140646252512535&pageName=homepage%2Findex&ts=1582644798)
So, if we filter our console with “Analytics – Request Queued”, we will only see the Analytics requests that are fired on a specific action, like below:
It’s quite obvious what those lines mean. The part in brackets contains the actual request parameters in an URL-encoded string. When we want to read it more clearly, we can throw it in an URL prettyprinter to get a more readable version like below:
The developers can now compare those variables to what you gave them in the tracking concept. Any deviations can be addressed immediately without any external involvement.
But this might get very cumbersome when every requests needs to be handled individually. To make this more manageable, I quickly put together a tool to streamline the process for our specific usecase.
The Adobe Analytics Mobile SDK Debug Parser
I wanted a way to pretty print multiple lines of debug output, at once, in a flexible way. So I came up with a single page HTML and JS app to do exactly that, you can find it here: https://www.fullstackanalyst.io/analytics_log_parser.html (Link also on top and bottom of this website). And since I am not much of a frontend developer, I put it in a Github Repo to allow contributions of more talented people than myself. Here is a quick rundown on the features:
- Easy Workflow: Just paste all your Analytics Requests in the Textbox and hit the button to get a nice table with all Requests in an understandable way.
- Built for Adobe Analytics: Columns are highlighted according to the variable type (Context Variables vs. SDK Variables vs. Normal Variables).
- Layout options: Columns can be rearranged by drag-and-drop or hidden individually or in Groups.
- Sorting options: Sort rows by clicking the column header.
- Search: Simple search to filter table by keyword.
- Export options: Export the table as CSV, Excel, or PDF, copy it to the clipboard or print it.
- Row highlighting: Highlight single or multiple rows by clicking them (with ctrl or shift for multiple).
Given that this tool is built for myself, I tested it on my machine (Chrome on Windows) to get everything running. If some things don’t work for you, try fixing it and submit a pull request on Github! As always: No guarantees on functionality and availability, use at your own risk!